Kubernetes Deployment: rolling update capacity

Operational decision

A document-index API runs four replicas and permits one extra Pod while keeping all four available during an update. Verify that the cluster has room for the temporary fifth Pod and that downstream services can tolerate overlap between old and new versions. Readiness must gate service traffic to each new Pod. The fragment focuses on rollout arithmetic; add the complete Pod template, probes, resources, and security context before deployment. If scheduling cannot place the surge Pod, the rollout may stall. If readiness always returns success, the controller can replace healthy old Pods with broken new ones. Record the image digest and use rollout status with an explicit timeout. A rollback to an earlier Pod template also has to be compatible with any schema migration already applied.

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0
replicas: 4
progressDeadlineSeconds: 240

Cost and verification

With four desired replicas, the fragment allows up to five Pods during the rollout and aims to keep four available. That extra Pod consumes CPU, memory, connections, and possibly a license slot. maxUnavailable: 0 cannot prevent user-visible errors if readiness is wrong or the shared database fails. Percent values have rounding rules, so absolute counts are clearer for a small replica set. Track stalled rollout conditions and stop promotion when the progress deadline is exceeded.

Common Mistakes

• Do not set maxSurge without checking spare capacity.
• Do not expect replica availability to prove application correctness.
• Do not roll back code that cannot read the migrated schema.

Connected lessons

• DevOps Tutorial
• Kubernetes probes: startup, readiness, and liveness
• Database change safety: expand, migrate, contract
• Progressive delivery: canary checks and rollback

Operational follow-up

• Kubernetes requests and limits: schedule for real load
• Horizontal autoscaling: choose a signal tied to demand

Advanced follow-up

• Pod disruption budgets: make node drains measurable
• Graceful Pod shutdown: stop accepting work before exit