<p>I have recently updated podManagementPolicy field in my StatefulSet from default(OrderedReady) to Parallel.</p>
<ul>
<li>It has significantly reduced the scale-up and scale-down time.</li>
<li>I have not seen any downsides of this change as of now, but I am worried if there can be any scenario where it might create problems for me?</li>
</ul>
<p>I wanted to know if there is any case where i can face any issue?</p>

<p>I would like to expand on this topic a bit.</p>
<p>The <a href="https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#orderedready-pod-management" rel="noreferrer"><code>OrderedReady</code> pod management</a> behaves as follows:</p>
<ul>
<li><p>For a StatefulSet with N replicas, when Pods are being deployed, they are created sequentially, in order from {0..N-1}.</p>
</li>
<li><p>When Pods are being deleted, they are terminated in reverse order, from {N-1..0}.</p>
</li>
<li><p>Before a scaling operation is applied to a Pod, all of its predecessors must be Running and Ready.</p>
</li>
<li><p>Before a Pod is terminated, all of its successors must be completely shutdown.</p>
</li>
</ul>
<p>While the <a href="https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#parallel-pod-management" rel="noreferrer"><code>Parallel</code> pod management</a>:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>Theoretically you will not face any downtime while updating your app as <code>parallel</code> 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 <code>parallel</code> strategy should be safe and quicker than the <code>OrderedReady</code> one. However, if you possibly face any issues with your <code>StatefulSet</code> in the future and would like to analyze it from the Kubernetes side, these <a href="https://kubernetes.io/docs/tasks/debug-application-cluster/debug-stateful-set/" rel="noreferrer">official docs</a> might be helpul for you.</p>
