How to restart stuck pods in Kubernetes with kubectl

Why do pods get stuck in Kubernetes?

Managing containerized applications means constantly dealing with minor glitches and unexpected behaviors. In Kubernetes, which acts as a giant maestro organizing dozens of servers called nodes, a pod is the smallest execution unit. It groups one or more containers sharing network and storage resources. Sometimes, due to application bugs, memory shortages, or network issues, a pod simply freezes and refuses to die or start properly, getting stuck in an operational limbo.

When this happens, the most common command engineers try is removing the object, but the virtual machine or physical node might be experiencing communication issues with the central control plane, resulting in endless waiting. In practice, this means the Kubernetes API is trying to tell the local server to shut down the container, but the command never arrives or the operating system's internal process refuses to release resources. Understanding this scenario is the first step to acting safely before running destructive commands in your cluster terminal.

Identifying the problem with diagnostic commands

Before forcing any abrupt restart, you need to discover exactly where the bottleneck is happening. The basic command to list pods in your current namespace is one of the most important tools in site reliability engineering. To understand the real state of your application, you can execute a quick listing and observe the status column on your command screen.

kubectl get pods -n production

If you notice states like Terminating lasting too long, or repeated failure counts, the problem requires a deeper investigation. This is where analyzing cluster events comes in handy, revealing the recent interaction history of that specific component. For complex environments, it is also worth checking complementary practices, such as how to set up Prometheus alerts for restarting pods in K8s, ensuring visibility before end users notice any downtime.

How to force deletion of a pod stuck in Terminating

Often, a pod gets stuck in the terminating state because the internal container is ignoring the signal to gracefully shut down. Kubernetes waits for a standard period, known as the grace period, so active connections can close without data loss. If the application does not respond, the object remains visible in the list and the only way out is manual intervention by applying stricter command-line parameters.

To resolve this directly, you can order immediate removal by zeroing out the system's default waiting time. In practice, this tells Kubernetes to stop waiting for the affected server's response and clear the pod record from the cluster's internal database. The command below performs this force operation:

kubectl delete pod my-stuck-pod --grace-period=0 --force -n production

Although this command is extremely useful, it should be used cautiously in production environments. Forcing removal skips important resource cleanup steps and may leave temporary files or pending database locks on the source node.

Checking logs and events to prevent recurrence

Brute-force restarting a pod solves the immediate symptom but does not fix the root cause of the issue. If the container crashed due to a memory shortage or a fatal code error, it will fail again right after spinning back up. Therefore, investigating the traces left by the application is a mandatory step for any professional aiming to maintain long-term system stability.

The logs command allows you to inspect what the application was doing right before freezing or failing. Combining this reading with network and connectivity diagnostics, such as how to inspect mTLS traffic in Kubernetes pods with cURL, helps ensure that strict security policies are not blocking internal service communication. Check out how to capture the last lines of logs from the affected container: To explore these architectural concepts further in production, see our related technical analysis on How to inspect Docker logs in real time with docker logs.

kubectl logs my-stuck-pod --tail=100 -n production

Final considerations on cluster stability

Dealing with stuck pods is part of the daily routine for anyone operating modern infrastructure based on containers and complex orchestrators. Knowing when to use aggressive commands and when to investigate logs prevents minor software glitches from turning into major outages for customers. Keeping clear and documented procedures within the team speeds up incident recovery and ensures the system remains resilient even under adverse infrastructure scenarios.

The continuous evolution of monitoring and automation tools has made Kubernetes increasingly self-sufficient in recovering from common failures. However, practical knowledge of fundamental terminal commands remains an indispensable differential for resolving critical situations where automatic mechanisms fail. Keep studying the behavior of your nodes and always validate your resilience strategies in controlled environments.