A pod is available when it is ready and has remained ready for the configured minimum duration. Deployments count available replicas separately from ready replicas. section 15.2.5
During a rolling update, availability affects when the Deployment continues:
- Without minReadySeconds, a ready pod becomes available immediately. section 15.2.5
- With minReadySeconds, the pod must stay ready for the configured duration. section 15.2.5
- A container crash or failed readiness probe resets the timer. section 15.2.5
- A ready but not-yet-available pod still belongs to Services and receives client requests. 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
Use minReadySeconds with a readiness probe to require a new replica to operate reliably before the rollout proceeds. section 15.2.5
