Docs / Kubernetes CIDR authority

The thing you call before a cluster exists, not after

Whereabouts, Cilium's cluster-pool IPAM, NVIDIA's IPAM plugin - every existing Kubernetes IPAM mechanism coordinates pod/service CIDR allocation within one cluster. None of them coordinateacross a fleet of clusters, and conflicting CIDRs across clusters is a real, documented failure mode: packets destined for a pod on one node get misrouted to another node with an overlapping range.

The module, wired to a real cluster

One call to nxip_subnet per cluster, guaranteed non-overlapping against every other cluster in the fleet, and against every other piece of address space your organization has registered, VPCs, on-prem sites, everything:

module "cluster_cidrs" {
  source = "github.com/uk-sw/terraform-nxip-modules//modules/aks-cidr"

  cluster_name = "payments-prod"
  environment  = "production"
  region       = "germanywestcentral"
}

resource "azurerm_kubernetes_cluster" "payments" {
  name                = "payments-prod"
  location            = "germanywestcentral"
  resource_group_name = azurerm_resource_group.payments.name
  dns_prefix          = "payments-prod"

  default_node_pool {
    name       = "default"
    node_count = 3
    vm_size    = "Standard_D2_v2"
  }

  network_profile {
    network_plugin = "kubenet"
    pod_cidr       = module.cluster_cidrs.pod_cidr
    service_cidr   = module.cluster_cidrs.service_cidr
    dns_service_ip = cidrhost(module.cluster_cidrs.service_cidr, 10)
  }

  identity {
    type = "SystemAssigned"
  }
}

EKS and GKE modules work the same way, wired to each cloud's actual cluster resource - see theterraform-nxip-modulesrepo for all three, including the one honest nuance specific to EKS (pods are first-class VPC citizens under the default CNI, there's no separate pod CIDR attribute the way AKS/GKE expose one).

Why this matters before the cluster exists

Run this a second time for a second cluster, and the ranges it gets are guaranteed distinct from the first, cluster-by-cluster math you'd otherwise track by hand, or discover has gone wrong only once two clusters are peered or federated and traffic starts landing in the wrong place. This puts nxip in theprovisioning path for cluster networking, not just watching after the fact and reporting drift.

Who this is actually for

A single cluster, or a handful you can keep in your head, doesn't need this - pick any CIDR that doesn't obviously clash and move on. This earns its keep once a fleet is big enough, or growing fast enough, that "did we already use this range somewhere else" stops being answerable from memory or a spreadsheet.

It's also deliberately the cheap version. Retroactive discovery of clusters that already exist, and a validating admission webhook that blocks a misconfigured cluster outside Terraform entirely, are real, harder engineering, tracked as the next phase innxip's public roadmap.

New to nxip? The Terraform quick startgets a pool and subnet running in a couple of minutes - the same nxip_subnet primitive these modules are built on.