Simplified Network Topology and Load-Balancing Enhancements in Windows for Kubernetes

We also simplified the network topology on Windows nodes in a Kubernetes cluster by reducing the number of endpoints required per container (or more generally, per pod) to one. Previously, Windows containers (pods) running in a Kubernetes cluster required two endpoints - one for external (internet) communication and a second for intra-cluster communication between between other nodes or pods in the cluster. This was due to the fact that external communication from containers attached to a host network with local scope (i.e. not publicly routable) required a NAT operation which could only be provided through the Windows NAT (WinNAT) component on the host. Intra-cluster communication required containers to be attached to a separate network with "global" (cluster-level) scope through a second endpoint. Recent platform improvements now enable NAT''ing to occur directly on a container endpoint which is implemented with the Microsoft Virtual Filtering Platform (VFP) Hyper-V switch extension. Now, both external and intra-cluster traffic can flow through a single endpoint. ## Load-Balancing using VFP in Windows kernel Kubernetes worker nodes rely on the kube-proxy to load-balance ingress network traffic to Service IPs between pods in a cluster. Previous versions of Windows implemented the Kube-proxy's load-balancing through a user-space proxy. We recently added support for "Proxy mode: iptables" which is implemented using VFP in the Windows kernel so that any IP traffic can be load-balanced more efficiently by the Windows OS kernel. Users can also configure an external load balancer by specifying the externalIP parameter in a service definition. In addition to the aforementioned improvements, we have also added platform support for the following: - Support for DNS search suffixes per container / Pod (Docker improvement - removes additional work previously done by kube-proxy to append DNS suffixes)  - [Platform Support] 5-tuple rules for creating ACLs (Looking for help from community to integrate this with support for K8s Network Policy) Now that Windows Server has [joined](https://blogs.technet.microsoft.com/hybridcloud/2017/07/13/new-windows-server-preview-release-available-to-windows-insiders/) the [Windows Insider Program](https://insider.windows.com/), customers and partners can take advantage of these new platform features today which accrue value to eagerly anticipated, new feature release later this year and new build after six months. The latest Windows Server insider [build](https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewserver) now includes support for all of these platform improvements. In addition to the platform improvements for Windows, the team submitted code (PRs) for CNI, kubelet, and kube-proxy with the goal of mainlining Windows support into the Kubernetes v1.8 release. These PRs remove previous work-arounds required on Windows for items such as user-mode proxy for internal load balancing, appending additional DNS suffixes to each Kube-DNS request, and a separate container endpoint for external (internet) connectivity. - [https://github.com/kubernetes/kubernetes/pull/51063](https://github.com/kubernetes/kubernetes/pull/51063)

The network topology on Windows nodes in Kubernetes clusters has been simplified by reducing the required endpoints per container to one, enabling both external and intra-cluster traffic to flow through a single endpoint. Load-balancing is improved with "Proxy mode: iptables" implemented using VFP in the Windows kernel. Support for DNS search suffixes and 5-tuple rules for ACLs has also been added. These improvements are available in the latest Windows Server insider build. Code contributions have been submitted to Kubernetes to mainline Windows support, removing previous workarounds for internal load balancing, DNS suffixes, and separate container endpoints.