CCNA Troubleshooting Questions

`--previous` retrieves logs from the container's prior terminated instance, not the current one. This directly satisfies the stem's constraint of a container that has already crashed and restarted, since the default `kubectl logs` reads only the running instance's output.

CoreDNS is the default cluster DNS provider in Kubernetes, responsible for resolving internal service names and external domains. If the CoreDNS deployment has zero ready replicas, there are no active pods to handle DNS queries sent to the kube-dns service IP. Consequently, any pod attempting to resolve a DNS name will experience a timeout or resolution failure.

Because the kubelet runs as a native systemd service on the control plane and worker nodes, its standard output and error streams are captured by systemd-journald. Using this command queries the journal daemon specifically for the `kubelet` unit, outputting its complete, chronological startup and runtime log history.

This error occurs when the kubelet is configured to use one cgroup driver (such as systemd) while the container runtime (like containerd) is configured to use another (such as cgroupfs). Because both systems must agree on how to manage cgroup hierarchies, this mismatch prevents the kubelet from registering the node and managing container resources properly, leading to a NotReady status. Aligning both configurations to use the same driver, preferably systemd on modern Linux distributions, resolves the issue.

dig is a dedicated DNS lookup utility that sends explicit DNS queries to the configured resolver and prints the full DNS response, including the resolved A/AAAA record and the answer section. When invoked from inside a pod, it directly interrogates the cluster DNS service (usually CoreDNS) for kubernetes.default.svc.cluster.local, so a successful answer proves that DNS resolution works end-to-end. It also distinguishes error types such as NXDOMAIN versus SERVFAIL, which makes it highly effective for isolating DNS-specific misconfigurations.

This command uses kubectl exec to run the nslookup utility directly inside the container of an existing pod, utilizing its specific network namespace and /etc/resolv.conf configuration. By querying the target service name from within the pod, you can accurately verify if the pod's configured DNS resolver (typically CoreDNS) is functioning and resolving names correctly. This is the standard method for diagnosing pod-level DNS resolution issues in a Kubernetes cluster.

Taints that are not tolerated prevent scheduling, causing Pending.

A PVC remains Pending when the control plane cannot find a PV that satisfies its request. This could be because no PV exists, or existing PVs do not match the storage class, access modes, or capacity. If the PVC uses a storage class with a dynamic provisioner, the provisioner might be failing to create a volume. Checking the PVC events and the storage class configuration is necessary.

ImagePullBackOff almost always follows a kubelet event that includes the exact registry response, such as 'manifest unknown', 'not found', or 'unauthorized'. Verifying the image exists in the configured registry, with the exact tag or digest specified in the pod spec, is the most direct confirmation of the root cause. Use `docker manifest inspect` or `skopeo inspect` against that registry, and remember that images can be deleted or made private after a pod was previously running. This check targets the registry artifact itself.

The 'manifest unknown' error in the kubectl describe pod event is the definitive signature: the registry does not have a manifest for the referenced tag, so either the tag was never pushed, was deleted, or contains a typo. Unlike authentication or storage failures, this is a content-addressing issue: the digest cannot be resolved because that tag's manifest is absent. Confirm by inspecting the image name and tag exactly as written and, if needed, querying the registry API directly.

When a Pod is configured with `hostNetwork: true`, it directly uses the node's network namespace, bypassing the Kubernetes CNI network. Consequently, such a pod inherits the node's `/etc/resolv.conf` for DNS resolution instead of the cluster's internal DNS (CoreDNS/kube-dns). The node's DNS resolver typically cannot resolve Kubernetes Service ClusterIPs, which are internal to the cluster's DNS domain, leading to name resolution failures for services. This specific DNS misconfiguration prevents the `hostNetwork` pod from finding the Service's IP address.

The presence of a 'no such host' or 'lookup failed' error in the pod's event log indicates that the node's local resolver cannot translate the registry's domain name into an IP address. Because the Kubelet cannot resolve the external registry's FQDN, it fails to initiate the TCP handshake, ultimately causing the container pull to fail and triggering the 'ImagePullBackOff' state.

When internal cluster communication works but external traffic times out, the issue lies in the external network path. Misconfigured cloud load balancers or restrictive security groups/firewalls blocking the NodePort range (typically 30000-32767) prevent external packets from reaching the cluster nodes.

