CKA — Key Debugging Commands

8 minute read

CKA Exam Domain

Domain Weight
Troubleshooting 30%

This page is your one-stop reference for every command you need for troubleshooting on the CKA exam. Bookmark it, practice every command, and know them by heart before exam day.

kubectl Commands

Pod Debugging

# List all Pods across all namespaces with node and IP info
kubectl get pods -A -o wide

# Describe a Pod — shows events, conditions, volumes, everything
kubectl describe pod <pod> -n <namespace>

# Application logs
kubectl logs <pod> -n <namespace>

# Logs from the PREVIOUS crashed container (critical for CrashLoopBackOff!)
kubectl logs <pod> -n <namespace> --previous

# Logs from a specific container in a multi-container Pod
kubectl logs <pod> -n <namespace> -c <container>

# Stream logs in real-time
kubectl logs <pod> -n <namespace> -f

# Last 100 lines of logs
kubectl logs <pod> -n <namespace> --tail=100

# Logs since a specific duration
kubectl logs <pod> -n <namespace> --since=5m

# Execute into a running container
kubectl exec -it <pod> -n <namespace> -- /bin/sh

# Execute a one-off command
kubectl exec <pod> -n <namespace> -- cat /etc/config/app.yaml

# Debug a node (creates a privileged debugging Pod on the node)
kubectl debug node/<node-name> -it --image=ubuntu

Cluster Information

# Cluster health overview
kubectl cluster-info

# Check component statuses (deprecated but may still appear on exam)
kubectl get componentstatuses

# List all nodes with details
kubectl get nodes -o wide

# Resource usage for nodes
kubectl top nodes

# Resource usage for Pods
kubectl top pods -A
kubectl top pods --sort-by=memory -A
kubectl top pods --sort-by=cpu -A

Events

Events are the single most useful debugging resource in Kubernetes:

# All events, sorted by time (most recent last)
kubectl get events -A --sort-by=.metadata.creationTimestamp

# Only warning events
kubectl get events --field-selector type=Warning

# Events for a specific Pod
kubectl get events --field-selector involvedObject.name=<pod-name>

# Events for a specific node
kubectl get events --field-selector involvedObject.kind=Node,involvedObject.name=<node-name>

# Events in a specific namespace
kubectl get events -n <namespace> --sort-by=.metadata.creationTimestamp

Exam Tip: When you’re stuck, kubectl get events --sort-by=.metadata.creationTimestamp is your best friend. It shows you everything that happened in chronological order.

Resource Inspection

# Get a resource in YAML format (great for seeing full spec)
kubectl get pod <pod> -o yaml
kubectl get deployment <deploy> -o yaml

# Check labels on resources
kubectl get pods --show-labels
kubectl get nodes --show-labels

# Check taints on nodes
kubectl describe nodes | grep -A 3 "Taints:"

# Check resource quotas and limits
kubectl get resourcequotas -A
kubectl get limitranges -A

journalctl Commands

For debugging system services on nodes (kubelet, containerd):

# Follow kubelet logs in real-time
journalctl -u kubelet -f

# Kubelet logs from the last 10 minutes
journalctl -u kubelet --since "10 minutes ago"

# Kubelet logs from a specific time range
journalctl -u kubelet --since "2025-02-09 12:00" --until "2025-02-09 12:30"

# Kubelet error logs only
journalctl -u kubelet -p err

# Last 50 lines of kubelet logs
journalctl -u kubelet --no-pager | tail -50

# Follow containerd logs
journalctl -u containerd -f

# Containerd logs from the last 5 minutes
journalctl -u containerd --since "5 minutes ago"

Exam Tip: You’ll need journalctl when kubectl can’t reach the cluster (API server or kubelet down). SSH to the node and use journalctl -u kubelet to find out what’s wrong.

crictl Commands

crictl talks directly to the container runtime — use it when kubectl is down:

# List running containers
crictl ps

# List ALL containers (including stopped/exited)
crictl ps -a

# Container logs
crictl logs <container-id>

# Follow container logs
crictl logs -f <container-id>

