k3s Series #3 — Kubernetes won’t let you shrink a PVC. Once you understand why, the same trick fixes two completely different problems. ![](https://miro.medium.com/v2/resize:fit:1400/1*F7by0P5becmEgEJMwC1J-A.png) *You can’t resize a PVC down. You can only rebuild it — carefully.* This is Part 3 of “Running Production Solo: My k3s High-Availability Journey” Previous: [Part 2 — From 1 Node to 3: The Full Story of Building Out Longhorn](https://jason-chen-0604.medium.com/from-1-node-to-3-the-full-story-of-building-out-longhorn-3b26f3f45e60) ｜ Series overview: [Running Production Solo — Series Overview](https://jason-chen-0604.medium.com/running-production-solo-my-k3s-high-availability-journey-series-overview-185da0289ace) ｜ Next: [Part 4 — RWO→RWX: Down the Rabbit Hole to a Corrupted Instance-Manager](https://jason-chen-0604.medium.com/rwo-rwx-down-the-rabbit-hole-to-a-corrupted-instance-manager-4b8bf293b443) ## TL;DR Two completely different incidents — one where I’d over-provisioned a PVC and wanted it smaller, one where a MongoDB StatefulSet crash-looped from disk full and needed more space — turned out to share the exact same underlying fix. **You cannot shrink a PVC, and you cannot always resize one in place either.** What actually works, in both directions, is detaching the workload, rebuilding just the PVC, and reattaching — while keeping the object that owns it alive the whole time. ## The Furniture That’s Nailed to the Floor Here’s a fact about PVCs that trips people up the first time they hit it: **once a volume is a certain size, it can only get bigger, never smaller.** Not in Longhorn, not in Kubernetes generally. It’s like furniture bolted to the floor — you can build an extension onto it, but you can’t just saw off a piece and call it resized. If it’s too big, your only option is to tear it out and build a new one in its place. That sounds like a minor inconvenience until you’re the one holding a PVC provisioned way larger than it needs to be, quietly wasting Longhorn replica space across three nodes for no reason. And it gets more interesting when the opposite problem shows up on a **StatefulSet** — where the fix for “too small” turns out to route through the exact same “tear it out and rebuild” logic as the fix for “too big.” ## The Fix, in One Sentence Whether you’re shrinking an oversized PVC or working around a StatefulSet’s immutable storage template, the underlying move is the same: detach safely, delete only the PVC (not the workload that owns it), and let Kubernetes rebuild the binding — using `--cascade=orphan` as the trick that keeps everything else standing. ## Quick Start: Two Flows, Same Instinct **Shrinking a Deployment-managed PVC** (the simple case — no `volumeClaimTemplates` involved): bash ``` # 1. Scale down so nothing is writing to the volume kubectl scale deployment --replicas=0 # 2. Delete only the oversized PVC kubectl delete pvc # 3. Recreate at the right size (inline YAML, always - see note below) kubectl apply -f - < spec: accessModes: ["ReadWriteOnce"] storageClassName: longhorn resources: requests: storage: 5Gi EOF # 4. Scale back up kubectl scale deployment --replicas=1 ``` **Growing a StatefulSet-managed PVC** (the tricky case — `volumeClaimTemplates` gets in the way): bash ``` # 1. Patch the PVC directly first, if allowVolumeExpansion is true on the StorageClass kubectl patch pvc -p '{"spec":{"resources":{"requests":{"storage":"10Gi"}}}}' # 2. Detach the StatefulSet object WITHOUT touching its pods or PVCs kubectl delete statefulset --cascade=orphan # 3. Re-apply the StatefulSet with the updated volumeClaimTemplates size kubectl apply -f - <

Blog