这是本节的多页打印视图。点击此处打印.

Kubernetes 中的 Windows

1: Kubernetes 中的 Windows 容器
2: Kubernetes 中的 Windows 容器调度指南

1 - 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 容器表示具有进程隔离能力的 Windows 容器。 Kubernetes 不支持使用 Hyper-V 隔离能力来运行 Windows 容器。

兼容性与局限性

某些节点层面的功能特性仅在使用特定容器运行时时才可用；另外一些特性则在 Windows 节点上不可用，包括：

巨页（HugePages）：Windows 容器当前不支持。
特权容器：Windows 容器当前不支持。 HostProcess 容器提供类似功能。
TerminationGracePeriod：需要 containerD。

Windows 节点并不支持共享命名空间的所有功能特性。有关更多详细信息，请参考 API 兼容性。

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

从 API 和 kubectl 的角度来看，Windows 容器的行为与基于 Linux 的容器非常相似。然而，在本节所概述的一些关键功能上，二者存在一些显著差异。

与 Linux 比较

Kubernetes 关键组件在 Windows 上的工作方式与在 Linux 上相同。本节介绍几个关键的工作负载抽象及其如何映射到 Windows。

Pod
Pod 是 Kubernetes 的基本构建块，是可以创建或部署的最小和最简单的单元。你不可以在同一个 Pod 中部署 Windows 和 Linux 容器。 Pod 中的所有容器都调度到同一 Node 上，每个 Node 代表一个特定的平台和体系结构。 Windows 容器支持以下 Pod 能力、属性和事件：
- 每个 Pod 有一个或多个容器，具有进程隔离和卷共享能力
- Pod status 字段
- 就绪、存活和启动探针
- postStart 和 preStop 容器生命周期回调
- ConfigMap 和 Secret：作为环境变量或卷
- emptyDir 卷
- 命名管道形式的主机挂载
- 资源限制
- 操作系统字段：
  .spec.os.name 字段应设置为 windows 以表明当前 Pod 使用 Windows 容器。需要启用 IdentifyPodOS 特性门控才能让这个字段被识别。
  说明： 从 1.24 开始，IdentifyPodOS 特性门控进入 Beta 阶段，默认启用。
  如果 IdentifyPodOS 特性门控已启用并且你将 .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
有关更多详细信息，请参考负载均衡和 Service。

Pod、工作负载资源和 Service 是在 Kubernetes 上管理 Windows 工作负载的关键元素。然而，它们本身还不足以在动态的云原生环境中对 Windows 工作负载进行恰当的生命周期管理。 Kubernetes 还支持：

kubectl exec
Pod 和容器度量指标
Pod 水平自动扩缩容
资源配额
调度器抢占

kubelet 的命令行选项

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

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

API 兼容性

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

从较高的层面来看，以下操作系统概念是不同的：

身份 - Linux 使用 userID（UID）和 groupID（GID），表示为整数类型。用户名和组名是不规范的，它们只是 /etc/groups 或 /etc/passwd 中的别名，作为 UID+GID 的后备标识。 Windows 使用更大的二进制安全标识符（SID），存放在 Windows 安全访问管理器（Security Access Manager，SAM）数据库中。此数据库在主机和容器之间或容器之间不共享。
文件权限 - Windows 使用基于 SID 的访问控制列表，而像 Linux 使用基于对象权限和 UID+GID 的位掩码（POSIX 系统）以及可选的访问控制列表。
文件路径 - Windows 上的约定是使用 \ 而不是 /。 Go IO 库通常接受两者，能让其正常工作，但当你设置要在容器内解读的路径或命令行时，可能需要用 \。

信号 - Windows 交互式应用处理终止的方式不同，可以实现以下一种或多种：
- UI 线程处理包括 WM_CLOSE 在内准确定义的消息。
- 控制台应用使用控制处理程序（Control Handler）处理 Ctrl-C 或 Ctrl-Break。
- 服务会注册可接受 SERVICE_CONTROL_STOP 控制码的服务控制处理程序（Service Control Handler）函数。

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

