Windows 网络
Kubernetes 支持运行 Linux 或 Windows 节点。 你可以在统一集群内混布这两种节点。 本页提供了特定于 Windows 操作系统的网络概述。
Windows 容器网络
Windows 容器网络通过 CNI 插件暴露。 Windows 容器网络的工作方式与虚拟机类似。 每个容器都有一个连接到 Hyper-V 虚拟交换机（vSwitch）的虚拟网络适配器（vNIC）。 主机网络服务（Host Networking Service，HNS）和主机计算服务（Host Compute Service，HCS） 协同创建容器并将容器 vNIC 挂接到网络。 HCS 负责管理容器，而 HNS 负责管理以下网络资源：
- 虚拟网络（包括创建 vSwitch）
- Endpoint / 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 被重写为主机 MAC，可使用 HNS OutboundNAT 策略将 IP 重写为主机 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 | 容器被赋予一个 vNIC，连接到外部 vSwitch。每个上层网络都有自己的 IP 子网，由自定义 IP 前缀进行定义。该上层网络驱动使用 VXLAN 封装。 | 用外部头进行封装。 | win-overlay, Flannel VXLAN（使用 win-overlay） | 当需要将虚拟容器网络与主机的下层隔离时（例如出于安全原因），应使用 win-overlay。如果你的数据中心的 IP 个数有限，可以将 IP 在不同的上层网络中重用（带有不同的 VNID 标记）。在 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 中未使用） | 容器被赋予一个 vNIC，连接到内部 vSwitch。DNS/DHCP 是使用一个名为 WinNAT 的内部组件实现的 | MAC 和 IP 重写为主机 MAC/IP。 | nat | 放在此处保持完整性。 |
如上所述，Windows 通过 VXLAN 网络后端（Beta 支持；委派给 win-overlay） 和 host-gateway 网络后端（稳定支持；委派给 win-bridge） 也支持Flannel 的 CNI 插件。
此插件支持委派给参考 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）
- Node → Pod
- Pod → Node
IP 地址管理（IPAM）
Windows 支持以下 IPAM 选项：
- host-local
- azure-vnet-ipam（仅适用于 azure-cni）
- Windows Server IPAM（未设置 IPAM 时的回滚选项）
直接服务器返回（DSR）
Kubernetes v1.33 [beta]在负载均衡模式中 IP 地址修正和 LBNAT 直接发生在容器 vSwitch 端口；服务流量到达时源 IP 被设置为原始 Pod IP。 这种模式通过允许返回流量绕过负载均衡器，直接响应客户端，从而实现性能优化； 这不仅减轻了负载均衡器的压力，还降低了整体延迟。更多信息请参阅 Direct Server Return (DSR) 简介。
负载均衡和 Service
Kubernetes Service 是一种抽象：定义了逻辑上的一组 Pod 和一种通过网络访问这些 Pod 的方式。 在包含 Windows 节点的集群中，你可以使用以下类别的 Service：
NodePortClusterIPLoadBalancerExternalName
Windows 容器网络与 Linux 网络有着很重要的差异。 更多细节和背景信息，参考 Microsoft Windows 容器网络文档。
在 Windows 上，你可以使用以下设置来配置 Service 和负载均衡行为：
| 功能特性 | 描述 | 支持的 Windows 操作系统最低版本 | 启用方式 |
|---|---|---|---|
| 会话亲和性 | 确保每次都将来自特定客户端的连接传递到同一个 Pod。 | Windows Server 2022 | 将 service.spec.sessionAffinity 设为 “ClientIP” |
| Direct Server Return (DSR) | 参见上文 DSR 说明。 | Windows Server 2019 | 设置以下命令行参数（假设版本 1.33）： --enable-dsr=true |
| 保留目标（Preserve-Destination） | 跳过服务流量的 DNAT，从而在到达后端 Pod 的数据包中保留目标服务的虚拟 IP。也会禁用节点间的转发。 | Windows Server，version 1903 | 在服务注解中设置 "preserve-destination": "true" 并在 kube-proxy 中启用 DSR。 |
| IPv4/IPv6 双栈网络 | 进出集群和集群内通信都支持原生的 IPv4 间与 IPv6 间流量 | Windows Server 2019 | 参考 IPv4/IPv6 双栈。 |
| 客户端 IP 保留 | 确保入站流量的源 IP 得到保留。也会禁用节点间转发。 | Windows Server 2019 | 将 service.spec.externalTrafficPolicy 设置为 “Local” 并在 kube-proxy 中启用 DSR。 |
限制
Windows 节点不支持以下网络功能：
- 主机网络模式
- 从节点本身访问本地 NodePort（可以从其他节点或外部客户端进行访问）
- 为同一 Service 提供 64 个以上后端 Pod（或不同目的地址）
- 在连接到上层网络的 Windows Pod 之间使用 IPv6 通信
- 非 DSR 模式中的本地流量策略（Local Traffic Policy）
- 通过
win-overlay、win-bridge使用 ICMP 协议，或使用 Azure-CNI 插件进行出站通信。
具体而言，Windows 数据平面（VFP）不支持 ICMP 数据包转换，这意味着：- 指向同一网络内目的地址的 ICMP 数据包（例如 Pod 间的 ping 通信）可正常工作；
- TCP/UDP 数据包可正常工作；
- 通过远程网络指向其它地址的 ICMP 数据包（例如通过 ping 从 Pod 到外部公网的通信）无法被转换， 因此无法被路由回到这些数据包的源点；
- 由于 TCP/UDP 数据包仍可被转换，所以在调试与外界的连接时， 你可以将
ping <destination>替换为curl <destination>。
其他限制：
- 由于缺少
CHECK实现，Windows 参考网络插件 win-bridge 和 win-overlay 未实现 CNI 规约 的 v0.4.0 版本。 - Flannel VXLAN CNI 插件在 Windows 上有以下限制：
- 使用 Flannel v0.12.0（或更高版本）时，节点到 Pod 的连接仅适用于本地 Pod。
- Flannel 仅限于使用 VNI 4096 和 UDP 端口 4789。 有关这些参数的更多详细信息，请参考官方的 Flannel VXLAN 后端文档。
