IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='' ;$$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 ``` {{< note >}} 端口映射也是支持的，但为简单起见，在此示例中容器端口 80 直接暴露给服务。 {{< /note >}} 1. 检查所有节点是否健康： ```bash kubectl get nodes ``` 1. 部署服务并观察 pod 更新： ```bash kubectl apply -f win-webserver.yaml kubectl get pods -o wide -w ``` 正确部署服务后，两个 Pod 都标记为“Ready”。要退出 watch 命令，请按 Ctrl + C。 1. 检查部署是否成功。验证： * 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` 服务名称[默认 DNS 后缀](/zh/docs/concepts/services-networking/dns-pod-service/#services) * 入站连接，从 Linux 主服务器或集群外部的计算机 `curl` NodePort * 出站连接，使用 kubectl exec 从 Pod 内部 curl 外部 IP {{< note >}} 由于当前平台对 Windows 网络堆栈的限制，Windows 容器主机无法访问在其上调度的服务的 IP。只有 Windows pods 才能访问服务 IP。 {{< /note >}} ## 使用可配置的容器用户名 从 Kubernetes v1.16 开始，可以为 Windows 容器配置与其镜像默认值不同的用户名来运行其入口点和进程。 此能力的实现方式和 Linux 容器有些不同。 在[此处](/zh/docs/tasks/configure-pod-container/configure-runasusername/)可了解更多信息。 ## 使用组托管服务帐户管理工作负载身份 从 Kubernetes v1.14 开始，可以将 Windows 容器工作负载配置为使用组托管服务帐户（GMSA）。 组托管服务帐户是 Active Directory 帐户的一种特定类型，它提供自动密码管理， 简化的服务主体名称（SPN）管理以及将管理委派给跨多台服务器的其他管理员的功能。 配置了 GMSA 的容器可以访问外部 Active Directory 域资源，同时携带通过 GMSA 配置的身份。 在[此处](/zh/docs/tasks/configure-pod-container/configure-gmsa/)了解有关为 Windows 容器配置和使用 GMSA 的更多信息。 ## 污点和容忍度 目前，用户需要将 Linux 和 Windows 工作负载运行在各自特定的操作系统的节点上， 因而需要结合使用污点和节点选择算符。 这可能仅给 Windows 用户造成不便。 推荐的方法概述如下，其主要目标之一是该方法不应破坏与现有 Linux 工作负载的兼容性。 ### 确保特定操作系统的工作负载落在适当的容器主机上 用户可以使用污点和容忍度确保 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 charts，以及程序化 Pod 生成案例，例如 Operators。 在这些情况下，您可能会不愿意更改配置添加 nodeSelector。替代方法是使用污点。 由于 kubelet 可以在注册期间设置污点，因此可以轻松修改它，使其仅在 Windows 上运行时自动添加污点。 例如：`--register-with-taints='os=windows:NoSchedule'` 向所有 Windows 节点添加污点后，Kubernetes 将不会在它们上调度任何负载（包括现有的 Linux Pod）。 为了使某 Windows Pod 调度到 Windows 节点上，该 Pod 既需要 nodeSelector 选择 Windows， 也需要合适的匹配的容忍度设置。 ```yaml 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 版本相匹配。 如果要在同一集群中使用多个 Windows Server 版本，则应该设置其他节点标签和 nodeSelector。 Kubernetes 1.17 自动添加了一个新标签 `node.kubernetes.io/windows-build` 来简化此操作。 如果您运行的是旧版本，则建议手动将此标签添加到 Windows 节点。 此标签反映了需要兼容的 Windows 主要、次要和内部版本号。以下是当前每个 Windows Server 版本使用的值。 | 产品名称 | 内部编号 | |--------------------------------------|------------------------| | Windows Server 2019 | 10.0.17763 | | Windows Server version 1809 | 10.0.17763 | | Windows Server version 1903 | 10.0.18362 | ### 使用 RuntimeClass 简化 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/) 可用于简化使用污点和容忍度的过程。 集群管理员可以创建 `RuntimeClass` 对象，用于封装这些污点和容忍度。 1. 将此文件保存到 `runtimeClasses.yml` 文件。它包括适用于 Windows 操作系统、体系结构和版本的 `nodeSelector`。 ```yaml 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" ``` 2. 集群管理员运行 `kubectl create -f runtimeClasses.yml` 操作 3. 根据需要向 Pod 规约中添加 `runtimeClassName: windows-2019` 例如： ```yaml 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 ```