What does "Available" mean in context of deployments?

Shazad_Brohi · May 9, 2019, 3:29pm

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

macintoshprime · May 12, 2019, 2:04pm

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.

rael · May 12, 2019, 5:24pm

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:

github.com

kubernetes/kubernetes/blob/master/pkg/controller/deployment/util/deployment_util.go#L727


      
          // when new pods are scaled up or become ready or available, or old pods are scaled down, then we
          // consider the deployment is progressing.
          func DeploymentProgressing(deployment *apps.Deployment, newStatus *apps.DeploymentStatus) bool {
          	oldStatus := deployment.Status
          
          	// Old replicas that need to be scaled down
          	oldStatusOldReplicas := oldStatus.Replicas - oldStatus.UpdatedReplicas
          	newStatusOldReplicas := newStatus.Replicas - newStatus.UpdatedReplicas
          
          	return (newStatus.UpdatedReplicas > oldStatus.UpdatedReplicas) ||
          		(newStatusOldReplicas < oldStatusOldReplicas) ||
          		newStatus.ReadyReplicas > deployment.Status.ReadyReplicas ||
          		newStatus.AvailableReplicas > deployment.Status.AvailableReplicas
          }
          
          // used for unit testing
          var nowFn = func() time.Time { return time.Now() }
          
          // DeploymentTimedOut considers a deployment to have timed out once its condition that reports progress
          // is older than progressDeadlineSeconds or a Progressing condition with a TimedOutReason reason already
          // exists.

github.com

kubernetes/kubernetes/blob/master/pkg/controller/deployment/util/deployment_util.go#L861


      
          func ResolveFenceposts(maxSurge, maxUnavailable *intstrutil.IntOrString, desired int32) (int32, int32, error) {
          	surge, err := intstrutil.GetScaledValueFromIntOrPercent(intstrutil.ValueOrDefault(maxSurge, intstrutil.FromInt32(0)), int(desired), true)
          	if err != nil {
          		return 0, 0, err
          	}
          	unavailable, err := intstrutil.GetScaledValueFromIntOrPercent(intstrutil.ValueOrDefault(maxUnavailable, intstrutil.FromInt32(0)), int(desired), false)
          	if err != nil {
          		return 0, 0, err
          	}
          
          	if surge == 0 && unavailable == 0 {
          		// Validation should never allow the user to explicitly use zero values for both maxSurge
          		// maxUnavailable. Due to rounding down maxUnavailable though, it may resolve to zero.
          		// If both fenceposts resolve to zero, then we should set maxUnavailable to 1 on the
          		// theory that surge might not work due to quota.
          		unavailable = 1
          	}
          
          	return int32(surge), int32(unavailable), nil
          }

Hope it helps.

Topic		Replies	Views
Kubernetes deployment strategy General Discussions	5	1280	September 20, 2019
Doc clarification: updating a deployment General Discussions	1	544	March 5, 2020
Deployment die General Discussions	3	403	November 5, 2022
Extra pod spins up with my new single replica deployment General Discussions	2	629	November 25, 2020
Question about pods and scalability General Discussions	2	480	March 31, 2020

What does "Available" mean in context of deployments?

Related Topics