Restarting a Kubernetes pod can be necessary to troubleshoot issues, apply configuration changes or simply ensure the pod starts fresh with a clean state. With the power of kubectl, you’ll be able to gracefully restart pods without disrupting the overall application availability.
This post will walk you through the process of restarting pods within a Kubernetes cluster using the command-line tool, kubectl.
Let’s dive in and learn how to effectively restart Kubernetes pods using kubectl! But first …
In Kubernetes, a pod is the smallest and most basic deployment unit. A pod represents a single instance of a running process within a cluster. A K8s pod encapsulates one or more containers, storage resources and network settings that are tightly coupled and need to be scheduled and managed together.
Think of it like a container with 1 or more beer bottles, and the bartender, in this case, is Kubernetes.
Containers within a pod share many things like the same network namespace, allowing them to communicate with each other over localhost. They can also share the same storage volumes, making sharing data and files between containers in the same pod easier.
Like many things, K8s pods also have a lifecycle. Let’s take a look.
Note: Some kubectl commands display a pod as terminating while it is being destroyed. One of the pod phases is not this Terminating state. A pod is given a term to end gracefully, which is 30 seconds by default.
A pod should continue to function until it is replaced by a new deployment. As a result, a pod cannot be restarted; instead, it must be replaced.
There are a few alternative ways to accomplish a pod “restart” with kubectl. While there is no kubectl restart [podname] command for usage with K8S, you can use Docker:
docker restart [container_id]
We shall discuss those methods too, if you are in a hurry, scroll down to the commands section.
There are several reasons why you may need to restart Kubernetes pods:
When you make changes to the configuration of your application or the environment it runs in, restarting pods can be necessary to apply those changes. This includes updates to environment variables, resource limits, volume mounts or any other configuration parameter that requires a pod restart to take effect.
When you deploy a new version of your application, restarting pods is often required to ensure that the updated code or container image is running.
If your application is experiencing issues or behaving unexpectedly, restarting pods can be a troubleshooting step to resolve the problem.
In some cases, pods may need to be restarted to address resource constraints. For example, if a pod is running out of memory or experiencing high CPU usage, restarting it can help reclaim the resources and restore normal operation.
When making changes to networking configurations or service discovery mechanisms, restarting pods can be necessary to ensure that the pods are properly connected to the updated network.
In situations where a pod’s internal state becomes corrupted or inconsistent, restarting the pod can help reset the state and start fresh.
Restarting pods periodically can be a part of performance optimization strategies.
In layman’s terms, Namespaces in Kubernetes can be described as the “Harry Potter Sorting Hats” of the cluster world. Just like Hogwarts houses students based on their traits, Kubernetes namespaces sort and separate workloads based on their teams or projects.
It’s like having magical boundaries around your resources, making sure they play nicely with others, and preventing any sneaky spells from causing chaos in the cluster.
In technical terms, Kubernetes uses namespaces as a way to create virtual clusters within a physical Kubernetes cluster. Namespaces provide a way to divide resources and isolate them from each other, enabling multiple teams or projects to run their workloads independently and securely within the same cluster.
Each namespace acts as a logical boundary, organizing and separating
resources such as pods, services, deployments and more.
Here’s an example to illustrate the usage of namespaces in Kubernetes.
Suppose you have a Kubernetes cluster with multiple teams, Team A and Team B, who need to deploy their applications. Without namespaces, there would be a risk of naming conflicts (conflicts are risky in prod) and resource collisions between the two teams. However, by leveraging namespaces, you can create separate environments for each team within the same cluster.
kubectl create namespace team-a
kubectl create namespace team-b
kubectl create deployment my-app --image=my-image --namespace=team-a
kubectl get pods --namespace=team-a
By utilizing namespaces effectively, Kubernetes enables teams to work concurrently and independently within a shared cluster environment, maintaining separation and ensuring resource efficiency.
Now let’s review kubectl commands for restarting Kubernetes pods.
Now that we understand why we need to restart Kubernetes pods, let’s explore all the ways in which we can.
There are a few methods to restart Kubernetes pods using the kubectl command-line tool:
If your pods are managed by a Deployment or StatefulSet, you can perform a rolling restart to gracefully restart the pods one by one without impacting the availability of your application. To trigger a rolling restart, you can use the kubectl rollout restart command followed by the name of the Deployment or StatefulSet. For example:
kubectl rollout restart deployment/my-app
This command initiates the rolling restart process, creating new pods with the updated configuration or image, and terminating the old pods gradually. This method can be used as of K8S v1.15.
If you don’t have a Deployment or StatefulSet managing your pods, you can delete the existing pods and let Kubernetes recreate them with the same configuration.
First, you can list the pods to identify the ones you want to restart:
kubectl get pods
Then, delete the pods using the kubectl delete pod command followed by the pod name. For example:
kubectl delete pod my-app-pod-123
Kubernetes will automatically create new pods to replace the deleted ones, ensuring your application remains running. You can use the following command to delete the ReplicaSet:
kubectl delete replicaset <name> -n <namespace>
Another method is to scale down the number of replicas for your pod deployment to zero and then scale it back up. This effectively terminates the existing pods and creates new ones.
To scale down the number of replicas, use the kubectl scale command with the desired number of replicas set to zero. For example:
kubectl scale deployment/my-app --replicas=0
After scaling down, you can scale up the deployment again to the desired number of replicas, triggering the creation of new pods:
kubectl scale deployment/my-app --replicas=3
You can add ‘-n <namespace>’ flag with the above command.
Scaling a kubernetes cluster can be done via different scaling solutions like AWS Karpenter and Kubernetes Cluster Autoscaler.
The pod will restart to implement the modification if an environment variable linked to it is set or altered. The example below restarts the pod by setting the environment variable DEPLOY_DATE to the chosen date.
kubectl set env deployment -n "$(date)" DEPLOY_DATE="$(namespace)"
Using a restart policy, Kubernetes may be set up to automatically restart pods that fail. The Always restart policy, which restarts the pod whenever it fails or is deleted, is the most popular restart setting.
How to set a restart policy is as follows:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
restartPolicy: Always
containers:
- name: my-container
image: my-image
kubectl apply -f my-pod.yaml
pod/my-pod created
Whenever the pod crashes or is deleted, Kubernetes will automatically create a new pod to replace it.
This wraps up all the common methods to restart K8s pods.
Remember that when you restart pods, there might be a temporary disruption in your application’s availability. It’s important to consider any dependencies or impacts on your workload before initiating a restart.
It’s worth noting that Kubernetes provides mechanisms like rolling updates and lifecycle hooks to minimize the need for manual pod restarts in certain scenarios. However, there are cases where a manual restart is still necessary to ensure the desired state or troubleshoot problems effectively.
However, if you need to restart a single pod, you can use the kubectl delete command or scale down the deployment and then scale it up again using the kubectl scale command.
Happy kubeclt-ing.
If you would like to be a guest contributor to the Stackify blog please reach out to stackify@stackify.com