Networking, services, and client connectivity
Clients and peers use different network paths, and the exam tests whether you can expose CQL without breaking internode traffic.
Core rules
- A headless Service provides stable per-Pod DNS for peer discovery and StatefulSet identity.
- A separate ClusterIP or LoadBalancer Service exposes CQL on 9042 to clients.
- Internode gossip uses 7000, TLS internode usually 7001; JMX is 7199 and should not be public.
- Drivers connect to a contact point, then discover peers from system tables; advertised addresses must be reachable.
- NetworkPolicies must allow DNS, internode traffic, and client CQL.
Worked example
A client connects to cluster1-dc1-service.db.svc:9042. The driver learns about cassandra-0, cassandra-1, and cassandra-2 and opens connections to each. If a NetworkPolicy allows only client-namespace traffic to 9042 but blocks 7000 between Cassandra Pods, the contact point may answer briefly while gossip and repair fail, and the cluster degrades. The policy needs both the internode ports among Cassandra Pods and CQL from the client namespace.
Traps
- Publishing JMX or internode ports through a public LoadBalancer.
- Using Pod IPs as static contact points.
- Forgetting DNS egress in a default-deny NetworkPolicy.
- Assuming a ClusterIP Service load-balances every query; drivers pool connections.