Cassandra K8s study plan
Cassandra K8s · Give each week a clear focus.
8 weeks · About 6 hours per week
Kubernetes fundamentals for stateful workloads & Persistent storage, StatefulSets, and volume management
Explain how a StatefulSet differs from a Deployment in pod identity, stable network IDs, and ordered create/terminate semantics, and state why Cassandra needs the former.
Trace the full lifecycle of a StatefulSet pod from PVC binding through volume attachment to container start, naming each controller involved.
Deploy a 3-replica StatefulSet with per-pod PersistentVolumeClaims on a local kind or minikube cluster and confirm each pod binds a distinct PV.
Use kubectl to inspect PVC, PV, and StorageClass objects and identify which reclaim policy and binding mode are in effect.
Demonstrate what happens to pod scheduling when a required PV cannot bind, and record the resulting pod events.
Your checkpoint
A running 3-replica StatefulSet on a local cluster plus a written one-page trace of the pod-to-PVC-to-PV path with the actual kubectl output pasted in.
Cassandra architecture and data modeling review & Cluster topology, racks, and node configuration
Map Cassandra's gossip, partitioner, replication factor, and consistency-level model onto how Kubernetes spreads pods across nodes and zones.
Distinguish node, rack, and datacenter in Cassandra's snitch model and explain how topology labels in Kubernetes must align with them.
Design a keyspace with NetworkTopologyStrategy for a 2-rack, 3-node-per-rack layout and compute the resulting replica placement.
Identify which Kubernetes constructs (node labels, topology spread constraints, anti-affinity) enforce rack awareness and which silently fail to.
Write the exact node labeling scheme you would apply so that the operator can infer rack membership.
Your checkpoint
A topology design document containing the keyspace CQL with NetworkTopologyStrategy, the node label schema, and a diagram of replica placement across two racks.
Cassandra operator installation and lifecycle management
Install a Cassandra operator (for example K8ssandra or cass-operator) into a local cluster using its documented Helm or manifest path and verify the controller pod is healthy.
Create a CassandraDatacenter or equivalent custom resource and watch the operator reconcile it into running pods.
Read the operator's custom resource definition fields and explain what each of size, racks, resources, and storageConfig controls.
Inspect operator-managed ConfigMaps and Secrets to see how cassandra.yaml is generated and where per-rack overrides land.
Trigger a failed reconciliation deliberately and locate the operator log lines and status conditions that explain the failure.
Your checkpoint
A committed YAML bundle (operator install plus custom resource) that a second person can apply from scratch to reach a healthy 3-node cluster, verified by re-applying on a clean namespace.
Cassandra operator installation and lifecycle management & Cluster topology, racks, and node configuration
Scale the custom resource from 3 to 6 nodes and confirm the operator adds one node at a time with correct rack assignment.
Verify with nodetool status that all nodes are UN and that ownership is distributed as the keyspace strategy predicts.
Configure per-rack resource requests and storage sizes and confirm the operator honors them per rack rather than globally.
Patch a rack definition and observe how the operator handles the change without data loss.
Document the operator's reconciliation order for a rolling restart versus a scale-out.
Your checkpoint
A before-and-after nodetool status capture plus a short comparison table showing rack, node count, and token ownership before and after scaling to 6 nodes.
Persistent storage, StatefulSets, and volume management & Security: TLS, authentication, and authorization
Expand a PVC for a running Cassandra node on a StorageClass that supports volume expansion and verify the new capacity inside the pod.
Explain the difference between volume expansion and adding a new data volume, and state which one Cassandra tolerates without a restart.
Enable internode TLS between Cassandra nodes using cert-manager-issued certificates and confirm gossip traffic is encrypted.
Enable client-to-node TLS and connect with cqlsh using a CA bundle and client certificate.
Configure authentication and a role with limited privileges, then prove the role cannot read a keyspace it lacks permission on.
Your checkpoint
A working TLS-plus-auth configuration committed as manifests, with captured cqlsh transcripts showing one successful encrypted authenticated login and one denied query.
Networking, services, and client connectivity & Backup, restore, and disaster recovery
Compare the service types used to expose Cassandra and choose one that gives clients a stable seed list without breaking pod-level addressing.
Configure a headless service for peer discovery and a separate client-facing service, then connect an application pod through each.
Take a snapshot of a keyspace with nodetool and upload it to object storage, then restore it into a fresh keyspace and verify row counts.
Explain why a snapshot alone is not a disaster recovery plan and describe what else must be captured (schema, tokens, configuration).
Draft a recovery runbook for total cluster loss that starts from backups and ends with clients reconnected.
Your checkpoint
A tested restore report: snapshot taken, uploaded, restored into a new keyspace, with row-count verification and a one-page runbook for full cluster rebuild.
Monitoring, metrics, and observability & Networking, services, and client connectivity
Scrape Cassandra JMX metrics into Prometheus using the operator's ServiceMonitor or an exporter and confirm targets are up.
Build dashboard panels for read/write latency, pending compactions, hinted handoff, and dropped mutations, and state a threshold that warrants action.
Configure alerting rules for a down node, sustained high latency, and disk usage above a set percentage.
Trace one client request through the service to a specific pod using logs and metrics to confirm which node served it.
Correlate a deliberately induced load spike with the metric changes it produces.
Your checkpoint
A Grafana dashboard JSON plus alert rule file, with a screenshot or exported panel data showing the induced load spike captured across at least three metrics.
Scaling, upgrades, and rolling operations & Cassandra operator installation and lifecycle management
Perform an operator-driven rolling upgrade of the Cassandra version and confirm the operator waits for each node to rejoin before proceeding.
Execute a scale-down and explain how the operator avoids losing the last replica of any token range.
Run a repair after topology change and interpret the nodetool repair output.
Review the full eight-week artifact set and close gaps in any domain where you cannot explain the mechanism without notes.
Take a timed 60-question practice set weighted by domain percentage and review every missed item to its root cause.
Your checkpoint
A rolling upgrade log showing node-by-node restart with health checks between steps, plus a scored practice exam result with a written remediation list for every missed domain.
Milestones
Week 2: You can draw the replica placement for a 2-rack keyspace from memory and name the Kubernetes label that makes each pod land in the correct rack.
Week 4: A clean namespace can be brought to a healthy 6-node, 2-rack cluster using only your committed YAML, and nodetool status shows all nodes UN.
Week 6: You have restored a keyspace from an object-storage snapshot into a fresh keyspace and verified row counts match the source.
Week 8: You have completed a rolling version upgrade without manual pod deletion, and your weighted practice score is at or above your target with every missed domain documented.