A NetworkPolicy with policyTypes: Ingress and an empty ingress rule list isolates the selected Pods, denying all inbound traffic except from the Pod's own node. Since the policy selects the web Pods, the client's connection is dropped, causing the timeout. This directly explains the symptom and the presence of the policy.

A misspelled image name or tag prevents the container runtime from locating the manifest in the specified registry. The kubelet first transitions to ErrImagePull, and after repeated failed attempts to download the non-existent image, it backs off to avoid overloading the registry, resulting in the ImagePullBackOff status. This indicates a configuration error in the pod specification.

The Metrics Server is an optional cluster component that aggregates resource usage from kubelets and exposes it through the metrics.k8s.io API, which kubectl top and the Horizontal Pod Autoscaler consume. In a standard kubeadm or vanilla cluster it is not installed by default, so kubectl top nodes fails with 'metrics not available' until the Metrics Server manifests are applied. Deploying the Metrics Server and allowing it time to collect its first metrics resolves the error.

When a node is in a `NotReady` state, it signifies that the Kubelet, the agent running on the node, is unable to register itself with the API server or report its health status. The Kubelet is responsible for managing pods, reporting node status, and executing container operations. Therefore, examining the Kubelet's logs via `journalctl -u kubelet` provides direct insight into why it might be failing to communicate, experiencing resource issues, or encountering problems with the container runtime, making it the most critical first step for diagnosis.

The kubelet is the component that reports Node status and manages pod lifecycle on each node; its logs often contain explicit error messages such as CNI failures, timeouts contacting the API server, or runtime issues. 'journalctl -u kubelet' allows you to view the kubelet's systemd journal, which is the authoritative source for why the kubelet has marked the node as NotReady. This is a direct, non-invasive diagnostic step that should be performed first when investigating node readiness problems.

This command aggregates detailed information about the Pod from the Kubernetes API, including its configuration, controller references, and container statuses. Crucially, it appends a dedicated "Events" section at the end of the output, which queries the cluster's event log for warnings and errors directly related to that Pod. This is where image pull failures, back-offs, and scheduling issues are explicitly logged.

When a node has a taint, the scheduler ignores that node for any pod that does not have a matching toleration in its pod spec. The describe output would include an event such as '0/1 nodes are available: 1 node(s) had untolerated taint', which precisely identifies this scheduling failure. To make the pod run, you must either remove the taint from the node or add a toleration that matches the taint key, value, and effect; because neither was done, the pod remains Pending.

The kubelet is the agent that reports the node's status, so its logs are the authoritative source for why it stopped reporting Ready. 'journalctl -u kubelet' shows systemd-managed kubelet output, including fatal errors such as failure to connect to the container runtime, CNI plugin failures, or authentication problems with the API server. Examining these logs is the first diagnostic step before any corrective action is taken.

kubectl describe pod <pod> aggregates the full object state with a timeline of Events, including the reason, message, and count for failed probes, image pulls, and container starts. It surfaces the container's current waiting reason (e.g., CrashLoopBackOff), last terminated exit code, and the actual error message from the runtime, which together pinpoint why the pod is repeatedly crashing. This is the standard diagnostic first step for a crash loop.

kubectl top pod <pod-name> is a valid command that queries the Metrics API (backed by metrics-server) to display real-time CPU and memory usage for the specific named pod. It reports usage in cores and MiB (or GiB) for each container, making it the precise tool for troubleshooting a single pod's resource consumption against its requests/limits.

Checking kubelet logs via journalctl is the primary, non-destructive diagnostic step: the kubelet is the agent that registers the node and reports its status, so any failure in its startup or operation (e.g., CNI misconfiguration, resource pressure, or runtime communication errors) will be logged there. Running `journalctl -u kubelet` (or `journalctl -u kubelet --since today`) reveals the exact error before deciding on any remediation. This step should always precede restarting services or modifying cluster objects, because it pinpoints the underlying cause without causing downtime.

Since the node is NotReady due to an inactive kubelet daemon, executing this command directly instructs systemd to launch the kubelet process. Once running, the kubelet will resume posting node status updates to the Kubernetes API server, restoring the node to a Ready state.

kubectl exec <pod> -- nslookup <service-name> is correct because it starts the nslookup process directly inside the pod's container, using the same /etc/resolv.conf, search domains, and network stack that the application uses. This actually queries the cluster's DNS service and returns the ClusterIP (or pod IPs for headless services) associated with that Service in the same namespace. If the Service is in a different namespace, you can test the fully qualified name <service-name>.<namespace>.svc.cluster.local. It is the standard, non-invasive way to validate service discovery from a pod's perspective.

