How to Debug Code in Kubernetes Pods

I use this simple 3-step logs flow that helps me debug almost anything in Kubernetes under 30 minutes. 𝗦𝘁𝗲𝗽 1 → kubectl logs <pod> Ask: “Did the app fail inside the container?” If the pod is up, this is your first stop. Look for stack traces, startup errors, misconfigs. But if logs show nothing (or the pod never started), move on fast. 𝗦𝘁𝗲𝗽 2 → kubectl describe pod <pod> Ask: “Did Kubernetes kill the pod?” This one’s underrated. It shows you probe failures, CrashLoops, image pull issues, and mount errors. Basically, if K8s is mad at your pod, this will tell you why. 𝗦𝘁𝗲𝗽 3 → kubectl get events --sort-by=.metadata.creationTimestamp Ask: “What else is breaking in the cluster?” This is your timeline. It shows broader issues: node pressure, CNI problems, preemptions. If the problem isn’t in logs or describe, this one usually holds the clue. This is the exact flow we use inside incident war rooms. ➤ If the pod is running → check logs. ➤ If it’s crashing or pending → check describe. ➤ If you’re still lost → check events. Don’t waste 45 minutes staring at Grafana hoping something makes sense. Start with the logs. Ask better questions. Fix faster. I built a 1-page cheatsheet of this debugging flow. It’s part of our SRE onboarding at Infra360. Want it? Drop a “LOGS” in the comments and I’ll send it to you.

#DAY112 I’m back from vacation and will resume regular posting! #Advanced Kubernetes Commands Every Expert Should Know: Debugging, Dry Runs, and More! 1. Dry Run for Resource Validation A dry run is essential for validating YAML files and configurations before applying them to your cluster. kubectl apply -f mydeployment.yaml --dry-run=client What it does: Simulates resource creation locally and flags potential issues without making any changes. 2. Debugging Pods on the Fly If a pod or container fails, kubectl debug lets you create a temporary debugging container within your pod for troubleshooting. kubectl debug -it mypod --image=busybox --target=containerName What it does: Starts a debugging session inside the pod using a different image, without interrupting the application. It's great for inspecting logs, files, or running isolated commands. 3. Quickly Editing Resources with kubectl edit Rather than editing YAML files manually, kubectl edit allows you to make live changes directly from the command line. kubectl edit deployment mydeployment What it does: Opens the resource configuration in your default editor (e.g., vim or nano) for quick editing. 4. Rolling Back Deployments To quickly revert to a previous version after a failed deployment: kubectl rollout undo deployment/mydeployment What it does: Rolls back to the last successful deployment, minimizing downtime. 5. Tail Logs from a Specific Pod Container When debugging, it’s crucial to view logs from the container causing issues. Instead of filtering through multiple containers, target the specific one. kubectl logs -f mypod -c mycontainer What it does: Streams logs from a specific container inside the pod for easier debugging. 6. Setting Resource Limits on the Fly Use kubectl set resources to adjust resource limits for a running pod, helpful for debugging resource constraints. kubectl set resources deployment mydeployment --limits=cpu=500m,memory=256Mi What it does: Sets CPU and memory limits for your deployment to see how it performs under different resource conditions. 7. Get Pod Events to Track Down Issues Events give you insights into what’s happening behind the scenes. Use kubectl get events to track issues like scheduling problems or failed probes. kubectl get events --field-selector involvedObject.name=mypod What it does: Filters events related to a specific pod, helping to identify problems. Pro Tip: Combine kubectl describe with kubectl get events for more thorough troubleshooting insights. TL;DR: These Kubernetes commands are essential for experts who want to: Simulate and validate changes Debug containers quickly Edit live resources Roll back deployments Gather logs and events for precise troubleshooting Master these commands to optimize your Kubernetes operations! 🌟 #Kubernetes #DevOps #Cloud #K8S #AdvancedCommands #CloudNative #Debugging #DryRun #DevOpsTools #KubernetesTips

🔎 Pro-tip: “kubectl debug” is a Swiss-army knife for investigations. My favorite trick: run pgbench inside the same Pod as Postgres. It eliminates all network noise from the test. A few other tricks I keep coming back to: 👉 Instant toolbox: Attach a container with gdb, strace, or tcpdump without modifying your image: kubectl debug mypod --image=busybox -c dbg 👉 CrashLoop investigation: Clone the pod with the same env and volume mounts, but start a shell instead of the crashing process: kubectl debug mypod --copy-to shell --share-processes -it -- bash 👉 Safe canary rollout: Create a new pod with a different image but same configs, secrets, and resources: kubectl debug mypod --copy-to api-next --image=ghcr.io/acme/api:1.4.0 📌 Notes: Ephemeral containers are GA since Kubernetes 1.25 --copy-to creates a brand-new pod Debug pods skip your normal lifecycle hooks, so clean up after yourself