Repository: kubernetes
Issue: Establish contract between kube-proxy on Windows and CNIs for handling source VIPs in overlay networking mode
Labels: area/kube-proxy,kind/feature,sig/windows,priority/important-longterm,triage/accepted

### What would you like to be added?

- Introduce a well-known, documented name for the HNS endpoint used as the source VIP, proposed to be named `sourcevip`. When `kube-proxy` starts up in [VXLAN overlay networking mode](https://kubernetes.io/docs/concepts/services-networking/windows-networking/#network-modes), it will check for the existence of an HNS endpoint named `sourcevip`. If found, the IP of this HNS endpoint will be used as the source VIP.
- The precedence will be as follows:
  1. Is `sourceVip` specified in the [KubeProxyWinkernelConfiguration](https://kubernetes.io/docs/reference/config-api/kube-proxy-config.v1alpha1/#kubeproxy-config-k8s-io-v1alpha1-KubeProxyWinkernelConfiguration)? If yes, use it. This step already exists.
  2. Does an HNS endpoint exist with the well-known name? If yes, use its IP as the `sourceVip`. This step is the proposed change.
  3. Fallback to creating a new source VIP. If this fails, log an error. This step already exists.
- Scope clarification: This change applies to Windows nodes operating in overlay networking mode.

### Why is this needed?

- Currently, in overlay networking mode on Windows nodes, `kube-proxy` can be configured with a [source VIP](https://github.com/kubernetes/kube-proxy/blob/8818cfbc4610c2baaba8778779877254b06f1c4f/config/v1alpha1/types.go#L137). 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, which `kube-proxy` can then reliably identify.
- Various CNIs have developed workarounds for this issue. This proposal aims to eliminate the need for such CNI-specific solutions, thereby enhancing ease of use and maintainability. For instance, Flannel utilizes a [script](https://github.com/kubernetes-sigs/sig-windows-tools/blob/fbe00b42e2a5cca06bc182e1b6ee579bd65ed1b5/hostprocess/flannel/kube-proxy/start.ps1#L58-L60) that must run before starting `kube-proxy` to determine the source VIP. This change would therefore render such scripts unnecessary.
- This change is also of importance in light of ongoing efforts in `sig-windows` to consolidate the `kube-proxy` image into an official host process Kubernetes container image, moving away from the currently more popular way of running `kube-proxy` as a binary agent on Windows nodes. A unified contract between `kube-proxy` and CNIs would facilitate the use of a this `kube-proxy` image across different CNIs.

```[tasklist]
### Tasks
- [x] Create draft PR and get early feedback from CNIs that support overlay networking mode
- [ ] Update kubernetes documentation with information on the well known HNS endpoint name
- [ ] Add unit tests
- [ ] Perform code changes and convert draft to final PR
```

### References
- [sig-windows Google Doc discussing this change]( https://docs.google.com/document/d/1A6Gkyx5EvL86Z4L2P4sxnk9HQjdRgnLXvBg6tIMDB3s/edit#heading=h.rqiiboge3f2e)