CCNA Application Observability and Maintenance Questions

CrashLoopBackOff means the container has started and exited repeatedly with a non-zero exit code, and the kubelet is applying an exponential backoff between restarts. This is typically caused by a misconfiguration—such as a missing ConfigMap value, incorrect environment variable, bad command-line argument, or a malformed config file—or an application-level error like an unhandled panic. Check kubectl logs with --previous to see the actual error message and exit code.

The scheduler places pods on nodes using the CPU request as the reservation; a pending pod with 'Insufficient cpu' events has a request larger than any node's free capacity. Reducing the CPU request in the pod spec to fit within an existing node's available allocatable CPU allows the scheduler to find a suitable node, and reapply the manifest (via kubectl replace -f or delete/recreate) so the pod is re-created with the lowered request. This directly addresses the root cause and is faster than infrastructure changes.

The readiness probe is the only probe that directly controls whether the Pod is added to or retained in the Endpoints object backing a Service. When it fails, the kubelet marks the Pod's Ready condition as False, and the endpoints controller removes its IP from all matching Service backends, so it stops receiving new traffic while it is still running. This precisely matches the symptom of a running Pod that is unresponsive: it should be taken out of rotation, not restarted.

Metrics Server is the correct choice because it is a built-in cluster addon that aggregates resource usage metrics (CPU and memory) per node and pod from kubelet's Summary API via the Metrics API. It provides these lightweight, in-memory metrics to `kubectl top` and the Horizontal Pod Autoscaler (HPA) without needing external storage. Being cluster-native and automatically available on most managed Kubernetes distributions, it is the standard zero-configuration tool for basic resource monitoring.

In the 'Containers' section of 'kubectl describe pod', you'll find a 'Limits' and 'Requests' line for each container, mirroring the resource requirements defined in the pod's YAML. These show the CPU and memory requests and limits that affect scheduling decisions and QoS class. Hence, this is a true capability of describe.

A readiness probe tells the kubelet whether the application inside the container is ready to accept incoming requests. When the probe succeeds, the pod is added to the endpoints of Services that select it; when it fails, the pod is removed from those endpoints without being terminated. This prevents clients from sending traffic to pods that are still starting up or are temporarily overloaded.

kubectl debug -it <pod> --image=busybox --target=<container> creates an ephemeral container inside the existing pod, sharing its network, volumes, and (if enabled) process namespace. The --target flag names the container whose namespaces the debug container will share, letting you inspect the failing container's filesystem and processes even while it is crashing. Because ephemeral containers do not restart or affect the original container's lifecycle, this is the correct way to inject a debugging tool into the pod without modifying the pod spec.

kubectl debug -it <pod> --image=busybox -- sh is the standard command to create an ephemeral debug container in the target pod. It injects a busybox container into the pod's namespace and attaches your terminal to it, allowing you to inspect the pod's shared network, storage, and process state. This is the sanctioned workflow for adding a temporary troubleshooting container.

The `terminationGracePeriodSeconds` field in a Pod spec defaults to 30 seconds when omitted. This value sets how long Kubernetes waits after sending SIGTERM to a container's main process before sending SIGKILL. It is a deliberate default to allow most workloads enough time to shut down cleanly without forcing an immediate hard kill.

Correct. The liveness probe checks a health endpoint or TCP port on the container; when that probe fails continuously, the kubelet kills the container and restarts it according to restartPolicy (Always by default). Each subsequent restart is followed by another failing probe, so the container enters a restart loop with exponential backoff, visible as CrashLoopBackOff in container status. This matches the expected behavior for a misconfigured or broken liveness probe on port 8080.

The `--previous` flag is the long form of `-p` and retrieves the logs from the last terminated instance of the container. In a crash loop, the currently running container may be brand new with little/no output, while the previous instance's logs contain the stack trace or error that caused the exit. This is the standard way to inspect logs from a crashed container that has since restarted. The command returns logs to stdout, making them easy to review or pipe to tools.

kubectl exec web-app -- top is correct because it runs the top utility inside the container, which reads /proc to display a live view of processes with their PID, CPU usage, memory usage, and command name. This directly identifies the process consuming the most CPU from the perspective of the container's PID namespace. Note that top must exist in the container image, or you may need an alternative like kubectl exec web-app -- ps aux or /bin/sh -c 'top -b -n 1'.

