`minReadySeconds` sets how long a pod must remain ready before its controller counts it as available. In a Deployment rolling update, the controller waits for a new pod to become available before continuing. Without this setting, a pod becomes available as soon as it is ready. The field belongs directly under `spec`, not inside the update strategy. section 15.2.5 section 15.2.2
Ready and available are different states. A ready pod that is still waiting out `minReadySeconds` can already receive requests through a Service. If its containers crash or it fails its readiness probe during the wait, the timer resets. The setting slows rollout progression; it does not hold the pod out of service. section 15.2.5
Listing 15.5 Deployment manifest with a readiness probe and minReadySeconds
apiVersion: apps/v1
kind: Deployment
...
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 0
maxUnavailable: 1
minReadySeconds: 60 #1
...
template:
...
spec:
containers:
- name: kiada
image: luksa/kiada:0.8 #2
env:
- name: FAIL_AFTER_SECONDS #3
value: "30" #3
...
readinessProbe: #4
initialDelaySeconds: 0 #4
periodSeconds: 10 #4
failureThreshold: 1 #4
httpGet: #4
port: 8080 #4
path: /healthz/ready #4
scheme: HTTP #4
... #4
The Deployment manifest sets `minReadySeconds: 60` alongside a readiness probe. Use their separate locations to see that the probe determines readiness, while the Deployment setting delays availability. section 15.2.5
Give a new version time to fail
Suppose a new container fails after 30 seconds. Set `spec.minReadySeconds: 60` and configure a readiness probe that detects the failure. The pod cannot complete its 60-second ready period, so the Deployment does not advance on the strength of that pod. Check `kubectl get deploy` to compare READY and AVAILABLE; use `kubectl rollout status` to follow the update. A stalled rollout can eventually report that it exceeded its progress deadline. section 15.2.5
The field also applies to StatefulSets and DaemonSets. For a StatefulSet, it affects scaling as well as updates. During a DaemonSet rolling update, the controller waits the additional time after a replacement pod is ready before updating pods on other nodes. Choose a longer interval when observing a new version matters more than finishing quickly. section 16.2.5 section 17.1.4 section 15.2.5
