Deployments & Strategies

Welcome to the Deployments & Strategies chapter. This section covers fundamental concepts and best practices necessary to master this topic in depth.

Imagine you are running a massive e-commerce platform during Black Friday. Your engineering team just pushed a critical bug fix for the checkout service, and you need to deploy it right now. If you take the system offline to update it, you lose thousands of dollars per minute. How do you swap out the old code for the new code across hundreds of servers without dropping a single user request?

This is the exact problem Deployments solve. They are the engine behind zero-downtime updates, instantaneous rollbacks, and full application lifecycle management in Kubernetes.

1. The Logic Hierarchy

You rarely create Pods directly. Instead, you create Deployments. Think of a Deployment as the “Regional Manager” of your application.

  1. Deployment (Regional Manager): Defines the desired state of the application. It manages Releases (Updates, Rollbacks) and delegates scaling to the ReplicaSet.
  2. ReplicaSet (Shift Supervisor): Manages Scale. Its sole job is to ensure exactly N copies of a Pod are running at any given moment. If a Pod crashes, the ReplicaSet hires a replacement.
  3. Pod (The Worker): The actual application container doing the work.

Deployment → manages → ReplicaSet → manages → Pod

2. Update Strategies

1. RollingUpdate (Default)

Updates Pods incrementally to guarantee Zero Downtime. Instead of taking down the entire service, Kubernetes replaces Pods one by one (or in small batches).

  • MaxUnavailable: The maximum number of pods that can be temporarily down during the update process (e.g., 25% or 1).
  • MaxSurge: The maximum number of extra pods that can be created above the desired replica count during the update (e.g., 25% or 1).

The Secret Sauce: Readiness Probes A RollingUpdate is fundamentally useless without configured Readiness Probes. Kubernetes needs to know when a newly created Pod is actually ready to receive traffic. If you don’t define a Readiness Probe, Kubernetes assumes the Pod is ready the moment the container starts, potentially routing traffic to an application that is still booting up (causing 502 Bad Gateway errors). Kubernetes will only terminate an old Pod once the new Pod’s Readiness Probe returns a success.

2. Recreate

Kills ALL old pods simultaneously, then starts ALL new pods.

  • Downtime: Yes (complete outage during the swap).
  • Use Case: Database schema migrations where the new application version is strictly incompatible with the old database schema, and running both versions simultaneously would corrupt data or cause deadlocks.

3. Interactive: Rolling Update Simulator

Watch how v1 is replaced by v2 sequentially without downtime.

Cluster State

4. Rollbacks

Mistake in v2? Undo it instantly. kubectl rollout undo deployment/my-app

When you issue a rollback, Kubernetes does not “delete” your newly applied configuration or magically rewrite the YAML file. Instead, it relies on the ReplicaSet History.

Every time you update a Deployment, it creates a new ReplicaSet while keeping the old one around (with a scale of 0). To roll back, the Deployment simply:

  1. Scales the active (v2) ReplicaSet down to 0.
  2. Scales the previous (v1) ReplicaSet back up to 3.

This makes rollbacks practically instantaneous because the previous configuration is already defined and stored natively in the cluster state.

5. Code Example: Deployment YAML Anatomy

Diff

 apiVersion: apps/v1
 kind: Deployment
 metadata:
   name: backend
 spec:
   replicas: 3
   template:
   spec:
     containers:
-      - image: my-app:v1
+      - image: my-app:v2

Full Anatomy YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend                      # Name of the Deployment
spec:
  replicas: 3                        # Desired number of Pods managed by the ReplicaSet
  selector:
    matchLabels:
      app: backend                   # How the Deployment finds the Pods it is supposed to manage
  strategy:
    type: RollingUpdate              # Defines the update mechanism
    rollingUpdate:
      maxSurge: 1                    # Can temporarily have 4 pods total during an update (3 + 1)
      maxUnavailable: 0              # Zero pods can be unavailable (ensures at least 3 are always running)
  template:                          # The blueprint for the Pods (Pod Template)
    metadata:
      labels:
        app: backend                 # This MUST match the selector.matchLabels above!
    spec:
      containers:
      - name: server
        image: nginx:1.14.2          # The container image and version
        ports:
        - containerPort: 80