Pods are the smallest and most basic unit of Kubetnetes(generally known as K8) and rollout is the process of removing old pods and starting new ones. kubectl rollout restart is a command which is used to restart a new rollout process for Kubernetes objects. The rollout process involves a step-by-step recreation process of pods.
In this tutorial, we’ll know exactly what kubectl rollout restart is, What is the purpose of using it, and How to use this command. With the help of this tutorial you will learn the step-by-step process of using kubectl rollout restart.
Here we’ll begin the process by creating a Deployment linked to a Secret object. Afterward, we’ll make changes to the Secret. And at the end, we’ll use the kubectl rollout restart command to initiate a new rollout ensuring the changes are picked up by the Deployment.
Let’s get started!
Table of Contents
What is kubectl rollout restart?
In the context of Kubernetes, kubectl is a command line interface (CLI) which is used to manage Kubernetes clusters. With the kubectl rollout restart command you can manage the rollout process of applications running on the platform.
This command is used to manage three specific Kubernetes objects: Deployment, DaemonSet, and StatefulSet.This command uses various sub-commands that help to manage different aspects of a rollout.
Using kubectl rollout command, you can view the status of a rollout, manage the updates to deployments, check the history of rollouts, and restart a rollout.
This command is used to manage complex applications that require multiple deployments, frequent updates and careful monitoring of the rollout process.
Why is Kubectl Rollout Restart Important?
There might be various key reasons to use kubectl rollout restart command. Some of them include:
- Updating ConfigMaps: When you want to update Secrets, environment variables, or ConfigMap, and your application to pick up the updated values it becomes important to run the command. In some cases, you may need to manually restart the pod for the changes to take effect.
- Troubleshoot and recovery: When your application has entered a bad state, the application is not running correctly, or experiencing any issues with it, it needs to be restarted, it can be a quick way to recreate all the Pods. It can be a good practice to restart or reset the significant pods to make troubleshooting and recovery easier.
- Pods stuck in a terminating state: In some cases, a node is taken out of service, and the pods cannot be removed from it. Restart will help you with addressing the issue.
- OOM(Out of Memory): Sometimes a pod is terminated with an OOM error then you may need to restart the pod after making significant changes to the resource specifications.
- Forcing a new image pull: You need to manually restart the pod to force a new image pull and if you are making changes to the image parameters.
- Resource conflict: If Pod is consuming excessive memory it can impact performance and workflows, in this situation you will need to restart the pod. It will help to release the resources and solve the issue.
- Undesirable Pod Status: If you see a pod in an undesirable state with ‘error’, you might try a ‘restart’ as part of your troubleshooting.
- CrashLoopBackOff: If you see the pod status CrashLoopBackOff, K8S tries to restart the pod automatically.
Prerequisites
- A running Kubernetes Cluster
- kubectl Command line tool Installed
- A valid Kubeconfig File
- Kubernetes Cluster Access
- Namespace Knowledge of the Deployment
- Permissions to perform actions on the Deployment resource
- Resource Details
Step-by-step Guide of Utilizing Kubectl Rollout Restart
In this section we will see the step-by-step process of using kubectl rollout restart command. But first we will define and create the secret object. So start with opening your code editor and create a folder.Then create two files for secret object and deployment object using .yaml extension
.
Now follow the steps given below:
Step-1: Define Secret Object
Go to the Secret object file and paste the following content:
apiVersion: v1
kind: Secret
metadata:
name: mysql-root-pass
type: Opaque
stringData:
password: mysql_secret_password
The Secret object has a key-value pair where the key is password , and the value is the actual password for the MySQL root account.
Step-2: Define a Deployment
Go to the Deployment object file and paste the following content:
apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql-deployment
spec:
replicas: 1
selector:
matchLabels:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
- name: mysql-container
image: mysql:8.0
env:
- name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-root-pass
key: password
In this deployment file, we have defined a deployment file with a name having mysql-deployment.
Here the Deployment manages a single Pod, which has a container running a MySQL database server.
MySQL Docker images require a root password to run successfully so we have stored the root password in the Secret object.
We will mount the Secret object in the Deployment as an environment variable named MYSQL_ROOT_PASSWORD so that it is automatically populated with the password when the container is launched.
Now, let’s get started creating Kubernetes objects.
Step-3: Creating the Secret
To create the Secret object run the following command:
kubectl apply -f <FILE-NAME>.yaml
Here, you need to replace <FILE-NAME>
with the same as the name of your file that contains the Secret object files.
This will create a Secret object named mysql-root-pass
.
@: ~/Desktop/kubernetes $ kubectl apply -f secret.yaml
secret/mysql-root-pass created
Step-4: Create the Deployment
You can create a Deployment object by running the following command:
kubectl apply -f <FILE-NAME>.yaml
Similarly replace the <FILE-NAME>
with the same as the name of your file that contains the Deployment object files.
This will create a Deployment named mysql-deployment
.
@: ~/Desktop/kubernetes $ kubectl apply -f secret.yaml
secret/mysql-root-pass created
Step-5: Check the Pod status
A pod has five statuses probably:
- Pending: At least one container in the pod hasn’t been created yet.
- Running: All containers have been created and running, are being started or restarted.
- Succeeded: All containers have been successfully terminated in the pod and will not be restarted.
- Failed: All containers have been terminated, and at least one container has failed.
- Unknown: The status of the pod cannot be determined.
After the Secret and Deployment creation, check the Pod status by:
kubectl get pods
This command will display a list of all the Pods running on your cluster:
@: ~/Desktop/kubernetes $ kubectl get pods
NAME READY STATUS RESTARTS AGE
mysql-deployment-7f8b6d4b8c-2bpbx 1/1 Running 0 42s
Find the Pod with a name starts with mysql-deployment
and ensure that it’s in the Running state.
Remember Kubernetes creates Pod names with unique characters to the name of the Deployment.
Step-6: Update the Secret object with a new root password
Update the password stored in the Secret object from mysql_secret_password
to mysql_super_secret_password
:
apiVersion: v1
kind: Secret
metadata:
name: mysql-root-pass
type: Opaque
stringData:
password: mysql_super_secret_password
Save the file and apply the changes using the commands:
kubectl apply -f <FILE-NAME>.yaml
@: ~/Desktop/kubernetes $ kubectl apply -f secret.yaml
secret/mysql-root-pass configured
Step-7: Check environment variable
Open a shell to the running container and then use the printenv
command to find the value of MYSQL_ROOT_PASSWORD
environment variable.
Run the following command to open and access the shell of the container:
kubectl exec -it <POD-NAME> -- /bin/bash
Replace <POD-NAME>
with the name of your Pod.
@: ~/Desktop/kubernetes $ kubectl exec -it mysql-deployment-7f8b6d4b8c-2bpbx -- /bin/bash
bash-4.4#
Now, run the following command to see the value of the environment variable available to the container:
printenv MYSQL_ROOT_PASSWORD
Here you can see, the container has not picked up the new password that we set in the Secret.
To ensure that the container uses the updated password, recreate the Pods using kubectl rollout restart
command.
Before running this command, type exit and press enter to come back to your local terminal.
Step-8: Triggering a new rollout
Now at our local terminal, run the following command to initiate a new rollout:
kubectl rollout restart deployment/mysql-deployment
@: ~/Desktop/kubernetes $ kubectl rollout restart deployment/mysql-deployment
deployment.apps/mysql-deployment restarted
You can see, the Deployment is restarted.
This New rollout process will replace the old Pod with a new one that will run the same container as the previous Pod, but with the changed password.
Step-9: Again Check Pod status
Now, check the Pod status again:
kubectl get pods
@: ~/Desktop/kubernetes $ kubectl get pods
NAME READY STATUS RESTARTS AGE
mysql-deployment-75c5bc4565-zbb cm 1/1 Running 0 75
Finally, you can see the new pods status is running, as a new Pod is running.
Step-10: Again Check the environment variable
Now we will check again the environment variable to ensure if the new pod is running with the updated password.
Open a shell to the running container using the command:
kubectl exec -it <POD-NAME> -- /bin/bash
Replace the <pod-name>
with yours one.
Next, check the value of MYSQL_ROOT_PASSWORD
environment variable by running the following command:
printenv MYSQL_ROOT_PASSWORD
@: ~/Desktop/kubernetes $ kubectl exec -it mysql-deployment-75c5bc4565-zbbcm -- /bin/bash
bash-4.4# printenv MYSQL_ROOT_PASSWORD
mysql_super_secret_password
You can see here, the new password mysql_super_secret_password
is now available to the container running the MySQL database server.
Before proceeding to the next section, exit the container shell by typing exit and enter.
Does kubectl rollout restart cause downtime?
Kubernetes uses a rolling update strategy for Deployments.
kubectl describe deployment/mysql-deployment
The process uses RollingUpdateStrategy
that ensures that Pods are being replaced gradually, not all at once.
Before removing the old Pod, a new pod is created with the updated version of the application. This way, the application runs without any downtime throughout the process.
Choose SupportFly’s Professional Kubernetes Consulting Services
Managing Kubernetes deployments can be a daunting and time-consuming task, here the role comes from Supportfly. From assessment and planning to cluster design, application containerization, security implementation, monitoring, and CI/CD integration – we cover all aspects of Kubernetes implementation and optimization.
SupportFly offers comprehensive Kubernetes consulting services. Our team of Kubernetes professionals can help you with:
- Kubernetes Assessment And Planning
- Kubernetes Cluster Design And Deployment
- Application Containerization And Orchestration
- Kubernetes Security And Governance
- Kubernetes Monitoring And Performance Optimization
- Continuous Integration And Delivery (CI/CD) With Kubernetes
Conclusion
In this blog post, you learned about the kubectl rollout restart command, the process of using this command, and its objective of use. Now you have equipped yourself with a valuable tool for effectively managing and updating Kubernetes Deployments.
Partner with us to level-up your Kubernetes operations and ensure your applications are always running at their best. Contact us today to learn more about our Kubernetes consulting services and how we can help you achieve your goals.
Restarting all pods in a deployment in Kubernetes can be achieved using the rolling update mechanism. This approach ensures minimal disruption to your application and provides version control and scalability benefits. By following the steps outlined, you’ll be able to effectively restart all pods in your Kubernetes deployment.