Pros & Cons: Kubernetes StatefulSet

Pros & Cons: Kubernetes StatefulSet.md

Pros	Cons
Stable and predictable network identity and storage for each Pod, which makes it easier to configure and communicate with stateful components	The storage for a given Pod must either be provisioned by a PersistentVolume Provisioner based on the requested storage class, or pre-provisioned by an admin. You cannot use emptyDir volumes or hostPath volumes with StatefulSets
Ordered and graceful deployment, scaling, and update of Pods, which preserves the application's availability and data consistency	Deleting and/or scaling a StatefulSet down will not delete the volumes associated with the StatefulSet. This is done to ensure data safety, which is generally more valuable than an automatic purge of all related StatefulSet resources. You have to manually delete the PersistentVolumeClaims and PersistentVolumes if you want to reclaim the storage space
Ability to use local or remote storage classes, depending on the performance and durability requirements of the application	StatefulSets currently require a headless Service to be responsible for the network identity of the Pods. You are responsible for creating this Service
Ability to perform complex initialization or configuration tasks using init containers or lifecycle hooks	StatefulSets do not provide any guarantees on the termination of Pods when a StatefulSet is deleted. To achieve ordered and graceful termination of the Pods in the StatefulSet, it is possible to scale the StatefulSet down to 0 prior to deletion
	When using Rolling Updates with the default Pod Management Policy (OrderedReady), it's possible to get into a broken state that requires manual intervention to repair