Configure CIDR blocks in VPCs
Use the following YAML fields to assign CIDR ranges to each resource type when you create or edit a VPC configuration. The following example shows a single VPC containing multiple clusters, with different CIDR ranges assigned to different resources:Example vpc.yaml
CIDR block size guidelines
CIDR blocks for Nodes, Pods, Services, and Load Balancers have different subnet allocation limits. The following guidelines are based on the maximum number of resources each CIDR block can accommodate:If you have a smaller environment, you can use smaller CIDR ranges. For example, if you plan only 500 Nodes for the cluster, a large CIDR block isn’t required. However, smaller CIDR ranges can limit future expansion, since Service IPs must be contiguous.
Pod CIDR capacity planning
CKS uses Cilium for Pod networking, and Cilium allocates a fixed block of 128 Pod IP addresses per Node. This block size doesn’t change when you lower the maximum Pods per Node, so the Pod CIDR sets a hard ceiling on how many Nodes the cluster can ever hold. Size the Pod CIDR for the total Node count you plan to reach, summed across every Node Pool:
The Node count includes both GPU and CPU Node Pools. For example, a cluster planned for 256 GPU Nodes plus any CPU Nodes exceeds the 256-Node limit of a
/17, so it needs at least a /16.
When a cluster runs out of Pod IP addresses, new Nodes can’t get Pod IPs, system Pods fail to start on them, and the Node Pool can report an InternalError status. If Node delivery fails as you approach a 256, 512, or 1,024 Node boundary, check Pod CIDR capacity before investigating Node hardware. On a cluster provisioned with too small a Pod CIDR from the start, the symptom can instead be Cilium agent Pods entering CrashLoopBackOff, followed by a cascade of downstream Pod failures. For a Node Pool already at its ceiling, contact support: expanding a live cluster’s Pod CIDR is a coordinated change, and on Direct Connect clusters it also requires advertising the new range.
Avoid rapidly recreating VPCs with the same name
VPC creation runs as an asynchronous workflow. If you delete a VPC and immediately recreate it with the same name, the new VPC can get stuck in a creating state for an extended period. When you test VPC creation and teardown, use a different, throwaway name for each attempt instead of reusing one name in quick succession. Treat a VPC as effectively immutable once you associate Direct Connect or custom endpoints with it. Deleting and recreating such a VPC destroys the provisioned resources and assigns a new VPC identifier, which also invalidates any infrastructure-as-code state that referenced the old identifier. If a VPC or cluster creation fails with a generic error such as “invalid request” in the Cloud Console, suspect a CIDR overlap with an existing VPC range. The VPC API returns a more descriptive error than the console surfaces, so check your new prefixes against existing VPC ranges.Plan CIDRs for connected VPCs
If your architecture connects multiple VPCs, plan address space carefully to avoid routing conflicts. When you connect two CoreWeave VPCs between CKS clusters, you must plan unique, non-overlapping address space across the clusters. At a minimum, the two clusters must have non-overlapping internal Load Balancer CIDR blocks. To simplify routing between VPCs, keep all CIDR ranges in each cluster non-overlapping, including the Pod, Service, and Load Balancer CIDRs. Set non-overlapping CIDR ranges when you create or edit each VPC in the Cloud Console. For the configuration flow, see Create and manage VPCs. For automation, you can provision VPCs and their prefixes with the VPC API (for example, with thehostPrefixes and vpcPrefixes fields).
Non-overlapping address space also benefits multi-cluster networking tools. If you use Liqo for multi-cluster networking, its network fabric prefers NAT-less communication when PodCIDRs are disjoint, and applies address translation only when overlaps exist.
Same-zone connectivity between two separate VPCs isn’t a standard self-service product. If you need to connect clusters in the same zone across separate VPCs, contact support or engage your CoreWeave representative to discuss the supported options for your deployment.
Advertise the right prefixes over Direct Connect
When you connect a cluster to your network over Direct Connect, advertise prefixes deliberately:- Advertise Pod IP ranges and LoadBalancer ranges as needed for the traffic you expect. Pod ranges are appropriate to advertise when on-premises systems must reach Pods directly.
- Don’t advertise the Service (ClusterIP) CIDR. ClusterIP addresses are virtual and resolve only inside the cluster, so routes to that range aren’t usable from your network.