Kubernetes 中的 Windows 容器

Windows 应用程序构成了许多组织中运行的大部分服务和应用。Windows 容器提供了一种封装进程和打包依赖项的方法，使 Windows 应用程序更容易采用 DevOps 实践并遵循云原生模式。

对于同时投资了基于 Windows 和基于 Linux 的应用程序的组织而言，无需寻找单独的协调器来管理工作负载，无论底层操作系统如何，这都能提高部署的运营效率。

Kubernetes 中的 Windows 节点

要在 Kubernetes 中实现 Windows 容器的编排，只需在现有的 Linux 集群中加入 Windows 节点即可。在 Kubernetes 中调度运行于 Pod 中的 Windows 容器与调度 Linux 容器的过程类似。

为了运行 Windows 容器，您的 Kubernetes 集群必须包含多种操作系统。虽然您只能在 Linux 上运行 控制平面，但您可以部署运行 Windows 或 Linux 的工作节点。

只要操作系统为 Windows Server 2022 或 Windows Server 2025，Windows 节点即是受支持的。

本文档使用“Windows 容器”一词来指代具备进程隔离功能的 Windows 容器。Kubernetes 不支持运行使用 Hyper-V 隔离的 Windows 容器。

兼容性与限制

某些节点功能仅在使用特定的容器运行时时才可用；其他一些功能（包括以下功能）在 Windows 节点上不可用：

  • HugePages（大页内存）：不支持用于 Windows 容器
  • 特权容器：不支持用于 Windows 容器。HostProcess 容器提供了类似的功能。
  • TerminationGracePeriod（终止宽限期）：需要使用 containerD

并非所有共享命名空间的功能都受支持。有关更多详细信息，请参阅API 兼容性。

有关 Kubernetes 已测试过的 Windows 版本详细信息，请参阅Windows OS 版本兼容性。

从 API 和 kubectl 的角度来看，Windows 容器的行为方式与基于 Linux 的容器基本相同。然而，关键功能上存在一些明显的差异，本节将对此进行概述。

与 Linux 的比较

Kubernetes 的核心元素在 Windows 上的工作方式与在 Linux 上相同。本节将介绍几个关键的工作负载抽象概念及其如何映射到 Windows。

  • Pod

    Pod 是 Kubernetes 的基本构建块，是您创建或部署的 Kubernetes 对象模型中最小且最简单的单元。您不能在同一个 Pod 中混合部署 Windows 和 Linux 容器。Pod 中的所有容器都被调度到单个节点上，每个节点代表一个特定的平台和架构。Windows 容器支持以下 Pod 功能、属性和事件：

    • 每个 Pod 可包含一个或多个具备进程隔离和卷共享功能的容器

    • Pod status（状态）字段

    • 就绪、存活和启动探针 (Readiness, liveness, and startup probes)

    • postStart 和 preStop 容器生命周期钩子

    • ConfigMap、Secrets：作为环境变量或卷

    • emptyDir 卷

    • 命名管道主机挂载

    • 资源限制 (Resource limits)

    • OS 字段

      .spec.os.name 字段应设置为 windows，以指示当前 Pod 使用 Windows 容器。

      如果您将 .spec.os.name 字段设置为 windows，则不得在该 Pod 的 .spec 中设置以下字段：

      • spec.hostPID
      • spec.hostIPC
      • spec.securityContext.seLinuxOptions
      • spec.securityContext.seccompProfile
      • spec.securityContext.fsGroup
      • spec.securityContext.fsGroupChangePolicy
      • spec.securityContext.sysctls
      • spec.shareProcessNamespace
      • spec.securityContext.runAsUser
      • spec.securityContext.runAsGroup
      • spec.securityContext.supplementalGroups
      • spec.containers[*].securityContext.seLinuxOptions
      • spec.containers[*].securityContext.seccompProfile
      • spec.containers[*].securityContext.capabilities
      • spec.containers[*].securityContext.readOnlyRootFilesystem
      • spec.containers[*].securityContext.privileged
      • spec.containers[*].securityContext.allowPrivilegeEscalation
      • spec.containers[*].securityContext.procMount
      • spec.containers[*].securityContext.runAsUser
      • spec.containers[*].securityContext.runAsGroup

      在上述列表中，通配符 (*) 表示列表中的所有元素。例如，spec.containers[*].securityContext 指的是所有容器的 SecurityContext 对象。如果指定了这些字段中的任何一个，API 服务器将拒绝该 Pod 的准入。

  • 工作负载资源，包括：

    • ReplicaSet
    • Deployment
    • StatefulSet
    • DaemonSet
    • Job
    • CronJob
    • ReplicationController

  • Services 有关更多详细信息，请参阅负载均衡与服务。

