How to delete pods with kubectl in Kubernetes

Introduction

One of the most crucial features of managing a Kubernetes cluster for an application to be highly available and smooth in its operations involves keeping track of resources such as pods and services. Among the core commands, kubectl delete serves to gracefully delete or, when necessary, forcibly delete Kubernetes resources.

Understanding Basics of kubectl delete

kubectl delete provides a way to delete Kubernetes resources, say pods, services, or custom resources. The command does support multiple formats, from JSON and YAML files right to defining resources directly by their name, label, or type.

Some of the important options of the kubectl delete subcommand:

• --force: Forces to remove the resources without waiting for their graceful termination. Use this carefully, especially for stateful applications.
• --grace-period: The amount of time given to resources to terminate gracefully before being forcefully terminated.
• --now: Forces resources down immediately, with a 1 second grace period. --all: Delete all resources of this type in the namespace: namespace all.

Example Use Cases for kubectl delete

Let's go through a few scenarios where it is necessary to delete pods, scale replicas, and maintain safe deletions.

1. Graceful Termination of Pods

To gracefully delete a pod that correctly terminates the resources first, use:

kubectl delete pod <pod-name>

This will trigger the Kubernetes scheduler to recreate the pod, if necessary.

2. Force Delete a Pod

If a pod isn't responding, or you suspect is stuck, you can force delete it:

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

Be very cautious when using this option, because it bypasses the graceful shutdown process, which could result in data loss or inconsistency in case that pod hadn't freed resources up to such a point.

---

Monitoring GitHub Actions Workflows

CICube is a GitHub Actions monitoring tool that provides you with detailed insights into your workflows to further optimize your CI/CD pipeline. With CICube, you will be able to track your workflow runs, understand where the bottlenecks are, and tease out the best from your build times. Go to cicube.io now and create a free account to better optimize your GitHub Actions workflows!

---

3. Scaling Pods Before Deletion

When you have to ensure a certain minimum number of pods are running all the time for an application, it is common first to scale up the deployment before pod deletion. For example, if you must have three replicas at all times:

kubectl scale deployment <deployment-name> --replicas=4

Once the new pod is ready, delete the old one:

kubectl delete pod <pod-name>

Then, scale down to original number of replicas:

kubectl scale deployment <deployment-name> --replicas=3

4. Managing Pod Disruption Budgets

When you see something like:

Cannot evict pod as it would violate the pod’s disruption budget.

That would mean Kubernetes is ensuring enough replicas of your application are running to fulfill the requirements of the Pod Disruption Budget (PDB). You may want to check the disruption budget with:

kubectl get poddisruptionbudget -A

Sometimes-if necessary-you can remove the PDB:

kubectl delete poddisruptionbudget <pdb-name>

Best Practices for Resource Clean Up

1. Graceful Deletion: Perform a graceful deletion of pods or other resources, whenever possible, in order to avoid service disruptions.
2. **Use Force Sparingly: The --force flag is to be used only when a pod reaches a bad state. Since it bypasses the usual shutdown process, which may be due to resource conflicts, use it sparingly.
3. Pod Disruption Budgets: Apply Pod Disruption Budgets to critical applications so that accidental deletions will not bring down critical services.
4. Scaling for Availability: In case some operations, such as the deletion of pods, it is necessary to increase temporary replicas count in order not to affect these highly available services.
5. Prevention of Data Loss: When managing applications with a StatefulSet, ensure at all times that your application can afford to lose a pod before its' force deletion since stateful applications usually operate based on sticky identities with consistent data.

Conclusion

kubectl delete is an extremely powerful tool when it comes to managing Kubernetes resources, and most especially when dealing with pods. We have seen within this article that clearing pods from a cluster is very easy, but once you have to manage deletions in a production environment, things can get much more complicated. This goes especially when handling stateful applications or ensuring high availability. By following these best practices in scaling and leveraging pod disruption budgets, you safely manage resources in your Kubernetes cluster without disrupting any services.