How to restart stuck Kubernetes pods using kubectl

Why do pods get stuck in anomalous states?

In the world of Kubernetes, which is a container orchestrator responsible for managing large-scale applications, it is common for service instances to get stuck in states like Terminating or CrashLoopBackOff. This happens when an internal process fails to shut down gracefully or when an infrastructure failure prevents resources from closing. For system administrators and developers, dealing with this scenario requires direct command-line intervention to prevent prolonged service disruptions.

When an application refuses to die, the control system keeps waiting for the termination signal to be recognized by the application. In practice, this means the virtual machine or cluster node continues allocating memory and CPU to a ghost process. Identifying this anomaly quickly is the first step toward restoring environment health and ensuring user traffic is redirected to active, functional instances.

Before applying any drastic forced removal measures, it is worth investigating what is happening behind the scenes. Much like how to stream logs from multiple Kubernetes pods at once, isolating the origin of the freeze prevents you from destroying important diagnostic data. Preliminary investigation ensures the root cause is fixed, preventing the same anomalous behavior from repeating on the next code update.

How to identify stuck pods with basic commands

The first essential command in troubleshooting routines is listing running resources in the current namespace. Using the standard Kubernetes query command helps map out exactly which units are exhibiting suspicious behavior. When you run the listing, states like Unknown or ContainerCreating stuck for more than a few minutes already raise a red flag in operations.

To perform this initial scan efficiently, use the terminal to filter out problematic components. The following command displays all pods and their respective current states in the cluster:

kubectl get pods -A --field-selector=status.phase!=Running

This quick query saves precious time in complex environments with hundreds of microservices running simultaneously. By restricting the view only to elements not operating normally, you focus attention precisely where technical intervention is required, without visual distractions on the monitor.

Forcing pod removal with kubectl delete

When the application completely ignores traditional shutdown signals, you must resort to controlled brute force. The command-line utility lets you send a direct deletion order, but we often need to shorten the tolerance time the system grants for the process to wind down. This tolerance time is technically known as the grace period.

To zero out this waiting time and destroy the stuck pod immediately, we apply specific parameters to the deletion instruction. Run the command below, replacing the resource name with your environment's actual identifier:

kubectl delete pod pod-name --grace-period=0 --force

In practice, this means Kubernetes will remove the pod reference from the control panel instantly, instructing the underlying node to forcefully kill any remaining processes. This maneuver must be used with caution, as ongoing transactions or temporary file writes might be abruptly interrupted, creating point-in-time inconsistencies.

Strategies for pods managed by deployments

Forcing the deletion of an isolated pod does not always solve the ultimate problem if the underlying controller insists on recreating it with the same corrupted configuration. In modern production environments, most pods belong to a deployment or a replica set, which act as automatic templates to maintain the correct number of active instances.

When the template itself is corrupted, the best approach is to restart the entire deployment in a controlled manner. This forces a rolling update where new healthy instances are created before the old ones are completely discarded. Use the following command to restart the manager object:

kubectl rollout restart deployment deployment-name

This approach ensures network traffic does not suffer abrupt drops, as the cluster's internal balancer directs requests only to the new pods once they pass liveness probes. It is the most elegant and secure way to clean up anomalous states at scale without resorting to manual destructive deletions. To complement this implementation in production environments, see our related technical analyses on Stuck container? How to inspect Docker logs in real time and How to audit user permissions on Linux with auditd.

Final considerations on cluster resilience

Managing stuck pods in Kubernetes is an indispensable skill for maintaining the operational stability of any modern container-based infrastructure. Understanding tolerance times and knowing when to apply forced deletions or deployment restarts prevents hours of downtime in critical systems. Keeping clear documented procedures for the team reduces incident stress and builds a strong culture of reliability and engineering resilience.

Constant troubleshooting practice combined with good observability turns complex problems into simple maintenance routines. By mastering these control tools, you ensure your architecture remains agile, self-healing, and ready to absorb unexpected failures without compromising the final user experience.