EKS Troubleshooting

1. The “Big 3” Diagnostic Workflow When a Pod is failing, you must follow this 1-2-3 sequence to find the root cause:

1. kubectl get pods: Shows the high-level status (e.g., ImagePullBackOff).
2. kubectl describe pod <name>: The “Medical Chart.” It shows Events at the bottom. This tells you if the problem is at the Kubernetes level (e.g., “Failed to mount volume” or “Insufficent CPU”).
3. kubectl logs <name>: The “Inside Story.” If the events look fine but the Pod is crashing, the error is inside your code (e.g., “Database connection failed”).
   • Pro Tip: Use kubectl logs --previous to see why the last instance of a crashing pod died.

2. Modern Debugging: Ephemeral Containers In the old days, if a container crashed or was “distroless” (had no shell), you couldn’t get inside to fix it. In 2026, we use Ephemeral Containers via kubectl debug. This allows you to “inject” a temporary container with all your favorite tools (curl, nslookup, vim) into a running Pod without restarting it. It’s like a mechanic sliding under a moving car to fix the engine.

3. K9s: The Terminal Dashboard While kubectl is powerful, it is slow for real-time troubleshooting. K9s is a terminal-based UI that lets you navigate your cluster using keyboard shortcuts. You can view logs, scale deployments, and shell into pods in seconds. It is the “Swiss Army Knife” of every 2026 DevSecOps engineer.