Kubernetes Windows 节点与混合工作负载：跨平台集群实战

很多企业面临存量 Windows 应用（.NET Framework、COM、Win32）上云的现实：无法一步迁移到 Linux 容器，又不愿让旧系统游离在 K8s 治理之外。Kubernetes 从 1.14 起正式支持 Windows 工作负载，可在同一集群混部 Linux 与 Windows 节点。本指南讲透 Windows 容器的限制、混合集群的架构设计 与 调度/运维的细节。

目录

• 1. Windows 容器：为什么与 Linux 容器不同
• 2. 混合集群架构：节点池分离是必须的
• 3. 调度约束：让 Windows Pod 只去 Windows 节点
• 4. Windows 容器的关键限制
• 5. 存储、网络与日志适配
• 6. 运维与监控适配
• 7. 迁移策略：从 VM 到 Windows 容器
• 8. 常见坑与最佳实践
• 9. 总结

1. Windows 容器：为什么与 Linux 容器不同

1.1 根本差异

Windows 与 Linux 的容器实现内核接口不同，因此 K8s 对两者的能力支持也不对称：

1.2 两种 Windows 容器运行模式

Windows 支持两种容器 隔离模式：

• 进程隔离（Process Isolation）：共享 Windows 内核，启动快、密度高；
• Hyper-V 隔离：每个容器独占轻量级 VM 内核，更强隔离、启动更慢。

一句话：Windows 容器不是"把 Linux 容器换个系统"——能力边界、网络模型、调度约束都不同，得按 Windows 的方式对待。

2. 混合集群架构：节点池分离是必须的

2.1 为什么必须分离节点池

Windows 与 Linux 容器不能混跑在同一节点（kubelet 需绑定对应运行时），因此节点池必须按 OS 分离：

Linux 节点池：运行 Linux 容器（业务主应用、中间件）
Windows 节点池：运行 Windows 容器（存量 .NET/Win32 应用）
同一集群：共享控制面、Service、Ingress

2.2 节点池划分与标签

在托管集群里创建 Windows 节点组，并打上 OS 标签：

节点池 windows-2022：os=windows，image=WindowsServerCore
节点池 linux-general：os=linux，image=Ubuntu

2.3 控制面与共享组件

控制面（etcd/apiserver/scheduler）跑在 Linux 节点；Windows 节点只跑 kubelet 与工作负载。

一句话：混合集群 = 一套控制面 + 按 OS 分离的节点池——Windows 负载与 Linux 负载各归各池，共享 K8s 治理。

3. 调度约束：让 Windows Pod 只去 Windows 节点

3.1 用 nodeSelector + os 标签约束

Windows 容器不能跑在 Linux 节点，因此必须显式调度到 Windows 池：

spec:
  nodeSelector:
    kubernetes.io/os: windows

为避免误调度，最好给 Linux 节点打污点（os=linux:NoSchedule）并给 Windows 池加对应容忍，形成双向隔离。

3.2 亲和性与多池混合的陷阱

• DaemonSet（CNI、日志、监控）通常只支持 Linux，需用 nodeSelector 排除 Windows 池；
• 跨池 Service：Windows Pod 与 Linux Pod 可通过同一 Service 暴露（网络需打通）；
• HPA：Windows 节点上的 HPA 指标（CPU/内存）也支持，但自定义指标适配要小心。

3.3 用 RuntimeClass 明确运行时

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: windows
handler: 'docker'   # 或 containerd + Windows
scheduling:
  nodeSelector:
    kubernetes.io/os: windows

一句话：调度 = nodeSelector 指定 OS + 污点隔离 + RuntimeClass 兜底——让 Windows 容器"只能去该去的地方"。

4. Windows 容器的关键限制

4.1 不支持的能力

4.2 Windows 容器镜像基线与兼容

• 镜像必须用 Windows 基镜像（Windows Server Core / Nano Server）；
• 容器内核版本与节点 OS 版本需匹配（LTS/SAC 差异会启动失败）；
• 存量 .NET Framework 应用需评估迁移到 .NET 6+ 或保持 Windows 容器。