容器规范的字段兼容性

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

巨页（Huge page）在 Windows 容器运行时中未实现，且不可用。巨页需要不可为容器配置的用户特权生效。
requests.cpu 和 requests.memory - 从节点可用资源中减去请求，因此请求可用于避免一个节点过量供应。但是，请求不能用于保证已过量供应的节点中的资源。如果运营商想要完全避免过量供应，则应将设置请求作为最佳实践应用到所有容器。

securityContext.allowPrivilegeEscalation - 不能在 Windows 上使用；所有权能字都无法生效。
securityContext.capabilities - POSIX 权能未在 Windows 上实现。
securityContext.privileged - Windows 不支持特权容器。
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 - Windows 操作系统不支持共享主机网络。
dnsPolicy - Windows 不支持将 Pod dnsPolicy 设为 ClusterFirstWithHostNet，因为未提供主机网络。Pod 始终用容器网络运行。
podSecurityContext（参见下文）
shareProcessNamespace - 这是一个 beta 版功能特性，依赖于 Windows 上未实现的 Linux 命名空间。 Windows 无法共享进程命名空间或容器的根文件系统（root filesystem）。只能共享网络。

terminationGracePeriodSeconds - 这在 Windows 上的 Docker 中没有完全实现，请参考 GitHub issue。目前的行为是通过 CTRL_SHUTDOWN_EVENT 发送 ENTRYPOINT 进程，然后 Windows 默认等待 5 秒，最后使用正常的 Windows 关机行为终止所有进程。 5 秒默认值实际上位于容器内的 Windows 注册表中，因此在构建容器时可以覆盖这个值。
volumeDevices - 这是一个 beta 版功能特性，未在 Windows 上实现。 Windows 无法将原始块设备挂接到 Pod。
volumes
- 如果你定义一个 emptyDir 卷，则你无法将卷源设为 memory。
你无法为卷挂载启用 mountPropagation，因为这在 Windows 上不支持。

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

Pod 的所有 securityContext 字段都无法在 Windows 上生效。

节点问题检测器

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

Pause 容器

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

Kubernetes 维护一个多体系结构的镜像，包括对 Windows 的支持。对于 Kubernetes v1.24，推荐的 pause 镜像为 k8s.gcr.io/pause:3.6。可在 GitHub 上获得源代码。

Microsoft 维护一个不同的多体系结构镜像，支持 Linux 和 Windows amd64，你可以找到的镜像类似 mcr.microsoft.com/oss/kubernetes/pause:3.6。此镜像的构建与 Kubernetes 维护的镜像同源，但所有 Windows 可执行文件均由 Microsoft 进行了验证码签名。如果你正部署到一个需要签名可执行文件的生产或类生产环境， Kubernetes 项目建议使用 Microsoft 维护的镜像。

容器运行时

你需要将容器运行时安装到集群中的每个节点，这样 Pod 才能在这些节点上运行。

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

说明： 本部分链接到提供 Kubernetes 所需功能的第三方项目。Kubernetes 项目作者不负责这些项目。此页面遵循CNCF 网站指南，按字母顺序列出项目。要将项目添加到此列表中，请在提交更改之前阅读内容指南。

ContainerD

特性状态： Kubernetes v1.20 [stable]

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

学习如何在 Windows 上安装 ContainerD。

说明： 将 GMSA 和 containerd 一起用于访问 Windows 网络共享时存在已知限制，这需要一个内核补丁。

Mirantis 容器运行时

Mirantis 容器运行时（MCR）可作为所有 Windows Server 2019 和更高版本的容器运行时。

有关更多信息，请参考在 Windows Server 上安装 MCR。

Windows 操作系统版本兼容性

在 Windows 节点上，如果主机操作系统版本必须与容器基础镜像操作系统版本匹配，则会应用严格的兼容性规则。仅 Windows Server 2019 作为容器操作系统时，才能完全支持 Windows 容器。

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