The --previous flag retrieves logs from the container's prior terminated instance, which is exactly what a crashed container requires. Without it, kubectl logs returns only the current container's output, which may not exist after a crash.

Removing the control-plane taint lets the scheduler place the pod on those nodes, directly resolving the 'taint the pod didn't tolerate' rejection. It addresses one of the two stated scheduling failures, freeing capacity that the Insufficient memory node cannot provide.

The `--previous` (or `-p`) flag instructs the Kubernetes API server to retrieve the log output from the most recently terminated or crashed instance of a container within the specified Pod. This is crucial for troubleshooting post-mortem events like CrashLoopBackOff, where the active container has restarted and its current log buffer is empty or reset.

The Metrics Server is a cluster add-on that collects resource metrics from each kubelet and exposes them through the aggregated `metrics.k8s.io` API; `kubectl top nodes` queries this API to display usage figures. If the Metrics Server is not installed, or if its pods are failing to start (e.g., due to image pull issues or invalid configuration), the API is unavailable and the command returns an error such as 'metrics.k8s.io is not available' or 'the server is currently unable to handle the request.' Even when installed, it may need about 15 seconds to collect its first batch of metrics; if queried immediately after cluster startup, you might see an empty or error response. Checking for metrics-server pods in the `kube-system` namespace and verifying that the aggregated API is registered will confirm this root cause.

The kubelet agent on each node continuously monitors the health and operational status of the CNI plugin. If the CNI plugin's pod (e.g., Calico, Flannel) crashes, fails its readiness probes, or is not running on a specific node, the kubelet cannot properly configure network interfaces for pods or establish essential network routes. Consequently, the kubelet reports the node's status as `NotReady` with the specific `NetworkPluginNotReady` condition, indicating a fundamental failure in the node's networking capabilities.

A misconfigured startup probe can force the kubelet to kill a container that has actually started successfully but fails the probe due to wrong parameters, such as an incorrect port, path, or timeout. With the startup probe, the kubelet specially guards the container until it reports readiness; if the probe thresholds are too restrictive, the container is restarted before the application can finish initializing. This creates an endless cycle of restart and re-probe, producing CrashLoopBackOff. It is a direct and common cause of crash loops because the container is terminated by the kubelet based on probe failure, not by an actual app error.

When a Pod references a PersistentVolumeClaim (PVC) in its volume definition, the Kubernetes scheduler will keep the Pod in a Pending state if that PVC is not bound to a PersistentVolume (PV) or if the PVC does not exist in the namespace. Running kubectl describe pod will explicitly show a warning event such as FailedScheduling with a message indicating the PVC is not bound, preventing the Pod from being assigned to a node.

The first and most decisive troubleshooting step is to run `kubectl get endpoints <service>` (or `kubectl describe service`) and confirm the endpoint list is non-empty. If the selector doesn't match any pod, or the matched pods are NotReady, the EndpointSlice controller generates zero addresses, leaving kube-proxy with no valid destination for the service IP. This explains why the Service is unreachable even though the Service object itself appears healthy. Checking endpoints isolates the problem to label selectors or pod readiness immediately.

kubectl top pods -n production is correct because it queries the metrics API (metrics.k8s.io) via the metrics-server and returns a live CPU and memory consumption report for every pod in the production namespace. The output shows CPU usage in cores (or millicores) and memory in bytes or MiB, which is exactly the resource usage data the task asks for. This command requires the metrics-server to be deployed and configured, otherwise it will return an error from the metrics API.

If an application terminates immediately upon execution—such as due to a missing shared library, a syntax error in an entrypoint script, or a rapid kernel panic—it may exit before writing any bytes to stdout or stderr. In this scenario, the container runtime creates an empty log file, resulting in no output when running kubectl logs.

The container's memory limit is implemented as a cgroup v2 (or v1) limit on the memory cgroup to which that container belongs. When the container's resident set size plus page cache exceeds this limit, the kernel's out-of-memory (OOM) killer selects a process in that cgroup — usually the container's main PID — and kills it, resulting in OOMKilled. Increasing spec.template.spec.containers[].resources.limits.memory raises this cgroup ceiling, giving the container more usable memory headroom before the kernel decides to kill its process, which is exactly why this field addresses the reported OOMKilled status.

