DevOps Tutorial · Containers and Kubernetes · Lesson 20 of 25

Rolling Updates, Probes and Resources

How Kubernetes rolls out new versions, why readiness probes and graceful shutdown matter, and how to set requests and limits.

Create a free account to save this page, take notes and track your progress. Sign in

Rolling updates

Changing a Deployment's image starts a rolling update. maxSurge (extra pods allowed) and maxUnavailable (pods allowed to be missing) control the pace; both default to 25%.

A rolling update with maxSurge and maxUnavailableTry it yourself
import math

def rollout(replicas, max_surge=0.25, max_unavailable=0.25):
    surge = math.ceil(replicas * max_surge)
    unavailable = math.floor(replicas * max_unavailable)
    old, new, step = replicas, 0, 0
    while old > 0 or new < replicas:
        step += 1
        start = min(replicas + surge - (old + new), replicas - new)   # new pods we may add now
        new += start
        stop = max(0, min(old, (old + new) - (replicas - unavailable)))  # old pods we may remove now
        old -= stop
        print(f"step {step}: +{start} new, -{stop} old -> old={old} new={new} (ready >= {replicas - unavailable})")

rollout(8)

Output

step 1: +2 new, -4 old -> old=4 new=2 (ready >= 6)
step 2: +4 new, -4 old -> old=0 new=6 (ready >= 6)
step 3: +2 new, -0 old -> old=0 new=8 (ready >= 6)

Probes

  • Readiness probe: "send me traffic?" A pod gets traffic only after it passes, so a rollout never routes to pods that are still starting.
  • Liveness probe: "restart me?" Keep it trivial; never check databases in it.
  • Startup probe: gives slow-starting apps time before liveness checks begin.

Graceful shutdown

When a pod is removed, Kubernetes sends SIGTERM and removes the pod from Service endpoints at the same time. Load balancers take a few seconds to notice, so the app should keep serving briefly, then stop accepting connections and finish in-flight requests. A small preStop sleep covers the gap:

lifecycle:
  preStop:
    exec: { command: ["sleep", "5"] }
terminationGracePeriodSeconds: 30

Requests and limits

  • Requests are what the scheduler reserves: the pod lands on a node with that much free.
  • Limits cap usage. Exceeding a memory limit gets the container OOMKilled; a CPU limit throttles it, which can add latency even when average CPU looks low. Many teams set memory limits but no CPU limits.
  • Make the runtime aware of the container's memory (JVM -XX:MaxRAMPercentage, Node --max-old-space-size).

Test yourself

What makes sure a new pod doesn't receive traffic before it's ready?

  1. A liveness probe
  2. A readiness probe
  3. A CPU limit
  4. maxSurge
Show answer

Answer: A readiness probe

Only pods passing their readiness probe are added to Service endpoints.

Was this page helpful?