Kubernetes 中 Windows 容器的调度指南

    • 配置一个示例 deployment 以在 Windows 节点上运行 Windows 容器
    • （可选）使用组托管服务帐户（GMSA）为您的 Pod 配置 Active Directory 身份

    在你开始之前

    • 创建一个 Kubernetes 集群，其中包括一个控制平面和
    • 重要的是要注意，对于 Linux 和 Windows 容器，在 Kubernetes 上创建和部署服务和工作负载的行为几乎相同。 与集群接口的 kubectl 命令相同。 提供以下部分中的示例只是为了快速启动 Windows 容器的使用体验。

    要在 Kubernetes 上部署 Windows 容器，您必须首先创建一个示例应用程序。 下面的示例 YAML 文件创建了一个简单的 Web 服务器应用程序。 创建一个名为 的服务规约，其内容如下：

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

    1. 检查所有节点是否健康：

      1. kubectl get nodes

    2. 部署服务并观察 pod 更新：

      正确部署服务后，两个 Pod 都标记为“Ready”。要退出 watch 命令，请按 Ctrl + C。

    3. 检查部署是否成功。验证：

      • Windows 节点上每个 Pod 有两个容器，使用 docker ps
      • Linux 控制平面节点列出两个 Pod，使用 kubectl get pods
      • 跨网络的节点到 Pod 通信，从 Linux 控制平面节点 curl 您的 pod IPs 的端口80，以检查 Web 服务器响应
      • Pod 到 Pod 的通信，使用 docker exec 或 kubectl exec 在 Pod 之间 （以及跨主机，如果你有多个 Windows 节点）进行 ping 操作
      • 服务到 Pod 的通信，从 Linux 控制平面节点和各个 Pod 中 curl 虚拟服务 IP （在 kubectl get services 下可见）
      • 服务发现，使用 Kubernetes curl 服务名称
      • 入站连接，从 Linux 控制平面节点或集群外部的计算机 curl NodePort

    Note: 由于当前平台对 Windows 网络堆栈的限制，Windows 容器主机无法访问在其上调度的服务的 IP。只有 Windows pods 才能访问服务 IP。

    可观测性

    日志是可观测性的重要一环；使用日志用户可以获得对负载运行状况的洞察， 因而日志是故障排查的一个重要手法。 因为 Windows 容器中的 Windows 容器和负载与 Linux 容器的行为不同， 用户很难收集日志，因此运行状态的可见性很受限。 例如，Windows 工作负载通常被配置为将日志输出到 Windows 事件跟踪 （Event Tracing for Windows，ETW），或者将日志条目推送到应用的事件日志中。 是 Microsoft 提供的一个开源工具，是监视 Windows 容器中所配置的日志源 的推荐方式。 LogMonitor 支持监视时间日志、ETW 提供者模块以及自定义的应用日志， 并使用管道的方式将其输出到标准输出（stdout），以便 kubectl logs <pod> 这类命令能够读取这些数据。

    从 Kubernetes v1.16 开始，可以为 Windows 容器配置与其镜像默认值不同的用户名 来运行其入口点和进程。 此能力的实现方式和 Linux 容器有些不同。 在此处 可了解更多信息。

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

    从 Kubernetes v1.14 开始，可以将 Windows 容器工作负载配置为使用组托管服务帐户（GMSA）。 组托管服务帐户是 Active Directory 帐户的一种特定类型，它提供自动密码管理， 简化的服务主体名称（SPN）管理以及将管理委派给跨多台服务器的其他管理员的功能。 配置了 GMSA 的容器可以访问外部 Active Directory 域资源，同时携带通过 GMSA 配置的身份。 在此处了解有关为 Windows 容器配置和使用 GMSA 的更多信息。

    目前，用户需要将 Linux 和 Windows 工作负载运行在各自特定的操作系统的节点上， 因而需要结合使用污点和节点选择算符。 这可能仅给 Windows 用户造成不便。 推荐的方法概述如下，其主要目标之一是该方法不应破坏与现有 Linux 工作负载的兼容性。

    Note:

    如果 IdentifyPodOS 是启用的， 你可以（并且应该）为 Pod 设置 .spec.os.name 以表明该 Pod 中的容器所针对的操作系统。 对于运行 Linux 容器的 Pod，设置 .spec.os.name 为 linux。 对于运行 Windows 容器的 Pod，设置 .spec.os.name 为 Windows。

    在将 Pod 分配给节点时，调度程序不使用 .spec.os.name 的值。你应该使用正常的 Kubernetes 机制将 Pod 分配给节点， 确保集群的控制平面将 Pod 放置到适合运行的操作系统。 对 Windows Pod 的调度没有影响，因此仍然需要污点、容忍度以及节点选择器， 以确保 Windows Pod 调度至合适的 Windows 节点。

    用户可以使用污点和容忍度确保 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。

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

    向所有 Windows 节点添加污点后，Kubernetes 将不会在它们上调度任何负载（包括现有的 Linux Pod）。 为了使某 Windows Pod 调度到 Windows 节点上，该 Pod 需要 nodeSelector 和合适的匹配的容忍度设置来选择 Windows，

    1. nodeSelector:
    2.   kubernetes.io/os: windows
    3.   node.kubernetes.io/windows-build: '10.0.17763'
    4. tolerations:
    5.   - key: "os"
    6.     operator: "Equal"
    8.     effect: "NoSchedule"

    每个 Pod 使用的 Windows Server 版本必须与该节点的 Windows Server 版本相匹配。 如果要在同一集群中使用多个 Windows Server 版本，则应该设置其他节点标签和 nodeSelector。

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

    此标签反映了需要兼容的 Windows 主要、次要和内部版本号。以下是当前每个 Windows Server 版本使用的值。

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

    1. 将此文件保存到 runtimeClasses.yml 文件。 它包括适用于 Windows 操作系统、体系结构和版本的 nodeSelector。

    2. 集群管理员执行 kubectl create -f runtimeClasses.yml 操作

    3. 根据需要向 Pod 规约中添加 runtimeClassName: windows-2019
    1. apiVersion: apps/v1
    2. kind: Deployment
    3. metadata:
    4.   name: iis-2019
    5.   labels:
    6.     app: iis-2019
    7. spec:
    8.   replicas: 1
    9.   template:
    10.     metadata:
    11.       name: iis-2019
    12.       labels:
    13.         app: iis-2019
    14.       runtimeClassName: windows-2019
    15.       containers:
    16.       - name: iis
    18.         resources:
    19.           limits:
    20.             cpu: 1
    21.             memory: 800Mi
    22.           requests:
    23.             cpu: .1
    24.             memory: 300Mi
    25.         ports:
    26.           - containerPort: 80
    27.  selector:
    28.     matchLabels:
    29.       app: iis-2019
    30. ---
    31. apiVersion: v1
    32. kind: Service
    33. metadata:
    34.   name: iis
    35. spec:
    36.   type: LoadBalancer
    37.   ports:
    38.   - protocol: TCP
    39.     port: 80
    40.     app: iis-2019

    最后修改 April 27, 2022 at 11:10 PM PST: [zh]Update content/zh/docs/setup/production-environment/windows/user-guide-windows-containers.md (75a812ca5)