This table explains basic concepts relating to the Kyma environment. It aims to give you an understanding of the Kyma environment before you actually start using it to build extensions for your SAP solutions.
For an overview of the basic Kubernetes concepts that the Kyma environment heavily relies on, see the official Kubernetes documentation.
|
Concept |
Description |
|---|---|
|
Kyma cluster |
A Kubernetes cluster provisioned with the latest version of the open-source project "Kyma". You can enable such a cluster on a given subaccount through the SAP BTP cockpit. After creating a Kyma environment instance on your subaccount, the cluster is provisioned automatically through Gardener on your chosen cloud service provider. To access the cluster, you must have appropriate roles assigned to your subaccount. |
|
Kyma module |
An extension to the Kyma environment that can be added, deleted, or re-configured at runtime. |
|
Role |
Access to every cluster is managed by the roles assigned. Roles give the assigned users a different level of permissions suitable for different purposes. For more information, read Assign Roles in the Kyma Environment. |
|
Namespace |
Namespaces are used to organize objects in a cluster and provide a way to divide cluster resources. This way, several users can share a cluster but have access only to resources within the namespace they have permissions for. This allows for increasing the security and organization of your cluster by dividing it into smaller units. Access to namespaces in the Kyma environment depends on your Kubernetes RBAC permissions. |
|
Service operator |
A service operator is a piece of software that provides a set of all necessary resources (such as CustomResourceDefinitions and controllers) needed to provision third-party services in your Kubernetes cluster. |
|
Binding |
The connection you create between a service instance and an SAP solution so that they can communicate with each other. You can also bind a service instance to any workload running in the Kyma environment, such as a Function or a microservice. |
|
CustomResourceDefinition (CRD) |
A Kubernetes API resource that allows you to define and manage custom resources (CRs), enabling the extension of Kubernetes API to cover additional use cases. |
|
Custom resource (CR) |
An object that extends the Kubernetes API and is defined by a CustomResourceDefintion (CRD), allowing for the management of use cases that are not directly covered by core Kubernetes. |
|
Credentials / Secrets |
Sensitive data necessary for an SAP solution to call the service, connect to it, and authenticate it. Depending on whether you use Kyma dashboard or kubectl to create the binding between a service instance and an SAP solution, the Kubernetes Secret object that contains these credentials is either created automatically or you need to create it manually. |
|
Function |
A simple code snippet that you can run without provisioning or managing servers. It implements the exact business logic you define. A Function is based on the Function custom resource and can be written in either Node.js or Python. A Function can perform a business logic of its own. You can also bind it to an instance of a service and configure it to be triggered whenever it receives a particular event type from the service or a call is made to the service's API. Functions are executed only if they are triggered by an event or an API call. |
|
Microservice |
An architectural variant for extensions or applications, where you separate the tasks into smaller pieces that interact with each other as loosely coupled, independently deployable units of code. A failing microservice should not cause your whole application to fail. Microservices are packed in a container that is always running; it's idling if there is no load. The microservice should always be reachable even when the Pods move around. Microservices typically communicate through APIs. |