How does minReadySeconds affect readiness probe?

11/10/2018

Let's say I have a deployment template like this

spec:
  minReadySeconds: 15
  readinessProbe:
    failureThreshold: 3
    httpGet:
      path: /
      port: 80
      scheme: HTTP
    initialDelaySeconds: 20
    periodSeconds: 20
    successThreshold: 1
    timeoutSeconds: 5

How will this affect the newly versions of my app? Will the minReadySeconds and initialDelaySeconds count at the same time? Will the initialDelaySeconds come first then minReadySeconds?

-- Dean Christian Armada
google-kubernetes-engine
kubernetes

1 Answer

11/10/2018

From Kubernetes Deployment documentation:

.spec.minReadySeconds is an optional field that specifies the minimum number of seconds for which a newly created Pod should be ready without any of its containers crashing, for it to be considered available. This defaults to 0 (the Pod will be considered available as soon as it is ready). To learn more about when a Pod is considered ready, see Container Probes

So your newly created app pod have to be ready for .spec.minReadySeconds seconds to be considered as available.

initialDelaySeconds: Number of seconds after the container has started before liveness or readiness probes are initiated.

So initialDelaySeconds comes before minReadySeconds.

Lets say, container in the pod has started at t seconds. Readiness probe will be initiated at t+initialDelaySeconds seconds. Assume Pod become ready at t1 seconds(t1 > t+initialDelaySeconds). So this pod will be available after t1+minReadySeconds seconds.

-- nightfury1204
Source: StackOverflow