Kubernetes Container Orchestration Pod Management 2 — Questions and Answers
Question 1: What happens to a Pod when its node is drained using `kubectl drain`?
- The Pod is deleted permanently
- The Pod is evicted and rescheduled on another node if managed by a controller (Correct answer)
- The Pod enters a Pending state on the same node
- The Pod is paused until the node is uncordoned
Correct answer: The Pod is evicted and rescheduled on another node if managed by a controller
kubectl drain evicts Pods from the node; Pods managed by controllers like Deployments are rescheduled elsewhere, while standalone Pods are deleted.
Question 2: Which field in a Pod spec controls how many times Kubernetes restarts a failed container before giving up?
- spec.maxRetries
- spec.restartPolicy (Correct answer)
- spec.backoffLimit
- spec.terminationGracePeriodSeconds
Correct answer: spec.restartPolicy
spec.restartPolicy (Always, OnFailure, Never) controls container restart behavior; the kubelet applies exponential backoff between restarts.
Question 3: A Pod is in the `Terminating` state for a long time. What is the most likely cause?
- The Pod has no resource limits set
- A finalizer is blocking deletion or the container is ignoring SIGTERM (Correct answer)
- The node has insufficient CPU
- The Pod's image cannot be pulled
Correct answer: A finalizer is blocking deletion or the container is ignoring SIGTERM
A stuck Terminating state is typically caused by a finalizer that has not been removed or a container that does not handle SIGTERM within the grace period.
Question 4: What is the purpose of `spec.terminationGracePeriodSeconds` in a Pod spec?
- Sets the maximum runtime for the Pod
- Defines how long Kubernetes waits after sending SIGTERM before sending SIGKILL (Correct answer)
- Controls how quickly a Pod is rescheduled after node failure
- Sets the timeout for liveness probe failures
Correct answer: Defines how long Kubernetes waits after sending SIGTERM before sending SIGKILL
terminationGracePeriodSeconds gives a container time to shut down gracefully after receiving SIGTERM before Kubernetes forcefully kills it with SIGKILL.
Question 5: Which command shows the logs of a previously terminated container in a Pod?
- kubectl logs <pod> --all
- kubectl logs <pod> --previous (Correct answer)
- kubectl logs <pod> --history
- kubectl describe pod <pod>
Correct answer: kubectl logs <pod> --previous
The --previous flag retrieves logs from the last terminated instance of a container, useful for debugging crash loops.
Question 6: What does a Pod's `QoS class` of `BestEffort` indicate?
- The Pod has equal resource requests and limits
- The Pod has no resource requests or limits set (Correct answer)
- The Pod has resource limits but no requests
- The Pod is scheduled on nodes with guaranteed capacity
Correct answer: The Pod has no resource requests or limits set
BestEffort QoS is assigned when a Pod has no resource requests or limits defined, making it the first evicted under memory pressure.
Question 7: How can you run a temporary Pod for debugging purposes and have it automatically deleted when you exit?
- kubectl create pod debug --image=busybox --restart=Never
- kubectl run debug --image=busybox --rm -it --restart=Never -- sh (Correct answer)
- kubectl exec -it --image=busybox -- sh
- kubectl debug node --image=busybox
Correct answer: kubectl run debug --image=busybox --rm -it --restart=Never -- sh
The --rm flag combined with -it and --restart=Never creates an ephemeral interactive Pod that is automatically deleted upon exit.
What happens to a Pod when its node is drained using `kubectl drain`?