Kubernetes Deployment

A Kubernetes Deployment is a higher-level abstraction used to manage and scale containerized applications while ensuring they remain in the desired operational state. It provides a declarative way to specify how many Pods should run, which container images they should use, and how updates or rollbacks should occur — all without downtime.

Key Capabilities of a Deployment

With a Deployment, you can:

Scale applications dynamically based on workload.
Maintain availability by ensuring the specified number of Pods are always healthy and running.
Perform rolling updates to deploy new versions seamlessly.
Rollback easily if a deployment introduces issues.
Automate self-healing, ensuring that failed Pods are recreated automatically.

Think of a Deployment as both a blueprint and a controller for Pods — it simplifies and automates most aspects of application lifecycle management in Kubernetes.

Common Use Cases

Kubernetes Deployments are widely used for managing application lifecycles. Common scenarios include:

Rolling out new applications:
Create a Deployment that launches a ReplicaSet, which in turn provisions Pods. You can monitor rollout progress using deployment status commands.
Seamless application updates:
Modify the PodTemplateSpec to trigger a new ReplicaSet. The Deployment automatically scales up the new version while gradually scaling down the old one — ensuring zero downtime.
Rollback to previous versions:
If an update introduces instability, roll back to an earlier revision easily.
Dynamic scaling:
Adjust the replica count manually or automatically using autoscalers to handle traffic fluctuations.
Pausing and resuming rollouts:
Pause a rollout to batch multiple updates together and resume when ready.
Monitoring rollout progress:
Check rollout status to confirm whether updates are progressing smoothly or stuck.
Resource cleanup:
Automatically remove obsolete ReplicaSets to maintain cluster efficiency.

Core Components of a Deployment

A Kubernetes Deployment consists of three key parts:

Metadata:
Includes the name and labels. Labels establish relationships between Deployments, ReplicaSets, and Services.
Specification (spec):
Defines:
- Number of replicas (Pods)
- Selector labels
- Pod template (template)
  The Pod template includes container specifications such as:
  - Container name
  - Image to use
  - Ports to expose
  - Resource limits (CPU, memory)
Status:
Automatically maintained by Kubernetes. It reflects the current state of the Deployment and enables self-healing. If the actual and desired states differ, Kubernetes reconciles them automatically.

Example: Nginx Deployment YAML


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

Commands:


# Create the Deployment
kubectl apply -f nginx.yaml

# Check status
kubectl get all

This will successfully create and deploy an Nginx application on your cluster.

Updating a Deployment

You can update Deployments in two main ways:

Method 1: Edit Using kubectl


kubectl edit deployment <deployment-name>

This opens the configuration in your terminal. Make the changes (press i to insert), then save and exit (Esc + :wq).

Method 2: Update the YAML File

Edit the YAML file directly (e.g., change container port from 80 to 8000), and reapply:


kubectl apply -f nginx.yaml

Rolling Back a Deployment

If an update causes problems, you can easily revert to a previous version.

Steps:

List all revisions:


kubectl rollout history deployment <deployment-name>

Rollback to a previous revision:


kubectl rollout undo deployment/nginx-deployment --to-revision=1

Validate:
Always test your rollback strategy to ensure minimal downtime during real incidents.

Viewing Rollout History


kubectl rollout history deployment/<deployment-name>

To view details for a specific revision:


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

This helps track configuration changes and revert if needed.

Scaling a Deployment

You can scale Deployments manually or automatically:

Manual Scaling:


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

Autoscaling:


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

Here:

--min=5: Minimum Pods always running
--max=8: Maximum Pods during high load
--cpu-percent=75: Scaling threshold based on CPU usage

Pausing and Resuming a Rollout

Pause a rollout:


kubectl rollout pause deployment/webapp-deployment

Resume the rollout:


kubectl rollout resume deployment/webapp-deployment

You can also update the container image during a paused rollout:


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

Deployment Status Phases

Kubernetes reports various statuses for a Deployment:

Status	Description
Pending	Deployment is initializing or waiting for resources.
Progressing	Deployment is rolling out changes or creating ReplicaSets.
Succeeded	Deployment completed successfully.
Failed	Deployment failed due to configuration or environment errors.
Unknown	API server cannot determine status or connection lost.

Check rollout progress:


kubectl rollout status deployment/<deployment-name>

Common Deployment Failures and Causes

Failure Reason	Description
Failed probes	Readiness or liveness probe misconfigured.
Image pull errors	Incorrect image name or tag.
Insufficient resources	Resource quota limits exceeded.
Dependency issues	Service dependencies (like databases) unavailable.

For detailed debugging:


kubectl describe deployment <deployment-name>

Canary Deployments

A Canary Deployment gradually introduces new versions of an application to a subset of users or Pods, allowing testing under real workloads before a full rollout.

Example Approach:

Deploy a new version to 50% of Pods while the rest continue serving the old version.
Based on feedback or monitoring results, either:
- Roll out to all Pods, or
- Roll back to the stable version.

Implementation Methods:

Traffic Splitting using Istio or other service mesh tools.
Blue-Green Deployment – maintain two environments (old and new) and switch traffic when ready.

ReplicaSet vs Deployment

ReplicaSet	Deployment
Ensures the specified number of Pods are running.	Manages ReplicaSets and automates Pod lifecycle.
Does not support rolling updates or rollbacks.	Supports both rolling updates and rollbacks.
Handles Pods directly.	Handles ReplicaSets, which in turn manage Pods.
Suitable for simple, static workloads.	Suitable for dynamic, frequently updated applications.

Summary

A Kubernetes Deployment simplifies managing applications by handling updates, scaling, rollbacks, and self-healing automatically. It abstracts away the complexity of direct Pod or ReplicaSet management, enabling you to define your application’s desired state and letting Kubernetes maintain it efficiently.

Search This Blog

AskTech