Pods contain many containers. Several pods are application containers, and they perform their role. Kubectl has no straightforward way to restart different pods. We need to run the pods till they are swapped as a measure of utilization. This is generally the case while issuing an original form of the container image.
The Kubernetes pod works without intrusion, but we may run into complications with the container not functioning properly. We can return the operations to a standard state by resuming the pod. We can use Rolling Restart to resume the pods from the deployment one at a time. This method is the suggested methodology as this method does not cause a service outage.
For running the commands in Kubernetes, we install Ubuntu 20.04. Here, we utilize the Linux operating system to execute the kubectl commands. Now, we install the Minikube cluster to run Kubernetes in Linux. Minikube offers an extremely smooth understanding as it provides an efficient mode to test the commands and applications.
In this article, we restart the Kubernetes pod. This article shows how to resume a pod in deployment with a variety of ways.
Methods to Restart Pods:
To resume the pod by the use of Kubectl, we start the Minikube.
Start Minikube:
In the terminal, we write the command “minikube start”. After this, we wait a while until it effectively starts. The output of this command is given underneath:
This method is time-consuming, and we will wait for a while to execute the procedure efficiently.
Get Deployments:
Now, let’s get deployments by using the command “kubectl get deployments”. Now, we can list the pods by using the following command:
After running the command, “kubectl get deployments”, it displays the name, ready state, up-to-date, availability, and age of deployments.
Method 1:
Rolling restart is utilized to resume every pod after deployment. For a rolling restart, we run the following command:
After running the command mentioned above, Kubernetes shuts down slowly and substitutes pods, but some containers are always running. Due to the gradual nature of the rollout, we can continue to serve the users, while efficiently rebooting the pod.
Method 2:
Another way to restart the pod is to reduce the number of replicas to 0 and scale back to the proper state. This requires all existing pods to exit, and a new pod is scheduled in its place. If we limit the number of replicas to 0, it will stop. Therefore, a rolling restart is recommended. Set the replica to 0 by using the following command. There is one limit to manually regulating the number of replicas. Reducing it to 0 will result in an interruption with no pods accessible to the user. Scale down the replicas to 0, and all current pods will be deleted:
This command identifies the number of deployments that have to be dynamic per pod. When we set it to zero, it effectively kills the process. If we set the value of replicas to 0, Kubernetes will discard the replicas that we don’t want.
We set the value of the replica to greater than 0 to restart the pods. Another option is to recruit a rolling restart that allows us to substitute a large number of pods without idle time. To resume the pod, we utilize a similar command and provide the value of replicas greater than zero:
When we set the replicas greater than zero, Kubernetes constructs a new replica. The name of the new replica is unlike the old replica.
We wait for the pods to be terminated and then utilize the “kubectl get pods” command to validate the pod’s position and check the new name. Kubernetes constructs a new pod with a new occurrence. The deployment is generated effectively. Then we utilize the following command to enlist the pods. The deployment detects the variation in status and activates new pods until the preferred replicas are attained:
Method 3:
ReplicaSet detects the pod disappeared because the container occurrences demolish underneath the number of target replicas. We use the following command:
Replica Set occurs to return minimum accessibility. A new pod will be constructed spontaneously, and a new container will be started in place of the old container.
We recommend utilizing the Rollout command that is clearer and intended. However, if we identify the ID of a single malfunctioning pod in a deployment, it’s useful to remove it manually. The rollout substitutes all achieved pods but not the failed pod.
Conclusion:
Kubernetes is an operative platform for coordinating containers. As with all systems, it causes problems. Therefore, resuming the pod does not fix the underlying problem that initiated the pod to fail. The rollout is the recommended key for the latest Kubernetes. On the other hand, other methods work and maybe more suitable for a particular situation. Manually deleting pods is idyllic if we want to “reboot” a single pod without interruption. However, if we are running multiple replicas, we cannot utilize the rollout command. We hope you found this article useful. Check out Linux Hint for more tips and information.
