Kubernetes 提供了对 Linux 或Windows 节点的全面支持，使用户可以在同一个集群内混合部署这两种类型的节点，为企业和开发人员提供了更大的灵活性和选择性，能够满足各种应用程序的需求。
一、Windows容器网络
Windows 容器网络通过 CNI 插件暴露，工作方式与虚拟机类似，每个容器都有一个连接到 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-kubernetes | 通过 ansible 部署。通过 Kubernetes 策略可以实施分布式 ACL。支持 IPAM。无需 kube-proxy 即可实现负载均衡。无需 iptables/netsh 即可进行 NAT。 |
| 数据包基于 OVN 网络控制器提供的隧道元数据信息被转发或丢弃。 | ||||
| 南北向通信使用 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 时的回滚选项）
四、负载均衡和Service
Kubernetes Service 是一种抽象：定义了逻辑上的一组 Pod 和一种通过网络访问这些 Pod 的方式。 在包含 Windows 节点的集群中，可以使用以下类别的 Service：
- NodePort
- ClusterIP
- LoadBalancer
- ExternalName
在 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 | 参考《 Kubernetes IPv4/IPv6 双栈》 |
| 客户端 IP 保留 | 确保入站流量的源 IP 得到保留。也会禁用节点间转发。 | Windows Server 2019 | 将 service.spec.externalTrafficPolicy 设置为 “Local” 并在 kube-proxy 中启用 DSR。 |
注意：
- 如果目的地节点在运行 Windows Server 2022，则上层网络的 NodePort Service 存在已知问题。 要完全避免此问题，可以使用 externalTrafficPolicy: Local 配置服务。
- 在安装了 KB5005619 的 Windows Server 2022 或更高版本上，采用 L2bridge 网络时 Pod 间连接存在已知问题。 要解决此问题并恢复 Pod 间连接，可以在 kube-proxy 中禁用 WinDSR 功能。
五、限制
Windows 节点不支持以下网络功能：
1、主机网络模式；
2、从节点本身访问本地 NodePort（可以从其他节点或外部客户端进行访问）；
3、为同一 Service 提供 64 个以上后端 Pod（或不同目的地址）；
4、在连接到上层网络的 Windows Pod 之间使用 IPv6 通信；
5、非 DSR 模式中的本地流量策略（Local Traffic Policy）；
6、通过 win-overlay、win-bridge 使用 ICMP 协议，或使用 Azure-CNI 插件进行出站通信，具体而言，Windows 数据平面（VFP）不支持 ICMP 数据包转换，这意味着：
- 指向同一网络内目的地址的 ICMP 数据包（例如 Pod 间的 ping 通信）可正常工作；
- TCP/UDP 数据包可正常工作；
- 通过远程网络指向其它地址的 ICMP 数据包（例如通过 ping 从 Pod 到外部公网的通信）无法被转换， 因此无法被路由回到这些数据包的源点；
- 由于 TCP/UDP 数据包仍可被转换，所以在调试与外界的连接时， 可以将 ping <destination> 替换为 curl <destination>。
7、由于缺少 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。
