Kubernetes Windows 节点的容器网络实现与 Linux 有明显差异，主要原因在于 Windows 使用主机网络服务（HNS）和虚拟交换机来管理容器网络，而不是直接操作 iptables 或路由表。Flannel 与 Calico 都需要适配这一套 Windows 网络栈，因此在 Windows 上两者的工作模式都发生了变化。理解这些差异有助于判断该选择哪一款网络插件。

Flannel 在 Linux 下常见的 VXLAN、host-gw、UDP 等后端，在 Windows 上通常只保留 VXLAN 和 host-gw 两种。Calico 在 Windows 上则主要使用 VXLAN 模式，因为 IPIP 和 BGP 直接路由在 Windows 网络栈中没有原生支持。下面先看数据平面层的具体区别。

一、Windows 节点上的数据平面差异

Flannel 在 Windows 上运行 flanneld.exe 进程，该进程会读取 C:\etc\kube-flannel\net-conf.json 中的配置。这个文件里通常会指定 VXLAN 作为后端类型，以及一个 Pod 网络 CIDR，例如 10.244.0.0/16。flanneld 会通过 Windows 主机网络服务创建一块 overlay 虚拟网络，并把 Pod 的流量封装成 VXLAN 报文，通过 UDP 4789 端口发送到目标节点。由于 Windows 并不像 Linux 那样可以方便地操作 netfilter，flanneld 主要依赖 HNS 的虚拟网络和虚拟交换机来完成数据包转发。host-gw 模式在 Windows 上也可以使用，但前提是节点之间必须在同一个二层网络，否则需要手动维护路由，实用性较弱。

Calico 在 Windows 上的实现由 Calico for Windows 提供，核心组件是 calico-node 服务。该服务同样通过 HNS 创建 VXLAN 网络，并在 Windows 防火墙和 HNS ACL 中下发策略。与 Flannel 不同的是，Calico 会启动 Felix 代理来监听 Kubernetes API 中的 NetworkPolicy 对象，并将这些策略转换为 Windows 可以执行的规则。数据面的 VXLAN 封装逻辑仍然存在，但 Calico 在封装之外增加了策略过滤层。这一点在 Windows 上尤其重要，因为容器默认的网络隔离能力较弱，必须依靠 HNS ACL 或 Windows 防火墙来实现 Pod 之间的访问控制。

从数据平面来看，Flannel 和 Calico 在 Windows 上都依赖 VXLAN 做跨节点通信，底层都使用 Windows 的虚拟交换机。Flannel 专注于把网络打通，策略部分几乎为零；Calico 则在同一套 VXLAN 数据通道之上增加了可编程的策略引擎。这也意味着 Calico 的数据路径会比 Flannel 多一次策略匹配，可能带来轻微的性能开销，但换来了更细粒度的安全控制。

二、安装与配置复杂度对比

Flannel 在 Windows 上的安装相对简单。管理员需要先从 Kubernetes 官方或 Flannel 仓库获取 Windows 版本的 flanneld.exe 和 CNI 插件，通常将它们放在 C:\flannel\ 目录下。接着在 C:\etc\kube-flannel\ 中准备 net-conf.json，并确保 kubelet 的配置指向正确的 CNI 目录。kubelet 启动后，flanneld 会作为 Windows 服务运行，负责创建虚拟网络。下面的 JSON 片段展示了常见的 Flannel 配置：

{
  "Network": "10.244.0.0/16",
  "Backend": {
    "Type": "vxlan"
  }
}

之后需要重启 kubelet 并确认 flanneld 服务状态正常。Flannel 的安装过程通常不会涉及太多 Windows 注册表或系统组件的修改，排障时主要查看 flanneld 日志和 HNS 网络状态。

Calico 的安装要复杂得多。Calico for Windows 通常以一个 zip 包形式提供，解压到 C:\CalicoWindows\ 后，管理员需要编辑 config.ps1 或 install.ps1 中的参数，包括 Kubernetes 服务网段、DNS 服务器 IP、Calico 控制平面地址等。安装脚本会创建 calico-node 服务，安装 CNI 插件，并向 Windows 防火墙添加必要的规则。下面是一段 PowerShell 安装示例：

