Rolling update
- Replaces pods gradually
- Users automatically move to new version
- No “choice” of who sees the new version
Canary deployment
Only a small % of traffic goes to the new version- You observe metrics
- You decide to promote or rollback
This project shows WHY DevOps prefers Canary for risky changes.
Architecture (keep this picture in mind)
User
│
▼
Service
│
├── 90% → app-v1 pods
└── 10% → app-v2 pods (CANARY)
Tools used
- Minikube
- kubectl
- hashicorp/http-echo
Step 1 — Deploy STABLE version (v1)
stable.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-v1
spec:
replicas: 9
selector:
matchLabels:
app: echo
version: v1
template:
metadata:
labels:
app: echo
version: v1
spec:
containers:
- name: app
image: hashicorp/http-echo:0.2.3
args:
- "-listen=:8080"
- "-text=STABLE v1"
ports:
- containerPort: 8080
Apply:
kubectl apply -f stable.yaml
Step 2 — Create CANARY version (v2)
canary.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-v2
spec:
replicas: 1
selector:
matchLabels:
app: echo
version: v2
template:
metadata:
labels:
app: echo
version: v2
spec:
containers:
- name: app
image: hashicorp/http-echo:0.2.3
args:
- "-listen=:8080"
- "-text=CANARY v2"
ports:
- containerPort: 8080
Apply:
kubectl apply -f canary.yaml
Step 3 — ONE Service (this is the key difference)
service.yaml
apiVersion: v1
kind: Service
metadata:
name: echo-svc
spec:
selector:
app: echo
ports:
- port: 80
targetPort: 8080
Apply:
kubectl apply -f service.yaml
Important:
- The Service selects both v1 and v2
- Kubernetes load-balances by pod count
- 9 pods vs 1 pod → ~90/10 traffic split
Step 4 — Access the service
minikube service echo-svc
Or:
URL=$(minikube service echo-svc --url)
Step 5 — Watch Canary behavior (LIVE demo)
Continuous traffic test
while true; do
curl -s $URL
sleep 0.2
done
Expected output
STABLE v1
STABLE v1
STABLE v1
CANARY v2
STABLE v1
STABLE v1
This is the money moment of the demo.
Compare: Rolling vs Canary (DevOps perspective)
| Feature | Rolling Update | Canary Deployment |
|---|---|---|
| User control | ❌ None | ✅ Partial |
| Risk | Medium | Low |
| Metrics-based decision | ❌ | ✅ |
| Rollback speed | Medium | Fast |
| Complexity | Low | Medium |
| Used in prod? | Yes | YES (preferred) |
DevOps job during Canary
You do NOT touch code.
You:
- Watch logs
kubectl logs -l version=v2
- Watch errors / latency
- Decide:
- Promote
- Pause
- Rollback
Step 6 — Promote Canary to Full Release
Option A — Scale up v2
kubectl scale deployment app-v2 --replicas=10
kubectl scale deployment app-v1 --replicas=0
Option B — Delete v1
kubectl delete deployment app-v1
Traffic now:
CANARY v2
CANARY v2
CANARY v2
Step 7 — Rollback scenario (very important)
Simulate failure:
kubectl delete deployment app-v2
Result:
- Traffic instantly returns to v1
- No downtime
- No rollout undo logic needed
Why Canary beats Rolling in real production
Rolling update:
- You find bugs after users complain
Canary:
- You detect issues before users notice
- You protect revenue
- You protect brand
That’s why:
- Netflix
- Amazon
all use Canary or Progressive Delivery
SOCIAL SHARE CARD GENERATOR