<p>I have a stateful set of pods, and due to the stateful nature of them one of them cannot be recreated due to some state error that deleting it wouldn't help.</p>

<p>Since it's a stateful set kubernetes will block creation of additional pods until it's able to get the stuck one running.
Statefulsets has podManagementPolicy: "Parallel" but it cannot be changed in runtime.</p>

<p>The question is if there's a way to make kubernetes skip the stuck one?</p>

<p>I belive you are looking for a WA for an known <a href="https://github.com/kubernetes/kubernetes/issues/67250" rel="nofollow noreferrer">issue</a> which is still open</p>

<p>StatefulSet will continue to wait for the broken Pod to become Ready (which never happens) before it will attempt to revert it back to the working configuration.</p>

<p>In term of upgrade found this on <a href="https://github.com/banzaicloud/bank-vaults/pull/157" rel="nofollow noreferrer">git hub</a> below from <a href="https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/#updating-statefulsets" rel="nofollow noreferrer">official doc</a></p>

<p>The Pods in the StatefulSet are updated in reverse ordinal order. The StatefulSet controller terminates each Pod, and waits for it to transition to Running and Ready prior to updating the next Pod. </p>

<blockquote>
  <p>Note that, <strong>even though the StatefulSet controller will not proceed to update the next Pod until its ordinal successor is Running and Ready, it will restore any Pod that fails during the update to its current version</strong>. Pods that have already received the update will be restored to the updated version, and Pods that have not yet received the update will be restored to the previous version. In this way, the controller attempts to continue to keep the application healthy and the update consistent in the presence of intermittent failures.</p>
</blockquote>

<p>Read <a href="https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#forced-rollback" rel="nofollow noreferrer">Forced Rollback</a></p>

<p><strong>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</strong>.</p>
