Kubernetes Deployment Availability Control

Kubernetes Deployment Availability Control is the set of fields and computed conditions through which a Deployment enforces a minimum bar of stability before a Pod is counted as genuinely contributing to service capacity, distinct from the rollout pacing controls that govern how quickly old Pods are replaced with new ones. Where maxSurge and maxUnavailable bound the mechanics of replacement, availability control governs the stricter question of when a newly created Pod is trusted enough to be relied upon.

minReadySeconds

The Stability Window

spec.minReadySeconds specifies how long a newly created Pod must remain in the Ready state, continuously, before it is considered available rather than merely ready. A Pod that flips to ready and then immediately becomes unready again, due to a flapping dependency or a probe misconfiguration, never accumulates this window and is not counted toward availability.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: availability-control-example
spec:
  replicas: 4
  minReadySeconds: 30
  template:
    spec:
      containers:
        - name: app
          image: registry.example.com/app:1.0.0
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080

Effect on Rollout Pacing

Because the rolling update process advances based on how many Pods are available, not merely ready, minReadySeconds directly throttles rollout speed: a higher value forces the controller to wait longer at each step, trading rollout speed for greater confidence that each newly surfaced Pod is stably functioning before the next batch proceeds.

The Available Condition

Distinguishing Available From Progressing

The Deployment's status.conditions includes an Available condition, True once the number of available replicas meets or exceeds the desired count, independent of whether a rollout is actively in progress. A Deployment can show Available: True while Progressing: True simultaneously, if enough old Pods remain to satisfy demand even as new ones are still being rolled in.

status:
  conditions:
    - type: Available
      status: "True"
      reason: MinimumReplicasAvailable
    - type: Progressing
      status: "True"
      reason: ReplicaSetUpdated

Interaction With maxUnavailable During Rollout

Availability as the Real Constraint

While maxUnavailable bounds how many desired replicas can be temporarily missing during a rollout, it is availability, not mere pod existence, that the controller actually tracks against that bound. A newly created Pod that is Running but has not yet cleared minReadySeconds still counts as unavailable, meaning the controller will not proceed to terminate additional old Pods until it does.

spec:
  strategy:
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

progressDeadlineSeconds as an Availability Failsafe

Detecting Stalled Availability

If new Pods never reach the available state within progressDeadlineSeconds, the Deployment's Progressing condition transitions to False with reason ProgressDeadlineExceeded, surfacing a rollout that is technically still creating Pods but never actually achieving stable availability, a distinct failure mode from a rollout that is simply proceeding slowly.

spec:
  progressDeadlineSeconds: 600

Availability Control Diagram

Configuring minReadySeconds appropriately, long enough to catch flapping Pods but short enough not to needlessly slow legitimate rollouts, is the primary lever operators have for tuning how conservative a Deployment's availability guarantees are during change.