Kubernetes Deployment

A Kubernetes Deployment is a high level resource used to manage and scale applications while ensuring they remain in the desired state. With a Deployment, you can:

• Scale applications up or down based on demand.
• Maintain reliability, ensuring the desired number of Pods are always running and healthy.
• Perform rolling updates to introduce new versions without downtime.
• Rollback easily if an update causes issues.

Think of it as both a blueprint and controller for Pods that simplifies application management in Kubernetes. A Deployment does not manage Pods directly. Instead, it manages ReplicaSets, and ReplicaSets manage Pods.

Use Cases of Kubernetes Deployments

Kubernetes Deployments are widely used to manage application lifecycles in a cluster. Typical use cases include:

• Rolling out new applications → Create a Deployment that launches a ReplicaSet, which in turn provisions Pods in the background. You can monitor the rollout status to verify success.
• Updating applications seamlessly → Modify the PodTemplateSpec in a Deployment to trigger a new ReplicaSet. The Deployment gradually scales the new ReplicaSet up while scaling the old one down, replacing Pods at a controlled pace. Each update increments the Deployment’s revision.
• Rolling back safely → Revert to a previous Deployment revision if the current rollout fails or becomes unstable. Each rollback generates a new revision.
• Scaling with demand → Increase or decrease replicas in a Deployment to handle varying traffic loads.
• Pausing and resuming rollouts → Temporarily pause a Deployment to apply multiple fixes to the Pod template, then resume it to roll out all changes at once.
• Monitoring rollout status → Use the Deployment’s status field to detect if a rollout is progressing or stuck.
• Cleaning up resources → Remove outdated ReplicaSets that are no longer needed to keep the cluster tidy and efficient.

Kubernetes Deployment Components

It mainly consists of three components:

1. Metadata: It consists of the name and labels for the configuration file. The labels are used for establishing the connection between deployment and services.
2. Specification: Defines replicas, labels, and a pod template that includes container details like image, name, and ports.
3. 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 YAML

We will be using Minikube to use Kubernetes on our local machine. The Deployment configuration file for Nginx will be:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx
spec:
 selector:
 matchLabels:
 app: nginx
 template:
 metadata:
 labels:
 app: nginx
 spec:
 containers:
 - name: nginx
 image: nginx
 resources:
 limits:
 memory: "128Mi"
 cpu: "500m"
 ports:
 - containerPort: 80

Now first open the directory where you have created nginx.yaml file in your terminal and create deployment using the command:

kubectl apply -f nginx.yaml

Now check the status of your deployment if it is ready or not by running the command

kubectl get all

Hence we have successfully deployed created a deployment for Nginx.

Updating a Kubernetes Deployment

To update a Kubernetes deployment we can simply update its config file using 2 methods:

Method 1: Using the kubectl edit command from the terminal

kubectl edit deployment deployment-name

Now you can edit the deployment configuration by pressing "i" for inserting and after editing it you can just press the escape key and then ":wq" to save your changes and exit.

Method 2: Updating Configuration Directly

You can open your config file in an IDE like VS Code and edit the config there and apply the config by using the command

kubectl apply -f deployment_config.yaml

Let's say in this case we are updating the container port from 80 to 800.

Rolling Back a Kubernetes Deployment

In kubernetes deployment, you can revert back to the previous version of the application if you find any bugs in the present version. It will help you to reduce the problems which are facing by the end users in the current version or updated version of the application.

The following steps can be followed for rolling back a deployment:

Step 1: First list all the revisions by using the following command and select the version of deployment to which you want to roll back.

kubectl rollout history deployment/nginx

Step 2: If you want to roll back to the previous version of the deployment you can do that by using the following command. it will roll back the immediate version of deployments.

kubectl rollout undo deployment/nginx-deployment --to-revision=1 (You can Mention the required version)

Step 3: Reverting back to the previous version of the application will help us to reduce the downtime for the customers It's crucial to regularly test and validate your rollback process to ensure its effectiveness in real world scenarios.

Checking the Rollout History of a Kubernetes Deployment

Rollout history can be seen by using the following command.

kubectl rollout history <name of the deployment>

This command allows you to view the no.of revisions available in the kubernetes cluster and changes made to them. If you want to see the detailed history of a specific version then you use the following command.

kubectl rollout history deployment/web-appdeployment --revision=3

Rollout history will help you to roll to previous versions of the application if you find bugs or problems in the currently deployed version of the application.

Command to Scale a Kubernetes Deployment

Scaling the deployment can be done in many ways we can do it by using the following command.

kubectl scale deployment/tomcat-1stdeployment --replicas= 5

You can do the scaling of the pods with the help of horizontal pod autoscaling by enabling it in the cluster where you chose the required no.of pods to run continuously if there is traffic or not and how many no.of pods should be run while the incoming traffic is increased.

