How to restart stuck pods in Kubernetes with kubectl

Why do pods freeze in Kubernetes?

Managing containerized applications means dealing with situations where software simply hangs or stops responding to external commands. In Kubernetes, the orchestration system responsible for managing hundreds or thousands of containers, a pod can get stuck in anomalous states like Terminating or CrashLoopBackOff. In practice, this means the application inside the container stopped working properly, but the control plane is still trying to figure out what happened, leaving the service unavailable to end users.

When this happens, infrastructure engineers need to act quickly to restore the service without causing additional impacts on the architecture. Before making any drastic decisions, it is essential to investigate the root cause to prevent the error from recurring right after the restart. To complement your troubleshooting workflow, check out our guide on how to inspect logs with stern, which makes reading distributed output streams much easier.

How to identify pods in anomalous states

The first step in resolving any cluster issue is seeing exactly what is happening in each node and container. Using basic listing commands helps map which instances are consuming excessive resources or trapped in infinite restart loops. The standard command to list all pods in a specific namespace quickly reveals which ones show statuses other than Running or Completed, pointing out immediate suspects.

To run this initial scan efficiently, open your terminal and use the official cluster command-line tool to list active resources. Analyze columns like RESTARTS and STATUS to identify abnormal behaviors outside the application's normal baseline. If you notice network anomalies associated with the freeze, you can also check out our article on how to inspect Kubernetes pod traffic with Ksniff to capture packets in real time.

Forcing the restart of a specific pod

When a specific pod refuses to respond and freezes completely, the most direct approach is to delete it so the control plane can recreate a clean new instance. Since pods are ephemeral by nature—meaning they are designed to be discarded and replaced easily—deleting one does not cause permanent data loss if the architecture was designed correctly. The underlying controller, such as a Deployment, will notice the absence of the unit and immediately provide a healthy replacement.

To perform this quick targeted cleanup, use the deletion command specifying the exact name of the affected pod. This operation forces the immediate shutdown of the problematic process without affecting other pods that make up the same balanced service. Check the practical command below:

kubectl delete pod my-stuck-pod-xyz --namespace my-project

This command instructs Kubernetes to destroy the specified pod. If the stop process takes too long due to deep freezes in the application code, you can add a parameter to force immediate deletion without waiting for the default timeout period.

Controlled restart via Deployment

Often, restarting just an isolated pod does not solve the issue because the bug is rooted in the current code version or a corrupted configuration shared by all replicas. In these scenarios, the best operational practice is to restart the entire set of pods associated with a Deployment gradually and safely. This ensures the application continues handling requests while new instances replace old ones one by one, avoiding any total downtime.

To perform this controlled rollout and force the reloading of all application components, use the controller's batch restart command. This method applies a simulated configuration change that forces the system to perform the replacement process automatically. Run the following command in your terminal:

kubectl rollout restart deployment my-deployment --namespace my-project

This approach maintains system stability and ensures user traffic is directed only to containers that have successfully initialized. If you need more automation and control over future rollbacks of problematic updates, consider reviewing our material on how to automate Kubernetes rollouts rollback with ArgoCD.

Final considerations on cluster stability

Maintaining a healthy Kubernetes cluster requires constant vigilance, intelligent automation, and mastery of manual intervention tools. Knowing the exact moment to force the restart of a pod or an entire deployment separates a chaotic operation from mature, resilient infrastructure management. By applying the right commands and understanding the underlying behavior of containers, you guarantee high availability for end users and drastically reduce incident response times.

Adopting good monitoring practices and preventive testing complements your resilience strategy, preventing minor freezes from turning into widespread system failures. Keep studying the platform's internal mechanisms and testing new scenarios in controlled environments to further improve your skills in modern distributed systems administration.