Windows 上的网络
Kubernetes 支持在 Linux 或 Windows 上运行节点。你可以在单个集群中混合使用这两种类型的节点。本页面概述了特定于 Windows 操作系统的网络。
Windows 上的容器网络
Windows 容器的网络功能通过 CNI 插件暴露出来。Windows 容器在网络方面与虚拟机功能类似。每个容器都有一个虚拟网卡 (vNIC)，该网卡连接到一个 Hyper-V 虚拟交换机 (vSwitch)。主机网络服务 (Host Networking Service, HNS) 和主机计算服务 (Host Compute Service, HCS) 协同工作，创建容器并将容器的 vNIC 连接到网络。HCS 负责容器的管理，而 HNS 负责管理网络资源，例如：
- 虚拟网络（包括创建 vSwitch）
- 端点 / vNIC
- 名字空间
- 策略，包括数据包封装、负载均衡规则、ACL 和 NAT 规则。
Windows HNS 和 vSwitch 实现了命名空间功能，可以根据需要为 Pod 或容器创建虚拟网卡。然而，许多配置（例如 DNS、路由和指标）存储在 Windows 注册表数据库中，而不是像 Linux 那样存储在 /etc 内的文件中。容器的 Windows 注册表与主机的注册表是分开的，因此像将主机的 /etc/resolv.conf 映射到容器中的概念在 Windows 上不像在 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，IP 可能使用 HNS 出站 NAT 策略重写为宿主机的 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，vSwitch 通过逻辑网络（逻辑交换机和路由器）实现 Pod 间通信。 | 数据包通过 GENEVE 或 STT 隧道封装，以到达不在同一宿主机上的 Pod。 数据包通过 ovn 网络控制器提供的隧道元数据信息进行转发或丢弃。 南北向通信使用 NAT。 | ovn-kubernetes | 通过 ansible 部署。分布式 ACL 可以通过 Kubernetes 策略应用。支持 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 (Name)
- Pod → Service (Cluster 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.33 [beta]负载均衡模式，其中 IP 地址修复和 LBNAT 直接在容器 vSwitch 端口上发生；服务流量到达时，源 IP 被设置为发起 Pod 的 IP。这通过允许通过负载均衡器路由的返回流量绕过负载均衡器并直接响应客户端来提供性能优化；减少了负载均衡器上的负载，同时也降低了整体延迟。更多信息请阅读 Direct Server Return (DSR) in a nutshell。
负载均衡和 Service
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.33）：--enable-dsr=true |
| Preserve-Destination | 跳过服务流量的 DNAT，从而在到达后端 Pod 的数据包中保留目标服务的虚拟 IP。同时也禁用节点间转发。 | Windows Server，版本 1903 | 在 service 的注解中设置 "preserve-destination": "true"，并在 kube-proxy 中启用 DSR。 |
| IPv4/IPv6 双栈网络 | 在集群内部、向集群或从集群进行的原生 IPv4-到-IPv4 与 IPv6-到-IPv6 通信并行进行 | Windows Server 2019 | 参见 IPv4/IPv6 双栈 |
| 客户端 IP 保留 | 确保入站 ingress 流量的源 IP 被保留。同时也禁用节点间转发。 | Windows Server 2019 | 将 service.spec.externalTrafficPolicy 设置为 "Local"，并在 kube-proxy 中启用 DSR |
限制
以下网络功能在 Windows 节点上不受支持：
- 宿主网络模式
- 从节点本身进行本地 NodePort 访问（对其他节点或外部客户端有效）
- 单个 Service 超过 64 个后端 Pod（或唯一目标地址）
- 连接到 overlay 网络的 Windows Pod 之间的 IPv6 通信
- 非 DSR 模式下的本地流量策略
- 通过
win-overlay、win-bridge或使用 Azure-CNI 插件进行使用 ICMP 协议的出站通信。具体来说，Windows 数据平面（VFP）不支持 ICMP 数据包转换，这意味着：- 发送到同一网络内目标（例如通过 ping 进行的 Pod 到 Pod 通信）的 ICMP 数据包按预期工作；
- TCP/UDP 数据包按预期工作；
- 发送到需要通过远程网络的目标（例如通过 ping 进行的 Pod 到外部互联网通信）的 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 后端文档。