Pod、工作负载资源和服务是管理 Kubernetes 上 Windows 工作负载的关键要素。然而，仅靠它们不足以在动态的云原生环境中实现对 Windows 工作负载的适当生命周期管理。

kubelet 的命令行选项

某些 kubelet 命令行选项在 Windows 上的行为有所不同，具体如下：

  • --windows-priorityclass 允许您设置 kubelet 进程的调度优先级（参见CPU 资源管理）
  • --kube-reserved、--system-reserved 和 --eviction-hard 标志会更新 NodeAllocatable
  • 使用 --enforce-node-allocable 进行驱逐的功能未实现
  • 当在 Windows 节点上运行时，kubelet 不受内存或 CPU 限制。--kube-reserved 和 --system-reserved 仅从 NodeAllocatable 中扣除，并不保证为工作负载提供资源。有关更多信息，请参阅Windows 节点的资源管理。
  • PIDPressure 条件未实现
  • kubelet 不执行 OOM 驱逐操作

API 兼容性

由于操作系统和容器运行时的不同，Kubernetes API 在 Windows 上的工作方式存在细微差别。某些专为 Linux 设计的工作负载属性在 Windows 上无法运行。

从宏观角度看，这些操作系统概念存在差异：

  • 标识 - Linux 使用以整数类型表示的用户 ID (UID) 和组 ID (GID)。用户名和组名不是规范性的——它们只是 /etc/groups 或 /etc/passwd 中指向 UID+GID 的别名。Windows 使用更庞大的二进制安全标识符 (SID)，存储在 Windows 安全访问管理器 (SAM) 数据库中。此数据库不在宿主机和容器之间，也不在容器之间共享。
  • 文件权限 - Windows 使用基于 SID 的访问控制列表，而像 Linux 这样的 POSIX 系统则使用基于对象权限和 UID+GID 的位掩码，外加可选的访问控制列表。
  • 文件路径 - Windows 的惯例是使用 \ 而不是 /。Go IO 库通常同时接受两者并使其工作，但当您设置在容器内解释的路径或命令行时，可能需要 \。
  • 信号 - Windows 交互式应用程序处理终止的方式不同，并且可以实现以下一种或多种方式：
    • UI 线程处理包括 WM_CLOSE 在内的定义明确的消息。
    • 控制台应用程序使用控制处理器 (Control Handler) 处理 Ctrl-C 或 Ctrl-break。
    • 服务注册一个可以接收 SERVICE_CONTROL_STOP 控制代码的服务控制处理器函数。

容器退出代码遵循相同的惯例：0 为成功，非零为失败。具体的错误代码在 Windows 和 Linux 之间可能有所不同。但是，从 Kubernetes 组件（kubelet、kube-proxy）传递出来的退出代码保持不变。

容器规范的字段兼容性

以下列表记录了 Pod 容器规范在 Windows 和 Linux 之间工作方式的差异：

  • 大页内存 (Huge pages) 在 Windows 容器运行时中未实现，不可用。它们需要声明用户特权，这对于容器而言是无法配置的。
  • requests.cpu 和 requests.memory - 请求资源会从节点可用资源中扣除，因此它们可用于避免节点超卖。然而，它们不能用于在超卖节点中保证资源。如果操作员希望完全避免超卖，应将此作为最佳实践应用于所有容器。
  • securityContext.allowPrivilegeEscalation - 在 Windows 上无法实现；没有任何能力 (capabilities) 被挂载
  • securityContext.capabilities - POSIX 能力在 Windows 上未实现
  • securityContext.privileged - Windows 不支持特权容器，请改用HostProcess 容器
  • securityContext.procMount - Windows 没有 /proc 文件系统
  • securityContext.readOnlyRootFilesystem - 在 Windows 上无法实现；运行在容器内的注册表和系统进程需要写入访问权限
  • securityContext.runAsGroup - 在 Windows 上无法实现，因为不支持 GID
  • securityContext.runAsNonRoot - 此设置将阻止容器以 ContainerAdministrator 身份运行，这是 Windows 上最接近根用户的等效用户。
  • securityContext.runAsUser - 请改用 runAsUserName
  • securityContext.seLinuxOptions - 在 Windows 上无法实现，因为 SELinux 是 Linux 特有的
  • terminationMessagePath - 这一点有一些限制，因为 Windows 不支持映射单个文件。默认值为 /dev/termination-log，它之所以有效，是因为该路径在 Windows 上默认不存在。

