Networking¶
This page describes the network model of the Servala platform: how clusters are placed in private networks, how address space is allocated, and how customer namespaces are isolated. For cluster and API connectivity, see Secure Access.
Network Architecture¶
Each cluster is deployed in a private network on the CSP. The only public exposure is for Gateway API traffic via the CSP's load balancer service.
CIDR Allocation Strategy¶
Each cluster receives non-overlapping network ranges:
| Range Type | Pool | Per Cluster |
|---|---|---|
| Pod CIDR | 10.0.0.0/9 | /17 |
| Service CIDR | 10.128.0.0/12 | /20 |
| Node CIDR | 172.16.0.0/16 | /24 |
This allocation supports 256 clusters.
Reserved for future expansion: 10.144.0.0 to 10.255.255.255 and 172.17.0.0/16.
Capacity Constraints¶
| Resource | Limit | Notes |
|---|---|---|
| Max clusters | 256 | Limited by all three pools equally |
| Max nodes/cluster | 128 | /17 pod CIDR divided by /24 per node = 128 nodes |
| Max pods/node | 110 | Talos default; /24 per node provides 256 IPs |
| Max pods/cluster | 14080 | 128 nodes * 110 pods |
| Max services/cluster | 4096 | /20 = 4096 IPs |
Kubernetes defaults to allocating a /24 (256 IPs) per node from the pod CIDR, providing roughly 2x headroom over the 110 max pods/node for churn during rolling updates.
Cluster CIDR Assignments¶
| Cluster ID | Pod CIDR | Service CIDR | Node CIDR |
|---|---|---|---|
| 0 | 10.0.0.0/17 | 10.128.0.0/20 | 172.16.0.0/24 |
| 1 | 10.0.128.0/17 | 10.128.16.0/20 | 172.16.1.0/24 |
| 2 | 10.1.0.0/17 | 10.128.32.0/20 | 172.16.2.0/24 |
| 3 | 10.1.128.0/17 | 10.128.48.0/20 | 172.16.3.0/24 |
| 4 | 10.2.0.0/17 | 10.128.64.0/20 | 172.16.4.0/24 |
| 5 | 10.2.128.0/17 | 10.128.80.0/20 | 172.16.5.0/24 |
| ... | ... | ... | ... |
| 255 | 10.127.128.0/17 | 10.143.240.0/20 | 172.16.255.0/24 |
When creating a new cluster, select the next available cluster ID and use the corresponding ranges.
Network Isolation¶
Each AppCat service instance is deployed to an isolated namespace with strict network boundaries.
- Default-deny network policies are applied to all customer namespaces
- Only external ingress traffic through the Gateway API gateways is permitted by default
- East-west traffic between customer namespaces is blocked unless explicitly configured