Was this page helpful?
Caution
You're viewing documentation for an unstable version of ScyllaDB Operator. Switch to the latest stable version.
Networking¶
This page explains how ScyllaDB Operator exposes ScyllaDB nodes on the network, how broadcast addresses work, and how IP family selection affects the cluster.
Services created by the Operator¶
For every ScyllaDB cluster the Operator manages two kinds of Kubernetes Service:
Service |
Count |
Purpose |
|---|---|---|
Identity (named |
One per datacenter |
Stable DNS names for the StatefulSet. A regular |
Member |
One per pod |
A dedicated Service whose type is controlled by |
The member Service uses a selector that matches exactly one pod, giving every ScyllaDB node its own stable network identity independent of the pod IP lifecycle.
Node Service types¶
The exposeOptions.nodeService.type field controls what kind of member Service the Operator creates for each ScyllaDB node.
Headless¶
Creates a headless Service (clusterIP: None). The DNS record for the Service resolves directly to the pod IP. No additional IP address is allocated.
Use Headless when pods broadcast their own IP and no cluster-internal virtual IP is needed — for example, in multi-VPC deployments where pod IPs are routable across VPCs.
ClusterIP¶
Creates a standard ClusterIP Service backed by a single pod. The Service receives a virtual IP that is routable only inside the Kubernetes cluster.
This is the default for ScyllaCluster.
LoadBalancer¶
Creates a LoadBalancer Service. On cloud platforms that support external load balancers the Service provisions one, giving each ScyllaDB node an externally reachable address.
Customisations such as restricting a load balancer to the internal network are managed through annotations on the Service. The annotations field in nodeService is merged into every member Service.
LoadBalancer Services are a superset of ClusterIP Services — every LoadBalancer Service also has a ClusterIP. Additional fields that propagate to member Services:
externalTrafficPolicyinternalTrafficPolicyloadBalancerClassallocateLoadBalancerNodePorts
Platform-specific annotations¶
exposeOptions:
nodeService:
type: LoadBalancer
annotations:
service.beta.kubernetes.io/aws-load-balancer-scheme: internal
service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp
exposeOptions:
nodeService:
type: LoadBalancer
annotations:
networking.gke.io/load-balancer-type: Internal
Broadcast options¶
ScyllaDB uses two broadcast addresses:
broadcast_address— the address other ScyllaDB nodes use to reach this node (gossip, streaming, repair).broadcast_rpc_address— the address CQL clients use to connect to this node (returned during driver discovery).
The Operator lets you configure these independently via exposeOptions.broadcastOptions.nodes and exposeOptions.broadcastOptions.clients. Separating the two is useful when node-to-node traffic and client traffic travel over different networks for cost, latency, or security reasons.
Broadcast address types¶
Type |
Address source |
When to use |
|---|---|---|
|
Pod’s IP from |
Pod IPs are routable from wherever the consumer lives — for example, within a VPC or across peered VPCs. |
|
|
Consumers are inside the same Kubernetes cluster. Requires |
|
First entry in |
Consumers are outside the Kubernetes cluster and reach nodes through a load balancer. Requires |
How broadcast addresses reach ScyllaDB¶
The controller passes
--nodes-broadcast-address-typeand--clients-broadcast-address-typeflags to both the sidecar and ignition containers.At startup, the sidecar resolves the flag value to a concrete IP address by inspecting the pod status or the member Service.
The resolved addresses are passed to the ScyllaDB binary as
--broadcast-addressand--broadcast-rpc-addresscommand-line arguments.
The ScyllaDB process itself listens on all interfaces (0.0.0.0 for IPv4, :: for IPv6). The broadcast addresses only control what address is advertised to other nodes and clients.
Defaults¶
A ScyllaCluster created without explicit exposeOptions uses the following defaults:
Field |
Default |
|---|---|
|
|
|
|
|
|
For multi-datacenter deployments using multiple ScyllaCluster resources connected via externalSeeds, you typically need to override these defaults to use Headless / PodIP so that pod IPs are broadcast directly. See the Multi-VPC / multi-datacenter scenario below.
Note
exposeOptions on ScyllaCluster are immutable — they cannot be changed after the cluster is created.
Common deployment scenarios¶
In-cluster only (default)¶
exposeOptions:
nodeService:
type: ClusterIP
broadcastOptions:
clients:
type: ServiceClusterIP
nodes:
type: ServiceClusterIP
Clients and nodes communicate through cluster-internal virtual IPs. The cluster is not reachable from outside Kubernetes.
Pod IPs within a VPC¶
exposeOptions:
nodeService:
type: ClusterIP
broadcastOptions:
clients:
type: PodIP
nodes:
type: ServiceClusterIP
Nodes talk to each other via ClusterIP (they share a Kubernetes cluster). Clients in the same VPC connect directly using pod IPs, which are routable within the VPC.
Multi-VPC / multi-datacenter¶
exposeOptions:
nodeService:
type: Headless
broadcastOptions:
clients:
type: PodIP
nodes:
type: PodIP
Two or more Kubernetes clusters in separate VPCs with VPC peering or a shared VPC. Each datacenter is a separate ScyllaCluster resource connected to the others via externalSeeds. Pod IPs are routable across VPCs, so both nodes and clients use them directly. No virtual IP is needed, hence Headless.
See Deploy a multi-datacenter cluster for deployment guides.
External access via load balancers¶
exposeOptions:
nodeService:
type: LoadBalancer
broadcastOptions:
clients:
type: ServiceLoadBalancerIngress
nodes:
type: ServiceClusterIP
Each node gets a load balancer with an externally reachable address. Clients outside the cluster connect through the load balancer address. Nodes still communicate within the cluster via ClusterIP.
IP families and dual-stack¶
The Operator supports IPv4, IPv6, and dual-stack networking. See IPv6 for configuration details.
Per-rack overrides¶
Each rack can override the labels and annotations on its member Services via exposeOptions at the rack level. This does not change the Service type — only metadata. It is useful for applying rack-specific load balancer annotations (for example, targeting a particular availability zone).
No NetworkPolicy by default¶
The Operator does not create Kubernetes NetworkPolicy resources. If your environment requires network-level isolation, you must create NetworkPolicy objects separately. See Security for related considerations.