Deployment & ReplicaSets

Deployment automatically creates a replicaset.

Deployment -> Manages Rollout -> Creates ReplicaSets for each version

kubectl create deployment nginx --image=nginx --replicas=4
kubectl scale deployment nginx --replicas=4
kubectl create deployment nginx --image=nginx --dry-run=client -o yaml > nginx-deployment.yaml

k rollout restart deployment my-app
k rollout status deployment/my-deployment
k rollout history deployment/my-deployment (--revision=3)
k rollout undo deployment/my-deployment [--to-revision=1]

k set image deployment/my-deployment nginx-container=nginx:latest
k get replicasets # will be changing during rollout

ReplicaSets

kubectl get rs
k scale --replicas=6 -f replicaset-definition.yml
k scale replicaset my-replicaset --replicas=6 

Save rs to file

kubectl get rs new-replica-set -o yaml > new-rs.yaml

warning

ReplicaSets don't have a rollout strategy like Deployments do. Image updates require manual pod deletion for the ReplicaSet to create new pods with the updated image.

Example def file:
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-replicaset
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest

Rollout Strategies

Kubernetes Deployments support two main rollout strategies for updating pods:

1. RollingUpdate (Default)

Gradually replaces old pods with new ones, ensuring zero downtime during updates.

Key Parameters:

• maxUnavailable: Maximum number of pods that can be unavailable during the update (default: 25%)
• maxSurge: Maximum number of pods that can be created above the desired replica count (default: 25%)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # Can be absolute number or percentage
      maxSurge: 1            # Can be absolute number or percentage
...

Use Cases:

• ✅ Production applications requiring high availability
• ✅ Stateless applications
• ✅ When you need zero downtime deployments

Example Scenarios:

# Conservative rollout (one pod at a time)
maxUnavailable: 0
maxSurge: 1

# Aggressive rollout (replace all pods quickly)
maxUnavailable: 50%
maxSurge: 50%

# Balanced approach (default)
maxUnavailable: 25%
maxSurge: 25%

2. Recreate

Terminates all existing pods before creating new ones. Results in downtime.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  strategy:
    type: Recreate
...

Use Cases:

• ✅ Stateful applications that can't run multiple versions simultaneously
• ✅ Applications with database schema migrations
• ✅ Dev/test environments where downtime is acceptable
• ✅ When resources are constrained and you can't run extra pods

Process:

1. All old pods are terminated
2. Wait for all pods to be fully terminated
3. Create new pods with updated configuration

Strategy Comparison

Strategy	Downtime	Resource Usage	Complexity	Use Case
RollingUpdate	None	Higher (temporary)	Medium	Production apps
Recreate	Yes	Lower	Simple	Stateful apps, dev/test

3. Blue/Green Deployment

Blue/Green deployment runs two identical environments (blue=current, green=new) and switches traffic instantly by updating the Service selector.

info

Blue/Green is not a native Kubernetes strategy but is implemented using labels and Service selectors.

How it works:

1. Deploy new version (green) alongside current version (blue)
2. Test the green environment thoroughly
3. Switch traffic by updating Service selector
4. Keep blue environment for quick rollback if needed

# Blue Deployment (Current Production)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: blue
...
---
# Service - Switch traffic by changing selector
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
    version: blue    # Change to 'green' to switch traffic
...

Switching Traffic:

# Deploy green environment
kubectl apply -f myapp-green-deployment.yaml

# Test green environment directly
kubectl port-forward deployment/myapp-green 8080:8080

# Switch traffic to green (instant cutover)
kubectl patch service myapp-service -p '{"spec":{"selector":{"version":"green"}}}'

# If issues occur, instant rollback to blue
kubectl patch service myapp-service -p '{"spec":{"selector":{"version":"blue"}}}'

# After validation, clean up blue deployment
kubectl delete deployment myapp-blue

Use Cases:

• ✅ Critical production deployments requiring instant rollback capability
• ✅ Major version upgrades
• ✅ Database migrations with synchronized schemas
• ✅ When you need thorough testing before switching traffic

Pros & Cons:

• ✅ Instant rollback (just change selector back)
• ✅ Full testing before traffic switch
• ✅ Zero downtime
• ❌ Requires double the resources during deployment
• ❌ Database migrations can be complex
• ❌ Not suitable if blue and green can't run simultaneously

4. Canary Deployment

Canary deployment gradually routes a small percentage of traffic to the new version while monitoring for issues.

info

Canary deployments use multiple Deployments with weighted traffic distribution through labels and replica counts.

How it works:

1. Deploy new version with small replica count
2. Route small percentage of traffic to new version
3. Monitor metrics and errors
4. Gradually increase traffic to new version
5. Complete rollout or rollback based on metrics

Simple Canary (Using Replica Ratios):

# Stable version - 9 replicas (90% traffic)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-stable
spec:
  replicas: 9
  selector:
    matchLabels:
      app: myapp
      track: stable
...
---
# Canary version - 1 replica (10% traffic)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
      track: canary
...

Canary Rollout Process:

kubectl scale deployment myapp-stable --replicas=5
kubectl scale deployment myapp-canary --replicas=5

# If successful - complete rollout
kubectl set image deployment/myapp-stable myapp=myapp:2.0
kubectl delete deployment myapp-canary

Use Cases:

• ✅ Testing new versions with real production traffic
• ✅ Validating performance under load
• ✅ Reducing risk of bad deployments
• ✅ A/B testing new features
• ✅ When you have good monitoring/observability

Pros & Cons:

• ✅ Lower risk - issues affect only small % of users
• ✅ Real production validation
• ✅ Gradual rollout based on confidence
• ❌ Requires good monitoring/metrics
• ❌ More complex than simple rolling update
• ❌ Can be challenging with stateful apps
• ❌ Need traffic management (Ingress/Service Mesh for advanced control)

Advanced Canary with Ingress

For more precise traffic control, use Ingress with weighted routing:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"  # 10% to canary
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp-canary
            port:
              number: 80

Strategy Decision Matrix

Strategy	Risk	Complexity	Resource Cost	Rollback Speed	Best For
RollingUpdate	Low-Medium	Low	Low	Medium	Standard deployments
Recreate	High	Very Low	Very Low	Slow	Dev/test, stateful apps
Blue/Green	Low	Medium	High (2x)	Instant	Critical releases
Canary	Very Low	High	Medium	Fast	High-risk changes

Choosing the Right Strategy

• RollingUpdate: Default choice for most stateless apps
• Recreate: Use when versions can't coexist
• Blue/Green: When you need instant rollback capability
• Canary: When testing with production traffic is critical