Pod 规范的字段兼容性

以下列表记录了 Pod 规范在 Windows 和 Linux 之间工作方式的差异：

  • hostIPC 和 hostpid - 在 Windows 上无法共享主机命名空间
  • hostNetwork - 在 Windows 上无法使用主机网络
  • dnsPolicy - 不支持将 Pod 的 dnsPolicy 设置为 ClusterFirstWithHostNet，因为 Windows 不提供主机网络。Pod 始终在容器网络中运行。
  • podSecurityContext 见下文
  • shareProcessNamespace - 这是一个 Beta 功能，依赖于 Windows 中未实现的 Linux 命名空间。Windows 无法共享进程命名空间或容器的根文件系统。只能共享网络。
  • terminationGracePeriodSeconds - 这在 Docker on Windows 中未完全实现，请参阅 GitHub issue。目前的行为是，ENTRYPOINT 进程会收到 CTRL_SHUTDOWN_EVENT，然后 Windows 默认等待 5 秒，最后使用正常的 Windows 关闭行为关闭所有进程。5 秒的默认值实际上在 Windows 注册表的容器内部，因此可以在构建容器时覆盖该值。
  • volumeDevices - 这是一个 Beta 功能，在 Windows 上未实现。Windows 无法将原始块设备附加到 Pod。
  • volumes（卷）
    • 如果定义了 emptyDir 卷，则无法将其卷源设置为 memory。
  • 无法为卷挂载启用 mountPropagation，因为 Windows 不支持此功能。

主机网络访问

Kubernetes v1.26 到 v1.32 包含了在主机网络命名空间中运行 Windows Pod 的 Alpha 支持。

Kubernetes v1.36 不包含 WindowsHostNetwork 功能门控，也不支持在主机网络命名空间中运行 Windows Pod。

Pod 安全上下文的字段兼容性

Pod securityContext 字段中，仅 securityContext.runAsNonRoot 和 securityContext.windowsOptions 在 Windows 上有效。

节点问题检测器 (Node problem detector)

节点问题检测器（参见监控节点健康状况）对 Windows 有初步支持。有关更多信息，请访问该项目的 GitHub 页面。

Pause 容器

在 Kubernetes Pod 中，首先创建一个基础设施（或“pause”）容器来托管该容器。在 Linux 中，构成 Pod 的 cgroup 和命名空间需要一个进程来维持其持续存在；pause 进程提供了这一点。属于同一个 Pod 的容器（包括基础设施容器和工作容器）共享一个公共网络端点（相同的 IPv4 和/或 IPv6 地址、相同的网络端口空间）。Kubernetes 使用 pause 容器来允许工作容器崩溃或重启而不会丢失任何网络配置。

Kubernetes 维护着一个包含 Windows 支持的多架构镜像。对于 Kubernetes v1.36.0，推荐的 pause 镜像是 registry.k8s.io/pause:3.6。源代码可在 GitHub 上获得。

Microsoft 维护着一个不同的多架构镜像，支持 Linux 和 Windows amd64，您可以在 mcr.microsoft.com/oss/kubernetes/pause:3.6 找到它。此镜像由与 Kubernetes 维护的镜像相同的源代码构建，但所有 Windows 二进制文件都经过了 Microsoft 的 Authenticode 签名。如果您要部署到需要签名二进制文件的生产环境或类似生产的环境中，Kubernetes 项目建议使用 Microsoft 维护的镜像。

容器运行时

您需要在集群中的每个节点上安装容器运行时，以便可以在其上运行 Pod。

以下容器运行时适用于 Windows：

注意： 本节链接到提供 Kubernetes 所需功能的第三方项目。Kubernetes 项目作者不对这些项目负责，项目按字母顺序排列。要将项目添加到此列表，请在提交更改之前阅读 内容指南。更多信息。

ContainerD

功能状态： Kubernetes v1.20 [稳定]

您可以将 ContainerD 1.4.0+ 作为运行 Windows 的 Kubernetes 节点的容器运行时。

了解如何在 Windows 节点上安装 ContainerD。

说明

