Should I use StatefulSets or Deployments for my database on K8s?

All answers to this question.

For databases, you should almost always use StatefulSets. Unlike Deployments, StatefulSets provide a stable, unique network identifier for each pod (e.g., pod-0, pod-1), which is crucial for database clustering and replication. They also ensure that when a pod is rescheduled, it reconnects to the same Persistent Volume (PV). In a Deployment, pods are interchangeable and storage is shared, which can lead to data corruption if multiple pods try to write to the same volume simultaneously. StatefulSets handle the ordered, graceful deployment and scaling required for stateful apps.

   Answered 2024-11-14 by Dorothy Martinez

What kind of storage class are you using? Even with a StatefulSet, the underlying storage needs to support the specific access modes (like ReadWriteOnce) required by your database to ensure consistency.

   Answered 2024-11-15 by Richard Moore

• Richard, we are using AWS EBS with the gp3 storage class. It supports ReadWriteOnce, which fits the StatefulSet model perfectly. I was worried about how the secondary nodes would find the primary after a restart, but Dorothy's explanation about the stable network ID via a Headless Service cleared that up. We'll be setting up a Headless Service today to manage the DNS for our Mongo members.

     Commented 2024-11-16 by Christopher Garcia

StatefulSets also give you ordered updates. This means it updates one pod at a time, ensuring your database cluster doesn't lose its quorum during a rollout.

   Answered 2024-11-17 by Margaret White

• Exactly. Margaret’s point about quorum is why we use StatefulSets for our ETCD and Consul clusters too. It's much safer than a rolling update in a Deployment.

     Commented 2024-11-18 by Dorothy Martinez