Kubernetes Pod CIDR Calculator

Use this tool to estimate:

  • Required pod CIDR
  • Node CIDR
  • Service CIDR
  • Total IP usage

It is designed for the exact question teams ask during cluster design:

How big should my Kubernetes pod CIDR be?

Enter:

  • Number of nodes
  • Max pods per node
  • Growth buffer
  • Network plugin

The calculator then recommends the smallest practical ranges for common Kubernetes networking models.

What This Tool Calculates

The planner estimates three capacity domains:

1. Pod CIDR

Pod capacity is based on:

nodes × max pods per node × growth buffer

If your network plugin uses a separate pod range, the calculator returns the smallest CIDR that can hold that pod demand.

If your plugin uses a shared subnet model, the calculator explains that pods consume the same range as nodes.

2. Node CIDR

Node CIDR sizing is based on planned node count after growth buffer.

The calculator also applies provider-style subnet reservation behavior where relevant:

  • Azure-style models: 5 reserved IPs
  • AWS-style models: 5 reserved IPs
  • GKE secondary ranges: 4 reserved IPs

3. Service CIDR

Kubernetes services need their own cluster IP range.

This tool recommends a practical service CIDR with headroom so that internal services do not become a hidden scaling bottleneck later.

4. Total IP Usage

The total output shows the planned IP demand across:

  • Node addressing
  • Pod addressing
  • Service addressing

That makes it easier to validate whether your design still fits your wider VNet, VPC, or subnet allocation strategy.

Network Plugin Options

The calculator supports the most common planning patterns:

Overlay CNI

Examples:

  • AKS Overlay
  • Kubenet
  • ARO / OpenShift-style overlay planning

Pods use a separate pod CIDR, which reduces pressure on the node subnet.

Azure CNI

Pods and nodes share the same Azure subnet.

This is one of the most common causes of subnet exhaustion in AKS.

AWS VPC CNI

Pods and nodes usually share the same VPC subnet.

This means pod density directly affects subnet sizing.

GKE Alias IP

GKE uses:

  • Primary subnet for nodes
  • Secondary range for pods
  • Secondary range for services

This is usually easier to scale cleanly, but it still requires deliberate CIDR planning.

Example

Assume:

  • 20 nodes
  • 30 max pods per node
  • 25% growth buffer
  • Overlay CNI

The calculator will estimate:

  • A pod CIDR large enough for total pod demand
  • A node CIDR sized for planned node growth
  • A service CIDR with reasonable headroom
  • Total planned IP consumption across all three ranges

Why Pod CIDR Sizing Matters

If your pod CIDR is too small, Kubernetes scaling fails in subtle ways:

  • New pods stop scheduling
  • New nodes cannot be allocated pod address space
  • Autoscaling appears broken
  • Cluster growth stalls during production events

Resizing these ranges later is often painful or impossible without migration.

That is why it is usually safer to start slightly larger than the mathematical minimum.