Kubernetes Service Address Management

Kubernetes Service Address Management refers to the allocation, tracking, and governance of the various IP addresses and address ranges a Service can hold or claim — ClusterIPs, external IPs, and load balancer addresses — treating address space as a finite, structured resource that must be planned rather than assumed to be infinite or self-managing.

ClusterIP Address Space

The Service CIDR Range

Every cluster reserves a dedicated CIDR block at creation time exclusively for Service ClusterIPs, separate from the pod network CIDR and the node network, and every ClusterIP Service (except headless ones) draws its virtual IP from this fixed pool.

kubectl cluster-info dump | grep -m 1 service-cluster-ip-range

Automatic vs. Manual Allocation

By default, the API server allocates the next available address from the Service CIDR automatically when a Service is created; a specific address can instead be requested explicitly via spec.clusterIP, which address management practice reserves for cases where a fixed, well-known internal address is genuinely required, such as compatibility with legacy configuration that hardcodes an IP rather than a DNS name.

spec:
  clusterIP: 10.96.14.100

Exhaustion Risk

Because the Service CIDR is fixed at cluster creation and difficult to resize afterward, address management includes monitoring how much of the range remains unallocated as the number of Services grows, since exhausting the Service CIDR blocks all further Service creation until the cluster's networking is reconfigured, an operation with broader disruption risk than most routine cluster changes.

kubectl get services --all-namespaces --no-headers | wc -l

External and Load Balancer Address Management

External IP Assignment

The externalIPs field allows a Service to be reached through a specific external IP address routed to the cluster outside of any cloud-managed load balancer, a manual address management mechanism generally used only in on-premises or specialized networking setups where the operator, not a cloud provider, controls how that external IP is actually routed to the nodes.

spec:
  externalIPs:
    - 203.0.113.10

Cloud-Allocated LoadBalancer Addresses

For LoadBalancer Services, the external address is allocated and managed by the cloud provider rather than by Kubernetes directly, with the resulting address reported back into the Service's status.loadBalancer.ingress field; address management here is primarily about tracking which Services hold which cloud-allocated addresses and reconciling that against the cloud provider's own billing and quota reporting.

kubectl get service ledger-api-public -o jsonpath='{.status.loadBalancer.ingress}'

Static Address Reservation

When a stable, persistent external address is required — one that must remain constant even if the Service is deleted and recreated — address management practice reserves a static IP directly with the cloud provider ahead of time and references it explicitly through loadBalancerIP or an equivalent provider-specific annotation, decoupling the address's lifecycle from the Service object's own lifecycle.

metadata:
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-eip-allocations: "eipalloc-0abc123456"

Dual-Stack Address Management

IPv4 and IPv6 Coexistence

In dual-stack clusters, a Service can hold both an IPv4 and an IPv6 ClusterIP simultaneously, tracked in the plural clusterIPs field, and address management in this context includes ensuring the Service CIDR ranges for both address families are sized appropriately, since exhaustion can occur independently in either family.

spec:
  ipFamilyPolicy: PreferDualStack
  ipFamilies:
    - IPv4
    - IPv6

Auditing and Reclaiming Address Usage

Identifying Unused Static Reservations

Because manually reserved static IPs and externalIPs entries persist independently of whether a Service is still actively used, address management includes periodic audits cross-referencing reserved external addresses against Services that still reference them, reclaiming addresses left behind by a deleted or migrated Service.

kubectl get services --all-namespaces -o jsonpath='{range .items[?(@.spec.externalIPs)]}{.metadata.namespace}{"/"}{.metadata.name}{": "}{.spec.externalIPs}{"\n"}{end}'

Address Collisions

Manually specified clusterIP or externalIPs values must be checked against existing allocations before assignment, since the API server rejects a request for an already-claimed ClusterIP but has no equivalent built-in protection preventing two Services from independently declaring the same conflicting externalIPs value, which is why address management treats explicit address requests as requiring coordination beyond what Kubernetes itself enforces.