Windows 上的网络
Kubernetes 支持在 Linux 或 Windows 上运行节点。你可以在单个集群中混合使用这两种节点。本页面概述了 Windows 操作系统特有的网络功能。
Windows 上的容器网络
Windows 容器的网络通过CNI 插件暴露。Windows 容器在网络方面与虚拟机功能相似。每个容器都有一个虚拟网络适配器 (vNIC)，连接到 Hyper-V 虚拟交换机 (vSwitch)。主机网络服务 (HNS) 和主机计算服务 (HCS) 协同工作以创建容器并将容器 vNIC 附加到网络。HCS 负责容器管理，而 HNS 负责网络资源管理，例如：
- 虚拟网络（包括 vSwitch 的创建）
- 端点/vNIC
- 命名空间
- 策略，包括数据包封装、负载均衡规则、ACL 和 NAT 规则。
Windows HNS 和 vSwitch 实现了命名空间，并可以根据需要为 Pod 或容器创建虚拟 NIC。但是，许多配置，如 DNS、路由和指标，存储在 Windows 注册表数据库中，而不是像 Linux 那样存储在 /etc 中的文件中。容器的 Windows 注册表与主机的注册表是分开的，因此像将主机上的 /etc/resolv.conf 映射到容器中这样的概念，不会产生与在 Linux 上相同的效果。这些必须使用在容器上下文中运行的 Windows API 进行配置。因此，CNI 实现需要调用 HNS，而不是依赖文件映射将网络详细信息传递到 Pod 或容器中。
网络模式
Windows 支持五种不同的网络驱动程序/模式：L2bridge、L2tunnel、Overlay (Beta)、Transparent 和 NAT。在一个同时包含 Windows 和 Linux 工作节点的异构集群中，你需要选择一个在 Windows 和 Linux 上都兼容的网络解决方案。下表列出了 Windows 上支持的树外插件，并就何时使用每个 CNI 提供了建议。
| 网络驱动程序 | 描述 | 容器数据包修改 | 网络插件 | 网络插件特性 |
|---|---|---|---|---|
| L2bridge | 容器连接到外部 vSwitch。容器连接到底层网络，尽管物理网络不需要学习容器 MAC，因为它们在入口/出口时会被重写。 | MAC 被重写为主机 MAC，IP 可能会使用 HNS OutboundNAT 策略重写为主机 IP。 | win-bridge，Azure-CNI，Flannel host-gateway 使用 win-bridge | win-bridge 使用 L2bridge 网络模式，将容器连接到主机的底层网络，提供最佳性能。需要用户定义的路由 (UDR) 来实现节点间连接。 |
| L2Tunnel | 这是 L2bridge 的一个特殊情况，但仅在 Azure 上使用。所有数据包都发送到应用 SDN 策略的虚拟化主机。 | MAC 重写，IP 在底层网络上可见 | Azure-CNI | Azure-CNI 允许容器与 Azure vNET 集成，并允许它们利用 Azure 虚拟网络提供的一系列功能。例如，安全连接到 Azure 服务或使用 Azure NSG。请参阅 azure-cni 获取一些示例 |
| Overlay | 容器被赋予一个连接到外部 vSwitch 的 vNIC。每个 Overlay 网络都有自己的 IP 子网，由自定义 IP 前缀定义。Overlay 网络驱动程序使用 VXLAN 封装。 | 用外部头部封装。 | win-overlay，Flannel VXLAN (使用 win-overlay) | 当希望虚拟容器网络与主机底层隔离时（例如出于安全原因），应使用 win-overlay。如果数据中心 IP 受限，它允许对不同的 Overlay 网络（具有不同的 VNID 标签）重用 IP。此选项需要 Windows Server 2019 上的 KB4489899。 |
| Transparent（ovn-kubernetes 的特殊用例） | 需要外部 vSwitch。容器连接到外部 vSwitch，通过逻辑网络（逻辑交换机和路由器）实现 Pod 内部通信。 | 数据包通过 GENEVE 或 STT 隧道封装，以到达不在同一主机上的 Pod。 数据包通过 ovn 网络控制器提供的隧道元数据信息进行转发或丢弃。 进行南北向通信的 NAT。 | ovn-kubernetes | 通过 Ansible 部署。可以通过 Kubernetes 策略应用分布式 ACL。支持 IPAM。无需 kube-proxy 即可实现负载均衡。无需使用 iptables/netsh 即可进行 NAT。 |
| NAT (Kubernetes 中不使用) | 容器被赋予一个连接到内部 vSwitch 的 vNIC。DNS/DHCP 通过名为 WinNAT 的内部组件提供。 | MAC 和 IP 被重写为主机 MAC/IP。 | nat | 此处列出仅为完整性 |
如上所述，Flannel CNI 插件也通过 VXLAN 网络后端（Beta 支持；委托给 win-overlay）和 host-gateway 网络后端（稳定支持；委托给 win-bridge）在 Windows 上受支持。
该插件支持委托给其中一个参考 CNI 插件（win-overlay、win-bridge），与 Windows 上的 Flannel 守护程序 (Flanneld) 协同工作，用于自动节点子网租约分配和 HNS 网络创建。该插件读取其自己的配置文件 (cni.conf)，并将其与 FlannelD 生成的 subnet.env 文件中的环境变量聚合。然后，它委托给其中一个参考 CNI 插件进行网络布线，并将包含节点分配子网的正确配置发送给 IPAM 插件（例如：host-local）。
对于 Node、Pod 和 Service 对象，以下网络流支持 TCP/UDP 流量
- Pod → Pod (IP)
- Pod → Pod (名称)
- Pod → Service (集群 IP)
- Pod → Service (PQDN，但仅当不包含 “.” 时)
- Pod → Service (FQDN)
- Pod → 外部 (IP)
- Pod → 外部 (DNS)
- 节点 → Pod
- Pod → 节点
IP 地址管理 (IPAM)
Windows 支持以下 IPAM 选项
- host-local
- azure-vnet-ipam (仅适用于 azure-cni)
- Windows Server IPAM (如果未设置 IPAM，则为备用选项)
直接服务器返回 (DSR)
Kubernetes v1.34 [稳定] (默认启用：true)负载均衡模式，其中 IP 地址修复和 LBNAT 直接发生在容器 vSwitch 端口上；服务流量以源 IP 设置为原始 Pod IP 的方式到达。这通过允许通过负载均衡器路由的返回流量绕过负载均衡器并直接响应客户端来提供性能优化；从而减少负载均衡器的负载并减少总体延迟。有关更多信息，请阅读直接服务器返回 (DSR) 简介。
负载均衡和服务
Kubernetes Service 是一种抽象，它定义了一组逻辑 Pod 和通过网络访问它们的方式。在包含 Windows 节点的集群中，你可以使用以下类型的 Service
NodePortClusterIPLoadBalancerExternalName
Windows 容器网络在某些重要方面与 Linux 网络不同。Microsoft 的 Windows 容器网络文档提供了更多详细信息和背景。
在 Windows 上，你可以使用以下设置来配置 Service 和负载均衡行为
| 特性 | 描述 | 支持的最低 Windows 操作系统版本 | 如何启用 |
|---|---|---|---|
| 会话亲和性 | 确保来自特定客户端的连接每次都传递给同一个 Pod。 | Windows Server 2022 | 将 service.spec.sessionAffinity 设置为 "ClientIP" |
| 直接服务器返回 (DSR) | 请参阅上面的 DSR 说明。 | Windows Server 2019 | 设置以下命令行参数（假设版本为 1.34）：--enable-dsr=true |
| 保留目的地址 | 跳过服务流量的 DNAT，从而保留到达后端 Pod 的数据包中目标服务的虚拟 IP。同时禁用节点间转发。 | Windows Server 版本 1903 | 在服务注解中设置 "preserve-destination": "true" 并在 kube-proxy 中启用 DSR。 |
| IPv4/IPv6 双栈网络 | 集群内部、出入集群的 IPv4-to-IPv4 与 IPv6-to-IPv6 通信并行进行 | Windows Server 2019 | 参阅 IPv4/IPv6 双栈 |
| 客户端 IP 保留 | 确保传入入口流量的源 IP 被保留。同时禁用节点间转发。 | Windows Server 2019 | 将 service.spec.externalTrafficPolicy 设置为 "Local" 并在 kube-proxy 中启用 DSR |
限制
Windows 节点不支持以下网络功能
- 主机网络模式
- 节点本身的本地 NodePort 访问（适用于其他节点或外部客户端）
- 单个 Service 的后端 Pod 数量（或唯一目标地址）超过 64 个
- 连接到 Overlay 网络的 Windows Pod 之间的 IPv6 通信
- 非 DSR 模式下的本地流量策略
- 使用
win-overlay、win-bridge或 Azure-CNI 插件通过 ICMP 协议进行出站通信。具体来说，Windows 数据平面 (VFP) 不支持 ICMP 数据包转换，这意味着：- 指向同一网络内目的地的 ICMP 数据包（例如 Pod 之间通过 ping 进行通信）按预期工作；
- TCP/UDP 数据包按预期工作；
- 指向通过远程网络（例如 Pod 到外部互联网通过 ping 进行通信）的 ICMP 数据包无法转换，因此不会路由回其源；
- 由于 TCP/UDP 数据包仍然可以转换，因此在调试与外部世界的连接时，可以用
curl <destination>替代ping <destination>。
其他限制
- Windows 参考网络插件 win-bridge 和 win-overlay 由于缺少
CHECK实现，未实现 CNI 规范 v0.4.0。 - Flannel VXLAN CNI 插件在 Windows 上有以下限制
- 节点-Pod 连接仅适用于 Flannel v0.12.0（或更高版本）的本地 Pod。
- Flannel 仅限于使用 VNI 4096 和 UDP 端口 4789。有关这些参数的更多详细信息，请参阅官方的 Flannel VXLAN 后端文档。