GCP VPC Network Planner
Plan GCP subnets and GKE secondary ranges, allowing for the four reserved addresses and the per-node pod CIDR.
Inputs
GKE recommends a /14 pod range, which supports a large cluster without renumbering.
GKE rounds this up to a power of two and carves that many addresses per node — 110 pods means a /24.
Usable Addresses in Subnet
4,092addresses
Reserved by Google
4addresses
Addresses Needed with Growth
1,224addresses
Primary Subnet Verdict
Comfortable for the planned growth
Pod Range Capacity
262,144addresses
Nodes the Pod Range Supports
1,024nodes
Addresses Carved per Node
256addresses
Service Range Capacity
4,096services
Step by step
Values used
Primary subnet prefix = 20 bits; Secondary pod range prefix = 14 bits; Secondary service range prefix = 20 bits; Maximum pods per node = 110 pods; Nodes planned in this subnet = 200 nodes; Other VMs and endpoints in the subnet = 400 addresses; Internal load balancer addresses = 12 addresses; Planned growth multiple = 2 x
GCP VPC Network
usable = 2^(32 − prefix) − 4 reserved; each GKE node consumes 2^ceil(log2(pods per node × 2)) addresses from the secondary pod range, so nodes supported = pod range size ÷ that block.
Usable Addresses in Subnet
= 4,092 addresses
Reserved by Google
= 4 addresses
Addresses Needed with Growth
= 1,224 addresses
Primary Subnet Verdict
= Comfortable for the planned growth
Pod Range Capacity
= 262,144 addresses
Nodes the Pod Range Supports
= 1,024 nodes
How it works
GCP reserves four addresses per subnet rather than two, and GKE consumes addresses from two secondary ranges on top of the primary one. The per-node pod block is rounded up to a power of two of roughly double the pod limit, so 110 pods per node burns a full /24 — which is why a /14 pod range is the standard recommendation. Primary subnet ranges can be expanded but never shrunk, and a GKE secondary pod range cannot be changed after cluster creation, so an undersized range means rebuilding the cluster rather than editing a setting. Getting the arithmetic right once is far cheaper than renumbering later.
Formula
GCP VPC Network
usable = 2^(32 − prefix) − 4 reserved; each GKE node consumes 2^ceil(log2(pods per node × 2)) addresses from the secondary pod range, so nodes supported = pod range size ÷ that block.
- 4 reserved
- GCP reserves the network address, the default gateway, and the last two addresses in every subnet
- pod block per node
- Power-of-two CIDR GKE allocates per node — 110 pods rounds up to 256 addresses, a /24
- secondary range
- Alias IP range for pods or services, sized independently of the primary subnet
Frequently Asked Questions
How is GCP VPC Network calculated?
usable = 2^(32 − prefix) − 4 reserved; each GKE node consumes 2^ceil(log2(pods per node × 2)) addresses from the secondary pod range, so nodes supported = pod range size ÷ that block. GCP reserves four addresses per subnet rather than two, and GKE consumes addresses from two secondary ranges on top of the primary one. The per-node pod block is rounded up to a power of two of roughly double the pod limit, so 110 pods per node burns a full /24 — which is why a /14 pod range is the standard recommendation.
Why does GCP VPC Network matter?
Primary subnet ranges can be expanded but never shrunk, and a GKE secondary pod range cannot be changed after cluster creation, so an undersized range means rebuilding the cluster rather than editing a setting. Getting the arithmetic right once is far cheaper than renumbering later.
What values do I need to enter?
This calculator takes 8 inputs: Primary subnet prefix, Secondary pod range prefix, Secondary service range prefix, Maximum pods per node, Nodes planned in this subnet, Other VMs and endpoints in the subnet, Internal load balancer addresses, Planned growth multiple. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Why does 110 pods per node need 256 addresses?
GKE allocates a power-of-two CIDR per node and adds headroom so addresses are not reused immediately as pods churn. At the default limit of 110 that rounds up to 256 addresses — a /24 per node — which is the figure to multiply when sizing the pod range.