Kubernetes 中的 Windows 容器

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

在 Windows 应用程序和 Linux 应用程序方面有投资的组织无需寻找单独的编排器来管理其工作负载，从而提高了其部署的运营效率，无论操作系统如何。

Kubernetes 中的 Windows 节点

为了在 Kubernetes 中启用 Windows 容器的编排，请在您现有的 Linux 集群中包含 Windows 节点。在 Kubernetes 中调度 Pod 上的 Windows 容器类似于调度基于 Linux 的容器。

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

Windows 节点 是 受支持的，前提是操作系统是 Windows Server 2019 或 Windows Server 2022。

本文档使用术语“Windows 容器”表示具有进程隔离的 Windows 容器。Kubernetes 不支持运行具有 Hyper-V 隔离 的 Windows 容器。

兼容性和限制

某些节点功能只有在您使用特定 容器运行时 时才可用；其他功能在 Windows 节点上不可用，包括

  • 巨页：不支持 Windows 容器
  • 特权容器：不支持 Windows 容器。 HostProcess 容器 提供类似的功能。
  • TerminationGracePeriod：需要 containerD

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

有关 Kubernetes 测试的 Windows 版本的详细信息，请参见 Windows 操作系统版本兼容性。

从 API 和 kubectl 的角度来看，Windows 容器的行为与基于 Linux 的容器非常相似。但是，关键功能方面存在一些显着差异，在本节中概述。

与 Linux 的比较

关键的 Kubernetes 元素在 Windows 中的工作方式与在 Linux 中相同。本节介绍几个关键的工作负载抽象以及它们如何映射到 Windows。

  • Pod

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

    • 每个 Pod 中使用进程隔离和卷共享的单个或多个容器

    • Pod 状态 字段

    • 就绪、存活和启动探测

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

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

    • emptyDir 卷

    • 命名管道主机挂载

    • 资源限制

    • 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。

  • 工作负载资源，包括

    • 副本集
    • 部署
    • StatefulSet
    • 守护进程集
    • 作业
    • CronJob
    • 复制控制器

  • 服务 有关更多详细信息，请参见 负载均衡和服务。

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 使用 userID (UID) 和 groupID (GID)，它们表示为整数类型。用户和组名不是规范的 - 它们只是 /etc/groups 或 /etc/passwd 中返回到 UID+GID 的别名。Windows 使用更大的二进制 安全标识符 (SID)，它存储在 Windows 安全访问管理器 (SAM) 数据库中。此数据库在主机和容器之间或容器之间不共享。
  • 文件权限 - Windows 使用基于 (SID) 的访问控制列表，而 POSIX 系统（如 Linux）使用基于对象权限和 UID+GID 的位掩码，以及可选的访问控制列表。
  • 文件路径 - Windows 上的约定是使用 \ 而不是 /。Go IO 库通常接受两者并使其正常工作，但是，当您设置在容器内解释的路径或命令行时，可能需要 \。
  • 信号 - Windows 交互式应用程序以不同的方式处理终止，并且可以实现以下一项或多项
    • UI 线程处理定义明确的消息，包括 WM_CLOSE。
    • 控制台应用程序使用控制处理程序处理 Ctrl-C 或 Ctrl-break。
    • 服务注册一个服务控制处理程序函数，该函数可以接受 SERVICE_CONTROL_STOP 控制代码。

容器退出代码遵循相同的约定，其中 0 表示成功，非零表示失败。特定错误代码在 Windows 和 Linux 之间可能有所不同。但是，从 Kubernetes 组件（kubelet、kube-proxy）传递的退出代码保持不变。

