Getting Started with SAP BTP Kyma Runtime Using the CLI

[neilaspin]

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

kubectl get 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