4.3 探针与健康检查适配

• 默认 exec 探针在 Windows 上可用（用 powershell 命令）；
• HTTP 探针需应用暴露 HTTP 端点。

一句话：Windows 容器的限制是结构性的——特权、部分卷、init 受限，需要按 Windows 的边界设计负载，而不是硬搬 Linux 玩法。

5. 存储、网络与日志适配

5.1 网络：Windows 上的 CNI

Windows 节点网络使用 Windows 专用 CNI 插件（如 win-overlay、Cilium Windows、Calico Windows），且依赖 Windows Host Network Service（HNS）：

Windows 节点 → 容器网络通过 HNS/vSwitch
  → CNI 插件（win-overlay/win-bridge）提供 overlay
  → 与 Linux 池互通（Pod CIDR 打通）

注意：部分云厂商提供托管 Windows 节点，会自带兼容网络；自建需仔细选 CNI。

5.2 存储限制

• Windows 容器不支持大多数 CSI 的读写语义（尤其需权限挂载的场景）；
• 常以 SMB / NFS 或 Azure Disk（托管） 等云托管方式满足持久化；
• hostPath 支持有限，尽量避免依赖。

5.3 日志

Windows 容器日志通过 Windows Event Log 与 stdout 输出，采集链路要适配（如 Fluent Bit 的 Windows 输入）。

一句话：网络（HNS/win-overlay）、存储（云托管/共享）、日志（Event Log）是 Windows 容器最需要单独适配的三层——别假设与 Linux 完全一致。

6. 运维与监控适配

6.1 节点运维差异

6.2 监控与告警适配

• kubelet/cAdvisor 指标 在 Windows 上支持度有限，优先用云厂商或 Windows 专属 exporter；
• CPU/内存指标可通过 kubelet stats API 或 Windows exporter 采集；
• 告警阈值需按 Windows 负载特性重新标定。

6.3 排障手段

kubectl get nodes | grep windows   # 节点状态
kubectl describe node win-1        # 条件/污点
进入 Windows 容器：kubectl exec -it <pod> -- powershell
查看事件：kubectl get events --field-selector reason=... 

一句话：Windows 节点的运维语言要换——日志看 Event Log、指标用专属 exporter、排障用 PowerShell；运维流程（drain/维护）与 Linux 一致但细节不同。

7. 迁移策略：从 VM 到 Windows 容器

7.1 迁移路径

VM 上的 .NET Framework 应用
  ├─ 保留 VM（继续跑）
  ├─ 容器化：Windows 容器承载（镜像 + 调度约束）
  └─ 重构：迁移到 .NET 6+/Linux（长期）

7.2 迁移评估要点

7.3 渐进式迁移

第一批：无状态、非关键 .NET 服务 → Windows 容器
第二批：有状态、需要持久化的 → 加存储适配
第三批：复杂依赖 → 重构到 Linux 或保留 VM

一句话：迁移不是"全有或全无"——先容器化无状态存量、再适配存储、最后决定重构或保留 VM，逐步把 Windows 负载纳入 K8s 治理。

8. 常见坑与最佳实践

8.1 常见坑

8.2 最佳实践

• 节点池按 OS 分离，给 Windows 池打标签 + 污点；
• 明确调度约束：nodeSelector + RuntimeClass + 容忍；
• 控制面与系统组件跑 Linux，Windows 只跑业务负载；
• 存储/网络/日志单独适配，别复用 Linux 方案；
• 迁移渐进式，无状态先行；
• 监控用 Windows 专属 exporter，别假设指标一致。

8.3 总结表

9. 总结

一句话记住：Windows 工作负载是 Kubernetes 的"第二公民"，但也是"正式成员"——按 OS 分离节点池、用调度约束管住去向、按 Windows 的边界适配存储/网络/日志、用渐进迁移把存量引入治理。让旧系统不游离于云原生之外，是混合集群的最大价值。