Introduction
If you're learning SAP BTP Kyma Runtime, most tutorials point you straight to the cockpit UI. But understanding the CLI tools — btp and kubectl — gives you a much deeper understanding of what's actually happening under the hood. In this post I'll walk through connecting to a Kyma cluster and exploring its core components purely from the command line.
Prerequisites
- SAP BTP Trial account with Kyma Runtime enabled
btp CLI installed (download here)kubectl installed
Step 1: Find Your Subaccount and Kyma Instance
Log in to BTP via CLI and find your subaccount:
btp login
btp list accounts/subaccount
Then find your Kyma environment instance:
btp list accounts/environment-instance --subaccount <subaccount-id>
You should see something like:
environment name environment id environment type state
<subdomain>-7tn04i0d <environment-id> kyma OK
Get the details including your kubeconfig URL:
btp get accounts/environment-instance <environment-id> --subaccount <subaccount-id>
This returns a labels field containing your KubeconfigURL and APIServerURL.
Step 2: Download the Kubeconfig and Connect kubectl
Download the kubeconfig from the Kyma Dashboard or via the KubeconfigURL, then point kubectl at it:
cp ~/Downloads/kubeconfig.yaml ~/.kube/kyma-config.yaml
export KUBECONFIG=~/.kube/kyma-config.yaml
kubectl get nodes
On a trial cluster you'll see an AWS EC2 worker node:
NAME STATUS ROLES AGE VERSION
<node-name>.ec2.internal Ready worker 7d v1.33.7
Step 3: Explore the Kyma Cluster
Namespaces
Key namespaces:
Namespace Purpose
kyma-system | Core Kyma components |
istio-system | Service mesh |
default | Your workloads |
Core Components in kyma-system
kubectl get pods -n kyma-system
Pod Purpose
api-gateway-controller-manager | Manages APIRule resources |
btp-manager-controller-manager | Manages BTP service bindings |
istio-controller-manager | Manages Istio service mesh |
sap-btp-operator-controller-manager | Provisions BTP services as Kubernetes resources |
warden-* | Image trust validation |
Kyma Custom Resources (CRDs)
kubectl api-resources | grep kyma
Key CRDs:
Resource Purpose
APIRule | Expose services externally with auth/routing |
RateLimit | Throttle API traffic |
BtpOperator | Configure BTP service operator |
Kyma | Top-level Kyma installation resource |
Step 4: Understanding an APIRule
The APIRule is the most important Kyma concept for exposing workloads. Here's what a typical one looks like:
apiVersion: gateway.kyma-project.io/v2
kind: APIRule
spec:
gateway: kyma-system/kyma-gateway
hosts:
- myapp.<cluster-id>.kyma.ondemand.com
rules:
- methods: [GET, POST]
noAuth: true
path: /*
service:
name: myapp
port: 80
Traffic flow:
Internet
→ https://myapp.<cluster-id>.kyma.ondemand.com
→ kyma-gateway (Istio ingress in kyma-system)
→ Service: myapp:80
→ Pod (with Istio sidecar injected automatically)
Note the noAuth: true setting — fine for development but in production you'd replace this with a JWT handler pointing to XSUAA or another identity provider.
Key Observations
- Istio sidecar injection is automatic — any pod in a labelled namespace gets a second container (
2/2 in kubectl get pods) - APIRules replace Ingress in Kyma — don't use standard Kubernetes Ingress resources
- BTP services bind as Kubernetes Secrets — via
ServiceInstance and ServiceBinding resources managed by the SAP BTP Operator
Next Steps
- Bind a BTP service (XSUAA, Destination Service) using
ServiceInstance and ServiceBinding - Secure an APIRule with JWT authentication
- Deploy a Kyma Serverless Function
Bluesky
