🚀 Kubernetes Deployments Explained ⚙️
In this post, we take a deep dive into Kubernetes Deployments — the backbone of running scalable, resilient applications in production. You’ll learn how deployments manage pods, handle updates, scale seamlessly, and support advanced rollout strategies like Blue/Green and Canary deployments.
1. Basic Deployment 🧱
We started with a simple nginx deployment defined in 01-nginx-deployment.yaml:
apiVersion: apps/v1 # API group and version for Deployments
kind: Deployment # Declares this resource as a Deployment
metadata:
name: nginx-deployment # Name of the deployment
labels:
app: nginx # Label used for identification
spec:
replicas: 3 # Number of pod replicas to run
selector:
matchLabels:
app: nginx # Tells the deployment which pods it manages
template:
metadata:
labels:
app: nginx # Labels applied to the created pods
spec:
containers:
- name: nginx # Container name
image: nginx:1.14 # Docker image and version
This deployment ensures that three nginx pods are always running.
Kubernetes continuously monitors the pods and automatically recreates them if one fails.
To apply this deployment, save the file and run:
kubectl apply -f 01-nginx-deployment.yaml.
2. Core Deployment Commands 🛠️
# Create deployment
kubectl apply -f exercises/1-basics/deployments/01-nginx-deployment.yaml # Creates or updates the deployment based on the YAML file
# View deployments
kubectl get deployments # Lists all deployments in the current namespace
# Describe deployment
kubectl describe deployment nginx-deployment # Shows detailed information, events, and rollout status
# Scale deployment
kubectl scale deployment nginx-deployment --replicas=5 # Increases the number of running pods to 5
# Update image
kubectl set image deployment/nginx-deployment nginx=nginx:1.16 # Triggers a rolling update by changing the container image
# Check rollout status
kubectl rollout status deployment/nginx-deployment # Monitors the progress of the rolling update
# Rollout history
kubectl rollout history deployment/nginx-deployment # Displays previous revisions for rollback purposes
# Rollback
kubectl rollout undo deployment/nginx-deployment # Reverts the deployment to the previous stable version
3. Deployment Strategies 🔁
A. Blue / Green Deployment 🔵🟢
This strategy runs two identical environments. Traffic is switched instantly via a Service selector.
# Blue Deployment (Current production version)
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-blue
labels:
app: nginx
version: blue # Identifies this as the blue version
spec:
replicas: 3
selector:
matchLabels:
app: nginx
version: blue
template:
metadata:
labels:
app: nginx
version: blue
spec:
containers:
- name: nginx
image: nginx:1.14 # Stable production image
ports:
- containerPort: 80
The blue deployment represents the currently live version. Traffic is routed here by a Service selector, ensuring users see the stable release.
# Green Deployment (New version)
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-green
labels:
app: nginx
version: green # Identifies this as the green version
spec:
replicas: 3
selector:
matchLabels:
app: nginx
version: green
template:
metadata:
labels:
app: nginx
version: green
spec:
containers:
- name: nginx
image: nginx:1.16 # New candidate version
ports:
- containerPort: 80
The green deployment runs alongside blue without receiving traffic. Switching traffic only requires updating the Service selector, allowing instant rollback if issues are detected.
🔵🟢 Blue / Green Deployment — Required Changes
File to create or update: services/nginx-service.yaml
apiVersion: v1 kind: Service metadata: name: nginx-service spec: selector: app: nginx version: blue # CHANGE THIS VALUE TO SWITCH TRAFFIC ports: - port: 80 targetPort: 80
This Service controls which deployment receives traffic. Initially, it points to version: blue. To switch traffic to Green, change version: blue to version: green and reapply the file.
Command to apply the change:
kubectl apply -f services/nginx-service.yaml
B. Canary Deployment 🐤
Canary deployments allow gradual exposure of a new version with reduced risk.
# Stable Deployment (90% of traffic)
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-stable
labels:
app: nginx
version: stable
spec:
replicas: 9 # Majority of traffic
selector:
matchLabels:
app: nginx
version: stable
template:
metadata:
labels:
app: nginx
version: stable
spec:
containers:
- name: nginx
image: nginx:1.14
ports:
- containerPort: 80
This deployment represents the main production workload. Most users continue to hit the stable version while testing occurs.
# Canary Deployment (10% of traffic)
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-canary
labels:
app: nginx
version: canary
spec:
replicas: 1 # Small percentage of traffic
selector:
matchLabels:
app: nginx
version: canary
template:
metadata:
labels:
app: nginx
version: canary
spec:
containers:
- name: nginx
image: nginxdemos/hello
ports:
- containerPort: 80
The canary deployment receives a small portion of traffic, allowing teams to validate changes in production before scaling further.
🐤 Canary Deployment — Required Changes
File to create or update: services/nginx-canary-service.yaml
apiVersion: v1 kind: Service metadata: name: nginx-canary-service spec: selector: app: nginx ports: - port: 80 targetPort: 80
This Service sends traffic to both Stable and Canary deployments because they share the label app: nginx. Traffic distribution is controlled purely by replica count.
Commands to shift traffic:
# 10% Canary kubectl scale deployment nginx-canary --replicas=1 kubectl scale deployment nginx-stable --replicas=9 30% Canary kubectl scale deployment nginx-canary --replicas=3 kubectl scale deployment nginx-stable --replicas=7
Increasing Canary replicas increases traffic to the new version. To roll back instantly, scale the Canary deployment to zero.
4. Key Concepts Learned 🧠
- Deployment Components: ReplicaSets, Pod templates, scaling
- Update Strategies: Rolling Update, Blue/Green, Canary
- Self-Healing: Pods recreated automatically
- Version Control: Rollout history & rollback
- Zero Downtime: Built-in traffic management
5. Cleanup 🧹
# Delete deployments
kubectl delete deployment nginx-deployment nginx-blue nginx-green # Removes all deployment resources created in this guide
# Verify cleanup
kubectl get deployments # Confirms all deployments have been deleted
Final Thoughts 💡
Most teams rely on Rolling Updates for simplicity and reliability. Blue/Green and Canary strategies are used when risk mitigation, fast rollback, or production testing is required — often alongside tools like Argo Rollouts or service meshes.
When you’re ready, continue to the next part or clean up everything:
kubectl delete all --all minikube stop # Removes all resources and stops the local cluster