What does "Available" mean in context of deployments?

Hi, when I query my deployment for my app, I see that myapp has **AVAILABLE** set to 0, while all of the other fields in the deployment (DESIRED, CURRENT, UP-TO-DATE) are set to the number of expected replicas. I understand that the number of pods classified as **AVAILABLE** is influenced in somepart by the **minReadySeconds**. In this case, this value is 178000 seconds for my deployment. However, until my deployment reaches the value of minReadySeconds, in what way will having 0 AVAILABLE impact my pods, services that access my pods, pod operational health? I see no errors or issues with any of my 12 pods in the deployment. The Kubernetes documentation does a poor job describing what exactly "AVAILABLE" means and what impact does it have on our pod operational health, services that try to access the pods, services that my pod is trying to access. I need to know if this is going to be an issue or if its just semantics based on not meeting "minReadySeconds". Thanks, Shazad

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.


If you look the ReplicaSet or the Deployment specification, is defined as:

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 maxSurge and maxUnavailable settings. This is much safer than just considering the news pods AVAILABLE after passing the ReadinessProbes.

Is not ideally, but you can find more information in the code:

Hope it helps.