Task 2.3: Troubleshooting

• Akubectl get pod <pod> -o wide

  Incorrect

  This shows the node and Pod IP; it shows no container output.

• Bkubectl top pod <pod>

  Incorrect

  top shows current CPU and memory figures, not logs.

• Ckubectl rollout status deployment/<name>

  Incorrect

  rollout status reports progress of a rollout; it does not show why a container exits.

• Dkubectl logs <pod> --previous

  Correct

  The --previous flag prints the logs of the previous, terminated instance of the container, which holds the output from before the crash.

For a crash loop, read the logs of the previous instance with --previous: the new container has not yet printed what explains the crash.

• AWhether the container's memory limit is high enough for the image

  Incorrect

  Memory limits matter once a container runs. This Pod has not pulled its image yet.

• BWhether the image name and the tag 2.4.1 exist in the registry

  Correct

  The most common cause of a waiting Pod is a failed image pull; check the name, check that the image was pushed, and try to pull it manually.

• CWhether the Pod has a readiness probe

  Incorrect

  Readiness decides whether a running Pod gets traffic. It plays no part before the image is pulled.

• DWhether the node has been cordoned

  Incorrect

  A cordon affects scheduling of new Pods. This Pod is already on a node and fails at the pull.

ImagePullBackOff means the kubelet keeps failing to pull the image and backs off between tries; a missing tag or name is the classic cause.

• AThe Pods have no liveness probe, so the kubelet never checks them

  Incorrect

  Without a liveness probe the kubelet never restarts a Pod for being unhealthy; it does not remove Ready Pods from a Service.

• BThe Service type is ClusterIP rather than LoadBalancer

  Incorrect

  Endpoints are tracked the same way for every selector-based Service type.

• CThe Service's spec.selector does not match the labels on the Pods

  Correct

  The EndpointSlice controller adds only Pods that the Service's selector matches; a typo or different label leaves the Service with no endpoints.

• DCoreDNS has not yet cached the Service name for the cluster domain

  Incorrect

  DNS resolves the Service name to its address; an empty endpoint list is about Pod selection, not name lookup.

When a Service has no endpoints but its Pods are healthy, compare the Service selector with the Pod labels.

• ANo PersistentVolume or StorageClass can satisfy the claim

  Correct

  A claim remains unbound until a matching volume exists or a StorageClass provisions one; until then the Pod cannot be scheduled.

• BThe scheduler has stopped running on the control plane

  Incorrect

  A stopped scheduler would leave Pods Pending without events about claims; this event names the unbound claim.

• CThe Pod requests more CPU than any node has free

  Incorrect

  That gives an Insufficient cpu event. The event here names the claim.

• DThe container image has not yet been pulled to any of the nodes

  Incorrect

  Images are pulled after the Pod is bound to a node; here scheduling itself is blocked by the unbound claim.

Pending plus an unbound claim points at storage: check the claim's storageClassName, size and access mode against what the cluster can provide.

• ALook for a warning about the field in the Pod's events

  Incorrect

  The misspelled key was ignored when the object was created, so the stored Pod simply lacks it and no event records the mistake.

• BRead the container's output with kubectl logs

  Incorrect

  The logs show what the image's default command printed; they do not name the field that was dropped from the manifest.

• CDelete one Pod so that the Deployment creates a fresh one

  Incorrect

  The replacement is built from the same stored Pod template, which already lacks the misspelled field, so it runs the same way.

• DRecreate it with kubectl apply --validate

  Correct

  Validation checks the manifest against the schema, so a misspelled field is reported as an unknown field instead of being silently ignored.

When a Pod does not do what its manifest says, a misspelled or wrongly nested key is a common cause. Current kubectl validates strictly by default (--validate defaults to strict), so such a typo usually fails at once; it slips through when validation is set to ignore, which silently drops unknown fields.

• A/var/log/kube-scheduler.log

  Correct

  The guide lists /var/log/kube-scheduler.log for the scheduler on control plane nodes.

• B/var/log/kubelet.log

  Incorrect

  That is the kubelet's log on a node.

• C/var/log/kube-proxy.log

  Incorrect

  That is kube-proxy's log on a node.

• D/etc/kubernetes/scheduler.conf

  Incorrect

  That is a kubeconfig file, not a log.

Without systemd, component logs are files under /var/log; with systemd, journalctl may be needed instead.

• AThe kubelet marks the node unschedulable, as kubectl cordon does

  Incorrect

  Memory pressure does not cordon the node. The scheduler keeps BestEffort Pods away because of a taint, and Pods that tolerate it can still land there.

• BThe control plane adds the node.kubernetes.io/memory-pressure taint

  Correct

  The node controller turns node conditions into NoSchedule taints, and the scheduler acts on those taints. Pods outside the BestEffort class get a matching toleration automatically.

• CThe node turns NotReady, and the not-ready taint keeps Pods off

  Incorrect

  Memory pressure is its own condition with its own taint; the not-ready taint corresponds to the Ready condition being False, which pressure alone does not cause.

• DThe kubelet evicts Pods from the node until the pressure clears

  Incorrect

  Node-pressure eviction terminates Pods that are already running to reclaim memory; it does not decide where the scheduler puts new Pods.

Node conditions such as memory, disk or PID pressure become taints with the NoSchedule effect, and the scheduler filters nodes on taints. Under memory pressure only new BestEffort Pods are kept off, because the control plane gives Guaranteed and Burstable Pods a toleration for that taint.

• APin the Pod to one node so it keeps its IP

  Incorrect

  A replaced Pod gets a new IP even on the same node.

• BSet the Pod's restartPolicy to Never so it stays put

  Incorrect

  That stops restarts but not replacements, and adds failures.

• CStore the IP in a ConfigMap and update it by hand

  Incorrect

  That keeps the fragile dependency and adds manual work.

• DUse the Service's DNS name instead of a Pod IP

  Correct

  Pods are replaced with new IPs; a Service keeps a stable name and address in front of them.

Pods are ephemeral; Services give clients a stable way to reach them.