Cassandra K8s: Kubernetes fundamentals for stateful workloads

This domain tests how Kubernetes primitives behave when a Pod is not disposable: stable identity, per-Pod storage, ordered rollout, and disruption control.

Core rules

• A StatefulSet gives each replica an ordinal name (cassandra-0), stable DNS through a headless Service, and its own PVC from volumeClaimTemplates.
• Cassandra needs that identity because tokens, data files, and rack assignment belong to a specific node.
• Readiness must reflect CQL availability, not merely a running process; termination needs a grace period long enough to drain.
• Pod anti-affinity, topology spread constraints, and a PodDisruptionBudget protect quorum during voluntary disruptions.

Worked example

A StatefulSet named cassandra uses serviceName: cassandra-headless, replicas: 3, and a 2 Ti data claim template. Scaling to 4 makes the controller create cassandra-3, bind data-cassandra-3, and register DNS cassandra-3.cassandra-headless.ns.svc. The first three Pods are not recreated. cassandra-3 must bootstrap as a new ring member. Scaling back to 3 deletes the Pod but leaves its PVC unless retention policy says otherwise, so a proper decommission must happen before removal.

Traps

• Using a Deployment: Pods are interchangeable and lack stable storage identity.
• Using a normal ClusterIP Service as serviceName: peer DNS breaks.
• Assuming StatefulSet deletion deletes PVCs; it usually does not.
• Marking a Pod ready on a TCP connect alone, before gossip and CQL are usable.