kubectl autoscale deployment/tomcat-1st deployment --min=5 --max=8 --cpu-percent=75

--min= 5 defines how many minimum no.of pods are to be run if there is traffic or not and if there is sudden traffic --max= 8 to how much it can maximize it and it depends upon the --CPU-percent.

Pausing and Resuming a rollout of a Kubernetes Deployment

You can pause the deployments which you are updating currently and resume the fallout updates for deployment when you feel that the changes are made correctly you can use the following command to pause the rollouts.

kubectl rollout pause deployment/webapp-deployment

To resume the deployment which is paused you can use the following command.

kubectl rollout resume deployment/webapp-deployment 

When you pause the rollouts you can update the image by using the following command. Then the current version of the deployment will be replaced with the image which we are going to update.

kubectl set image deployment/webapp-deployment webapp=webapp: 2.1

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.

There are a few deployment statuses as follows which will show the health of the pods there are.

1. Pending: Deployment is pending representing that it going to start or it is facing some issues to start.
2. Progressing: Deployment was in progress it was going to be deployed.
3. Succeeded: Deployment was deployed successfully without any errors or bugs.
4. Failed: Deployment was not deployed successfully it failed due to some issues.
5. Unknown: This happens if the kubernetes API is not reached for deployment or the problem with the deployment itself.

Deployment status will help you to monitor the pods and you can take action immediately if you found any trouble or bugs in it.

Progressing Kubernetes Deployment

If any deployment is in progress it is meant to be that deployment is in the stage of updating or creating a new replicaset. Following are some of the reasons that deployment is in progress.

• The deployment is creating for the first time or it was creating a new replicaset.
• If the deployment is going under the updation or scaling then it will be in progress.
• The deployment will be in progress when the pods are scaling down or the pod is getting started.

If you want to troubleshoot the deployment then you can use the following command.

kubectl describe deployments

Complete Kubernetes Deployment

The following conditions must be satisfied to mark deployment as completed.

1. All the replicas of the pods must be up and running.
2. The desired count of pods must match the running count of pods.
3. All the replicas of the pods which are associated with the deployment must be available.
4. There must be no single replica of old pods must be running.

To check the status of the pods which are running you can use the following command.

kubectl rollout status <deployment/name of deployment>

Failed Kubernetes Deployment

Deployment may fail for several reasons when you try to deploy its newest ReplicaSet it may be in an incomplete position forever. This can cause for different reasons following are the reasons.

• There is a failure of the readiness probe and liveness probe.
• Error while pulling the image (Mentioned the wrong tag).
• There may be insufficient quota while deploying as we mentioned resources.
• The deployment cannot connect to a dependency, such as a database.

To get more information about the deployment and why is was failed you can use the following command. Which gives you a detailed description of the deployment.

kubectl describe deployments 

Canary Deployment

A canary deployment is a release strategy where a new version of an application is deployed alongside the stable version and exposed to a small percentage of production traffic first.

• Risk Isolation: Deploys a new version to a tiny subset of users (e.g., 5%) to detect bugs without impacting the entire user base.
• Metric-Driven Validation: Success is determined by comparing real-time telemetry (latency, error rates, KPIs) between the "canary" and the stable version.
• Traffic Weighting: Unlike standard updates, traffic is split via logic or networking rules rather than simply the number of active servers/pods.
• Incremental Progression: Traffic is shifted in stages (e.g., 5% → 25% → 50% → 100%) only after the new version proves stable at each tier.
• Instant Rollback: Enables immediate redirection of 100% of traffic back to the stable version if performance degrades, ensuring high availability.
• Istio Advantage: Using a service mesh allows for precise layer 7 routing (e.g., routing based on headers or cookies) without changing application code.

Blue/Green Deployment

Blue/Green Deployment is a release strategy where two identical production environments are maintained to reduce downtime and deployment risk.

• Dual Environments: Maintains two identical, hardware-isolated production environments: Blue (live) and Green (staging/new).
• Zero Downtime: Traffic is switched at the router or load balancer level, enabling an instantaneous transition between versions.
• Full-Scale Validation: Allows for comprehensive testing of the new version in a production-identical environment before any users see it.
• All-or-Nothing Switch: Unlike Canary, 100% of traffic is flipped from Blue to Green at once, rather than incrementally.
• Instant Rollback: If Green fails post-launch, traffic is immediately routed back to Blue, which remains untouched and functional.
• Resource Intensive: Requires doubling infrastructure capacity since two full environments must run concurrently during the deployment window.

Key Difference

• Canary Deployment → Gradual traffic shifting and progressive validation.
• Blue/Green Deployment → Instant full traffic switch after validation.