Windows Server LTSC release: Windows Server 2019; Windows Server 2022
Windows Server SAC release: Windows Server version 20H2

也适用 Kubernetes 版本偏差策略。

获取帮助和故障排查

对 Kubernetes 集群进行故障排查的主要帮助来源应始于故障排查页面。

本节包括了一些其他特定于 Windows 的故障排查帮助。日志是解决 Kubernetes 中问题的重要元素。确保在任何时候向其他贡献者寻求故障排查协助时随附了日志信息。遵照 SIG Windows 日志收集贡献指南中的指示说明。

报告问题和功能请求

如果你发现疑似 bug，或者你想提出功能请求，请按照 SIG Windows 贡献指南新建一个 Issue。你应该先搜索 issue 列表，以防之前报告过这个问题，凭你对该问题的经验添加评论，并随附日志信息。 Kubernetes Slack 上的 SIG Windows 频道也是一个很好的途径，可以在创建工单之前获得一些初始支持和故障排查思路。

接下来

部署工具

kubeadm 工具帮助你部署 Kubernetes 集群，提供管理集群的控制平面以及运行工作负载的节点。添加 Windows 节点阐述了如何使用 kubeadm 将 Windows 节点部署到你的集群。

Kubernetes 集群 API 项目也提供了自动部署 Windows 节点的方式。

Windows 分发渠道

有关 Windows 分发渠道的详细阐述，请参考 Microsoft 文档。

有关支持模型在内的不同 Windows Server 服务渠道的信息，请参考 Windows Server 服务渠道。

2 - Kubernetes 中的 Windows 容器调度指南

在许多组织中运行的服务和应用程序中，Windows 应用程序构成了很大一部分。本指南将引导你完成在 Kubernetes 中配置和部署 Windows 容器的步骤。

目标

配置 Deployment 样例以在 Windows 节点上运行 Windows 容器
在 Kubernetes 中突出 Windows 特定的功能

在你开始之前

创建一个 Kubernetes 集群，其中包含一个控制平面和一个运行 Windows Server 的工作节点
务必请注意，在 Kubernetes 上创建和部署服务和工作负载的行为方式与 Linux 和 Windows 容器的行为方式大致相同。与集群交互的 kubectl 命令是一致的。下一小节的示例旨在帮助你快速开始使用 Windows 容器。

快速开始：部署 Windows 容器

以下示例 YAML 文件部署了一个在 Windows 容器内运行的简单 Web 服务器的应用程序。

创建一个名为 win-webserver.yaml 的 Service 规约，其内容如下：

apiVersion: v1
kind: Service
metadata:
  name: win-webserver
  labels:
    app: win-webserver
spec:
  ports:
    # 此 Service 服务的端口
    - port: 80
      targetPort: 80
  selector:
    app: win-webserver
  type: NodePort
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: win-webserver
  name: win-webserver
spec:
  replicas: 2
  selector:
    matchLabels:
      app: win-webserver
  template:
    metadata:
      labels:
        app: win-webserver
      name: win-webserver
    spec:
     containers:
      - name: windowswebserver
        image: mcr.microsoft.com/windows/servercore:ltsc2019
        command:
        - powershell.exe
        - -command
        - "<#code used from https://gist.github.com/19WAS85/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ;  ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count += $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='<html><body><H1>Windows Container Web Server</H1>' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString+='<p>IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='</body></html>' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus)  } ; "
     nodeSelector:
      kubernetes.io/os: windows

说明：

端口映射也是支持的，但为简单起见，此示例将容器的端口 80 直接暴露给服务。

检查所有节点是否健康
```
kubectl get nodes
```

部署 Service 并监视 Pod 更新：
```
kubectl apply -f win-webserver.yaml
kubectl get pods -o wide -w
```
当 Service 被正确部署时，两个 Pod 都被标记为就绪（Ready）。要退出 watch 命令，请按 Ctrl+C。