This is correct because kubectl logs expects the Pod name as the first positional argument, then -c names a specific container within that Pod, and --tail=50 limits the output to the last 50 lines. The flag syntax --tail=N is valid; it tells the kubelet to read only the requested number of lines from the container's log file, which is far more efficient than streaming the entire log for a long-running Pod. This exactly satisfies the requirement to see the last 50 lines from the named Pod's api-container.

A pod that references a PersistentVolumeClaim (PVC) remains in Pending when that claim is unbound because the scheduler cannot determine which node has the required storage volume unless the PVC is already in the Bound phase. The kubelet will not start containers until all referenced volumes are successfully attached and mounted, and if the PVC is lost or awaiting dynamic provisioning, the pod cannot progress. For example, a manually pre-created PV with a mismatched access mode or storage class can leave the PVC unbound, indefinitely keeping the pod in Pending.

"kubectl describe pod <pod-name>" provides a comprehensive summary of a pod's current state, including its status, events, and container specifications. When a pod is in `ImagePullBackOff`, this command will display the specific events related to the image pull attempt, such as `Failed` or `ErrImagePull`, along with the exact error message from the container runtime. This detailed output is crucial for diagnosing the root cause, such as an incorrect image name, a private registry authentication failure, or network issues, making it the most direct and effective diagnostic tool.

Adding matching tolerations to the Pod's specification directly instructs the kube-scheduler that this Pod is allowed to run on nodes with corresponding taints. This is the standard, least-privilege method to resolve scheduling issues on tainted nodes without compromising the cluster's overall node isolation strategy. Once the toleration is applied, the scheduler can successfully bind the Pod to the tainted node.

The kubelet is the primary node agent responsible for posting node status and heartbeats back to the control plane via the Node Lifecycle Controller. When a node transitions to NotReady, checking the kubelet's systemd logs using 'journalctl -u kubelet' is the most direct way to diagnose the issue. These logs will reveal critical failures such as container runtime connection errors, out-of-memory (OOM) events, misconfigured certificates, or disk pressure conditions that caused the agent to fail.

Binding to localhost (127.0.0.1) restricts connections to only the same network namespace, which is isolated to the container itself. Kubernetes networking relies on the pod's IP address and virtual Ethernet interfaces, so a loopback bind cannot receive traffic from outside the pod. Listening on 0.0.0.0 makes the port available on all interfaces, including the pod's external-facing one.

Running 'systemctl status kubelet' on the node checks whether the kubelet systemd service is active or has failed, showing the current unit state, exit code, and recent process info. This is a logical first step because a Node stuck NotReady often means the kubelet process itself is not running or repeatedly crashing. It directly inspects the node agent, unlike control-plane diagnostics, and can quickly reveal if the service is masked, stopped, or in a failed state.

A NetworkPolicy is a namespaced Kubernetes resource that acts as a pod-level firewall, and if cluster networking is configured with a CNI that enforces it, any ingress rule can explicitly deny traffic from pods in other namespaces. The default behavior is allow-all only when no NetworkPolicy selects the pod; once one exists, the default becomes deny for anything not matched by its rules. If a policy selects pod-b and its ingress list does not include namespace 'foo' or a matching podSelector, it will silently drop the TCP SYN packets from pod-a, making the port 5432 connection time out or refuse while the service IP ping still succeeds.

kubectl describe pod pod-name aggregates the pod's current state, recent events, container statuses (waiting/running/terminated), restart counts, and last termination reason into a human-readable summary. This surfaces CrashLoopBackOff events with timestamps, showing whether the container exited due to an error, OOMKill, or probe failure. It is the first step for diagnosing why Kubernetes is restarting the container.

This is the correct answer because the scheduler cannot place the pod on any node that has a taint not tolerated by the pod. When every node has the node.kubernetes.io/not-ready taint (a direct result of the node controller marking them NotReady), there is no feasible node in the cluster. The pod stays in Pending until at least one node returns to Ready status, which clears the taint and allows scheduling.

The kubelet requires a valid kubeconfig to authenticate to the API server. If the file is missing or has permissions that prevent the kubelet user from reading it, the kubelet will fail to start with an error referencing the kubeconfig path. This aligns with the journalctl output. Restoring or regenerating the file fixes the issue.

When no node has enough allocatable CPU or memory to satisfy the Pod's resource requests, the kube-scheduler's filter phase rejects every candidate node, leaving the Pod unscheduled in Pending. This is the classic capacity-driven cause.