# Detailed container info
crictl inspect <container-id>

# List container images
crictl images

# Remove unused images
crictl rmi --prune

# Runtime info
crictl info

# List Pods (at the sandbox level)
crictl pods

# Filter by name
crictl ps --name=apiserver
crictl pods --name=etcd

When to Use crictl vs kubectl

Scenario Use
Everything working normally kubectl
API server down crictl
kubelet down (need to check why) journalctl -u kubelet
Need to inspect a static Pod that won’t start crictl ps -a + crictl logs
Container runtime issues crictl info

Network Debugging

# List listening TCP ports
ss -tlnp

# List listening UDP ports
ss -ulnp

# All active connections
ss -tunap

# Network interfaces and IPs
ip addr show

# Routing table
ip route

# DNS resolution
nslookup <service-name>
nslookup kubernetes.default.svc.cluster.local

# More detailed DNS info
dig <service-name>

# HTTP request
curl -s http://<ip>:<port>
curl -s -o /dev/null -w "%{http_code}" http://<ip>:<port>

# TCP port check
nc -zv <ip> <port>

# Ping
ping -c 3 <ip>

# Trace route
traceroute <ip>

# iptables rules (for Service routing debugging)
iptables -t nat -L KUBE-SERVICES | head -20
iptables -t nat -L KUBE-NODEPORTS

System Commands

# Check service status
systemctl status kubelet
systemctl status containerd

# Start/stop/restart services
systemctl start kubelet
systemctl stop kubelet
systemctl restart kubelet

# Enable service to start on boot
systemctl enable kubelet

# Reload systemd after changing unit files
systemctl daemon-reload

# Check disk usage
df -h

# Check memory usage
free -h

# Check CPU and memory by process
top
# (press M for memory sort, P for CPU sort, q to quit)

# Check number of processes
ps aux | wc -l