kubectl debug attaches an ephemeral container to the target pod without restarting or modifying the original container, so you can inspect the shared filesystem, environment variables, and network namespace even while the main container is crash-looping. Ephemeral containers are managed by the kubelet and are not subject to the pod's restart policy, allowing them to remain available for interactive troubleshooting when the main container keeps failing. This is the direct, supported way to debug a crashing pod when exec is impossible.

kubectl top pod is the correct choice because it directly queries the metrics-server (via the metrics.k8s.io API) for live CPU and memory usage data per pod and per container. It returns a compact table of instantaneous resource usage, such as MEMORY and MEMORY% columns, which is exactly what a user needs to inspect memory consumption across the three replicas. This command requires the metrics-server to be deployed and properly configured in the cluster to function.

timeoutSeconds is a valid Kubernetes probe parameter. It defines the maximum time in seconds that the kubelet waits for a probe to complete after starting it. If the probe exceeds this duration, it is considered failed, and the failure is counted toward failureThreshold. To be effective, timeoutSeconds should be less than periodSeconds to avoid overlapping probe executions.

Setting initialDelaySeconds gives the application a grace period to finish startup tasks such as loading configuration, connecting to databases, or opening listen sockets before the kubelet begins sending probe requests. Without this delay, a still-initializing container may fail its first probes and be repeatedly restarted, creating a crash loop instead of a healthy pod.

Readiness probes are the mechanism Kubernetes uses to decide if a container is ready to serve traffic. When a readiness probe fails, the pod is removed from all backing Service endpoints, so no requests are forwarded to it, but the container is not killed or restarted. This makes readiness probes the direct indicator of whether a container is prepared to handle incoming traffic, including dependencies like database connectivity or loaded configuration.

The --previous flag instructs kubectl to retrieve logs from the previous, terminated instance of the container rather than the current one. In a typical crash-loop scenario, the kubelet retains the log file of the last terminated container on the node, and kubectl accesses it through the API's 'previous' option. This gives the developer visibility into the exact output that caused the prior container to exit, making it the correct command when the pod is named with an instance suffix and the developer suspects a restart has occurred.

kubectl get pod <pod-name> -o yaml returns the live pod object from the API server serialized as YAML, including metadata (annotations/labels), spec, and status. This is the canonical way to dump the complete pod specification as stored by Kubernetes, though it includes defaulted fields and status that aren't part of the original input manifest.

A startupProbe is the only probe type designed for slow-starting containers; it runs repeatedly until the process signals it has initialized successfully. Kubelet disables liveness and readiness probes until this probe succeeds, so the container gets unlimited (or configured) attempts to start without being killed. You can set a large failureThreshold with short periodSeconds to allow a long but controlled startup window.

terminationGracePeriodSeconds is the correct PodSpec field that sets the time allotted for a container to shut down gracefully. After the kubelet sends SIGTERM to the primary process, it waits this many seconds before sending SIGKILL to force termination. The default value is 30 seconds, and you can override it per deletion request with kubectl delete --grace-period.

A startup probe with failureThreshold=30 and periodSeconds=2 gives the container up to 60 seconds to become ready (30 failures × 2 seconds). The kubelet runs the startup probe first, and only after it succeeds do the liveness and readiness probes begin executing. This cleanly separates the startup phase from steady-state health checking, preventing premature liveness restarts without limiting the app's startup time to a hard-coded initialDelay. Once the startup probe passes, the liveness probe takes over to restart the container if it later becomes unhealthy, while the readiness probe controls traffic admission.

This is a valid parameter in the Kubernetes probe specification. It sets the number of seconds the kubelet waits after the container starts before performing the first probe, giving the application time to initialize. Properly setting this value is critical for liveness probes to avoid restarting containers that are still starting up.

Readiness probes are a first-class probe type that tells the kubelet when a container is ready to begin accepting traffic. If the probe fails, the Pod's IP is removed from the endpoints of all Services, but the container is not terminated or restarted. This allows the container to remain running while it load-balances nothing, making it distinct from liveness probes which restart containers. The assignment of readiness is crucial for rolling updates to avoid sending requests to Pods still starting up.

This statement is correct because a readiness probe is a recurring health check, not a one-time gate. The kubelet executes it every periodSeconds once the container is running, even after the pod has already become Ready. If the probe later fails, the pod is marked NotReady and traffic is withdrawn; if it passes again, the pod is marked Ready and endpoints are restored.

