Kubernetes interview question · Most asked
What do the common kubectl debugging commands tell you?
Summary
kubectl get (status), describe (configuration and events), logs (--previous, -f, -c container), exec (shell into a running container), debug (ephemeral debug container or a copy of a pod or node), top (resource usage from metrics-server), get events --sort-by=.lastTimestamp, rollout status/history/undo, and port-forward for direct access.
Longer Answer
Useful habits: start from events and status conditions, use -o yaml to see the full object including status, kubectl auth can-i for permission problems, and kubectl get endpointslices -l kubernetes.io/service-name=<svc> when a Service routes nowhere (usually a selector mismatch or no ready pods). Minimal images often lack a shell, which is exactly what kubectl debug with a tooling image solves.
Key Points
- get, describe, logs, events first.
- exec / debug for inspection.
- top for usage; rollout for deploys.
- Empty endpoints = selector or readiness issue.
More most-asked Kubernetes questions
- ConfigMaps and Secrets: how do they differ, and how should secrets really be handled?
- How does the scheduler place pods? Explain resource requests, node affinity, taints and tolerations.
- Describe the Kubernetes architecture: what runs on the control plane and what runs on the nodes?
- How do rolling updates work in a Deployment, and how do you roll back?
- Explain the Service types: ClusterIP, NodePort, LoadBalancer, ExternalName and headless.
- What happens, step by step, when you run kubectl apply for a Deployment?
- Deployment, StatefulSet, DaemonSet, Job and CronJob: when do you use each?
- What is the difference between resource requests and limits, and what are the QoS classes?