容器规范的字段兼容性

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

  • 巨页未在 Windows 容器运行时中实现，并且不可用。它们需要 断言用户权限，该权限不可为容器配置。
  • requests.cpu 和 requests.memory - 请求从节点可用资源中减去，因此它们可用于避免过度配置节点。但是，它们不能用于在过度配置的节点中保证资源。如果操作员希望完全避免过度配置，则应将其应用于所有容器作为最佳实践。
  • securityContext.allowPrivilegeEscalation - 在 Windows 上不可用；没有连接任何功能
  • securityContext.capabilities - POSIX 功能在 Windows 上未实现
  • securityContext.privileged - Windows 不支持特权容器，请改用 HostProcess 容器
  • securityContext.procMount - Windows 没有 /proc 文件系统
  • securityContext.readOnlyRootFilesystem - 在 Windows 上不可用；注册表和系统进程需要写入访问权限才能在容器内运行
  • securityContext.runAsGroup - 在 Windows 上不可用，因为不支持 GID
  • securityContext.runAsNonRoot - 此设置将阻止容器以 ContainerAdministrator 身份运行，这是 Windows 上最接近 root 用户的等效项。
  • securityContext.runAsUser - 请改用 runAsUserName
  • securityContext.seLinuxOptions - 在 Windows 上不可用，因为 SELinux 是 Linux 特定的
  • terminationMessagePath - 这有一些限制，因为 Windows 不支持映射单个文件。默认值为 /dev/termination-log，它确实有效，因为默认情况下它在 Windows 上不存在。

Pod 规范的字段兼容性

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

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

hostNetwork 的字段兼容性

功能状态： Kubernetes v1.26 [alpha]

kubelet 现在可以请求在 Windows 节点上运行的 Pod 使用主机的网络命名空间，而不是创建新的 Pod 网络命名空间。要启用此功能，请将 --feature-gates=WindowsHostNetwork=true 传递给 kubelet。

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

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

节点问题检测器

节点问题检测器（请参阅 监控节点运行状况）对 Windows 的支持处于初步阶段。有关更多信息，请访问该项目的 GitHub 页面。

暂停容器

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

Kubernetes 维护一个多架构映像，其中包含对 Windows 的支持。对于 Kubernetes v1.31.0，推荐的暂停映像是 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

ContainerD

功能状态： Kubernetes v1.20 [stable]

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

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

Mirantis 容器运行时

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

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

Windows 操作系统版本兼容性

在 Windows 节点上，适用严格的兼容性规则，其中主机操作系统版本必须与容器基本映像操作系统版本匹配。仅完全支持容器操作系统为 Windows Server 2019 的 Windows 容器。

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

Windows Server LTSC 版本
Windows Server 2019
Windows Server 2022
Windows Server SAC 版本
Windows Server 版本 20H2

Kubernetes 的 版本偏差策略 也适用。

硬件建议和注意事项

  • 64 位处理器 4 个或更多个 CPU 内核，能够支持虚拟化
  • 8GB 或更多 RAM
  • 50GB 或更多可用磁盘空间

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

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

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

获取帮助和故障排除

为 Kubernetes 集群故障排除提供的主要帮助来源应从 故障排除 页面开始。

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

报告问题和功能请求

如果您遇到了看起来像是错误，或者想提出功能请求，请按照 SIG Windows 贡献指南 创建一个新问题。您应该首先搜索问题列表，以防它之前被报告过，并使用您的经验对问题进行评论，添加其他日志。Kubernetes Slack 上的 SIG Windows 频道也是在创建工单之前获得一些初步支持和故障排除建议的好途径。

验证 Windows 集群的运行状况

Kubernetes 项目提供了一个*Windows 运行状况就绪*规范，并附带了一个结构化的测试套件。此套件分为两组测试，核心和扩展，每组都包含旨在测试特定区域的类别。它可以用于验证 Windows 和混合系统（与 Linux 节点混合）的所有功能，并提供全面覆盖范围。

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

部署工具

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

Kubernetes 的 集群 API 项目还提供自动部署 Windows 节点的方法。

Windows 发行渠道

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

有关不同 Windows Server 服务渠道（包括其支持模型）的信息，请参阅 Windows Server 服务渠道。

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

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

最后修改时间：2024 年 7 月 29 日下午 3:56 PST：更新 Windows 节点驱逐信号文档 (b3ce13edaf)