Windows 网络

    Windows 容器网络通过 暴露。 Windows 容器网络的工作方式与虚拟机类似。 每个容器都有一个连接到 Hyper-V 虚拟交换机（vSwitch）的虚拟网络适配器（vNIC）。 主机网络服务（Host Networking Service，HNS）和主机计算服务（Host Comute Service，HCS） 协同创建容器并将容器 vNIC 挂接到网络。 HCS 负责管理容器，而 HNS 负责管理以下网络资源：

    • 虚拟网络（包括创建 vSwitch）
    • Endpoint / vNIC
    • 命名空间
    • 包括数据包封装、负载均衡规则、ACL 和 NAT 规则在内的策略。

    Windows HNS 和 vSwitch 实现命名空间划分，且可以按需为 Pod 或容器创建虚拟 NIC。 然而，诸如 DNS、路由和指标等许多配置将存放在 Windows 注册表数据库中， 而不是像 Linux 将这些配置作为文件存放在 内。 针对容器的 Windows 注册表与主机的注册表是分开的，因此将 /etc/resolv.conf 从主机映射到一个容器的类似概念与 Linux 上的效果不同。 这些必须使用容器环境中运行的 Windows API 进行配置。 因此，实现 CNI 时需要调用 HNS，而不是依赖文件映射将网络详情传递到 Pod 或容器中。

    Windows 支持五种不同的网络驱动/模式：L2bridge、L2tunnel、Overlay (Beta)、Transparent 和 NAT。 在 Windows 和 Linux 工作节点组成的异构集群中，你需要选择一个同时兼容 Windows 和 Linux 的网络方案。 下表列出了 Windows 支持的树外插件，并给出了何时使用每种 CNI 的建议：

    如上所述，Windows 通过 （Beta 支持；委派给 win-overlay） 和 host-gateway 网络后端（稳定支持；委派给 win-bridge） 也 Flannel 的 。

    此插件支持委派给参考 CNI 插件（win-overlay、win-bridge）之一，配合使用 Windows 上的 Flannel 守护程序（Flanneld），以便自动分配节点子网租赁并创建 HNS 网络。 该插件读取自己的配置文件（cni.conf），并聚合 FlannelD 生成的 subnet.env 文件中的环境变量。 然后，委派给网络管道的参考 CNI 插件之一，并将包含节点分配子网的正确配置发送给 IPAM 插件（例如：host-local）。

    • Pod → Pod（IP）
    • Pod → Pod（名称）
    • Pod → Service（集群 IP）
    • Pod → Service（FQDN）
    • Pod → 外部（IP）
    • Pod → 外部（DNS）
    • Node → Pod
    • Pod → Node

    Windows 支持以下 IPAM 选项：

    • azure-vnet-ipam（仅适用于 azure-cni）
    • （未设置 IPAM 时的回滚选项）

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

    • NodePort
    • ClusterIP
    • ExternalName

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

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

    Windows Service 设置
    功能特性描述支持的 Windows 操作系统最低版本启用方式
    会话亲和性确保每次都将来自特定客户端的连接传递到同一个 Pod。Windows Server 2022将 service.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参考 。
    客户端 IP 保留确保入站流量的源 IP 得到保留。也会禁用节点间转发。Windows Server 2019将 设置为 “Local” 并在 kube-proxy 中启用 DSR。

    警告：

    在安装了 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-overlay、win-bridge 使用 ICMP 协议，或使用 Azure-CNI 插件进行出站通信。
      具体而言，Windows 数据平面（VFP）不支持 ICMP 数据包转换，这意味着：

      • 指向同一网络内目的地址的 ICMP 数据包（例如 Pod 间的 ping 通信）可正常工作；
      • TCP/UDP 数据包可正常工作；
      • 通过远程网络指向其它地址的 ICMP 数据包（例如通过 ping 从 Pod 到外部公网的通信）无法被转换， 因此无法被路由回到这些数据包的源点；
      • 由于 TCP/UDP 数据包仍可被转换，所以在调试与外界的连接时， 你可以将 ping <destination> 替换为 。
    • 由于缺少 CHECK 实现，Windows 参考网络插件 win-bridge 和 win-overlay 未实现 的 v0.4.0 版本。
    • Flannel VXLAN CNI 插件在 Windows 上有以下限制：
      • 使用 Flannel v0.12.0（或更高版本）时，节点到 Pod 的连接仅适用于本地 Pod。