在使用 containerd 通过 GMSA 访问 Windows 网络共享时存在一个已知限制，这需要修补内核。

Mirantis 容器运行时

Mirantis 容器运行时 (MCR) 可作为所有 Windows Server 2019 及更高版本的容器运行时。

有关更多信息，请参阅在 Windows 服务器上安装 MCR。

Windows OS 版本兼容性

在 Windows 节点上，适用严格的兼容性规则，即宿主机操作系统版本必须与容器基础镜像的操作系统版本匹配。

对于 Kubernetes v1.36，Windows 节点（和 Pod）的操作系统兼容性如下：

Windows Server LTSC 版本
Windows Server 2022
Windows Server 2025

Kubernetes 版本倾斜策略同样适用。

硬件建议与注意事项

注意： 本节链接到提供 Kubernetes 所需功能的第三方项目。Kubernetes 项目作者不对这些项目负责，项目按字母顺序排列。要将项目添加到此列表，请在提交更改之前阅读 内容指南。更多信息。

说明

此处列出的以下硬件规范应视为合理的默认值。它们并非旨在代表生产环境的最低要求或特定建议。根据您工作负载的需求，这些值可能需要调整。
  • 64 位处理器，4 个或更多 CPU 核心，支持虚拟化
  • 8GB 或更多的 RAM
  • 50GB 或更多的可用磁盘空间

有关最低硬件要求的最新信息，请参考Windows Server Microsoft 文档的硬件要求。有关决定生产工作节点资源的指导，请参考Kubernetes 关于生产工作节点的文档。

为了优化系统资源，如果不需要图形用户界面，最好使用不包含 Windows 桌面体验 (Desktop Experience) 安装选项的 Windows Server 操作系统安装，因为这种配置通常会释放更多的系统资源。

在评估 Windows 工作节点的磁盘空间时，请注意 Windows 容器镜像通常比 Linux 容器镜像大，单个镜像的大小从 300MB 到超过 10GB 不等。此外，请注意 Windows 容器中的 C: 驱动器默认代表 20GB 的虚拟可用大小，这并非实际占用的空间，而是使用主机上的本地存储时单个容器可以增长并占用的最大磁盘空间。有关更多详细信息，请参阅Windows 容器 - 容器存储文档。

寻求帮助与故障排查

您排查 Kubernetes 集群故障的主要帮助来源应从故障排查页面开始。

本节包含了一些额外的、特定于 Windows 的故障排查帮助。日志是排查 Kubernetes 问题的重要元素。在向其他贡献者寻求故障排查帮助时，请务必包含这些日志。请按照 SIG Windows 贡献指南中关于收集日志的说明进行操作。

报告问题与功能请求

如果您发现了一个看起来是 Bug 的问题，或者想提交功能请求，请按照 SIG Windows 贡献指南创建一个新的 Issue。在创建之前，您应先搜索现有 Issue 列表，看看是否之前已被报告过，并评论您的经验并补充额外的日志。Kubernetes Slack 上的 SIG Windows 频道也是在创建工单之前获得初步支持和故障排查建议的绝佳途径。

验证 Windows 集群可用性

Kubernetes 项目提供了一份Windows 操作就绪 (Windows Operational Readiness) 规范，并附带了一套结构化的测试套件。该套件分为核心测试和扩展测试两组，每组都包含旨在测试特定领域的类别。它可以用于全面验证 Windows 和混合系统（与 Linux 节点混合）的所有功能。

要在新创建的集群上设置该项目，请参考项目指南中的说明。

部署工具

kubeadm 工具可帮助您部署 Kubernetes 集群，提供用于管理集群的控制平面以及用于运行工作负载的节点。

Kubernetes 集群 API (Cluster API) 项目也提供了自动化部署 Windows 节点的方法。

Windows 分发渠道

有关 Windows 分发渠道的详细说明，请参阅 Microsoft 文档。

有关不同 Windows Server 服务渠道及其支持模型的详细信息，请参阅 Windows Server 服务渠道。


最后修改时间：2026 年 4 月 14 日凌晨 1:15（太平洋标准时间）：fix(links): update kubernetes/community links from master to main (03c191bcc4)

此页面上的项目涉及提供 Kubernetes 所需功能的第三方产品或项目。Kubernetes 项目作者不对这些第三方产品或项目负责。有关详细信息，请参阅 CNCF 网站指南。

在提出添加额外的第三方链接的更改之前，您应该阅读 内容指南。