diff --git a/content/en/blog/_posts/2023-12-18-kubernetes-1-29-feature-loadbalancer-ip-mode-alpha.md b/content/en/blog/_posts/2023-12-18-kubernetes-1-29-feature-loadbalancer-ip-mode-alpha.md new file mode 100644 index 0000000000000..14767cd5b999e --- /dev/null +++ b/content/en/blog/_posts/2023-12-18-kubernetes-1-29-feature-loadbalancer-ip-mode-alpha.md @@ -0,0 +1,110 @@ +--- +layout: blog +title: "Kubernetes 1.29: New (alpha) Feature, Load Balancer IP Mode for Services" +date: 2023-12-18 +slug: kubernetes-1-29-feature-loadbalancer-ip-mode-alpha +--- + +**Author:** [Aohan Yang](https://github.com/RyanAoh) + +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. + +## Background + +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: + +1. **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. + +2. **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. + +## Problems + +However, there are several problems with the aforementioned behavior: + +1. **[Source IP](https://github.com/kubernetes/kubernetes/issues/79783):** + 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. + +2. **[Feature loss at load balancer level](https://github.com/kubernetes/kubernetes/issues/66607):** + 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](https://github.com/kubernetes/kubernetes/issues/66607#issuecomment-474513060) +that involves setting `.status.loadBalancer.ingress.hostname` for the Service, in order +to bypass kube-proxy binding. +But this is just a makeshift solution. + +## 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: + +- If the traffic is delivered to the node then DNATed to the pod, the destination would be set to the node's IP and node port; +- If the traffic is delivered directly to the pod, the destination would be set to the pod's IP and port. + +## Usage + +Here are the necessary steps to enable this feature: + +- Download the [latest Kubernetes project](https://kubernetes.io/releases/download/) (version `v1.29.0` or later). +- Enable the feature gate with the command line flag `--feature-gates=LoadBalancerIPMode=true` +on kube-proxy, kube-apiserver, and cloud-controller-manager. +- For Services with `type: LoadBalancer`, set `ipMode` to the appropriate value. +This step is likely handled by your chosen cloud-controller-manager during the `EnsureLoadBalancer` process. + +## More information + +- Read [Specifying IPMode of load balancer status](/docs/concepts/services-networking/service/#load-balancer-ip-mode). +- Read [KEP-1860](https://kep.k8s.io/1860) - [Make Kubernetes aware of the LoadBalancer behaviour](https://github.com/kubernetes/enhancements/tree/b103a6b0992439f996be4314caf3bf7b75652366/keps/sig-network/1860-kube-proxy-IP-node-binding#kep-1860-make-kubernetes-aware-of-the-loadbalancer-behaviour) _(sic)_. + +## Getting involved + +Reach us on [Slack](https://slack.k8s.io/): [#sig-network](https://kubernetes.slack.com/messages/sig-network), +or through the [mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-network). + +## Acknowledgments + +Huge thanks to [@Sh4d1](https://github.com/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): + +- [@aojea](https://github.com/aojea) +- [@danwinship](https://github.com/danwinship) +- [@sftim](https://github.com/sftim) +- [@tengqm](https://github.com/tengqm) +- [@thockin](https://github.com/thockin) +- [@wojtek-t](https://github.com/wojtek-t) \ No newline at end of file