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 注册表数据库中，而不是作为 /etc 中的文件，而 Linux 使用这种方式存储这些配置。容器的 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，因为它们在 ingress/egress 上会被重写。 | 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。每个覆盖网络都有自己的 IP 子网，由自定义 IP 前缀定义。覆盖网络驱动程序使用 VXLAN 封装。 | 使用外部报头进行封装。 | win-overlay、Flannel VXLAN（使用 win-overlay） | 当希望虚拟容器网络与主机的底层隔离时（例如出于安全原因），应使用 win-overlay。允许在不同的覆盖网络（具有不同的 VNID 标记）中重复使用 IP（如果您在数据中心中对 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 的情况下实现。NATing 是通过不使用 iptables/netsh 来完成的。 |
| NAT（*Kubernetes 中未使用*） | 容器被赋予一个连接到内部 vSwitch 的 vNIC。DNS/DHCP 是使用称为 WinNAT 的内部组件提供的 | MAC 和 IP 重写为主机 MAC/IP。 | nat | 出于完整性考虑，在此包含 |
如上所述，Flannel CNI 插件 也通过 支持 Windows，方法是使用 VXLAN 网络后端（**Beta 支持**；委托给 win-overlay）和 host-gateway 网络后端（稳定支持；委托给 win-bridge）。
此插件支持委托给一个参考 CNI 插件（win-overlay、win-bridge），以与 Windows 上的 Flannel 守护程序 (Flanneld) 协同工作，以自动分配节点子网租用并创建 HNS 网络。此插件读取其自己的配置文件 (cni.conf)，并将它与 FlannelD 生成的 subnet.env 文件中的环境变量聚合。然后，它委托给一个参考 CNI 插件以进行网络管道，并将包含分配给节点的子网的正确配置发送到 IPAM 插件（例如：host-local）。
对于节点、Pod 和服务对象，以下网络流支持 TCP/UDP 流量
- Pod → Pod（IP）
- Pod → Pod（名称）
- Pod → 服务（集群 IP）
- Pod → 服务（PQDN，但仅当没有“.”时）
- Pod → 服务（FQDN）
- Pod → 外部（IP）
- Pod → 外部（DNS）
- 节点 → Pod
- Pod → 节点
IP 地址管理 (IPAM)
以下 IPAM 选项在 Windows 上受支持
- host-local
- azure-vnet-ipam（仅适用于 azure-cni）
- Windows Server IPAM（如果未设置 IPAM，则为备用选项）
负载均衡和服务
Kubernetes 服务 是一个抽象，它定义了一组逻辑 Pod 以及通过网络访问它们的方法。在包含 Windows 节点的集群中，您可以使用以下类型的服务
NodePortClusterIPLoadBalancerExternalName
Windows 容器网络在某些重要方面与 Linux 网络有所不同。Microsoft 关于 Windows 容器网络的文档 提供了更多详细信息和背景信息。
在 Windows 上，您可以使用以下设置来配置服务和负载均衡行为
| 功能 | 描述 | 最低支持的 Windows 操作系统版本 | 如何启用 |
|---|---|---|---|
| 会话亲和性 | 确保每次来自特定客户端的连接都传递到同一个 Pod。 | Windows Server 2022 | 将 service.spec.sessionAffinity 设置为“ClientIP” |
| 直接服务器返回 (DSR) | 负载均衡模式，其中 IP 地址修复和 LBNAT 直接在容器 vSwitch 端口处发生；服务流量到达时，源 IP 设置为源 Pod IP。 | Windows Server 2019 | 在 kube-proxy 中设置以下标志：--feature-gates="WinDSR=true" --enable-dsr=true |
| 保留目标 | 跳过服务流量的 DNAT，从而保留到达后端 Pod 的数据包中的目标服务的虚拟 IP。此外，还禁用节点间转发。 | Windows Server，版本 1903 | 在服务注释中设置 "preserve-destination": "true"，并在 kube-proxy 中启用 DSR。 |
| IPv4/IPv6 双栈网络 | 与集群内、来自集群和到集群的 IPv6 到 IPv6 通信并行使用本机 IPv4 到 IPv4 通信 | Windows Server 2019 | 请参阅 IPv4/IPv6 双栈 |
| 客户端 IP 保留 | 确保传入的入站流量的源 IP 被保留。此外，还禁用节点间转发。 | Windows Server 2019 | 将 service.spec.externalTrafficPolicy 设置为“Local”，并在 kube-proxy 中启用 DSR |
警告
在覆盖网络上的 NodePort 服务上存在已知问题，如果目标节点运行的是 Windows Server 2022。为了完全避免此问题，您可以使用 externalTrafficPolicy: Local 配置服务。
在安装了 KB5005619 或更高版本的 Windows Server 2022 上，L2bridge 网络上的 Pod 到 Pod 连接存在已知问题。为了解决问题并恢复 Pod 到 Pod 连接，您可以禁用 kube-proxy 中的 WinDSR 功能。
这些问题需要操作系统修复。请关注 https://github.com/microsoft/Windows-Containers/issues/204 以获取更新。
限制
以下网络功能*不受*Windows 节点支持
- 主机网络模式
- 来自节点本身的本地 NodePort 访问（适用于其他节点或外部客户端）
- 单个服务超过 64 个后端 Pod（或唯一目标地址）
- 连接到覆盖网络的 Windows Pod 之间的 IPv6 通信
- 非 DSR 模式下的本地流量策略
- 使用 ICMP 协议通过 `win-overlay`、`win-bridge` 或 Azure-CNI 插件进行出站通信。
具体来说，Windows 数据平面 (VFP) 不支持 ICMP 数据包置换，这意味着- 定向到同一网络内目标的 ICMP 数据包（例如通过 ping 进行的 Pod 到 Pod 通信）按预期工作；
- TCP/UDP 数据包按预期工作；
- 定向到通过远程网络的 ICMP 数据包（例如通过 ping 进行的 Pod 到外部互联网通信）无法置换，因此不会路由回其源；
- 由于 TCP/UDP 数据包仍然可以置换，因此在调试与外部世界的连接时，可以使用 `curl <destination>` 代替 `ping <destination>`。
其他限制
- Windows 参考网络插件 win-bridge 和 win-overlay 未实现 CNI 规范 v0.4.0，因为缺少 `CHECK` 实现。
- Flannel VXLAN CNI 插件在 Windows 上存在以下限制
- 节点-Pod 连接仅在 Flannel v0.12.0（或更高版本）中对本地 Pod 可用。
- Flannel 仅限于使用 VNI 4096 和 UDP 端口 4789。有关这些参数的更多详细信息，请参见官方 Flannel VXLAN 后端文档。