Kyma Runtime
SAP BTP's managed Kubernetes environment — container-native, serverless-capable, and ideal for microservices architectures, event-driven applications, and teams embracing cloud-native DevOps.
Executive Summary
Kyma Runtime is SAP's managed Kubernetes (K8s) offering on BTP. Built on Gardener (SAP's Kubernetes-as-a-Service), Kyma adds SAP-specific components: Istio service mesh, NATS-based eventing, Kyma Functions (serverless), and Service Manager for OSBAPI integration. It is the runtime of choice for containerised microservices, event-driven architectures, and teams using Helm and GitOps.
Unlike Cloud Foundry, Kyma gives teams full Kubernetes API access — enabling standard tooling (kubectl, Helm, ArgoCD) while BTP manages the control plane, upgrades, and scaling of the underlying cluster.
Kyma Architecture Concepts
Kyma Function + Event Subscription
1# kyma-function.yaml — Kyma serverless function
2apiVersion: serverless.kyma-project.io/v1alpha2
3kind: Function
4metadata:
5 name: bp-changed-handler
6 namespace: production
7spec:
8 runtime: nodejs18
9 source:
10 inline:
11 source: |
12 const axios = require('axios');
13 module.exports = {
14 main: async function(event, context) {
15 const { data } = event;
16 console.log('BusinessPartner changed:', data.BusinessPartner);
17 // Call CAP service to sync data
18 await axios.post(
19 process.env.CAP_SRV_URL + '/odata/v4/bp-sync/syncPartner',
20 { businessPartner: data.BusinessPartner }
21 );
22 return { status: 'synced' };
23 }
24 };
25---
26# Event subscription — trigger on S/4HANA BusinessPartner.Changed
27apiVersion: eventing.kyma-project.io/v1alpha2
28kind: Subscription
29metadata:
30 name: bp-changed-sub
31 namespace: production
32spec:
33 sink: http://bp-changed-handler.production.svc.cluster.local:80
34 source: sap.s4.beh.businesspartner.v1
35 typeMatching: standard
36 types:
37 - sap.s4.beh.businesspartner.v1.BusinessPartner.Changed.v1Kyma CLI Commands
1# Deploy to Kyma using kubectl
2kubectl apply -f kyma-function.yaml
3
4# Check Kyma function status
5kubectl get functions -n production
6
7# Deploy CAP app as K8s Deployment
8helm upgrade --install my-cap-app ./charts/cap-app \
9 --namespace production \
10 --set image.repository=my-registry/cap-app \
11 --set image.tag=1.0.0
12
13# Access Kyma dashboard
14kubectl proxy &
15open http://localhost:8001/api/v1/namespaces/kyma-system/services/console-web:80/proxy/Enterprise Example: DEWA Smart City Event Platform
Best Practices
Separate namespaces per domain (not per environment — use separate clusters for production) to isolate workloads and apply RBAC cleanly.
Verify Istio sidecar injection is active on all application namespaces. mTLS provides automatic in-cluster encryption with no code changes.
Declare BTP service instances and bindings as K8s CRDs (ServiceInstance / ServiceBinding). Avoid manual secret creation.
Use distroless or alpine base images. Smaller images reduce attack surface, speed up pull times, and lower cluster egress costs.
Set HPA on all production CAP deployments with CPU and memory targets. Define min/max replicas based on expected load patterns.
Common Pitfalls
Security Considerations
Kyma uses Istio for mTLS between services — verify Istio is enabled on all application namespaces. Use K8s RBAC roles (not cluster-admin) for developer access. Store sensitive configuration as K8s Secrets encrypted with KMS. Apply Pod Security Standards (restricted profile) for all production namespaces. Regularly rotate kubeconfig credentials and audit RBAC role bindings quarterly.