terminationGracePeriodSeconds is actually a Pod-level field in the pod spec, not a container-level field, and it controls the duration Kubernetes waits after sending SIGTERM to containers before forcefully sending SIGKILL. This grace period gives processes time to save state, close connections, and complete cleanup handlers. After the period elapses, the kubelet forcibly terminates any containers that have not exited, and overriding it on a per-container basis is impossible.

The lastState.terminated object records the previous container instance, including its exitCode, reason, and signal. Querying it with jsonpath returns exactly the diagnostic data the monitoring agent needs, allowing a reason of OOMKilled to be separated from a generic Error exit code without inspecting node-level logs or restarting anything.

A tcpSocket readiness probe is considered successful if the kubelet can establish a TCP connection to the specified port, typically via a three-way handshake. It does not send any application-level data, nor does it read or inspect the application's response. Consequently, as long as the listening socket is open, the pod is marked Ready and receives traffic, even if the application inside is misconfigured, returning errors, or not fully initialized.

During the startup phase, the liveness probe is suppressed until the startup probe succeeds, so a slow-initializing container will not be prematurely killed. By configuring a generous failureThreshold and periodSeconds, the startup probe gives the container a controlled window to become ready. This prevents a crash-looping cycle that would otherwise occur when a liveness check fires before the application is fully operational.

The --tail=20 flag instructs kubectl to print only the last 20 lines of the container's log output. For a pod in CrashLoopBackOff, these final lines almost always contain the exact exception, panic, or error that triggered the latest restart. This targeted snapshot cuts through the noise of earlier failed attempts and gives you the actionable diagnostic information you need immediately.

Resizing the PersistentVolumeClaim provides immediate temporary relief by giving the container more disk headroom, which is often the fastest way to mitigate an acute disk-full incident. However, without log rotation inside the container, the new space will eventually be consumed again, so configuring rotation (e.g., logrotate to cap total log size) prevents recurrence by keeping per-file and aggregate growth bounded. This combination addresses the immediate symptom and the root cause, making it the right answer.

Connection refused means the client sent a SYN to port 8080 on the loopback address, and the kernel responded with RST because nothing is bound to that listen socket. The application either never started, crashed before binding, or is configured to listen on a different port or interface such as 127.0.0.1:9090 instead of 0.0.0.0:8080. Troubleshooting should include checking the process in the container (ss -tlnp), reading application logs, and confirming the command/config passed to the container.

kubectl top node node-1 is correct because it directly queries the metrics-server for that specific node and displays real-time CPU and memory utilization at the node level. This command provides a snapshot of current usage, typically expressed as a percentage and absolute values, fulfilling the requirement to see what resources the node is actually using.

The field specifies the waiting period after the container starts before the kubelet begins running the probe. It is crucial for applications that need time to initialize, such as loading configuration or establishing connections. Without it, probes might fail prematurely, causing unnecessary restarts. The field is part of the probe specification along with periodSeconds, timeoutSeconds, successThreshold, and failureThreshold.

The correct calculation multiplies failureThreshold (10) by periodSeconds (5), yielding 50 seconds. With no initialDelaySeconds specified, the kubelet begins probing immediately and gives exactly this window for the container to become ready. If the probe fails 10 consecutive times at 5-second intervals, the kubelet restarts the container, making 50 seconds the definitive startup deadline.

Containers that take a variable amount of time to become ready—for example, because they must load large datasets or wait for external dependencies—can trip the default liveness probe settings and be restarted before they finish initializing. A startup probe lets you set a generous periodSeconds and failureThreshold so the kubelet waits an adequate, configurable window that can encompass all startup variability. Once the startup probe succeeds, normal liveness/readiness probing begins, but the startup probe itself ensures the variable initialization doesn't cause premature termination.

The FailedScheduling event is emitted by the kube-scheduler when no node passes all scheduling predicates for the pod. For a plain resource shortage, the scheduler cannot find a node with enough allocatable CPU/memory to meet the sum of container requests (not limits). This can also be triggered by node selectors, taints/tolerations, or affinity rules excluding every node, but the most common cause is insufficient resources. The event message typically names the specific constraint, such as 'Insufficient memory', for the node(s) attempted.

Running `kubectl get pod my-pod -o json` requests the full Pod resource from the Kubernetes API and formats it as a JSON document. This output contains the complete object, including metadata (labels, annotations, ownerReferences), the desired spec, and the live status (pod IP, phase, container states, conditions). It is the canonical machine-readable representation, which can be piped to tools like `jq` for automation.

