Kubernetes Deployment for Zero Downtime
Introduction
In Kubernetes (K8s), a Pod is the smallest resource unit used to run one or more containers during deployment. There are several ways to create a Pod: you can create it directly, use a ReplicationController, or a ReplicaSet. However, the most commonly used resource for managing Pods is the Deployment. When you use a Deployment, it actually creates a ReplicaSet to manage the Pods but comes with many additional benefits that support the deployment process.
Some Advantages of Deployment:
- Ensures Pod Availability: It guarantees that the specified number of Pods are always running according to the configuration, automatically deploying additional Pods if any failures occur.
- Supports Restart and Undo Deployment: Allows you to easily restart or roll back to previous versions of your Deployment.
- Zero Downtime Deployment: When updating configurations or scaling Deployments, zero downtime is crucial. This means that new Pods are created while the old Pods are still running, ensuring that users can continue to use the service during the deployment. Once the new Pods are up and running, the old Pods are gradually removed, completing the deployment process without any interruption.
Prerequisites
Before proceeding, make sure you have:
- Installed `kubectl` or using local K8s with Kind.
- Installed the Google Cloud CLI if you are using Google Cloud Provider.
- Initialized a cluster before creating K8s resources.
Create Deployment
First, create a `deployment.yml` file that includes both the Deployment and Service configurations as follows:
- The default nginx container uses port 80, so you only need to set the service port to 80 to automatically map the container port to the service port.
- Feel free to replace the deployment name, label name, and service name with values that suit your needs. I've clearly defined the resource names to make them easier for you to recognize. You can use the same value for Deployment, Service, and Label if these resources are related.
To create the resource, apply the following:
Checking the created resources:
You can see that the Deployment and Service have been created as defined in the configuration file. Additionally, a ReplicaSet has been automatically created to manage the Pods. The number of Pods corresponds to the `replicas` field in the manifest.
Access the EXTERNAL-IP to verify that nginx is running successfully.
Next, use the following command to update the image. This is useful when deploying a new version.
Notice that the initial version used is `nginx:1.14.2`. After updating, it becomes `nginx:1.16.1`.
To see the process of deleting old Pods and creating new Pods when updating resources.
To check the status of a Deployment when creating new resources or updating existing ones:
To view the rollout history, which shows the versions that have been updated:
Next, perform a rollback to the previous version. This is useful if the current deployed version has errors and you need to revert to the last working version.
You can also specify which version to roll back to as follows:
The revision number is the value taken from the rollout history.
If you have any suggestions or questions about the article, please feel free to leave a comment below!
Comments
Post a Comment