KCNA — Deployment Strategies

Deployment Strategies

Choosing the right deployment strategy is critical for releasing new versions safely. The KCNA exam tests your knowledge of common strategies and when to use each one.

---

Rolling Update

The default strategy in Kubernetes Deployments. Pods are gradually replaced with the new version.

Time 0:  [v1] [v1] [v1] [v1]     ← All v1
Time 1:  [v1] [v1] [v1] [v2]     ← First v2 pod
Time 2:  [v1] [v1] [v2] [v2]     ← Replacing...
Time 3:  [v1] [v2] [v2] [v2]     ← Almost done
Time 4:  [v2] [v2] [v2] [v2]     ← All v2

Configuration

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1    # Max pods that can be unavailable during update
      maxSurge: 1          # Max extra pods above desired count during update

Parameter	Description
maxUnavailable	How many pods can be down simultaneously (number or %)
maxSurge	How many extra pods can be created above desired count

Pros and Cons

Pros	Cons
Zero downtime	Both versions run simultaneously (briefly)
Built-in to Kubernetes	Slow rollback (must reverse the rolling process)
Simple configuration	Not suitable if versions are incompatible

---

Recreate

Terminate all v1 pods, then start all v2 pods. Simple, but causes downtime.

Time 0:  [v1] [v1] [v1] [v1]     ← All v1 running
Time 1:  [ ] [ ] [ ] [ ]          ← All terminated (DOWNTIME!)
Time 2:  [v2] [v2] [v2] [v2]     ← All v2 running

spec:
  strategy:
    type: Recreate

Pros	Cons
Simple — no version mixing	Causes downtime
Good for incompatible versions	Not suitable for production services
Clean cutover	Users see errors during transition

---

Blue-Green Deployment

Run two identical environments. Blue is the current production; Green is the new version. Switch traffic all at once.

                    ┌─────────────────┐
                    │   Load Balancer  │
                    └────────┬────────┘
                             │
              ┌──────────────┼──────────────┐
              ▼                             ▼
     ┌─────────────────┐         ┌─────────────────┐
     │   Blue (v1)      │         │   Green (v2)     │
     │   [v1] [v1] [v1] │         │   [v2] [v2] [v2] │
     │   (current prod)  │         │   (new version)   │
     └─────────────────┘         └─────────────────┘

Switch traffic from Blue → Green by updating the Service selector:

# Point to Green
spec:
  selector:
    app: my-app
    version: v2    # Switch from v1 to v2

Pros	Cons
Instant rollback (switch back to Blue)	Requires 2x resources
No mixed versions	Expensive — both environments run simultaneously
Easy to test Green before switching	Database migration complexity

---

Canary Deployment

Release the new version to a small percentage of users first. Gradually increase if everything looks good.

Stage 1 (5% canary):
[v1] [v1] [v1] [v1] [v1] [v1] [v1] [v1] [v1] [v2]
                                                 ↑ canary

Stage 2 (25%):
[v1] [v1] [v1] [v1] [v1] [v1] [v2] [v2] [v2] [v2]

Stage 3 (50%):
[v1] [v1] [v1] [v1] [v1] [v2] [v2] [v2] [v2] [v2]

Stage 4 (100%):
[v2] [v2] [v2] [v2] [v2] [v2] [v2] [v2] [v2] [v2]

In Kubernetes, this can be done with:

• Multiple Deployments with different replica counts under the same Service
• Service mesh (Istio) for percentage-based traffic splitting
• Argo Rollouts for automated canary analysis

Pros	Cons
Low risk — small blast radius	Complex to implement (needs traffic splitting)
Real user validation	Requires observability to detect issues
Gradual rollout	Both versions running simultaneously

---

A/B Testing

Similar to canary, but traffic is split based on user attributes (headers, cookies, geography) rather than percentage.

                    ┌─────────────────┐
                    │   Load Balancer  │
                    └────────┬────────┘
                             │
         ┌───────────────────┼───────────────────┐
         │                                       │
    Users matching               All other users
    criteria (header,
    cookie, region)
         │                                       │
    ┌────▼────┐                            ┌─────▼────┐
    │   v2    │                            │    v1    │
    │ (test)  │                            │ (stable) │
    └─────────┘                            └──────────┘

Use cases:

• Test a new UI with specific users
• Feature flags for specific regions
• Comparison testing between versions

---

Comparison

Strategy	Downtime	Risk	Resource Cost	Rollback Speed	K8s Native
Rolling Update	None	Medium	Normal	Medium	Yes
Recreate	Yes	High	Normal	Slow	Yes
Blue-Green	None	Low	2x	Instant	Manual (Services)
Canary	None	Very Low	Slightly more	Fast	Partial (Istio/Argo)
A/B Testing	None	Low	Slightly more	Fast	No (requires Ingress/mesh)

---

Argo Rollouts

Argo Rollouts (part of the Argo project, CNCF Graduated) provides advanced deployment strategies as a Kubernetes controller:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app
spec:
  strategy:
    canary:
      steps:
      - setWeight: 5       # 5% traffic to canary
      - pause: {duration: 5m}
      - setWeight: 25      # 25% traffic
      - pause: {duration: 5m}
      - setWeight: 50      # 50% traffic
      - pause: {duration: 5m}
      # Implicit 100% at the end

---

KCNA Exam Tips

• Rolling Update is the default Kubernetes deployment strategy
• Know maxUnavailable and maxSurge parameters
• Blue-Green requires 2x resources but provides instant rollback
• Canary releases to a small % of users first — lowest risk
• Recreate is the only strategy that causes downtime
• Argo Rollouts automates blue-green and canary deployments
• Know when to use each strategy based on risk tolerance and resource constraints

---

What’s Next?

Test your knowledge of application delivery with practice questions.

Next: Practice Questions →