This article is more than one year old. Older articles may contain outdated content. Check that the information in the page has not become incorrect since its publication.
This blog introduces a new alpha feature in Kubernetes 1.29. It provides a configurable approach to define how Service implementations, exemplified in this blog by kube-proxy, handle traffic from pods to the Service, within the cluster.
In older Kubernetes releases, the kube-proxy would intercept traffic that was destined for the IP
address associated with a Service of type: LoadBalancer. This happened whatever mode you used
for kube-proxy.
The interception implemented the expected behavior (traffic eventually reaching the expected
endpoints behind the Service). The mechanism to make that work depended on the mode for kube-proxy;
on Linux, kube-proxy in iptables mode would redirecting packets directly to the endpoint; in ipvs mode,
kube-proxy would configure the load balancer's IP address to one interface on the node.
The motivation for implementing that interception was for two reasons:
Traffic path optimization: Efficiently redirecting pod traffic - when a container in a pod sends an outbound packet that is destined for the load balancer's IP address - directly to the backend service by bypassing the load balancer.
Handling load balancer packets: Some load balancers send packets with the destination IP set to the load balancer's IP address. As a result, these packets need to be routed directly to the correct backend (which might not be local to that node), in order to avoid loops.
However, there are several problems with the aforementioned behavior:
Source IP:
Some cloud providers use the load balancer's IP as the source IP when
transmitting packets to the node. In the ipvs mode of kube-proxy,
there is a problem that health checks from the load balancer never return. This occurs because the reply packets
would be forward to the local interface kube-ipvs0(where the load balancer's IP is bound to)
and be subsequently ignored.
Feature loss at load balancer level: Certain cloud providers offer features(such as TLS termination, proxy protocol, etc.) at the load balancer level. Bypassing the load balancer results in the loss of these features when the packet reaches the service (leading to protocol errors).
Even with the new alpha behaviour disabled (the default), there is a
workaround
that involves setting .status.loadBalancer.ingress.hostname for the Service, in order
to bypass kube-proxy binding.
But this is just a makeshift solution.
In summary, providing an option for cloud providers to disable the current behavior would be highly beneficial.
To address this, Kubernetes v1.29 introduces a new (alpha) .status.loadBalancer.ingress.ipMode
field for a Service.
This field specifies how the load balancer IP behaves and can be specified only when
the .status.loadBalancer.ingress.ip field is also specified.
Two values are possible for .status.loadBalancer.ingress.ipMode: "VIP" and "Proxy".
The default value is "VIP", meaning that traffic delivered to the node
with the destination set to the load balancer's IP and port will be redirected to the backend service by kube-proxy.
This preserves the existing behavior of kube-proxy.
The "Proxy" value is intended to prevent kube-proxy from binding the load balancer's IP address
to the node in both ipvs and iptables modes.
Consequently, traffic is sent directly to the load balancer and then forwarded to the destination node.
The destination setting for forwarded packets varies depending on how the cloud provider's load balancer delivers traffic:
Here are the necessary steps to enable this feature:
v1.29.0 or later).--feature-gates=LoadBalancerIPMode=true
on kube-proxy, kube-apiserver, and cloud-controller-manager.type: LoadBalancer, set ipMode to the appropriate value.
This step is likely handled by your chosen cloud-controller-manager during the EnsureLoadBalancer process.Reach us on Slack: #sig-network, or through the mailing list.
Huge thanks to @Sh4d1 for the original KEP and initial implementation code. I took over midway and completed the work. Similarly, immense gratitude to other contributors who have assisted in the design, implementation, and review of this feature (alphabetical order):