检查部署是否成功。请验证：
- 当执行 kubectl get pods 命令时，能够从 Linux 控制平面所在的节点上列出两个 Pod。
- 跨网络的节点到 Pod 通信，从 Linux 控制平面所在的节点上执行 curl 命令来访问 Pod IP 的 80 端口以检查 Web 服务器响应。
- Pod 间通信，使用 docker exec 或 kubectl exec 命令进入容器，并在 Pod 之间（以及跨主机，如果你有多个 Windows 节点）相互进行 ping 操作。
- Service 到 Pod 的通信，在 Linux 控制平面所在的节点以及独立的 Pod 中执行 curl 命令来访问虚拟的服务 IP（在 kubectl get services 命令下查看）。
- 服务发现，执行 curl 命令来访问带有 Kubernetes 默认 DNS 后缀的服务名称。
- 入站连接，在 Linux 控制平面所在的节点上或集群外的机器上执行 curl 命令来访问 NodePort 服务。
- 出站连接，使用 kubectl exec，从 Pod 内部执行 curl 访问外部 IP。

说明：

由于当前 Windows 平台的网络堆栈限制，Windows 容器主机无法访问调度到其上的 Service 的 IP。只有 Windows Pod 能够访问 Service IP。

可观察性

捕捉来自工作负载的日志

日志是可观察性的重要元素；它们使用户能够深入了解工作负载的运行情况，并且是解决问题的关键因素。由于 Windows 容器和 Windows 容器中的工作负载与 Linux 容器的行为不同，因此用户很难收集日志，从而限制了操作可见性。例如，Windows 工作负载通常配置为记录到 ETW（Windows 事件跟踪）或向应用程序事件日志推送条目。 LogMonitor 是一个微软开源的工具，是监视 Windows 容器内所配置的日志源的推荐方法。 LogMonitor 支持监视事件日志、ETW 提供程序和自定义应用程序日志，将它们传送到 STDOUT 以供 kubectl logs <pod> 使用。

按照 LogMonitor GitHub 页面中的说明，将其二进制文件和配置文件复制到所有容器，并为 LogMonitor 添加必要的入口点以将日志推送到标准输出（STDOUT）。

配置容器用户

使用可配置的容器用户名

Windows 容器可以配置为使用不同于镜像默认值的用户名来运行其入口点和进程。在这里了解更多信息。

使用组托管服务帐户（GMSA）管理工作负载身份

Windows 容器工作负载可以配置为使用组托管服务帐户（Group Managed Service Accounts，GMSA）。组托管服务帐户是一种特定类型的活动目录（Active Directory）帐户，可提供自动密码管理、简化的服务主体名称（Service Principal Name，SPN）管理，以及将管理委派给多个服务器上的其他管理员的能力。配置了 GMSA 的容器可以携带使用 GMSA 配置的身份访问外部活动目录域资源。在此处了解有关为 Windows 容器配置和使用 GMSA 的更多信息。

污点和容忍度

用户需要使用某种污点（Taint）和节点选择器的组合，以便将 Linux 和 Windows 工作负载各自调度到特定操作系统的节点。下面概述了推荐的方法，其主要目标之一是该方法不应破坏现有 Linux 工作负载的兼容性。

如果启用了 IdentifyPodOS 特性门控，你可以（并且应该）将 Pod 的 .spec.os.name 设置为该 Pod 中的容器设计所用于的操作系统。对于运行 Linux 容器的 Pod，将 .spec.os.name 设置为 linux。对于运行 Windows 容器的 Pod，将 .spec.os.name 设置为 Windows。

说明：

从 1.24 开始，IdentifyPodOS 特性处于 Beta 阶段，默认启用。

调度器在将 Pod 分配到节点时并不使用 .spec.os.name 的值。你应该使用正常的 Kubernetes 机制将 Pod 分配给节点，以确保集群的控制平面将 Pod 放置到运行适当操作系统的节点上。

.spec.os.name 值对 Windows Pod 的调度没有影响，因此仍然需要污点和容忍以及节点选择器来确保 Windows Pod 落在适当的 Windows 节点。

