I need to move a legacy database into Kubernetes, but I'm terrified of data loss. I understand how Deployments work, but StatefulSets and Persistent Volume Claims (PVC) are still a bit confusing. How do I ensure that if a pod restarts, it reattaches to the exact same disk? Also, how do you handle backups for volumes that are managed by a Cloud Storage Provisioner?
3 answers
StatefulSets are designed exactly for this scenario. Unlike a Deployment, a StatefulSet gives each pod a stable, unique identifier (like 'db-0', 'db-1'). When 'db-0' dies and restarts, Kubernetes ensures it mounts the specific Persistent Volume Claim associated with 'db-0'. This "sticky" identity is what makes it work for databases. For backups, you shouldn't rely on the pod; you should use a tool like Velero or the native snapshot capabilities of your cloud provider. We use Velero for scheduled backups of both our cluster metadata and our actual PVC data, which has saved us during several accidental deletions.
Are you planning on using a 'ReadWriteOnce' or 'ReadWriteMany' storage class, and have you considered how that affects your ability to scale across different zones?
Always test your "Volume Expansion" capabilities. Some storage classes allow you to increase disk size on the fly, which is vital as your database grows over time.
Great advice, Cynthia. There's nothing worse than running out of disk space and finding out your storage provisioner doesn't support online expansion!
Gregory, that's a huge point. Most cloud block storage (EBS/GPD) is ReadWriteOnce and bound to a single zone. If your pod tries to move to a node in a different availability zone, it will get stuck because the disk can't follow it. You either need to use a regional storage class or ensure your StatefulSet is restricted to a single zone, though that obviously reduces your high-availability rating.