This is the standard approach for Prometheus operator's annotation-based discovery: the service's annotations `prometheus.io/scrape: "true"` and `prometheus.io/port: "8080"` allow the auto-discovery component to generate a scrape_config targeting the service's endpoints on port 8080. The Service provides a stable DNS name and selects the pods, so even if pod IPs change, Prometheus can dynamically look up the current endpoints. This is distinct from the static ConfigMap method because it enables automatic, label-based target discovery across the cluster.

The liveness probe is executed by the kubelet on the node, which dials the pod's IP address on the specified port, not the container's loopback interface. If the application binds only to 127.0.0.1 (or ::1), it is reachable solely from within its own network namespace, making the pod IP's port appear closed or refused from the node. This exactly matches the symptom: curl localhost:8080 succeeds inside the container, but the kubelet's external connection fails. The fix is to configure the application server to listen on 0.0.0.0 (or the container's specific eth0 IP) so it accepts connections on all interfaces.

A pod with a CPU request exceeding the allocatable CPU on every node cannot be scheduled. The Kubernetes scheduler filters out nodes lacking sufficient unallocated capacity to satisfy the request, leaving the pod in the Pending phase and emitting events such as 'Insufficient cpu'. Requests, not limits, drive these placement decisions, so the pod can wait indefinitely until node capacity is freed or the request is lowered.

kubectl get pods -o wide is correct because the -o wide flag extends the default pod listing with the IP and NODE columns, displaying each pod's cluster-assigned IP address and the name of the node hosting it. These fields come directly from the pod's status.podIP and spec.nodeName, and the output remains a single-row-per-pod table, making it ideal for quickly answering exactly what the question asks.

Container logs are one of the first places to look when a readiness probe fails. The kubelet sends probe requests (e.g., HTTP GET to the probe path), and if the application logs each request, you may see the probe arriving with a non-2xx status, stack traces, or slow response times indicating why the endpoint is not healthy. While probe requests are not always logged, if they are, they can directly reveal the underlying cause such as a crash loop, a missing dependency, or a connection timeout.

kubectl logs accepts a deployment as a resource argument and, with --all-containers=true, streams logs from every container in the pods the deployment owns. Piping that combined stream through grep filters the JSON lines locally in the engineer's shell, satisfying the requirement with no extra software on the cluster nodes.

terminationGracePeriodSeconds is the correct Pod-level setting that determines how long Kubernetes waits between sending SIGTERM and the forced SIGKILL when a Pod is being terminated. This gives the main container process time to flush state, close connections, and complete cleanup. It is configurable per Pod in the Pod spec and defaults to 30 seconds; setting it appropriately is essential for graceful shutdown.

kubectl top pod is the correct command because it queries the metrics API (typically backed by metrics-server) to retrieve and display live CPU and memory usage for each pod. It shows current resource consumption at the container and pod level, and optionally displays per-container details with the --containers flag. This makes it the standard command for quick, immediate resource observation.

Editing the Deployment's pod template and applying the manifest updates the desired state, which makes the Deployment controller create a new ReplicaSet while scaling down the old one according to the configured strategy (default RollingUpdate). New pods are launched with the increased memory limit, and old pods are terminated only once the new ones are Healthy, keeping the service available throughout. Because the Pod spec is immutable, the template change is the declarative, supported path to alter resources without manual pod handling.

This is the correct command because it directly queries the metrics API for pod-level CPU and memory usage from the Metrics Server. The `-n` flag scopes the output to a specific namespace, and when combined with a pod name or label selector it shows live resource consumption for those pods. Without `-n`, it defaults to the current namespace, but specifying it explicitly ensures you are viewing the intended namespace.

The --previous flag specifically tells kubectl to display logs from the prior container instance that ran in the pod, typically one that has terminated due to a crash or a restart. The kubelet retains the terminated container's logs in a separate file, and this flag directs kubectl to that historical log while ignoring the current container's output. This is exactly what you need to diagnose why a container previously crashed, as it shows the last output before the failure.

This command queries the Metrics Server through the metrics.k8s.io API and prints per-container CPU and memory usage for the named pod. The --containers flag is required to break the output down by container when a pod has more than one, and it works fine for single-container pods too, giving exactly the usage figures needed to spot throttling.

The readiness probe is the correct mechanism because it directly controls whether a pod is added to or removed from the endpoints of a Service. When the probe fails, the kubelet marks the pod as NotReady, and the endpoints controller immediately removes its IP from all backing Services, stopping new traffic. This is essential for deployments where the application needs time to warm up or load data before accepting requests, and it also enables zero-downtime rolling updates by holding back new pods until they are fully operational.

Probe failures are surfaced as events on the pod, and the message includes the probe type, the failure detail, and the endpoint being tested. That directly shows whether the kubelet is dialing the wrong port or path, or whether the application is returning a failing status, which is exactly the distinction the engineer needs before changing anything.

kubectl exec pod-name -- env executes the env binary as a separate process inside the container's namespaces, printing all environment variables visible to that process. The -- delimiter tells kubectl that everything after it is a command to run inside the container, not a flag for kubectl itself. This non-interactive, single-command invocation is exactly suited for checking environment variables.

This field is the authoritative control for how long the kubelet will wait between sending SIGTERM and SIGKILL to a container during pod termination. Setting it to 60 explicitly grants the main process a 60-second window to handle the signal and shut down gracefully, whereas without it the default is only 30 seconds. This is the only direct mechanism for ensuring the pod receives SIGTERM and has time to react.

Relying solely on CPU utilization can miss memory-bound workloads, where pods degrade due to memory pressure long before CPU approaches its target. Adding a memory metric to the HPA—using targetAverageValue or targetAverageUtilization—makes the autoscaler react to actual resource exhaustion. Since memory is a non-compressible resource, Kubernetes cannot throttle it as it does with CPU, so the only effective mitigation is to add replicas when average memory consumption exceeds the configured threshold.

When a pod's CPU request exceeds the total allocatable CPU capacity on every node in the cluster, the kube-scheduler cannot find a feasible node and leaves the pod in Pending state. The scheduler compares each node's allocatable CPU against the sum of requests for all pods, and a `FailedScheduling` event with `Insufficient cpu` is recorded. This is a scheduling failure, not a runtime failure, so the pod remains Pending until a node with enough free CPU becomes available.

The --previous flag explicitly instructs kubectl to retrieve the logs written by the most recent terminated container instance of the pod. When a container has crashed or restarted, this shows the complete stdout/stderr from the old instance, which is often the only source of diagnostic information about the failure. It is the straightforward, unambiguous long-form command for viewing previous container logs.

kubectl describe pod outputs a detailed, human-readable summary of a pod's current state, including its metadata, spec, status, conditions, container states, restart counts, and, notably, a tail of recent events from the Kubernetes event stream. This event history is essential for debugging because it reveals scheduler decisions, image pull outcomes, and liveness/readiness probe failures that are not visible in the pod's YAML or its logs.

A readiness probe determines whether a pod can accept requests by periodically executing a check (HTTP, TCP, or command) inside the container; if the check fails because a required dependency, such as a database or configuration service, is not yet available, the pod is marked NotReady. The kubelet then removes the pod's IP from all backing Service EndpointSlices, so live traffic is never forwarded to a container that would fail the request. This prevents users from hitting a pod that is running but still initializing its dependent components.

kubectl top pod — correct because it directly invokes the top command with the pod resource type, without a specific pod name, which causes it to retrieve CPU and memory usage for all pods running in the current namespace from the metrics API. This is the exact syntax required to get a namespace-wide view of pod resource consumption.

The exec command 'cat /tmp/healthy' succeeds only if that file exists and is readable. If the application fails to create or regularly update this file, the command exits with a non-zero status, causing the liveness probe to fail. After the configured failureThreshold is exceeded, kubelet kills and restarts the container, matching the symptom of a restarting Deployment. This is the expected failure mode for this probe definition.

This statement is correct because readiness probes support the exact same four handler types as liveness probes: `httpGet` (sending an HTTP GET request to a specific path/port), `exec` (running a command in the container), `tcpSocket` (attempting a TCP connection to a port), and `gRPC` (performing a gRPC health check, available as a beta feature in recent Kubernetes versions). Each handler has its own configuration fields, but all are valid for determining container readiness. The readiness probe is defined under the `readinessProbe` key in the container spec.

CrashLoopBackOff is the Kubernetes state when a container repeatedly starts, exits with an error, and is restarted by the kubelet. A non-zero exit code from the main process signals that the application failed during startup or at runtime, prompting a restart. After each successive failure, the kubelet applies an exponential backoff (10s, 20s, 40s, up to 5m) to prevent tight restart loops, and this cycle produces the CrashLoopBackOff status. This option is correct because an immediate non-zero exit is the direct mechanism driving the crash loop.

The scheduler filters nodes by checking whether each node's allocatable CPU and memory can accommodate the pod's declared requests. When every node fails that check, the events on the pod show '0/N nodes are available' with 'Insufficient cpu' or 'Insufficient memory', and the pod remains Pending until resources free up or the request is lowered.

Setting spec.terminationGracePeriodSeconds to 35 is appropriate because this pod-level field defines the maximum time allowed between the kubelet sending SIGTERM and forcibly sending SIGKILL. With an expected shutdown time around 35 seconds, this value gives the container sufficient time to complete graceful cleanup without delaying cluster operations.

Once the grace period has elapsed, the kubelet sends SIGKILL (signal 9) to the container’s main process to force immediate termination. SIGKILL cannot be caught, handled, or ignored by the application, so the process dies instantly and the container is removed. This is the final step in the termination sequence: SIGTERM is sent first, and SIGKILL is the escalation when the process has not voluntarily exited within the configured terminationGracePeriodSeconds.

kubectl exec -it my-pod -- /bin/sh attaches an interactive TTY to the pod's sole container and launches a shell, satisfying the stem's requirement to run a command inside the existing container. Omitting -c is valid because the pod has only one container, so no container name is needed.

kubectl logs <pod-name> streams the container's stdout and stderr, which is exactly where a crashing application typically writes the error or stack trace before exiting. Because CrashLoopBackOff means the process starts, fails, and restarts, the logs usually contain the root cause, such as a missing dependency or a failed readiness check. If the container has already restarted, you must add --previous to retrieve the crashed instance's output, making this the first, most direct diagnostic step.

This command correctly narrows the event stream by using the field selector `involvedObject.name=web-1`, which matches the `involvedObject` metadata that every event carries about the resource it references. Field selectors operate on object fields, not labels, so this targets events whose involved object has exactly the name `web-1`. Since pod names are unique within a namespace, this returns all events for that pod, and you can further scope it with `--namespace` or `involvedObject.kind=Pod` if needed.

A startup probe is designed exactly for this scenario: it runs until it succeeds, and while it is active, the kubelet disables liveness and readiness probes. Configure failureThreshold high enough (e.g., 30) with a short periodSeconds, so the total startup allowance is failureThreshold * periodSeconds; once the startup probe succeeds, liveness and readiness probes resume normal operation. This cleanly decouples startup duration from liveness/readiness tuning and prevents restarts during slow initialization.

The -p (or --previous) flag is the correct way to retrieve logs from the previous container instance, as it explicitly instructs kubectl to read from the retained log buffer of the last terminated container. This is the standard diagnostic step when a container is in CrashLoopBackOff, and it works because the kubelet preserves the terminated container's logs until the pod is deleted; note that if no previous instance exists, this command returns an error.

kubectl debug -it pod-name --image=busybox --target=container-name creates an ephemeral container inside the existing Pod's sandbox, so it shares the same network namespace, IPC namespace, and (when --target is specified) the target container's process namespace. The ephemeral container includes the provided busybox image, giving you a shell (via -it) and common debugging tools even though the original container lacks a shell or has crashed. Because ephemeral containers are managed by the kubelet, the original Pod's spec and lifecycle are unaffected, and if the Pod is not running, kubectl debug will create a copy, so this is the right tool when no containers are running. The --target flag is what lets you see the crashed container's processes, but for ordinary filesystem inspection the ephemeral container also mounts the Pod's volumes.

Running `kubectl describe node <name>` is a core diagnostic action: it renders a human-readable summary that includes the node's addresses, allocatable resources, and a Conditions table (e.g., Ready, MemoryPressure, DiskPressure, PIDPressure). The command also surfaces operational events such as reboots or kubelet failures, making it the standard first look when a node is NotReady or under-resourced.

The tcpSocket probe instructs the kubelet to attempt a raw TCP connection to the specified port (e.g., `:8080`) and marks the container healthy if the three-way handshake completes successfully. It does not interpret any application-level response, so it is ideal for verifying that a listener is active on the port without requiring an HTTP or gRPC endpoint. This matches the requirement to check if the port is open and is therefore the correct choice.