What is a Kubernetes Deployment?
Kubernetes deployment is a high-level resource object by which you can manage the deployment and scaling of the applications while maintaining the desired state of the application. You can scale the containers with the help of Kubernetes deployment up and down depending on the incoming traffic. If you have performed any rolling updates with the help of deployment and after some time if you find any bugs in it then you can perform rollback also. Kubernetes deployments are deployed with the help of CLI like Kubectl it can be installed on any platform.
K8s Deployment Components
It mainly consists of three components:
Metadata: It consists of the name and labels for the configuration file. The labels are used for establishing the connection between deployment and services.
Specification: It consists of information regarding the number of replicas, selector labels, and template that is the blueprint for pods. The template itself is like a configuration file for pods and consists of metadata and specification for pods that stores information regarding the containers to be used in the pod, the image to be used for building the container, and the name and ports of the container.
Status: This component is automatically generated and added by Kubernetes. This is the basis of the self-healing feature of Kubernetes. If the desired status and actual status of a deployment do not match Kubernetes fixes the pod and matches it with the desired status.
Kubernetes Deployment Status
The deployment will pass different stages while it was in deploying. Each stage will say the health of the pods and shows us if any problems are arising.
Deployment status will help you to monitor the pods and you can take action immediately if you found any trouble or bugs in it.
Pending: Deployment is pending representing that it going to start or it is facing some issues to start.
Progressing: Deployment was in progress it was going to be deployed.
Succeeded: Deployment was deployed successfully without any errors or bugs.
Failed: Deployment was not deployed successfully it failed due to some issues.
Unknown: This happens if the kubernetes API is not reached for deployment or the problem with the deployment itself.
What are Kubernetes Deployment Strategies?
Kubernetes offers several deployment strategies to handle a broad range of application development and deployment needs. Once you define the desired state of the application, the deployment controller goes to work. It can make changes at a controlled rate to optimize the deployment.
1. Recreate Deployment
A recreate deployment strategy is an all-or-nothing process that lets you update an application immediately, with some downtime.
With this strategy, existing pods from the deployment are terminated and replaced with a new version. This means the application experiences downtime from the time the old version goes down until the new pods start successfully and start serving user requests.
A recreate strategy is suitable for development environments, or when users prefer a short period of downtime rather than a prolonged period of reduced performance or errors (which might happen in a rolling deployment).
2. Rolling Deployment
Rolling deployment is a deployment strategy that updates a running instance of an application to a new version. All nodes in the target environment are incrementally updated to a new version; the update occurs in pre-specified batches. This means rolling deployments requires two versions of a Service—one for the old version and another for the new version of the application.
The advantages of a rolling deployment are that it is relatively easy to roll back, is less risky than a recreate deployment, and is easier to implement.
3. Blue/Green Deployment
A blue/green deployment strategy enables you to deploy a new version while avoiding downtime. Blue represents the current version of the application, while green represents the new version.
This strategy keeps only one version live at any given time. It involves routing traffic to a blue deployment while creating and testing a green deployment. After the testing phase is concluded, you start routing traffic to the new version. Then, you can keep the blue deployment for a future rollback or decommission it.
4. Canary Deployment
A canary deployment strategy enables you to test a new application version on a real user base without committing to a full rollout. It involves using a progressive delivery model that initiates a phased deployment. Canary deployment strategies encompass various deployment types, including A/B testing and dark launches.
Typically, a canary strategy gradually deploys a new application version to the Kubernetes cluster, testing it on a small amount of live traffic. It enables you to test a major upgrade or experimental feature on a subset of live users while providing all other users with the previous version.
5. A/B Testing
A/B testing refers to canary deployments that distribute traffic to different versions of an application based on certain parameters. A typical canary deployment routes users based on traffic weights, whereas A/B testing can target specific users based on cookies, user agents, or other parameters.
An important application of A/B testing in Kubernetes is testing a few options of a new feature, identifying which one users prefer, and then rolling out that version to all users.
6. Shadow Deployment
Shadow deployments are another type of canary deployments where you test a new release on production workloads. A shadow deployment splits traffic between a current and a new version, without end users noticing the difference. When the stability and performance of the new version meets predefined requirements, operators trigger a full rollout.
The advantage of shadow deployments is that they can help test non-functional aspects of a new version, such as performance and stability.