Kubernetes StatefulSet Storage Expansion: Overcoming the Immutable Constraint Without Downtime Using a Non-cascade Strategy

In StatefulSet environments, volumeClaimTemplates is Immutable, so storage capacity cannot be modified directly. DBs or message queues that require data persistence cannot discard their disks, and availability must be maintained during operation, so a typical redeployment approach is difficult to apply.

The solution combines Online Volume Expansion with Non-cascade redeployment. First, increasing the PVC's capacity lets the CSI driver and kubelet handle volume and filesystem expansion, and then the StatefulSet is deleted with --cascade=orphan, which detaches only the controller while keeping the Pods intact.

The procedure is as follows.

• Step 1. Expand the PVC capacity first. kubectl patch pvc <pvc-name> -p '{"spec":{"resources":{"requests":{"storage":"100Gi"}}}}'
• Step 2. Delete the StatefulSet as Non-cascade. In ArgoCD, check the Non-cascade option; in the CLI, use kubectl delete sts <name> --cascade=orphan.
• Step 3. Deploy a new StatefulSet manifest reflecting the modified capacity. At this point, the capacity in volumeClaimTemplates must exactly match the actual PVC.
• Step 4. Verify the capacity is reflected inside the Pod. Check with kubectl exec -it <pod-name> -- df -h, and if the reflection is delayed, use kubectl rollout restart sts <name> for RollingUpdate, or manually delete Pods one by one for OnDelete to trigger remounting.

The key is to maintain the order of physical expansion (PVC) → spec update (STS). If the order is reversed, the API server will block deployment due to a capacity mismatch between the existing PVC and the new template. After the operation, separating the lifecycle of the controller and the actual resources allows for safe management going forward.