I have recently updated podManagementPolicy field in my StatefulSet from default(OrderedReady) to Parallel.
I wanted to know if there is any case where i can face any issue?
I would like to expand on this topic a bit.
The OrderedReady pod management behaves as follows:
For a StatefulSet with N replicas, when Pods are being deployed, they are created sequentially, in order from {0..N-1}.
When Pods are being deleted, they are terminated in reverse order, from {N-1..0}.
Before a scaling operation is applied to a Pod, all of its predecessors must be Running and Ready.
Before a Pod is terminated, all of its successors must be completely shutdown.
While the Parallel pod management:
tells the StatefulSet controller to launch or terminate all Pods in parallel, and to not wait for Pods to become Running and Ready or completely terminated prior to launching or terminating another Pod. This option only affects the behavior for scaling operations. Updates are not affected.
Theoretically you will not face any downtime while updating your app as parallel strategy only affects the scaling operations. As already said by Jonas it is hard to foresee the potential consequences without knowing much about your app and architecture. But generally it is safe to say that if your app's instances does not depend on each other (and thus does not have to wait for each pod to be Running and Ready) the parallel strategy should be safe and quicker than the OrderedReady one. However, if you possibly face any issues with your StatefulSet in the future and would like to analyze it from the Kubernetes side, these official docs might be helpul for you.
What are some pros and cons of parallel podManagementPolicy over OrderedReady podManagementPolicy in StatefulSets?
This totally depends on your application. Does it need ordered instance scale-up and scale-down?
If you share what application you are using, it is easier to tell if it tolerate that the instances scale-up or down in a specific order.
E.g. a distributed database - that replicates data to its instances - might run with 3 instances - then you want to scale-up to 5 - but it takes time to replicate data to those two new instaces - and you migth regret scaling up. In this case it is preferred to scale down the two instances that are not yet fully replicated.
