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.