My understanding is that if the Pod is not
available it isn’t ready to take any work. So if you had your
minReadySeconds set to
178000 the Pods wouldn’t be available to take work until they passed that threshold.
Minimum number of seconds for which a newly created pod should be ready without any of its container crashing, for it to be considered available. Defaults to 0 (pod will be considered available as soon as it is ready)
This can be useful when you deploy a new version of your application with some issues, that causes the container to die after a few seconds/minutes when receiving traffic. This value is used during
Deployment Updates to let the controller know for how long the containers of the new
Pod need to be running without restarting to be considered
AVAILABLE, so it can continue with the update of the remaining pods.
In case of a problem during the deployment when user traffic reaches the new version of your application, this setting can help minimize the service affectation as the deploy will stop if the containers of the new pods are restarting. The
Deployment controller will wait at least
minReadySeconds with the new pods receiving traffic and look for any container restart in the pod before continuing creating pods with the new version and removing the ones with the old version, taking in account
maxUnavailable settings. This is much safer than just considering the news pods
AVAILABLE after passing the
Is not ideally, but you can find more information in the code:
Hope it helps.