The kubelet depends on a CNI configuration file in /etc/cni/net.d/ to set up pod networking. When this file is absent or malformed, the kubelet cannot initialize the network plugin and marks the node as NotReady. The kubelet logs will show a 'CNI configuration uninitialized' error, which directly matches the symptom described in the question.

kubectl top nodes is the correct command because it queries the Metrics API, typically served by metrics-server, and aggregates resource usage from each node's kubelet and cAdvisor. It outputs a table showing CPU usage (e.g., 348m) and memory usage (e.g., 1200Mi) alongside the node's total capacity, making it the standard kubectl command for viewing current CPU and memory consumption across nodes.

When an image resides in a private registry, the kubelet must authenticate itself using image pull secrets specified in the pod's spec via `imagePullSecrets`. If those secrets are missing or not attached to the pod, the registry responds with an authorization error (e.g., "unauthorized: authentication required"), and the kubelet reports ErrImagePull before entering ImagePullBackOff. This is a common production misconfiguration because merely having the secret in the namespace does not grant the pod access.

`kubectl logs pod-name --previous` correctly retrieves the logs from the last terminated container instance in the pod. Because CrashLoopBackOff means the container keeps crashing and restarting, the logs from the most recent crashed instance contain the panic, exception, or startup failure that caused the crash. The `--previous` flag explicitly tells the kubelet to read the terminated container's log file, which is exactly what you need to inspect when the current container has already restarted.

The kubelet is responsible for registering the node with the API server and continuously reporting its health and status. If the kubelet loses its ability to communicate with the API server, it cannot send its periodic heartbeats or update the node's conditions. After a default timeout period, the control plane will mark the node as NotReady because it has stopped receiving updates, indicating a potential issue with the node's availability or connectivity.

The application's connection string or manifest refers to a Kubernetes Service by the DNS name "service", but no Service object with that name exists in the "default" namespace. When the pod attempts to resolve it, CoreDNS returns NXDOMAIN because no A/AAAA record has been created for a non-existent Service, so the application fails to connect to its required dependency and exits, causing Kubernetes to restart the pod in a CrashLoopBackOff state. This is a configuration error in the workload definition, not an infrastructure or DNS-server failure.

The 'manifest not found' error explicitly indicates that the container runtime successfully contacted the image registry but could not locate the specific image manifest associated with the requested tag '1.0'. This means the registry confirmed its existence but reported that no image with that precise tag is available. This is the most direct and accurate interpretation of the given error message, signifying the tag itself is absent.

The kubelet is the node agent that registers the node, runs pods, and continuously posts its status and heartbeat to the control plane, so its logs are the definitive source for why it stopped functioning. Running 'journalctl -u kubelet' reveals systemd unit output including fatal errors like failure to connect to the container runtime via the CRI socket, expired certificates, or resource exhaustion. You can also use '--since' or '-f' to focus on the time the node became NotReady and to watch for live errors, making this a primary diagnostic step.

kubectl describe pod is the correct and most useful command because it displays the pod's complete status, conditions, container states, and recent events in one place, including the exact kubelet-generated error from the failed image pull. This output reveals crucial details such as the image name/tag, whether the registry returned a 'manifest unknown' error, an authentication failure, or a network issue, and shows the exponential backoff timing, enabling a precise root-cause diagnosis.

The ImagePullBackOff status indicates that the kubelet tried to pull the image from the repository but the attempt failed and it is backing off with exponential retry delay. A misspelled image name means the registry cannot find a matching repository or tag, often returning a 404 or 'manifest unknown' error, which leaves the kubelet in this backoff loop. For example, specifying 'ngin:x' instead of 'nginx:latest' will surface as ImagePullBackOff; fixing the typo and re-pulling resolves it.

This is correct because during the PodInitializing phase, the pod's init containers are still executing, meaning the primary application containers have not yet been created or started by the container runtime. Because the target application container does not exist in a running or terminated state yet, the kubelet cannot stream any log output, resulting in a waiting to start error.

The container was OOMKilled because its memory footprint hit the hard memory limit set in the container spec, and the Linux OOM killer terminated it to protect the node. Increasing the memory limit (and, if applicable, the memory request) gives the container more headroom under its cgroup, so it can allocate the additional memory it needs without being killed. This is the direct fix: update the Deployment or Pod template with a higher memory limit, which triggers a rolling update to apply the new limit.

