Blog: Minimum Ready Seconds for StatefulSets
-
Authors: Ravi Gudimetla (Red Hat), Maciej Szulik (Red Hat)
This blog describes the notion of Availability for
StatefulSet
workloads, and a new alpha feature in Kubernetes 1.22 which addsminReadySeconds
configuration forStatefulSets
.What problems does this solve?
Prior to Kubernetes 1.22 release, once a
StatefulSet
Pod
is in theReady
state it is consideredAvailable
to receive traffic. For some of theStatefulSet
workloads, it may not be the case. For example, a workload like Prometheus with multiple instances of Alertmanager, it should be consideredAvailable
only when Alertmanager's state transfer is complete, not when thePod
is inReady
state. SinceminReadySeconds
adds buffer, the state transfer may be complete before thePod
becomesAvailable
. While this is not a fool proof way of identifying if the state transfer is complete or not, it gives a way to the end user to express their intention of waiting for sometime before thePod
is consideredAvailable
and it is ready to serve requests.Another case, where
minReadySeconds
helps is when usingLoadBalancer
Services
with cloud providers. SinceminReadySeconds
adds latency after aPod
isReady
, it provides buffer time to prevent killing pods in rotation before new pods show up. Imagine a load balancer in unhappy path taking 10-15s to propagate. If you have 2 replicas then, you'd kill the second replica only after the first one is up but in reality, first replica cannot be seen because it is not yet ready to serve requests.So, in general, the notion of
Availability
inStatefulSets
is pretty useful and this feature helps in solving the above problems. This is a feature that already exists forDeployments
andDaemonSets
and we now have them forStatefulSets
too to give users consistent workload experience.How does it work?
The statefulSet controller watches for both
StatefulSets
and thePods
associated with them. When the feature gate associated with this feature is enabled, the statefulSet controller identifies how long a particularPod
associated with aStatefulSet
has been in theRunning
state.If this value is greater than or equal to the time specified by the end user in
.spec.minReadySeconds
field, the statefulSet controller updates a field calledavailableReplicas
in theStatefulSet
's status subresource to include thisPod
. Thestatus.availableReplicas
inStatefulSet
's status is an integer field which tracks the number of pods that areAvailable
.How do I use it?
You are required to prepare the following things in order to try out the feature:
- Download and install a kubectl greater than v1.22.0 version
- Switch on the feature gate with the command line flag
--feature-gates=StatefulSetMinReadySeconds=true
onkube-apiserver
andkube-controller-manager
After successfully starting
kube-apiserver
andkube-controller-manager
, you will seeAvailableReplicas
in the status andminReadySeconds
of spec (with a default value of 0).Specify a value for
minReadySeconds
for any StatefulSet and you can check ifPods
are available or not by checkingAvailableReplicas
field using:kubectl get statefulset/<name_of_the_statefulset> -o yaml
How can I learn more?
- Read the KEP: minReadySeconds for StatefulSets
- Read the documentation: Minimum ready seconds for StatefulSet
- Review the API definition for StatefulSet
How do I get involved?
Please reach out to us in the #sig-apps channel on Slack (visit https://slack.k8s.io/ for an invitation if you need one), or on the SIG Apps mailing list: [email protected]
https://kubernetes.io/blog/2021/08/27/minreadyseconds-statefulsets/
© Lightnetics 2024