本文超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。

Windows 网络与 Kubernetes 的 Linux 网络达到同等水平

作者：Jason Messer（微软） |

自从我四个月前在博客上发表关于Windows 的 Kubernetes 网络的文章以来，Windows 核心网络团队在平台和开源 Kubernetes 项目方面都取得了巨大的进步。通过这些更新，Windows 现在在网络方面与 Linux 处于同等水平。客户现在可以在任何环境（包括 Azure、本地和第三方云堆栈）中部署混合操作系统 Kubernetes 集群，并使用与 Linux 上支持的相同的网络原语和拓扑，而无需任何变通方法、“黑客手段”或第三方交换机扩展。

你可能会问“那又怎样？”。这些平台改进对希望运行 Kubernetes 的开发人员和运营团队的生活产生了重大影响，原因有很多，涉及应用程序和基础设施。继续阅读以了解更多信息！

紧密耦合通信

这些改进支持单个“Pod”内多个 Windows Server 容器（无 Hyper-V 隔离）之间的紧密耦合通信。可以将 Pod 视为 Kubernetes 集群的调度单元，在其中，一个或多个应用程序容器位于同一位置并能够共享存储和网络资源。Pod 内的所有容器共享相同的 IP 地址和端口范围，并且能够使用 localhost 相互通信。这使应用程序能够轻松利用“辅助”程序来执行监控、配置更新、日志管理和代理等任务。另一种将 Pod 视为计算主机的方式是将应用程序容器表示为进程。

简化的网络拓扑

我们还通过减少每个容器（或更一般地说，每个 Pod）所需的端点数到一个，简化了 Kubernetes 集群中 Windows 节点上的网络拓扑。以前，在 Kubernetes 集群中运行的 Windows 容器 (Pod) 需要两个端点 - 一个用于外部（互联网）通信，另一个用于集群内其他节点或 Pod 之间的通信。这是因为从连接到具有本地范围（即不可公开路由）的主机网络的容器进行外部通信需要 NAT 操作，而该操作只能通过主机上的 Windows NAT (WinNAT) 组件提供。集群内通信要求容器通过第二个端点连接到具有“全局”（集群级别）范围的单独网络。最近的平台改进现在允许 NAT 直接在容器端点上发生，该端点是使用 Microsoft 虚拟过滤平台 (VFP) Hyper-V 交换机扩展实现的。现在，外部和集群内流量都可以通过单个端点流动。

使用 Windows 内核中的 VFP 进行负载均衡

Kubernetes 工作节点依靠 kube-proxy 在集群中的 Pod 之间对流向服务 IP 的入口网络流量进行负载均衡。以前版本的 Windows 通过用户空间代理实现了 Kube-proxy 的负载均衡。我们最近添加了对“代理模式：iptables”的支持，该模式是使用 Windows 内核中的 VFP 实现的，以便 Windows 操作系统内核可以更有效地对任何 IP 流量进行负载均衡。用户还可以通过在服务定义中指定 externalIP 参数来配置外部负载均衡器。除了上述改进之外，我们还添加了对以下内容的平台支持

  • 支持每个容器/Pod 的 DNS 搜索后缀（Docker 改进 - 删除了 kube-proxy 以前为追加 DNS 后缀所做的额外工作）
  • [平台支持] 用于创建 ACL 的 5 元组规则（正在寻求社区帮助以将其与对 K8s 网络策略的支持集成）

现在 Windows Server 已加入Windows 预览体验计划，客户和合作伙伴今天就可以利用这些新的平台功能，这些功能将在今年晚些时候发布的 eagerly anticipated 的新功能版本和六个月后的新版本中发挥价值。最新的 Windows Server 预览体验成员版本现在包含对所有这些平台改进的支持。

除了对 Windows 的平台改进之外，该团队还为 CNI、kubelet 和 kube-proxy 提交了代码（PR），目标是将 Windows 支持纳入 Kubernetes v1.8 版本的主线。这些 PR 删除了 Windows 以前所需的解决方法，例如用于内部负载均衡的用户模式代理、向每个 Kube-DNS 请求追加额外的 DNS 后缀，以及用于外部（互联网）连接的单独容器端点。

这些新的平台功能以及 kubelet 和 kube-proxy 上的工作与 Linux 上 Kubernetes 使用的 CNI 网络模型保持一致，并简化了 K8s 集群的部署，无需额外的配置或自定义（Azure）资源模板。为此，我们完成了 CNI 网络和 IPAM 插件的工作，以创建/删除端点并管理 IP 地址。CNI 插件通过 kubelet 来定位 Windows 主机网络服务 (HNS) API，以创建由 VFP 交换机扩展强制执行的“l2bridge”网络（类似于 Linux 上的 macvlan）。

'l2bridge' 网络驱动程序在入口和出口处重写容器网络流量的 MAC 地址，以使用容器主机的 MAC 地址。这避免了上游网络交换机端口（容器主机连接到该端口）需要“学习”多个 MAC 地址（主机上每个容器一个）。这保留了物理交换机 TCAM 表中的内存空间，并依赖 Hyper-V 虚拟交换机在主机中进行 MAC 地址转换以将流量转发到正确的容器。IP 地址由默认的 Windows IPAM 插件管理，该插件要求 POD CIDR IP 取自容器主机的网络 IP 空间。

该团队向 SIG-Windows 组演示了（链接到视频）这些新的平台功能和开源更新。8/8。我们正在与社区合作，合并 kubelet 和 kube-proxy PR，以便及时将这些更改纳入将于今年 9 月发布的 Kubernetes v1.8 版本的主线。然后，这些功能可以在当前的 Windows Server 预览体验成员版本和Windows Server 版本 1709 中使用。

RTM 后不久，我们还将在 Azure 容器服务 (ACS) 中引入这些改进，以便 Windows 工作节点和托管的容器成为一流的 Azure VNet 公民。适用于 Windows CNI 的 Azure IPAM 插件将使这些端点能够直接连接到 Azure VNet，并以与 VM 相同的方式对 Windows 容器强制执行网络策略。

| 功能 | Windows Server 2016（已上市） | 下一个 Windows Server 功能版本，半年频道 | Linux | | 具有共享网络命名空间（隔离区）的每个 Pod 的多个容器 | 每个 Pod 一个容器 | ✔ | ✔ | | 每个 Pod 的单个（共享）端点 | 两个端点：WinNAT（外部）+ 透明（集群内） | ✔ | ✔ | | 用户模式，负载均衡 | ✔ | ✔ | ✔ | | 内核模式，负载均衡 | 不支持 | ✔ | ✔ | | 支持每个 Pod 的 DNS 搜索后缀（Docker 更新） | Kube-Proxy 为每个请求添加了多个 DNS 后缀 | ✔ | ✔ | | CNI 插件支持 | 不支持 | ✔ | ✔ |

Kubernetes SIG Windows 组每两周的星期二下午 12:30（美国东部时间）举行一次会议。要加入或查看以前会议的记录，请查看此文档。