确保特定于操作系统的工作负载落到合适的容器主机上

用户可以使用污点（Taint）和容忍度（Toleration）确保将 Windows 容器调度至合适的主机上。现在，所有的 Kubernetes 节点都有以下默认标签：

kubernetes.io/os = [windows|linux]
kubernetes.io/arch = [amd64|arm64|...]

如果 Pod 规约没有指定像 "kubernetes.io/os": windows 这样的 nodeSelector，则 Pod 可以被调度到任何主机上，Windows 或 Linux。这可能会有问题，因为 Windows 容器只能在 Windows 上运行，而 Linux 容器只能在 Linux 上运行。最佳实践是使用 nodeSelector。

但是，我们了解到，在许多情况下，用户已经预先存在大量 Linux 容器部署，以及现成配置的生态系统，例如社区中的 Helm Chart 包和程序化的 Pod 生成案例，例如 Operator。在这些情况下，你可能不愿更改配置来添加节点选择器。另一种方法是使用污点。因为 kubelet 可以在注册过程中设置污点，所以可以很容易地修改为，当只能在 Windows 上运行时，自动添加污点。

例如：--register-with-taints='os=windows:NoSchedule'

通过向所有 Windows 节点添加污点，任何负载都不会被调度到这些节点上（包括现有的 Linux Pod）。为了在 Windows 节点上调度 Windows Pod，它需要 nodeSelector 和匹配合适的容忍度来选择 Windows。

nodeSelector:
    kubernetes.io/os: windows
    node.kubernetes.io/windows-build: '10.0.17763'
tolerations:
    - key: "os"
      operator: "Equal"
      value: "windows"
      effect: "NoSchedule"

处理同一集群中的多个 Windows 版本

每个 Pod 使用的 Windows Server 版本必须与节点的版本匹配。如果要在同一个集群中使用多个 Windows Server 版本，则应设置额外的节点标签和节点选择器。

Kubernetes 1.17 自动添加了一个新标签 node.kubernetes.io/windows-build 来简化这一点。如果你运行的是旧版本，则建议手动将此标签添加到 Windows 节点。

此标签反映了需要匹配以实现兼容性的 Windows 主要、次要和内部版本号。以下是目前用于每个 Windows Server 版本的值。

产品名称	构建号
Windows Server 2019	10.0.17763
Windows Server, Version 20H2	10.0.19042
Windows Server 2022	10.0.20348

使用 RuntimeClass 进行简化

RuntimeClass 可用于简化使用污点和容忍度的流程。集群管理员可以创建一个用于封装这些污点和容忍度的 RuntimeClass 对象。

将此文件保存到 runtimeClasses.yml。它包括针对 Windows 操作系统、架构和版本的 nodeSelector。

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: windows-2019
handler: 'docker'
scheduling:
  nodeSelector:
    kubernetes.io/os: 'windows'
    kubernetes.io/arch: 'amd64'
    node.kubernetes.io/windows-build: '10.0.17763'
  tolerations:
  - effect: NoSchedule
    key: os
    operator: Equal
    value: "windows"

以集群管理员身份运行 kubectl create -f runtimeClasses.yml
根据情况，向 Pod 规约中添加 runtimeClassName: windows-2019

例如：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: iis-2019
  labels:
    app: iis-2019
spec:
  replicas: 1
  template:
    metadata:
      name: iis-2019
      labels:
        app: iis-2019
    spec:
      runtimeClassName: windows-2019
      containers:
      - name: iis
        image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
        resources:
          limits:
            cpu: 1
            memory: 800Mi
          requests:
            cpu: .1
            memory: 300Mi
        ports:
          - containerPort: 80
 selector:
    matchLabels:
      app: iis-2019
---
apiVersion: v1
kind: Service
metadata:
  name: iis
spec:
  type: LoadBalancer
  ports:
  - protocol: TCP
    port: 80
  selector:
    app: iis-2019