[[{“value”:”
Troubleshooting applications running in Kubernetes often requires switching between tools, creating temporary resources, and preparing the environment before you can even start investigating the actual problem.
If you’ve worked with Kubernetes applications, you’ve probably encountered situations where you needed to verify connectivity, inspect service configuration, or debug networking issues between workloads.
A common workflow is to create a temporary Pod, install debugging tools, and only then start investigating the issue. While this approach works, it adds extra steps before troubleshooting can begin.
With the new Terminal feature, you can execute commands directly from within the cluster and focus on solving the problem instead of preparing the environment.
A Practical Example
Let’s walk through a common troubleshooting scenario in Kubernetes: a Service that appears to be running correctly but is not reachable.
We’ll deploy a simple Pod and Service, use the built-in Terminal to verify connectivity, identify the root cause, and validate the fix directly from Kyma dashboard.
Step 1: Create Test Resources
In Kyma dashboard, choose Upload YAML and apply the following configuration:
apiVersion: v1
kind: Namespace
metadata:
name: my-test-env
---
apiVersion: v1
kind: Pod
metadata:
namespace: my-test-env
name: nginx
labels:
app.kubernetes.io/name: my-api
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: my-service
namespace: my-test-env
spec:
selector:
app.kubernetes.io/name: my-nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
a namespace called
my-test-env- an nginx Pod
- a Service intended to expose the Pod
Open the command palette: (macOS:
Cmd + K, Windows/Linux: Ctrl + K), type ns/my-test-env, and press Enter.To navigate to your nginx Pod open the command palette and type
pods/nginx. Press Enter.If the Pod status shows Running, your application is up.
Step 3: Verify Pod Connectivity
From the Pod details page, note the Pod IP address shown in the Status card.
Open the Terminal and run:
curl -I ${YOUR_POD_IP}
HTTP/1.1 200 OK.This confirms that the Pod itself is reachable and serving requests.
Step 4: Test the Service
Now let’s verify whether the Service is correctly configured.
Open the command palette and navigate to svc/my-service
You can call Kubernetes Services either through their ClusterIP or their DNS name. For real applications, it’s recommended to use the DNS name, and this is how we proceed in this example.
Open the Terminal and execute:
curl -I my-service.my-test-env.svc.cluster.local
At first glance, this might look like a networking problem. However, the Pod itself was reachable in the previous step. Thanks to the built-in Terminal, we were able to quickly verify Pod connectivity and narrow the scope of the problem to the communication between the Service and its target Pods.
Finding the Root Cause
Looking closer at the Service configuration, the issue becomes clear.
The Pod has the label:
app.kubernetes.io/name: my-api
app.kubernetes.io/name: my-nginx
This is a common Kubernetes misconfiguration and a perfect example of a problem that’s easy to diagnose from the built-in Terminal.
Fixing the Service
- Upload the updated YAML from the Cluster Overview page.
apiVersion: v1
kind: Service
metadata:
name: my-service
namespace: my-test-env
spec:
selector:
app.kubernetes.io/name: my-api
ports:
- protocol: TCP
port: 80
targetPort: 80
curl -I my-service.my-test-env.svc.cluster.local
HTTP/1.1 200 OK response.
The Service can now successfully route traffic to the Pod.
Faster Troubleshooting Out of the Box
This simple example demonstrates the value of the new Terminal feature. With a single click, you gain access to a browser-based terminal connected directly to your cluster. There’s no need to create temporary Pods or install utilities manually. You can immediately start investigating problems and validating fixes.
Try It Out
The Terminal feature is designed to make troubleshooting faster, more convenient, and more accessible directly from Kyma dashboard.
Give it a try and let us know what you think. We’d love to hear how you’re using the Terminal and which troubleshooting scenarios it helps you solve. Feel free to share your feedback or create an issue in the Busola repository.
And if you’d like to stay up to date with the latest Kyma features and releases, make sure to subscribe to the What’s New page.
“}]]
[[{“value”:”Troubleshoot Your Cluster Directly from Kyma Dashboard with TerminalTroubleshooting applications running in Kubernetes often requires switching between tools, creating temporary resources, and preparing the environment before you can even start investigating the actual problem. To simplify this experience, Kyma dashboard (Busola) will introduce a new Terminal feature on October 6, 2026. It will provide direct, browser-based access to your cluster and include common troubleshooting tools such as curl, jq, and yq, allowing you to start debugging immediately without creating temporary workloads or installing additional utilities. Why We Built ItIf you’ve worked with Kubernetes applications, you’ve probably encountered situations where you needed to verify connectivity, inspect service configuration, or debug networking issues between workloads.A common workflow is to create a temporary Pod, install debugging tools, and only then start investigating the issue. While this approach works, it adds extra steps before troubleshooting can begin.With the new Terminal feature, you can execute commands directly from within the cluster and focus on solving the problem instead of preparing the environment.A Practical ExampleLet’s walk through a common troubleshooting scenario in Kubernetes: a Service that appears to be running correctly but is not reachable.We’ll deploy a simple Pod and Service, use the built-in Terminal to verify connectivity, identify the root cause, and validate the fix directly from Kyma dashboard.Step 1: Create Test ResourcesIn Kyma dashboard, choose Upload YAML and apply the following configuration:apiVersion: v1
kind: Namespace
metadata:
name: my-test-env
—
apiVersion: v1
kind: Pod
metadata:
namespace: my-test-env
name: nginx
labels:
app.kubernetes.io/name: my-api
spec:
containers:
– name: nginx
image: nginx
ports:
– containerPort: 80
—
apiVersion: v1
kind: Service
metadata:
name: my-service
namespace: my-test-env
spec:
selector:
app.kubernetes.io/name: my-nginx
ports:
– protocol: TCP
port: 80
targetPort: 80This creates:a namespace calledmy-test-envan nginx Poda Service intended to expose the Pod Step 2: Navigate to the Namespace and Check the Pod StatusOpen the command palette: (macOS: Cmd + K, Windows/Linux: Ctrl + K), type ns/my-test-env, and press Enter.To navigate to your nginx Pod open the command palette and type pods/nginx. Press Enter.If the Pod status shows Running, your application is up.Step 3: Verify Pod ConnectivityFrom the Pod details page, note the Pod IP address shown in the Status card.Open the Terminal and run:curl -I ${YOUR_POD_IP}You should receive a response containing HTTP/1.1 200 OK.This confirms that the Pod itself is reachable and serving requests.Step 4: Test the ServiceNow let’s verify whether the Service is correctly configured.Open the command palette and navigate to svc/my-serviceYou can call Kubernetes Services either through their ClusterIP or their DNS name. For real applications, it’s recommended to use the DNS name, and this is how we proceed in this example.Open the Terminal and execute:curl -I my-service.my-test-env.svc.cluster.localInstead of a successful response, you’ll receive a connection error.At first glance, this might look like a networking problem. However, the Pod itself was reachable in the previous step. Thanks to the built-in Terminal, we were able to quickly verify Pod connectivity and narrow the scope of the problem to the communication between the Service and its target Pods.Finding the Root CauseLooking closer at the Service configuration, the issue becomes clear.The Pod has the label:app.kubernetes.io/name: my-apiBut the Service selector expects:app.kubernetes.io/name: my-nginxBecause the labels don’t match, the Service cannot find any target Pods and therefore has no endpoints available.This is a common Kubernetes misconfiguration and a perfect example of a problem that’s easy to diagnose from the built-in Terminal.Fixing the ServiceUpload the updated YAML from the Cluster Overview page.apiVersion: v1
kind: Service
metadata:
name: my-service
namespace: my-test-env
spec:
selector:
app.kubernetes.io/name: my-api
ports:
– protocol: TCP
port: 80
targetPort: 802. Once the Service is updated, return to the Terminal and run: curl -I my-service.my-test-env.svc.cluster.localThis time, you should receive an HTTP/1.1 200 OK response.The Service can now successfully route traffic to the Pod.Faster Troubleshooting Out of the BoxThis simple example demonstrates the value of the new Terminal feature. With a single click, you gain access to a browser-based terminal connected directly to your cluster. There’s no need to create temporary Pods or install utilities manually. You can immediately start investigating problems and validating fixes.Try It OutThe Terminal feature is designed to make troubleshooting faster, more convenient, and more accessible directly from Kyma dashboard.Give it a try and let us know what you think. We’d love to hear how you’re using the Terminal and which troubleshooting scenarios it helps you solve. Feel free to share your feedback or create an issue in the Busola repository.And if you’d like to stay up to date with the latest Kyma features and releases, make sure to subscribe to the What’s New page.”}]] Read More Technology Blog Posts by SAP articles
#SAPCHANNEL