# Find large files
du -sh /var/log/*
find / -type f -size +100M 2>/dev/null

Troubleshooting Decision Tree

Use this flowchart when you’re not sure where to start:

Problem Reported
│
├── Can kubectl reach the API server?
│   │
│   ├── NO → SSH to control plane node
│   │   ├── crictl ps -a | grep apiserver
│   │   ├── crictl logs <apiserver-id>
│   │   ├── Check /etc/kubernetes/manifests/kube-apiserver.yaml
│   │   └── Fix manifest → kubelet auto-restarts
│   │
│   └── YES → Is the node Ready?
│       │
│       ├── NO → kubectl describe node <node>
│       │   ├── Check Conditions (Memory/Disk/PID Pressure)
│       │   ├── SSH to node
│       │   ├── systemctl status kubelet
│       │   ├── journalctl -u kubelet
│       │   ├── systemctl status containerd
│       │   └── Fix kubelet/containerd → systemctl restart
│       │
│       └── YES → Is the Pod running?
│           │
│           ├── Pending → kubectl describe pod
│           │   ├── FailedScheduling: resources → reduce requests or add nodes
│           │   ├── FailedScheduling: taints → add toleration or remove taint
│           │   ├── FailedScheduling: nodeSelector → fix labels
│           │   └── PVC not bound → create PV or fix StorageClass
│           │
│           ├── CrashLoopBackOff → kubectl logs --previous
│           │   ├── Wrong command → fix command/args
│           │   ├── Missing config → create ConfigMap/Secret
│           │   └── Application error → fix the app
│           │
│           ├── ImagePullBackOff → kubectl describe pod (Events)
│           │   ├── Wrong image name/tag → fix image
│           │   └── Private registry → create imagePullSecret
│           │
│           ├── Running but not working → 
│           │   ├── kubectl logs (check for errors)
│           │   ├── kubectl exec -- curl localhost:<port>
│           │   ├── Check Service → kubectl get endpoints
│           │   ├── Check DNS → nslookup from Pod
│           │   └── Check NetworkPolicy → kubectl get netpol
│           │
│           └── ContainerCreating (stuck) →
│               ├── CNI issue → check CNI plugin Pods
│               ├── Volume issue → check PVC/PV
│               └── Image pulling (slow) → check image size/registry

Quick Reference Card

What’s Wrong First Command Second Command
Pod not running kubectl describe pod <pod> kubectl logs <pod> --previous
Node NotReady kubectl describe node <node> SSH → systemctl status kubelet
API server down crictl ps -a \| grep apiserver crictl logs <id>
Scheduler broken kubectl logs -n kube-system kube-scheduler-* Check /etc/kubernetes/manifests/
DNS not working kubectl get pods -n kube-system -l k8s-app=kube-dns kubectl logs -n kube-system -l k8s-app=kube-dns
Service no endpoints kubectl get endpoints <svc> kubectl describe svc <svc>
NetworkPolicy blocking kubectl get netpol -n <ns> kubectl describe netpol <name>

Practice Questions

Q1. A cluster has multiple issues but you don’t know where to start. What’s your systematic approach?

Show Answer 
# Step 1: Can you reach the API server?
kubectl cluster-info

# Step 2: Check all nodes
kubectl get nodes

# Step 3: Check all Pods across namespaces
kubectl get pods -A

# Step 4: Check kube-system Pods specifically
kubectl get pods -n kube-system

# Step 5: Check recent events
kubectl get events -A --sort-by=.metadata.creationTimestamp | tail -20

# Step 6: Based on what you find, drill down using the decision tree

Follow the decision tree above — start broad, then narrow down.

Q2. You need to debug a Pod but kubectl exec fails. What alternatives do you have?

Show Answer 
# Option 1: kubectl debug (ephemeral debug container)
kubectl debug <pod> -it --image=busybox -- /bin/sh

# Option 2: kubectl debug with copy (creates a copy of the Pod)
kubectl debug <pod> -it --image=busybox --copy-to=debug-pod -- /bin/sh

# Option 3: Check logs instead
kubectl logs <pod>
kubectl logs <pod> --previous

# Option 4: If on the node, use crictl
crictl ps | grep <pod-name>
crictl logs <container-id>
crictl exec -it <container-id> /bin/sh

Q3. How do you check the health of ALL control plane components at once?

Show Answer 
# Check all kube-system Pods
kubectl get pods -n kube-system

# Check specific components
kubectl get pods -n kube-system -l tier=control-plane

# Check component statuses (deprecated but quick)
kubectl get cs

# Check cluster info
kubectl cluster-info

# On the control plane node, check all manifests
ls /etc/kubernetes/manifests/
crictl ps | grep -E "apiserver|etcd|scheduler|controller"

Q4. A worker node has a failing kubelet. The logs show “failed to load kubelet config file /var/lib/kubelet/config.yaml”. Fix it.

Show Answer 
# Step 1: SSH to the node
ssh <node>

# Step 2: Check if the config file exists
ls -la /var/lib/kubelet/config.yaml

# If it doesn't exist, check where kubelet is looking:
systemctl cat kubelet | grep config
# Or:
ps aux | grep kubelet | grep config

# Step 3: If the file path is wrong in the kubelet service:
# Edit the kubelet service drop-in
vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
# Fix the --config flag path

# Step 4: Reload and restart
systemctl daemon-reload
systemctl restart kubelet

# Step 5: Verify
systemctl status kubelet

Q5. What’s the difference between kubectl logs, crictl logs, and journalctl? When should you use each?

Show Answer
Tool Use When What It Shows
kubectl logs <pod> kubectl is working, Pod exists Application stdout/stderr
crictl logs <container-id> kubectl is down (API server/kubelet broken) Container stdout/stderr from runtime
journalctl -u kubelet Node-level service debugging kubelet system service logs
journalctl -u containerd Container runtime issues containerd system service logs

Rule of thumb:

  • Start with kubectl logs for Pod issues
  • Use crictl logs when kubectl is broken
  • Use journalctl for node services (kubelet, containerd)

What’s Next

You now have a complete toolkit for Kubernetes troubleshooting. It’s time to put it all into practice with hands-on lab scenarios that simulate real CKA exam questions.

Next: Troubleshooting Lab →

Updated:

You may also enjoy