Open tzifudzi opened 9 months ago
/kind feature /sig windows /milestone v1.30
@tzifudzi: You must be a member of the kubernetes/milestone-maintainers GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your Milestone Maintainers Team and have them propose you as an additional delegate for this responsibility.
/kind feature /sig windows
cc @jsturtevant
/assign tzifudzi
/area kube-proxy
hi @tzifudzi , I appreciate you bringing up the need to establish a clear protocol between kube-proxy on Windows and CNIs for handling source VIPs. This is a crucial step forward in enhancing interoperability and simplifying configurations. Thank you for your efforts in addressing this issue.
@tzifudzi I kindly suggest integrating a validation feature within kube-proxy to confirm CNI compliance with the proposed naming standards for source VIPs in overlay networks. This proactive measure could enhance integration and prevent potential misconfigurations, ensuring a smoother collaboration between kube-proxy and CNIs.
I kindly suggest integrating a validation feature within kube-proxy to confirm CNI compliance with the proposed naming standards for source VIPs in overlay networks
however, implementing it could increase complexity, diverse CNI architectures, ensuring backward compatibility, and crafting precise error handling strategies. These aspects would need careful navigation to integrate effectively.
@tzifudzi I'm genuinely interested in contributing to the conversation and development of this feature. Should there be a need for deeper discussion or hands-on assistance in bringing this concept to fruition, I'm more than willing to lend my expertise and collaborate closely. Thanks for the contribution!
/triage accepted /priority important-longterm
Adding the original document at was shared with sig-windows for historical reference: https://docs.google.com/document/d/1A6Gkyx5EvL86Z4L2P4sxnk9HQjdRgnLXvBg6tIMDB3s/edit#heading=h.rqiiboge3f2e
/cc @daschott
@pranav-pandey0804 Thanks for the comments and considerations. In the notes in the description I briefly touched on the error handling workflow and considerations for backward compatibility. Will add more information in the PR when the change is ready. I will be working on this change alongside jsturtevant@ and assigned the issue to myself, but we will need all the feedback we can get. I will add you as a reviewer on the PR.
Thanks, @tzifudzi, for considering my input and the detailed update. I'm keen to see how we tackle error handling and backward compatibility in the PR. Looking forward to contributing to the review process.
What would you like to be added?
sourcevip
. Whenkube-proxy
starts up in VXLAN overlay networking mode, it will check for the existence of an HNS endpoint namedsourcevip
. If found, the IP of this HNS endpoint will be used as the source VIP.sourceVip
specified in the KubeProxyWinkernelConfiguration? If yes, use it. This step already exists.sourceVip
. This step is the proposed change.Why is this needed?
kube-proxy
can be configured with a source VIP. The challenge arises because the IP address for the source VIP is not always predetermined and varies depending on the CNI implementation. A well-known HNS endpoint name would streamline the process by allowing the CNI to set the source VIP on a well known name, whichkube-proxy
can then reliably identify.kube-proxy
to determine the source VIP. This change would therefore render such scripts unnecessary.sig-windows
to consolidate thekube-proxy
image into an official host process Kubernetes container image, moving away from the currently more popular way of runningkube-proxy
as a binary agent on Windows nodes. A unified contract betweenkube-proxy
and CNIs would facilitate the use of a thiskube-proxy
image across different CNIs.References