`helm upgrade` is rejected because a StatefulSet's volumeClaimTemplates changed — how do you ship it?

### Why there is no in-place answer `volumeClaimTemplates` on a StatefulSet is set at creation and refused afterwards, so `helm upgrade` cannot edit it and no Helm flag changes that. Everything that follows is about the same act — the object stops existing and is created again — done at three different costs. The interviewer is grading the choice, not the flag. Make one thing explicit before choosing: **the template is not the claims.** Claims created earlier were made from the old template and keep the size and class they were created with. Recreating the StatefulSet gives you a correct template for whatever is created next; it does not migrate anything that exists. Those claims are also not release objects — Helm never created them — so Helm does not remove them when it removes the StatefulSet. Whether they survive the object's own deletion is a property of the object's retention setting, so check it rather than assume. ### Route one: replace it `helm upgrade --force-replace` removes the StatefulSet and creates it again from the rendered manifest. It is one command and it works. Its cost is that every pod the object manages goes at once and comes back from scratch — not one at a time, all of them. It is also a flag on the upgrade rather than on the offending object, so treat every object in the release as in scope. For a PDF-signing service whose requests can run for the better part of a minute, that is a hard outage plus a set of failed signings. For a workload that already tolerates a full restart during a window, it is the right answer and the cheapest one, and you say so in the change record. ### Route two: recreate the object, keep the pods The useful trick is that the object and the pods can be separated. Delete the StatefulSet out-of-band while orphaning its children, so the pods it managed keep running and keep serving. Then run the ordinary `helm upgrade`: the object is gone, so Helm creates it fresh with the new `volumeClaimTemplates` — no immutable-field refusal, since there is no prior value — and the newly created object adopts the running pods because they match its selector. This is the route that fits a signing service. There is a window during which no controller is watching the pods, which is exactly why it is a deliberate, attended operation with the second command already typed, not a step in a pipeline. The cost is that it happens outside the chart: the object is created by Helm afterwards, so it carries the release's ownership metadata correctly, but the deletion itself is a manual act that must be recorded, and a rollback plan means knowing how to get the old object back. ### Route three: rename it Give the object a new name through the chart, and the upgrade renders a new StatefulSet while removing the old one as part of the same release. Nothing is refused, because nothing is updated. This buys you an explicit migration point — the new set comes up with new claims from the new template — and it costs you a real data migration plus a period where two sets exist. It is the honest answer when the storage change is a genuine re-shaping rather than a tweak, and the one to reach for when the same chart change has to run unattended across many releases. ### If what you actually wanted was more space A very common version of this question is somebody growing a claim from, say, 40Gi to 96Gi and editing the chart's template to say so. If the cluster's storage supports growing an existing claim, that growth happens at the claim level and is not something the StatefulSet template performs — so the practical sequence is to grow the existing claims first and then get the template into line with route two, so future pods are created from the shape you want. Editing the template alone would have changed nothing about the existing volumes even if the upgrade had been accepted. ### Framing the answer A strong answer states the constraint (the object must be recreated), separates the object from its claims, names the three routes with their costs, and picks one from the workload's tolerance for a gap. It also mentions confirming the diagnosis with a server-side dry run first, and checking what else is in the release before reaching for a release-wide replacement. A weak answer is `--force-replace` with no mention of what it does to the pods, or the belief that a template change resizes existing storage.