kubectl top pod --namespace=production is the correct kubectl command because it directly queries the metrics-server, which receives its data from kubelet cAdvisor, and returns the current CPU and memory usage for every pod in the production namespace. This is the only option among the four that actually measures live runtime memory consumption per pod, exactly satisfying the requirement. It produces a table with columns for NAME, CPU(cores), and MEMORY(bytes); note that without an explicit --namespace flag, kubectl top pod would default to the current namespace, so specifying production is essential.

This is the standard command used to retrieve the stdout and stderr streams from the primary container running inside a pod. If the pod contains multiple containers, you must specify the target container using the `-c` or `--container` flag, otherwise it defaults to the first container defined in the spec.

If a container crashes due to a missing environment variable sourced from a ConfigMap, verifying the existence of the target ConfigMap and its keys using kubectl get configmap is the correct troubleshooting step. This confirms whether the reference in the Pod specification is valid and populated.

This is the correct command to resolve the `NotReady` status and ensure future stability. The `systemctl enable --now kubelet` command not only configures the `kubelet` service to start automatically during subsequent system boots but also immediately starts the service in the current session. This dual action ensures the `kubelet` is running right away, allowing the node to quickly transition to a `Ready` state without requiring a manual reboot.

This command launches nslookup inside pod-a's network namespace, querying the cluster's CoreDNS/kube-dns service to resolve the name "service-name". Successful resolution proves that DNS pod(s), kube-dns service, and the pod's resolv.conf are functioning, and it returns the ClusterIP or headless endpoints needed for service discovery. It is a valid connectivity test because without DNS, application-level communication via service names fails regardless of reachable pods.

When a pod defines a nodeSelector that does not match the labels of any active node in the cluster, the default-scheduler cannot find a valid placement. Consequently, the pod remains in a Pending state, and the scheduler emits a FailedScheduling warning event indicating that zero nodes match the selector.

The kubectl describe pod output lists Events from the scheduler. In this case, the events directly report two distinct issues: three nodes have insufficient CPU to satisfy the pod's resource request, and one node has a taint for which the pod has no matching toleration. Since these are the exact messages shown, this option correctly captures the full diagnosis.

When a pod definition references a PersistentVolumeClaim that is either missing from the namespace or stuck in a 'Pending' state (unbound), the kubelet cannot mount the volume. Consequently, the pod remains blocked in the 'ContainerCreating' or 'Pending' phase, and 'kubectl describe' will display a warning event such as 'FailedMount' or 'FailedScheduling' due to the missing volume.

The application inside the container is crashing because it cannot establish a network connection to its dependency, which is a classic symptom of a misconfigured database host environment variable. When the application attempts to resolve or connect to an invalid hostname or IP address specified in its configuration, it throws an unhandled connection exception and terminates, causing Kubernetes to place the pod in a CrashLoopBackOff state.

kube-proxy is the component responsible for implementing the Service abstraction by installing iptables, IPVS, or eBPF rules on every node. If it is not running, misconfigured, or its rules are out of sync, packets destined for the ClusterIP have no forwarding rules and are silently dropped or rejected. This directly matches the symptom of an unreachable ClusterIP while the backing pods and their endpoints may still be healthy.

The "kubectl top nodes" command queries the Metrics Server API to retrieve and display the current, real-time CPU and memory utilization of all nodes in the cluster. This is the standard, built-in command used by administrators to quickly identify resource-constrained nodes. It requires the Metrics Server to be properly installed and running in the cluster to function.

This command retrieves the current logs from every CoreDNS pod by targeting the standard label selector `k8s-app=kube-dns` in the `kube-system` namespace. Since CoreDNS is normally deployed as a Deployment with multiple replicas, the `-l` flag aggregates output from all pods, allowing you to spot query processing errors, panics, or plugin misconfigurations (e.g., kubernetes plugin failures, upstream resolution timeouts) that would not be visible if you inspected only a single pod. Logs directly reveal whether DNS requests are reaching CoreDNS and how it handles them, making this the first-line diagnostic method.

When a container crashes and restarts, standard log commands only show the output of the currently running instance. Appending the `--previous` flag retrieves the stdout and stderr logs from the prior, terminated instance of the container, which typically contains the stack trace or error that caused the crash.

The correct action is to free disk space and reduce memory consumption on the affected nodes. When the underlying pressure conditions clear, the kubelet automatically removes the corresponding taints, allowing the pending pod to schedule normally. This directly addresses the root cause of the unschedulable state and aligns with Kubernetes' intended behavior of reflecting node health through taints and conditions.