Getting Started with SAP BTP Kyma Runtime Using the CLI

[[{“value”:”

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

Core Components in kyma-system

kubectl get pods -n kyma-system

Pod Purpose

Kyma Custom Resources (CRDs)

kubectl api-resources | grep kyma

Key CRDs:

Resource Purpose

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

“}]] 

  Read More Technology Blog Posts by Members articles 

#abap