cd C:\CalicoWindows
.\install.ps1 -ServiceCidr 10.96.0.0/12 -DNSServerIPs 10.96.0.10

除了安装脚本，Calico 还需要在 Windows 节点上配置 kubelet 的 CNI 目录，并且要确保 Kubernetes API 服务能够从节点访问。Calico 的策略组件会在后台持续同步 NetworkPolicy，因此对 Windows 节点的系统资源占用也高于 Flannel。整体看，Flannel 适合快速搭建，Calico 适合对网络策略有明确要求的生产环境。

三、网络策略与功能覆盖

Flannel 原生不支持 Kubernetes NetworkPolicy 对象。在 Linux 上，用户往往会搭配 Calico 或 Canal 来提供策略能力，但在 Windows 节点上，这种组合并不总是可行。如果集群中同时存在 Linux 和 Windows 节点，Flannel 只能保证基础连通性，Windows Pod 的访问控制需要依赖节点级别的防火墙规则，但无法根据 Kubernetes 标签和命名空间动态调整。这种限制在多租户或安全敏感的场景下会比较突出。

Calico 则把 NetworkPolicy 支持作为核心能力。在 Windows 节点上，Calico 的 Felix 代理会监听 API Server 中的 NetworkPolicy 和 GlobalNetworkPolicy，然后将允许或拒绝的规则下发到 Windows 防火墙或 HNS ACL。管理员可以使用与 Linux 节点相同的策略 YAML 来管理 Windows Pod 流量，例如拒绝默认流量、仅允许特定标签之间的访问。不过 Windows 版本的 Calico 对某些高级策略特性支持可能滞后，例如基于端口的策略通常可用，但基于 FQDN 的策略在 Windows 上不一定完全生效，需要查看 Calico 文档确认。

功能覆盖方面，Calico 还提供 IP 地址管理（IPAM）、出口 NAT、服务负载均衡的配合等能力。Flannel 则依赖 Kubernetes 自带的 IPAM 和 kube-proxy 完成这些工作。总体来说，如果仅仅需要 Pod 之间互通，Flannel 足够；如果需要 Kubernetes 原生的网络策略在 Windows 节点上真实落地，Calico 是更完整的选择。

四、性能表现与选型建议

在性能层面，Flannel 与 Calico 在 Windows 上的 VXLAN 封装开销非常接近，因为它们都使用 HNS 创建的 overlay 网络。Flannel 由于不执行额外的策略匹配，数据路径更短，在小包吞吐和连接建立速度上可能略占优势。Calico 在策略开启时，每个连接都要经过规则匹配，转发延迟会略有增加，但通常在可接受范围内。实际测试中，两者的带宽差异一般在 5% 以内，主要瓶颈还是 Windows 虚拟交换机和 VXLAN 本身的封装成本。

选型时需要考虑集群规模和运维能力。如果 Windows 节点数量少、应用隔离要求低，Flannel 的轻量特性可以明显降低安装和排障成本。管理员只需要关注 flanneld 服务和 HNS 网络是否正常，日志通常在 C:\var\log\ 或 C:\flannel\ 下。如果生产环境要求按命名空间、标签或 CIDR 做细粒度访问控制，并且已经使用 Calico 管理 Linux 节点，那么 Windows 节点继续使用 Calico 可以保持策略配置一致。但需要预留更多时间处理安装依赖和版本兼容问题，例如 Windows Server 2019 与 2022 对 HNS 和 VXLAN 的支持存在差异。

最后还要注意，无论选择 Flannel 还是 Calico，都应确保 Windows 节点的 kube-proxy 与 CNI 插件版本匹配，并定期清理 HNS 中残留的虚拟网络。排障时可以执行 Get-HnsNetwork 或查看 C:\Windows\System32\LogFiles\ 下的系统日志。只有结合实际的网络需求和团队维护能力，才能判断 Flannel 和 Calico 哪一款更适合当前环境。