changing the  replicas  count or deleting it). All Pods belonging to a ReplicaSet start shutting down simultaneously without any ordering and dependency among them. This behavior may be faster to complete, but is not desired by stateful applications, especially if data partitioning and distribution are involved among the instances. To allow proper data synchronization during scale-up and -down, StatefulSet by default performs sequential startup and shutdown. That means Pods start from the first one (with index 0), and only when that Pod has successfully started, is the next one scheduled (with index 1), and the sequence continues. During scaling down, the order reverses—first shutting down the Pod with the highest index, and only when it has shut down successfully is the Pod with the next lower index stopped. This sequence continues until the Pod with index 0 is terminated. StatefulSets have other aspects that are customizable to suit the needs of stateful applications. Each stateful application is unique and requires careful consideration while trying to fit it into the StatefulSet model. Let’s see a few more Kubernetes fea‐ tures that may turn out to be useful while taming stateful applications: We described above the sequential ordering guarantees while scaling a Stateful‐ Set. As for updating an already running stateful application (e.g., by altering the  .spec.template  element), StatefulSets allow phased rollout (such as a canary release), which guarantees a certain number of instances to remain intact while applying updates to the rest of the instances. By using the default rolling update strategy, you can partition instances by speci‐ fying a  .spec.updateStrategy.rollingUpdate.partition  number. The param‐ eter (with a default value of 0) indicates the ordinal at which the StatefulSet should be partitioned for updates. If the parameter is specified, all Pods with an ordinal index greater than or equal to the  partition  are updated while all Pods with an ordinal less than that are not updated. That is true even if the Pods are deleted; Kubernetes recreates them at the previous version. This feature can enable partial updates to clustered stateful applications (ensuring the quorum is preserved, for example), and then roll out the changes to the rest of the cluster by setting the  partition  back to 0. When we set  .spec.podManagementPolicy  to  Parallel , the StatefulSet launches or terminates all Pods in parallel, and does not wait for Pods to become running and ready or completely terminated before moving to the next one. If sequential processing is not a requirement for your stateful application, this option can speed up operational procedures. Parallel Deployments Partitioned Updates Other Features Solution  |  95