Goglides Dev 🌱

Goglides Dev 🌱 is a community of amazing users

We are working on this space so that IT professionals can grow together.

Create account Log in

Posted on • Originally published at kubernetes.io on

Blog: Kubernetes 1.24: Avoid Collisions Assigning IP Addresses to Services

Author: Antonio Ojea (Red Hat)

In Kubernetes, Services are an abstract way to expose an application running on a set of Pods. Services can have a cluster-scoped virtual IP address (using a Service of type: ClusterIP). Clients can connect using that virtual IP address, and Kubernetes then load-balances traffic to that Service across the different backing Pods.

How Service ClusterIPs are allocated?

A Service ClusterIP can be assigned:

the cluster's control plane automatically picks a free IP address from within the configured IP range for type: ClusterIP Services.
you specify an IP address of your choice, from within the configured IP range for Services.

Across your whole cluster, every Service ClusterIP must be unique. Trying to create a Service with a specific ClusterIP that has already been allocated will return an error.

Why do you need to reserve Service Cluster IPs?

Sometimes you may want to have Services running in well-known IP addresses, so other components and users in the cluster can use them.

The best example is the DNS Service for the cluster. Some Kubernetes installers assign the 10th address from the Service IP range to the DNS service. Assuming you configured your cluster with Service IP range and you want your DNS Service IP to be, you'd have to create a Service like this:

apiVersion: v1
kind: Service
 k8s-app: kube-dns
 kubernetes.io/cluster-service: "true"
 kubernetes.io/name: CoreDNS
 name: kube-dns
 namespace: kube-system
 - name: dns
 port: 53
 protocol: UDP
 targetPort: 53
 - name: dns-tcp
 port: 53
 protocol: TCP
 targetPort: 53
 k8s-app: kube-dns
 type: ClusterIP

Enter fullscreen mode Exit fullscreen mode

but as I explained before, the IP address has not been reserved; if other Services are created before or in parallel with dynamic allocation, there is a chance they can allocate this IP, hence, you will not be able to create the DNS Service because it will fail with a conflict error.

How can you avoid Service ClusterIP conflicts?

In Kubernetes 1.24, you can enable a new feature gate ServiceIPStaticSubrange. Turning this on allows you to use a different IP allocation strategy for Services, reducing the risk of collision.

The ClusterIP range will be divided, based on the formula min(max(16, cidrSize / 16), 256), described as never less than 16 or more than 256 with a graduated step between them.

Dynamic IP assignment will use the upper band by default, once this has been exhausted it will use the lower range. This will allow users to use static allocations on the lower band with a low risk of collision.


Service IP CIDR block:

Range Size: 28 - 2 = 254

Band Offset: min(max(16,256/16),256) = min(16,256) = 16

Static band start:

Static band end:

Range end:

pie showData title "Static" : 16 "Dynamic" : 238

JavaScript must be enabled to view this content

Service IP CIDR block:

Range Size: 212 - 2 = 4094

Band Offset: min(max(16,256/16),256) = min(256,256) = 256

Static band start:

Static band end:

Range end:

pie showData title "Static" : 256 "Dynamic" : 3838

JavaScript must be enabled to view this content

Service IP CIDR block:

Range Size: 216 - 2 = 65534

Band Offset: min(max(16,65536/16),256) = min(4096,256) = 256

Static band start:

Static band ends:

Range end:

pie showData title "Static" : 256 "Dynamic" : 65278

JavaScript must be enabled to view this content

Get involved with SIG Network

The current SIG-Network KEPs and issues on GitHub illustrate the SIG’s areas of emphasis.

SIG Network meetings are a friendly, welcoming venue for you to connect with the community and share your ideas. Looking forward to hearing from you!

Discussion (0)