Introduction
If you often find yourself debugging applications after deployment and jumping into the Azure Portal just to check pod logs (and sometimes not even finding what you need), you’re not alone.
In this article, I’ll walk through a set of essential kubectl commands that I personally use to debug applications during and after deployment in Kubernetes. These commands are simple, powerful, and can save you a lot of time.
Listing Pods
The first step in debugging is usually checking whether your pods are running.
kubectl get pods
To target a specific namespace:
kubectl get pods -n <namespace>
You can also filter pods using labels:
kubectl get pods -l app=my-app -n production
Or quickly search through results:
On Unix-based systems:
kubectl get pods -n production | grep my-app
On Windows (PowerShell):
kubectl get pods -n production | Select-String "my-app"
💡 Tip: To see everything in a namespace:
kubectl get all -n <namespace>
Viewing Logs
Once your pod is running, the next step is checking the application logs:
kubectl logs <pod-name>
Stream logs in real-time:
kubectl logs -f <pod-name>
If your pod has multiple containers:
kubectl logs <pod-name> -c <container-name>
Describing a Pod
Sometimes logs are not enough. You need deeper insight into what Kubernetes is doing behind the scenes.
kubectl describe pod <pod-name> -n <namespace>
This command shows:
- Events (e.g., image pull errors)
- Scheduling issues
- Container state
👉 Always scroll to the bottom — the Events section is gold.
Port Forwarding (Accessing Pods Locally)
If your application is running but not accessible externally, you can map a local port to the pod:
kubectl port-forward <pod-name> 8080:80 -n <namespace>
Now you can access it via:
http://localhost:8080⚠️ Note: Port-forwarding bypasses cluster networking rules. Avoid using it for sensitive services in production unless you understand the implications.
Executing Commands Inside a Pod
Sometimes you need to go inside the container and inspect things manually.
kubectl exec -it <pod-name> -n <namespace> -- sh
Or if Bash is available:
kubectl exec -it <pod-name> -n <namespace> -- /bin/bash
This allows you to:
- Inspect files
- Check environment variables
- Test network connectivity
⚠️ Be careful—you’re interacting directly with a live container.
Common Troubleshooting Flow
When something goes wrong, this is a simple flow I follow:
kubectl get pods
→ Is the pod running?kubectl describe pod
→ Any scheduling or image issues?kubectl logs
→ What is the application saying?kubectl exec
→ Inspect the container manually if needed
Conclusion
Debugging Kubernetes applications doesn’t have to be painful or slow. With a few essential kubectl commands, you can quickly understand what’s happening inside your cluster without relying on external dashboards.
The more you use these commands, the faster and more confident you’ll become when dealing with production issues.