diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index 95151f0e27c..8a60fb989ff 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -626,8 +626,7 @@ Each feature gate is designed for enabling/disabling a specific feature: - `MixedProtocolLBService`: Enable using different protocols in the same `LoadBalancer` type Service instance. - `MultiCIDRRangeAllocator`: Enables the MultiCIDR range allocator. -- `MultiCIDRServiceAllocator`: Enables a new IPAddress object kind, and a new Service ClusterIP allocator. - The new allocator removes previous Service CIDR block size limitations for IPv4, and limits IPv6 size to a /64. +- `MultiCIDRServiceAllocator`: Track IP address allocations for Service cluster IPs using IPAddress objects. - `NetworkPolicyEndPort`: Enable use of the field `endPort` in NetworkPolicy objects, allowing the selection of a port range instead of a single port. - `NetworkPolicyStatus`: Enable the `status` subresource for NetworkPolicy objects. diff --git a/content/en/docs/reference/networking/virtual-ips.md b/content/en/docs/reference/networking/virtual-ips.md index 32ff8626f0e..555d3c8ea59 100644 --- a/content/en/docs/reference/networking/virtual-ips.md +++ b/content/en/docs/reference/networking/virtual-ips.md @@ -271,25 +271,21 @@ When clients connect to the VIP, their traffic is automatically transported to a appropriate endpoint. The environment variables and DNS for Services are actually populated in terms of the Service's virtual IP address (and port). -{{< feature-state for_k8s_version="v1.27" state="alpha" >}} -If you enable the `MultiCIDRServiceAllocator` -[feature gate](/docs/reference/command-line-tools-reference/feature-gates/), -the `ClusterIP` address associated to each `Service` will have a referenced -`IPAddress` object. - ### Avoiding collisions One of the primary philosophies of Kubernetes is that you should not be exposed to situations that could cause your actions to fail through no fault of your own. For the design of the Service resource, this means not making -you choose your own port number if that choice might collide with +you choose your own IP address if that choice might collide with someone else's choice. That is an isolation failure. -In order to allow you to choose a port number for your Services, we must +In order to allow you to choose an IP address for your Services, we must ensure that no two Services can collide. Kubernetes does that by allocating each Service its own IP address from within the `service-cluster-ip-range` CIDR range that is configured for the {{< glossary_tooltip term_id="kube-apiserver" text="API Server" >}}. +#### IP address allocation tracking + To ensure each Service receives a unique IP, an internal allocator atomically updates a global allocation map in {{< glossary_tooltip term_id="etcd" >}} prior to creating each Service. The map object must exist in the registry for @@ -302,6 +298,16 @@ in-memory locking). Kubernetes also uses controllers to check for invalid assignments (e.g. due to administrator intervention) and for cleaning up allocated IP addresses that are no longer used by any Services. +{{< feature-state for_k8s_version="v1.27" state="alpha" >}} +If you enable the `MultiCIDRServiceAllocator` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/), +the control plane replaces the existing etcd allocator with a new one, using IPAddress +objects instead of an internal global allocation map. The ClusterIP address +associated to each `Service` will have a referenced IPAddress object. + +The background allocator is also replaced by a new one to handle the new IPAddress +objects and the migration from the old allocator model. + #### IP address ranges for Service virtual IP addresses {#service-ip-static-sub-range} {{< feature-state for_k8s_version="v1.25" state="beta" >}}