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-bridgeAzure-CNI、Flannel host-gateway 使用 win-bridgewin-bridge 使用 L2bridge 网络模式,将容器连接到主机的下层,提供最佳性能。节点间连接需要用户定义的路由(UDR)。
L2Tunnel这是 L2bridge 的一种特例,但仅用在 Azure 上。所有数据包都会被发送到应用了 SDN 策略的虚拟化主机。MAC 被重写,IP 在下层网络上可见。Azure-CNIAzure-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 内通信。数据包通过 GENEVESTT 隧道进行封装,以到达其它主机上的 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) 也支持 FlannelCNI 插件

此插件支持委派给参考 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 选项:

负载均衡和 Service

Kubernetes Service 是一种抽象:定义了逻辑上的一组 Pod 和一种通过网络访问这些 Pod 的方式。 在包含 Windows 节点的集群中,你可以使用以下类别的 Service:

  • NodePort
  • ClusterIP
  • LoadBalancer
  • ExternalName

Windows 容器网络与 Linux 网络有着很重要的差异。 更多细节和背景信息,参考 Microsoft Windows 容器网络文档

在 Windows 上,你可以使用以下设置来配置 Service 和负载均衡行为:

Windows Service 设置
功能特性描述支持的 Windows 操作系统最低版本启用方式
会话亲和性确保每次都将来自特定客户端的连接传递到同一个 Pod。Windows Server 2022service.spec.sessionAffinity 设为 “ClientIP”
Direct Server Return (DSR)在负载均衡模式中 IP 地址修正和 LBNAT 直接发生在容器 vSwitch 端口;服务流量到达时源 IP 设置为原始 Pod IP。Windows Server 2019在 kube-proxy 中设置以下标志:—feature-gates=”WinDSR=true” —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 2019service.spec.externalTrafficPolicy 设置为 “Local” 并在 kube-proxy 中启用 DSR。

警告:

如果目的地节点在运行 Windows Server 2022,则上层网络的 NodePort Service 存在已知问题。 要完全避免此问题,可以使用 externalTrafficPolicy: Local 配置服务。

在安装了 KB5005619 的 Windows Server 2022 或更高版本上,采用 L2bridge 网络时 Pod 间连接存在已知问题。 要解决此问题并恢复 Pod 间连接,你可以在 kube-proxy 中禁用 WinDSR 功能。

这些问题需要操作系统修复。 有关更新,请参考 https://github.com/microsoft/Windows-Containers/issues/204

限制

Windows 节点不支持以下网络功能:

  • 主机网络模式
  • 从节点本身访问本地 NodePort(可以从其他节点或外部客户端进行访问)
  • 为同一 Service 提供 64 个以上后端 Pod(或不同目的地址)
  • 在连接到上层网络的 Windows Pod 之间使用 IPv6 通信
  • 非 DSR 模式中的本地流量策略(Local Traffic Policy)

  • 通过 win-overlaywin-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 后端文档。