Cassandra K8s: Cluster topology, racks, and node configuration

Topology questions test whether replicas land in separate failure domains and whether the Kubernetes scheduler actually honors the rack plan.

Core rules

• A Cassandra rack is a failure domain; in Kubernetes it usually maps to a zone or a dedicated node pool.
• NetworkTopologyStrategy uses rack information to place replicas on distinct racks.
• The operator's rack entries should carry node affinity or node selectors so Pods land in the intended domain.
• GossipingPropertyFileSnitch uses the rack and datacenter names supplied to each node.
• Seeds are contact points, not a fixed membership list; every node still gossips.

Worked example

A datacenter has three racks, rack-a, rack-b, and rack-c, each pinned to one availability zone, with RF 3. A partition's three replicas land one per rack. If zone A is lost, two replicas remain, so QUORUM with RF 3 still needs two and remains available. If all three Pods were scheduled into zone A, losing that zone would remove all three replicas even though the cluster has three nodes. That is why rack labels and affinity must agree.

Traps

• Declaring three racks but letting the scheduler place all Pods on one node pool.
• Setting RF 3 while only two racks exist for that datacenter.
• Assuming seeds are the only nodes a driver can use.
• Omitting a PodDisruptionBudget during node drains.