Getting Started with SAP BTP Kyma Runtime Using the CLI

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 enabledbtp CLI installed (download here)kubectl installed

Step 1: Find Your Subaccount and Kyma Instance

Log in to BTP via CLI and find your subaccount:

Then find your Kyma environment instance:

You should see something like:

Get the details including your kubeconfig URL:

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:

On a trial cluster you’ll see an AWS EC2 worker node:

Step 3: Explore the Kyma Cluster

Namespaces

Key namespaces:

Namespace Purpose

kyma-systemCore Kyma componentsistio-systemService meshdefaultYour workloads

Core Components in kyma-system

Pod Purpose

api-gateway-controller-managerManages APIRule resourcesbtp-manager-controller-managerManages BTP service bindingsistio-controller-managerManages Istio service meshsap-btp-operator-controller-managerProvisions BTP services as Kubernetes resourceswarden-*Image trust validation

Kyma Custom Resources (CRDs)

Key CRDs:

Resource Purpose

APIRuleExpose services externally with auth/routingRateLimitThrottle API trafficBtpOperatorConfigure BTP service operatorKymaTop-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:

Traffic flow:

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 resourcesBTP 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 ServiceBindingSecure an APIRule with JWT authenticationDeploy a Kyma Serverless Function 

​ IntroductionIf 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.PrerequisitesSAP BTP Trial account with Kyma Runtime enabledbtp CLI installed (download here)kubectl installedStep 1: Find Your Subaccount and Kyma InstanceLog in to BTP via CLI and find your subaccount:btp login
btp list accounts/subaccountThen 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 OKGet 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 kubectlDownload 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 nodesOn 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.7Step 3: Explore the Kyma ClusterNamespaceskubectl get namespacesKey namespaces:Namespace Purposekyma-systemCore Kyma componentsistio-systemService meshdefaultYour workloadsCore Components in kyma-systemkubectl get pods -n kyma-systemPod Purposeapi-gateway-controller-managerManages APIRule resourcesbtp-manager-controller-managerManages BTP service bindingsistio-controller-managerManages Istio service meshsap-btp-operator-controller-managerProvisions BTP services as Kubernetes resourceswarden-*Image trust validationKyma Custom Resources (CRDs)kubectl api-resources | grep kymaKey CRDs:Resource PurposeAPIRuleExpose services externally with auth/routingRateLimitThrottle API trafficBtpOperatorConfigure BTP service operatorKymaTop-level Kyma installation resourceStep 4: Understanding an APIRuleThe 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: 80Traffic 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 ObservationsIstio 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 resourcesBTP services bind as Kubernetes Secrets — via ServiceInstance and ServiceBinding resources managed by the SAP BTP OperatorNext StepsBind a BTP service (XSUAA, Destination Service) using ServiceInstance and ServiceBindingSecure an APIRule with JWT authenticationDeploy a Kyma Serverless Function   Read More Technology Blog Posts by Members articles 

#SAP

#SAPTechnologyblog