Switch language name 'zh' to 'zh-cn'
This is the first step to rename 'zh' to 'zh-cn'. There are several reasons why we rename the language name.
- The upstream docsy theme changed the language name, leading to many warnings during site build;
The side-effect is that the i18n strings are no longer working.
- We believe renaming the language is the right thing to do, because this move can make room for other variants of Chinese language, such as 'zh-tw', 'zh-sg' etc.
There would be several follow-ups to this PR, such as fixing the intra-site links, adding redirects etc.
We will lock up changes to zh/zh-cn pages for the moment, until this one gets in.
This PR is based on commit cdad0a7342.
This commit is contained in:
Qiming Teng
@@ -0,0 +1,8 @@
|
||||
---
|
||||
title: "Kubernetes 中的 Windows"
|
||||
weight: 50
|
||||
---
|
||||
<!--
|
||||
title: "Windows in Kubernetes"
|
||||
weight: 50
|
||||
-->
|
||||
@@ -0,0 +1,721 @@
|
||||
---
|
||||
title: Kubernetes 中的 Windows 容器
|
||||
content_type: concept
|
||||
weight: 65
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- jayunit100
|
||||
- jsturtevant
|
||||
- marosset
|
||||
- perithompson
|
||||
title: Windows containers in Kubernetes
|
||||
content_type: concept
|
||||
weight: 65
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
<!--
|
||||
Windows applications constitute a large portion of the services and applications that
|
||||
run in many organizations. [Windows containers](https://aka.ms/windowscontainers)
|
||||
provide a way to encapsulate processes and package dependencies, making it easier
|
||||
to use DevOps practices and follow cloud native patterns for Windows applications.
|
||||
|
||||
Organizations with investments in Windows-based applications and Linux-based
|
||||
applications don't have to look for separate orchestrators to manage their workloads,
|
||||
leading to increased operational efficiencies across their deployments, regardless
|
||||
of operating system.
|
||||
-->
|
||||
在许多组织中，所运行的很大一部分服务和应用是 Windows 应用。
|
||||
[Windows 容器](https://aka.ms/windowscontainers)提供了一种封装进程和包依赖项的方式，
|
||||
从而简化了 DevOps 实践，令 Windows 应用程序同样遵从云原生模式。
|
||||
|
||||
对于同时投入基于 Windows 应用和 Linux 应用的组织而言，他们不必寻找不同的编排系统来管理其工作负载，
|
||||
使其跨部署的运营效率得以大幅提升，而不必关心所用的操作系统。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Windows nodes in Kubernetes
|
||||
|
||||
To enable the orchestration of Windows containers in Kubernetes, include Windows nodes
|
||||
in your existing Linux cluster. Scheduling Windows containers in
|
||||
{{< glossary_tooltip text="Pods" term_id="pod" >}} on Kubernetes is similar to
|
||||
scheduling Linux-based containers.
|
||||
|
||||
In order to run Windows containers, your Kubernetes cluster must include
|
||||
multiple operating systems.
|
||||
While you can only run the {{< glossary_tooltip text="control plane" term_id="control-plane" >}} on Linux,
|
||||
you can deploy worker nodes running either Windows or Linux.
|
||||
-->
|
||||
## Kubernetes 中的 Windows 节点 {#windows-nodes-in-k8s}
|
||||
|
||||
若要在 Kubernetes 中启用对 Windows 容器的编排，可以在现有的 Linux 集群中包含 Windows 节点。
|
||||
在 Kubernetes 上调度 {{< glossary_tooltip text="Pod" term_id="pod" >}} 中的 Windows 容器与调度基于 Linux 的容器类似。
|
||||
|
||||
为了运行 Windows 容器，你的 Kubernetes 集群必须包含多个操作系统。
|
||||
尽管你只能在 Linux 上运行{{< glossary_tooltip text="控制平面" term_id="control-plane" >}}，
|
||||
你可以部署运行 Windows 或 Linux 的工作节点。
|
||||
|
||||
<!--
|
||||
Windows {{< glossary_tooltip text="nodes" term_id="node" >}} are
|
||||
[supported](#windows-os-version-support) provided that the operating system is
|
||||
Windows Server 2019.
|
||||
|
||||
This document uses the term *Windows containers* to mean Windows containers with
|
||||
process isolation. Kubernetes does not support running Windows containers with
|
||||
[Hyper-V isolation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container).
|
||||
-->
|
||||
支持 Windows {{< glossary_tooltip text="节点" term_id="node" >}}的前提是操作系统为 Windows Server 2019。
|
||||
|
||||
本文使用术语 **Windows 容器**表示具有进程隔离能力的 Windows 容器。
|
||||
Kubernetes 不支持使用
|
||||
[Hyper-V 隔离能力](https://docs.microsoft.com/zh-cn/virtualization/windowscontainers/manage-containers/hyperv-container)来运行
|
||||
Windows 容器。
|
||||
|
||||
<!--
|
||||
## Compatibility and limitations {#limitations}
|
||||
|
||||
Some node features are only available if you use a specific
|
||||
[container runtime](#container-runtime); others are not available on Windows nodes,
|
||||
including:
|
||||
|
||||
* HugePages: not supported for Windows containers
|
||||
* Privileged containers: not supported for Windows containers.
|
||||
[HostProcess Containers](/docs/tasks/configure-pod-container/create-hostprocess-pod/) offer similar functionality.
|
||||
* TerminationGracePeriod: requires containerD
|
||||
-->
|
||||
## 兼容性与局限性 {#limitations}
|
||||
|
||||
某些节点层面的功能特性仅在使用特定[容器运行时](#container-runtime)时才可用；
|
||||
另外一些特性则在 Windows 节点上不可用，包括：
|
||||
|
||||
* 巨页（HugePages）：Windows 容器当前不支持。
|
||||
* 特权容器：Windows 容器当前不支持。
|
||||
[HostProcess 容器](/zh/docs/tasks/configure-pod-container/create-hostprocess-pod/)提供类似功能。
|
||||
* TerminationGracePeriod：需要 containerD。
|
||||
|
||||
<!--
|
||||
Not all features of shared namespaces are supported. See [API compatibility](#api)
|
||||
for more details.
|
||||
|
||||
See [Windows OS version compatibility](#windows-os-version-support) for details on
|
||||
the Windows versions that Kubernetes is tested against.
|
||||
|
||||
From an API and kubectl perspective, Windows containers behave in much the same
|
||||
way as Linux-based containers. However, there are some notable differences in key
|
||||
functionality which are outlined in this section.
|
||||
-->
|
||||
Windows 节点并不支持共享命名空间的所有功能特性。
|
||||
有关更多详细信息，请参考 [API 兼容性](#api)。
|
||||
|
||||
有关 Kubernetes 测试时所使用的 Windows 版本的详细信息，请参考 [Windows 操作系统版本兼容性](#windows-os-version-support)。
|
||||
|
||||
从 API 和 kubectl 的角度来看，Windows 容器的行为与基于 Linux 的容器非常相似。
|
||||
然而，在本节所概述的一些关键功能上，二者存在一些显著差异。
|
||||
|
||||
<!--
|
||||
### Comparison with Linux {#compatibility-linux-similarities}
|
||||
|
||||
Key Kubernetes elements work the same way in Windows as they do in Linux. This
|
||||
section refers to several key workload abstractions and how they map to Windows.
|
||||
-->
|
||||
### 与 Linux 比较 {#comparison-with-Linux-similarities}
|
||||
|
||||
Kubernetes 关键组件在 Windows 上的工作方式与在 Linux 上相同。
|
||||
本节介绍几个关键的工作负载抽象及其如何映射到 Windows。
|
||||
|
||||
<!--
|
||||
* [Pods](/docs/concepts/workloads/pods/)
|
||||
|
||||
A Pod is the basic building block of Kubernetes–the smallest and simplest unit in
|
||||
the Kubernetes object model that you create or deploy. You may not deploy Windows and
|
||||
Linux containers in the same Pod. All containers in a Pod are scheduled onto a single
|
||||
Node where each Node represents a specific platform and architecture. The following
|
||||
Pod capabilities, properties and events are supported with Windows containers:
|
||||
* Single or multiple containers per Pod with process isolation and volume sharing
|
||||
* Pod `status` fields
|
||||
* Readiness, liveness, and startup probes
|
||||
* postStart & preStop container lifecycle hooks
|
||||
* ConfigMap, Secrets: as environment variables or volumes
|
||||
* `emptyDir` volumes
|
||||
* Named pipe host mounts
|
||||
* Resource limits
|
||||
* OS field:
|
||||
The `.spec.os.name` field should be set to `windows` to indicate that the current Pod uses Windows containers.
|
||||
The `IdentifyPodOS` feature gate needs to be enabled for this field to be recognized.
|
||||
|
||||
{{< note >}}
|
||||
Starting from 1.24, the `IdentifyPodOS` feature gate is in Beta stage and defaults to be enabled.
|
||||
{{< /note >}}
|
||||
|
||||
If the `IdentifyPodOS` feature gate is enabled and you set the `.spec.os.name` field to `windows`,
|
||||
you must not set the following fields in the `.spec` of that Pod:
|
||||
In the above list, wildcards (`*`) indicate all elements in a list.
|
||||
For example, `spec.containers[*].securityContext` refers to the SecurityContext object
|
||||
for all containers. If any of these fields is specified, the Pod will
|
||||
not be admited by the API server.
|
||||
-->
|
||||
* [Pod](/zh/docs/concepts/workloads/pods/)
|
||||
|
||||
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` 特性门控才能让这个字段被识别。
|
||||
|
||||
{{< note >}}
|
||||
从 1.24 开始，`IdentifyPodOS` 特性门控进入 Beta 阶段，默认启用。
|
||||
{{< /note >}}
|
||||
|
||||
如果 `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。
|
||||
|
||||
<!--
|
||||
* [Workload resources](/docs/concepts/workloads/controllers/) including:
|
||||
* ReplicaSet
|
||||
* Deployment
|
||||
* StatefulSet
|
||||
* DaemonSet
|
||||
* Job
|
||||
* CronJob
|
||||
* ReplicationController
|
||||
* {{< glossary_tooltip text="Services" term_id="service" >}}
|
||||
See [Load balancing and Services](#load-balancing-and-services) for more details.
|
||||
-->
|
||||
* [工作负载资源](/zh/docs/concepts/workloads/controllers/)包括：
|
||||
|
||||
* ReplicaSet
|
||||
* Deployment
|
||||
* StatefulSet
|
||||
* DaemonSet
|
||||
* Job
|
||||
* CronJob
|
||||
* ReplicationController
|
||||
|
||||
* {{< glossary_tooltip text="Services" term_id="service" >}}
|
||||
|
||||
有关更多详细信息，请参考[负载均衡和 Service](#load-balancing-and-services)。
|
||||
|
||||
<!--
|
||||
Pods, workload resources, and Services are critical elements to managing Windows
|
||||
workloads on Kubernetes. However, on their own they are not enough to enable
|
||||
the proper lifecycle management of Windows workloads in a dynamic cloud native
|
||||
environment. Kubernetes also supports:
|
||||
|
||||
* `kubectl exec`
|
||||
* Pod and container metrics
|
||||
* {{< glossary_tooltip text="Horizontal pod autoscaling" term_id="horizontal-pod-autoscaler" >}}
|
||||
* {{< glossary_tooltip text="Resource quotas" term_id="resource-quota" >}}
|
||||
* Scheduler preemption
|
||||
-->
|
||||
Pod、工作负载资源和 Service 是在 Kubernetes 上管理 Windows 工作负载的关键元素。
|
||||
然而，它们本身还不足以在动态的云原生环境中对 Windows 工作负载进行恰当的生命周期管理。
|
||||
Kubernetes 还支持：
|
||||
|
||||
* `kubectl exec`
|
||||
* Pod 和容器度量指标
|
||||
* {{< glossary_tooltip text="Pod 水平自动扩缩容" term_id="horizontal-pod-autoscaler" >}}
|
||||
* {{< glossary_tooltip text="资源配额" term_id="resource-quota" >}}
|
||||
* 调度器抢占
|
||||
|
||||
<!--
|
||||
### Command line options for the kubelet {#kubelet-compatibility}
|
||||
|
||||
Some kubelet command line options behave differently on Windows, as described below:
|
||||
-->
|
||||
### kubelet 的命令行选项 {#kubelet-compatibility}
|
||||
|
||||
某些 kubelet 命令行选项在 Windows 上的行为不同，如下所述：
|
||||
|
||||
<!--
|
||||
* The `--windows-priorityclass` lets you set the scheduling priority of the kubelet process
|
||||
(see [CPU resource management](/docs/concepts/configuration/windows-resource-management/#resource-management-cpu))
|
||||
* The `--kubelet-reserve`, `--system-reserve` , and `--eviction-hard` flags update
|
||||
[NodeAllocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
|
||||
* Eviction by using `--enforce-node-allocable` is not implemented
|
||||
* Eviction by using `--eviction-hard` and `--eviction-soft` are not implemented
|
||||
* When running on a Windows node the kubelet does not have memory or CPU
|
||||
restrictions. `--kube-reserved` and `--system-reserved` only subtract from `NodeAllocatable`
|
||||
and do not guarantee resource provided for workloads.
|
||||
See [Resource Management for Windows nodes](/docs/concepts/configuration/windows-resource-management/#resource-reservation)
|
||||
for more information.
|
||||
* The `MemoryPressure` Condition is not implemented
|
||||
* The kubelet does not take OOM eviction actions
|
||||
-->
|
||||
* `--windows-priorityclass` 允许你设置 kubelet 进程的调度优先级
|
||||
（参考 [CPU 资源管理](/zh/docs/concepts/configuration/windows-resource-management/#resource-management-cpu)）。
|
||||
* `--kubelet-reserve`、`--system-reserve` 和 `--eviction-hard` 标志更新
|
||||
[NodeAllocatable](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)。
|
||||
* 未实现使用 `--enforce-node-allocable` 驱逐。
|
||||
* 未实现使用 `--eviction-hard` 和 `--eviction-soft` 驱逐。
|
||||
* 在 Windows 节点上运行时，kubelet 没有内存或 CPU 限制。
|
||||
`--kube-reserved` 和 `--system-reserved` 仅从 `NodeAllocatable` 中减去，并且不保证为工作负载提供的资源。
|
||||
有关更多信息，请参考 [Windows 节点的资源管理](/zh/docs/concepts/configuration/windows-resource-management/#resource-reservation)。
|
||||
* 未实现 `MemoryPressure` 条件。
|
||||
* kubelet 不会执行 OOM 驱逐操作。
|
||||
|
||||
<!--
|
||||
### API compatibility {#api}
|
||||
|
||||
There are subtle differences in the way the Kubernetes APIs work for Windows due to the OS
|
||||
and container runtime. Some workload properties were designed for Linux, and fail to run on Windows.
|
||||
|
||||
At a high level, these OS concepts are different:
|
||||
-->
|
||||
### API 兼容性 {#api}
|
||||
|
||||
由于操作系统和容器运行时的缘故，Kubernetes API 在 Windows 上的工作方式存在细微差异。
|
||||
某些工作负载属性是为 Linux 设计的，无法在 Windows 上运行。
|
||||
|
||||
从较高的层面来看，以下操作系统概念是不同的：
|
||||
|
||||
<!--
|
||||
* Identity - Linux uses userID (UID) and groupID (GID) which
|
||||
are represented as integer types. User and group names
|
||||
are not canonical - they are just an alias in `/etc/groups`
|
||||
or `/etc/passwd` back to UID+GID. Windows uses a larger binary
|
||||
[security identifier](https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/security-identifiers) (SID)
|
||||
which is stored in the Windows Security Access Manager (SAM) database. This
|
||||
database is not shared between the host and containers, or between containers.
|
||||
* File permissions - Windows uses an access control list based on (SIDs), whereas
|
||||
POSIX systems such as Linux use a bitmask based on object permissions and UID+GID,
|
||||
plus _optional_ access control lists.
|
||||
* File paths - the convention on Windows is to use `\` instead of `/`. The Go IO
|
||||
libraries typically accept both and just make it work, but when you're setting a
|
||||
path or command line that's interpreted inside a container, `\` may be needed.
|
||||
-->
|
||||
* 身份 - Linux 使用 userID（UID）和 groupID（GID），表示为整数类型。
|
||||
用户名和组名是不规范的，它们只是 `/etc/groups` 或 `/etc/passwd` 中的别名，
|
||||
作为 UID+GID 的后备标识。
|
||||
Windows 使用更大的二进制[安全标识符](https://docs.microsoft.com/zh-cn/windows/security/identity-protection/access-control/security-identifiers)（SID），
|
||||
存放在 Windows 安全访问管理器（Security Access Manager，SAM）数据库中。
|
||||
此数据库在主机和容器之间或容器之间不共享。
|
||||
* 文件权限 - Windows 使用基于 SID 的访问控制列表，
|
||||
而像 Linux 使用基于对象权限和 UID+GID 的位掩码（POSIX 系统）以及**可选的**访问控制列表。
|
||||
* 文件路径 - Windows 上的约定是使用 `\` 而不是 `/`。
|
||||
Go IO 库通常接受两者，能让其正常工作，但当你设置要在容器内解读的路径或命令行时，
|
||||
可能需要用 `\`。
|
||||
|
||||
<!--
|
||||
* Signals - Windows interactive apps handle termination differently, and can
|
||||
implement one or more of these:
|
||||
* A UI thread handles well-defined messages including `WM_CLOSE`.
|
||||
* Console apps handle Ctrl-C or Ctrl-break using a Control Handler.
|
||||
* Services register a Service Control Handler function that can accept
|
||||
`SERVICE_CONTROL_STOP` control codes.
|
||||
Container exit codes follow the same convention where 0 is success, and nonzero is failure.
|
||||
The specific error codes may differ across Windows and Linux. However, exit codes
|
||||
passed from the Kubernetes components (kubelet, kube-proxy) are unchanged.
|
||||
-->
|
||||
* 信号 - Windows 交互式应用处理终止的方式不同，可以实现以下一种或多种：
|
||||
* UI 线程处理包括 `WM_CLOSE` 在内准确定义的消息。
|
||||
* 控制台应用使用控制处理程序（Control Handler）处理 Ctrl-C 或 Ctrl-Break。
|
||||
* 服务会注册可接受 `SERVICE_CONTROL_STOP` 控制码的服务控制处理程序（Service Control Handler）函数。
|
||||
|
||||
容器退出码遵循相同的约定，其中 0 表示成功，非零表示失败。
|
||||
具体的错误码在 Windows 和 Linux 中可能不同。
|
||||
但是，从 Kubernetes 组件（kubelet、kube-proxy）传递的退出码保持不变。
|
||||
|
||||
<!--
|
||||
##### Field compatibility for container specifications {#compatibility-v1-pod-spec-containers}
|
||||
|
||||
The following list documents differences between how Pod container specifications
|
||||
work between Windows and Linux:
|
||||
|
||||
* Huge pages are not implemented in the Windows container
|
||||
runtime, and are not available. They require [asserting a user
|
||||
privilege](https://docs.microsoft.com/en-us/windows/desktop/Memory/large-page-support)
|
||||
that's not configurable for containers.
|
||||
* `requests.cpu` and `requests.memory` - requests are subtracted
|
||||
from node available resources, so they can be used to avoid overprovisioning a
|
||||
node. However, they cannot be used to guarantee resources in an overprovisioned
|
||||
node. They should be applied to all containers as a best practice if the operator
|
||||
wants to avoid overprovisioning entirely.
|
||||
-->
|
||||
##### 容器规范的字段兼容性 {#compatibility-v1-pod-spec-containers}
|
||||
|
||||
以下列表记录了 Pod 容器规范在 Windows 和 Linux 之间的工作方式差异：
|
||||
|
||||
* 巨页（Huge page）在 Windows 容器运行时中未实现，且不可用。
|
||||
巨页需要不可为容器配置的[用户特权生效](https://docs.microsoft.com/zh-cn/windows/win32/memory/large-page-support)。
|
||||
* `requests.cpu` 和 `requests.memory` -
|
||||
从节点可用资源中减去请求，因此请求可用于避免一个节点过量供应。
|
||||
但是，请求不能用于保证已过量供应的节点中的资源。
|
||||
如果运营商想要完全避免过量供应，则应将设置请求作为最佳实践应用到所有容器。
|
||||
<!--
|
||||
* `securityContext.allowPrivilegeEscalation` -
|
||||
not possible on Windows; none of the capabilities are hooked up
|
||||
* `securityContext.capabilities` -
|
||||
POSIX capabilities are not implemented on Windows
|
||||
* `securityContext.privileged` -
|
||||
Windows doesn't support privileged containers
|
||||
* `securityContext.procMount` -
|
||||
Windows doesn't have a `/proc` filesystem
|
||||
* `securityContext.readOnlyRootFilesystem` -
|
||||
not possible on Windows; write access is required for registry & system
|
||||
processes to run inside the container
|
||||
* `securityContext.runAsGroup` -
|
||||
not possible on Windows as there is no GID support
|
||||
-->
|
||||
* `securityContext.allowPrivilegeEscalation` -
|
||||
不能在 Windows 上使用；所有权能字都无法生效。
|
||||
* `securityContext.capabilities` - POSIX 权能未在 Windows 上实现。
|
||||
* `securityContext.privileged` - Windows 不支持特权容器。
|
||||
* `securityContext.procMount` - Windows 没有 `/proc` 文件系统。
|
||||
* `securityContext.readOnlyRootFilesystem` -
|
||||
不能在 Windows 上使用；对于容器内运行的注册表和系统进程，写入权限是必需的。
|
||||
* `securityContext.runAsGroup` - 不能在 Windows 上使用，因为不支持 GID。
|
||||
<!--
|
||||
* `securityContext.runAsNonRoot` -
|
||||
this setting will prevent containers from running as `ContainerAdministrator`
|
||||
which is the closest equivalent to a root user on Windows.
|
||||
* `securityContext.runAsUser` -
|
||||
use [`runAsUserName`](/docs/tasks/configure-pod-container/configure-runasusername)
|
||||
instead
|
||||
* `securityContext.seLinuxOptions` -
|
||||
not possible on Windows as SELinux is Linux-specific
|
||||
* `terminationMessagePath` -
|
||||
this has some limitations in that Windows doesn't support mapping single files. The
|
||||
default value is `/dev/termination-log`, which does work because it does not
|
||||
exist on Windows by default.
|
||||
-->
|
||||
* `securityContext.runAsNonRoot` -
|
||||
此设置将阻止以 `ContainerAdministrator` 身份运行容器，这是 Windows 上与 root 用户最接近的身份。
|
||||
* `securityContext.runAsUser` - 改用 [`runAsUserName`](/zh/docs/tasks/configure-pod-container/configure-runasusername)。
|
||||
* `securityContext.seLinuxOptions` - 不能在 Windows 上使用，因为 SELinux 特定于 Linux。
|
||||
* `terminationMessagePath` - 这个字段有一些限制，因为 Windows 不支持映射单个文件。
|
||||
默认值为 `/dev/termination-log`，因为默认情况下它在 Windows 上不存在，所以能生效。
|
||||
|
||||
<!--
|
||||
##### Field compatibility for Pod specifications {#compatibility-v1-pod}
|
||||
|
||||
The following list documents differences between how Pod specifications work between Windows and Linux:
|
||||
|
||||
* `hostIPC` and `hostpid` - host namespace sharing is not possible on Windows
|
||||
* `hostNetwork` - There is no Windows OS support to share the host network
|
||||
* `dnsPolicy` - setting the Pod `dnsPolicy` to `ClusterFirstWithHostNet` is
|
||||
not supported on Windows because host networking is not provided. Pods always
|
||||
run with a container network.
|
||||
* `podSecurityContext` (see below)
|
||||
* `shareProcessNamespace` - this is a beta feature, and depends on Linux namespaces
|
||||
which are not implemented on Windows. Windows cannot share process namespaces or
|
||||
the container's root filesystem. Only the network can be shared.
|
||||
-->
|
||||
##### Pod 规范的字段兼容性 {#compatibility-v1-pod}
|
||||
|
||||
以下列表记录了 Pod 规范在 Windows 和 Linux 之间的工作方式差异：
|
||||
|
||||
* `hostIPC` 和 `hostpid` - 不能在 Windows 上共享主机命名空间。
|
||||
* `hostNetwork` - Windows 操作系统不支持共享主机网络。
|
||||
* `dnsPolicy` - Windows 不支持将 Pod `dnsPolicy` 设为 `ClusterFirstWithHostNet`，
|
||||
因为未提供主机网络。Pod 始终用容器网络运行。
|
||||
* `podSecurityContext`（参见下文）
|
||||
* `shareProcessNamespace` - 这是一个 beta 版功能特性，依赖于 Windows 上未实现的 Linux 命名空间。
|
||||
Windows 无法共享进程命名空间或容器的根文件系统（root filesystem）。
|
||||
只能共享网络。
|
||||
<!--
|
||||
* `terminationGracePeriodSeconds` - this is not fully implemented in Docker on Windows,
|
||||
see the [GitHub issue](https://github.com/moby/moby/issues/25982).
|
||||
The behavior today is that the ENTRYPOINT process is sent CTRL_SHUTDOWN_EVENT,
|
||||
then Windows waits 5 seconds by default, and finally shuts down
|
||||
all processes using the normal Windows shutdown behavior. The 5
|
||||
second default is actually in the Windows registry
|
||||
[inside the container](https://github.com/moby/moby/issues/25982#issuecomment-426441183),
|
||||
so it can be overridden when the container is built.
|
||||
* `volumeDevices` - this is a beta feature, and is not implemented on Windows.
|
||||
Windows cannot attach raw block devices to pods.
|
||||
* `volumes`
|
||||
* If you define an `emptyDir` volume, you cannot set its volume source to `memory`.
|
||||
* You cannot enable `mountPropagation` for volume mounts as this is not
|
||||
supported on Windows.
|
||||
-->
|
||||
* `terminationGracePeriodSeconds` - 这在 Windows 上的 Docker 中没有完全实现，
|
||||
请参考[GitHub issue](https://github.com/moby/moby/issues/25982)。
|
||||
目前的行为是通过 CTRL_SHUTDOWN_EVENT 发送 ENTRYPOINT 进程，然后 Windows 默认等待 5 秒，
|
||||
最后使用正常的 Windows 关机行为终止所有进程。
|
||||
5 秒默认值实际上位于[容器内](https://github.com/moby/moby/issues/25982#issuecomment-426441183)的 Windows 注册表中，
|
||||
因此在构建容器时可以覆盖这个值。
|
||||
* `volumeDevices` - 这是一个 beta 版功能特性，未在 Windows 上实现。
|
||||
Windows 无法将原始块设备挂接到 Pod。
|
||||
* `volumes`
|
||||
* 如果你定义一个 `emptyDir` 卷，则你无法将卷源设为 `memory`。
|
||||
* 你无法为卷挂载启用 `mountPropagation`，因为这在 Windows 上不支持。
|
||||
|
||||
<!--
|
||||
##### Field compatibility for Pod security context {#compatibility-v1-pod-spec-containers-securitycontext}
|
||||
|
||||
None of the Pod [`securityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context) fields work on Windows.
|
||||
-->
|
||||
##### Pod 安全上下文的字段兼容性 {#compatibility-v1-pod-spec-containers-securitycontext}
|
||||
|
||||
Pod 的所有 [`securityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context)
|
||||
字段都无法在 Windows 上生效。
|
||||
|
||||
<!--
|
||||
## Node problem detector
|
||||
|
||||
The node problem detector (see
|
||||
[Monitor Node Health](/docs/tasks/debug/debug-cluster/monitor-node-health/))
|
||||
has preliminary support for Windows.
|
||||
For more information, visit the project's [GitHub page](https://github.com/kubernetes/node-problem-detector#windows).
|
||||
-->
|
||||
## 节点问题检测器 {#node-problem-detector}
|
||||
|
||||
节点问题检测器（参考[节点健康监测](/zh/docs/tasks/debug/debug-cluster/monitor-node-health/)）初步支持 Windows。
|
||||
有关更多信息，请访问该项目的 [GitHub 页面](https://github.com/kubernetes/node-problem-detector#windows)。
|
||||
|
||||
<!--
|
||||
### Pause container
|
||||
|
||||
In a Kubernetes Pod, an infrastructure or “pause” container is first created
|
||||
to host the container. In Linux, the cgroups and namespaces that make up a pod
|
||||
need a process to maintain their continued existence; the pause process provides
|
||||
this. Containers that belong to the same pod, including infrastructure and worker
|
||||
containers, share a common network endpoint (same IPv4 and / or IPv6 address, same
|
||||
network port spaces). Kubernetes uses pause containers to allow for worker containers
|
||||
crashing or restarting without losing any of the networking configuration.
|
||||
-->
|
||||
### Pause 容器 {#pause-container}
|
||||
|
||||
在 Kubernetes Pod 中，首先创建一个基础容器或 “pause” 容器来承载容器。
|
||||
在 Linux 中，构成 Pod 的 cgroup 和命名空间维持持续存在需要一个进程；
|
||||
而 pause 进程就提供了这个功能。
|
||||
属于同一 Pod 的容器（包括基础容器和工作容器）共享一个公共网络端点
|
||||
（相同的 IPv4 和/或 IPv6 地址，相同的网络端口空间）。
|
||||
Kubernetes 使用 pause 容器以允许工作容器崩溃或重启，而不会丢失任何网络配置。
|
||||
|
||||
<!--
|
||||
Kubernetes maintains a multi-architecture image that includes support for Windows.
|
||||
For Kubernetes v{{< skew currentVersion >}} the recommended pause image is `k8s.gcr.io/pause:3.6`.
|
||||
The [source code](https://github.com/kubernetes/kubernetes/tree/master/build/pause)
|
||||
is available on GitHub.
|
||||
|
||||
Microsoft maintains a different multi-architecture image, with Linux and Windows
|
||||
amd64 support, that you can find as `mcr.microsoft.com/oss/kubernetes/pause:3.6`.
|
||||
This image is built from the same source as the Kubernetes maintained image but
|
||||
all of the Windows binaries are [authenticode signed](https://docs.microsoft.com/en-us/windows-hardware/drivers/install/authenticode) by Microsoft.
|
||||
The Kubernetes project recommends using the Microsoft maintained image if you are
|
||||
deploying to a production or production-like environment that requires signed
|
||||
binaries.
|
||||
-->
|
||||
Kubernetes 维护一个多体系结构的镜像，包括对 Windows 的支持。
|
||||
对于 Kubernetes v{{< skew currentVersion >}}，推荐的 pause 镜像为 `k8s.gcr.io/pause:3.6`。
|
||||
可在 GitHub 上获得[源代码](https://github.com/kubernetes/kubernetes/tree/master/build/pause)。
|
||||
|
||||
Microsoft 维护一个不同的多体系结构镜像，支持 Linux 和 Windows amd64，
|
||||
你可以找到的镜像类似 `mcr.microsoft.com/oss/kubernetes/pause:3.6`。
|
||||
此镜像的构建与 Kubernetes 维护的镜像同源，但所有 Windows 可执行文件均由
|
||||
Microsoft 进行了[验证码签名](https://docs.microsoft.com/zh-cn/windows-hardware/drivers/install/authenticode)。
|
||||
如果你正部署到一个需要签名可执行文件的生产或类生产环境，
|
||||
Kubernetes 项目建议使用 Microsoft 维护的镜像。
|
||||
|
||||
<!--
|
||||
### Container runtimes {#container-runtime}
|
||||
|
||||
You need to install a
|
||||
{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}
|
||||
into each node in the cluster so that Pods can run there.
|
||||
|
||||
The following container runtimes work with Windows:
|
||||
-->
|
||||
### 容器运行时 {#container-runtime}
|
||||
|
||||
你需要将{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}安装到集群中的每个节点，
|
||||
这样 Pod 才能在这些节点上运行。
|
||||
|
||||
以下容器运行时适用于 Windows：
|
||||
|
||||
{{% thirdparty-content %}}
|
||||
|
||||
<!--
|
||||
#### ContainerD
|
||||
|
||||
{{< feature-state for_k8s_version="v1.20" state="stable" >}}
|
||||
|
||||
You can use {{< glossary_tooltip term_id="containerd" text="ContainerD" >}} 1.4.0+
|
||||
as the container runtime for Kubernetes nodes that run Windows.
|
||||
|
||||
Learn how to [install ContainerD on a Windows node](/docs/setup/production-environment/container-runtimes/#install-containerd).
|
||||
-->
|
||||
#### ContainerD {#containerd}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.20" state="stable" >}}
|
||||
|
||||
对于运行 Windows 的 Kubernetes 节点，你可以使用
|
||||
{{< glossary_tooltip term_id="containerd" text="ContainerD" >}} 1.4.0+ 作为容器运行时。
|
||||
|
||||
学习如何[在 Windows 上安装 ContainerD](/zh/docs/setup/production-environment/container-runtimes/#install-containerd)。
|
||||
|
||||
<!--
|
||||
There is a [known limitation](/docs/tasks/configure-pod-container/configure-gmsa/#gmsa-limitations)
|
||||
when using GMSA with containerd to access Windows network shares, which requires a
|
||||
kernel patch.
|
||||
-->
|
||||
{{< note >}}
|
||||
将 GMSA 和 containerd 一起用于访问 Windows
|
||||
网络共享时存在[已知限制](/zh/docs/tasks/configure-pod-container/configure-gmsa/#gmsa-limitations)，
|
||||
这需要一个内核补丁。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
#### Mirantis Container Runtime {#mcr}
|
||||
|
||||
[Mirantis Container Runtime](https://docs.mirantis.com/mcr/20.10/overview.html) (MCR) is available as a container runtime for all Windows Server 2019 and later versions.
|
||||
|
||||
See [Install MCR on Windows Servers](https://docs.mirantis.com/mcr/20.10/install/mcr-windows.html) for more information.
|
||||
-->
|
||||
#### Mirantis 容器运行时 {#mcr}
|
||||
|
||||
[Mirantis 容器运行时](https://docs.mirantis.com/mcr/20.10/overview.html)（MCR）
|
||||
可作为所有 Windows Server 2019 和更高版本的容器运行时。
|
||||
|
||||
有关更多信息，请参考[在 Windows Server 上安装 MCR](https://docs.mirantis.com/mcr/20.10/install/mcr-windows.html)。
|
||||
|
||||
<!--
|
||||
## Windows OS version compatibility {#windows-os-version-support}
|
||||
|
||||
On Windows nodes, strict compatibility rules apply where the host OS version must
|
||||
match the container base image OS version. Only Windows containers with a container
|
||||
operating system of Windows Server 2019 are fully supported.
|
||||
|
||||
For Kubernetes v{{< skew currentVersion >}}, operating system compatibility for Windows nodes (and Pods)
|
||||
is as follows:
|
||||
-->
|
||||
## Windows 操作系统版本兼容性 {#windows-os-version-support}
|
||||
|
||||
在 Windows 节点上，如果主机操作系统版本必须与容器基础镜像操作系统版本匹配，
|
||||
则会应用严格的兼容性规则。
|
||||
仅 Windows Server 2019 作为容器操作系统时，才能完全支持 Windows 容器。
|
||||
|
||||
对于 Kubernetes v{{< skew currentVersion >}}，Windows 节点（和 Pod）的操作系统兼容性如下：
|
||||
|
||||
Windows Server LTSC release
|
||||
: Windows Server 2019
|
||||
: Windows Server 2022
|
||||
|
||||
Windows Server SAC release
|
||||
: Windows Server version 20H2
|
||||
|
||||
<!--
|
||||
The Kubernetes [version-skew policy](/docs/setup/release/version-skew-policy/) also applies.
|
||||
-->
|
||||
也适用 Kubernetes [版本偏差策略](/zh/docs/setup/release/version-skew-policy/)。
|
||||
|
||||
<!--
|
||||
## Getting help and troubleshooting {#troubleshooting}
|
||||
|
||||
Your main source of help for troubleshooting your Kubernetes cluster should start
|
||||
with the [Troubleshooting](/docs/tasks/debug/)
|
||||
page.
|
||||
|
||||
Some additional, Windows-specific troubleshooting help is included
|
||||
in this section. Logs are an important element of troubleshooting
|
||||
issues in Kubernetes. Make sure to include them any time you seek
|
||||
troubleshooting assistance from other contributors. Follow the
|
||||
instructions in the
|
||||
SIG Windows [contributing guide on gathering logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs).
|
||||
-->
|
||||
## 获取帮助和故障排查 {#troubleshooting}
|
||||
|
||||
对 Kubernetes 集群进行故障排查的主要帮助来源应始于[故障排查](/zh/docs/tasks/debug/)页面。
|
||||
|
||||
本节包括了一些其他特定于 Windows 的故障排查帮助。
|
||||
日志是解决 Kubernetes 中问题的重要元素。
|
||||
确保在任何时候向其他贡献者寻求故障排查协助时随附了日志信息。
|
||||
遵照 SIG Windows
|
||||
[日志收集贡献指南](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)中的指示说明。
|
||||
|
||||
<!--
|
||||
### Reporting issues and feature requests
|
||||
|
||||
If you have what looks like a bug, or you would like to
|
||||
make a feature request, please follow the [SIG Windows contributing guide](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#reporting-issues-and-feature-requests) to create a new issue.
|
||||
You should first search the list of issues in case it was
|
||||
reported previously and comment with your experience on the issue and add additional
|
||||
logs. SIG Windows channel on the Kubernetes Slack is also a great avenue to get some initial support and
|
||||
troubleshooting ideas prior to creating a ticket.
|
||||
-->
|
||||
### 报告问题和功能请求 {#report-issue-and-feature-request}
|
||||
|
||||
如果你发现疑似 bug，或者你想提出功能请求，请按照
|
||||
[SIG Windows 贡献指南](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#reporting-issues-and-feature-requests)
|
||||
新建一个 Issue。
|
||||
你应该先搜索 issue 列表，以防之前报告过这个问题，凭你对该问题的经验添加评论，
|
||||
并随附日志信息。
|
||||
Kubernetes Slack 上的 SIG Windows 频道也是一个很好的途径，
|
||||
可以在创建工单之前获得一些初始支持和故障排查思路。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
### Deployment tools
|
||||
|
||||
The kubeadm tool helps you to deploy a Kubernetes cluster, providing the control
|
||||
plane to manage the cluster it, and nodes to run your workloads.
|
||||
[Adding Windows nodes](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)
|
||||
explains how to deploy Windows nodes to your cluster using kubeadm.
|
||||
|
||||
The Kubernetes [cluster API](https://cluster-api.sigs.k8s.io/) project also provides means to automate deployment of Windows nodes.
|
||||
-->
|
||||
### 部署工具 {#deployment-tools}
|
||||
|
||||
kubeadm 工具帮助你部署 Kubernetes 集群，提供管理集群的控制平面以及运行工作负载的节点。
|
||||
[添加 Windows 节点](/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)阐述了如何使用
|
||||
kubeadm 将 Windows 节点部署到你的集群。
|
||||
|
||||
Kubernetes [集群 API](https://cluster-api.sigs.k8s.io/) 项目也提供了自动部署 Windows 节点的方式。
|
||||
|
||||
<!--
|
||||
### Windows distribution channels
|
||||
|
||||
For a detailed explanation of Windows distribution channels see the [Microsoft documentation](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19).
|
||||
|
||||
Information on the different Windows Server servicing channels
|
||||
including their support models can be found at
|
||||
[Windows Server servicing channels](https://docs.microsoft.com/en-us/windows-server/get-started/servicing-channels-comparison).
|
||||
-->
|
||||
### Windows 分发渠道 {#windows-distribution-channels}
|
||||
|
||||
有关 Windows 分发渠道的详细阐述，请参考
|
||||
[Microsoft 文档](https://docs.microsoft.com/zh-cn/windows-server/get-started-19/servicing-channels-19)。
|
||||
|
||||
有关支持模型在内的不同 Windows Server 服务渠道的信息，请参考
|
||||
[Windows Server 服务渠道](https://docs.microsoft.com/zh-cn/windows-server/get-started/servicing-channels-comparison)。
|
||||
@@ -0,0 +1,482 @@
|
||||
---
|
||||
title: Kubernetes 中的 Windows 容器调度指南
|
||||
content_type: concept
|
||||
weight: 75
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- jayunit100
|
||||
- jsturtevant
|
||||
- marosset
|
||||
title: Guide for scheduling Windows containers in Kubernetes
|
||||
content_type: concept
|
||||
weight: 75
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
Windows applications constitute a large portion of the services and applications that run in many organizations.
|
||||
This guide walks you through the steps to configure and deploy Windows containers in Kubernetes.
|
||||
-->
|
||||
在许多组织中运行的服务和应用程序中，Windows 应用程序构成了很大一部分。
|
||||
本指南将引导你完成在 Kubernetes 中配置和部署 Windows 容器的步骤。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Objectives
|
||||
|
||||
* Configure an example deployment to run Windows containers on the Windows node
|
||||
* Highlight Windows specific funcationality in Kubernetes
|
||||
-->
|
||||
## 目标 {#objectives}
|
||||
|
||||
* 配置 Deployment 样例以在 Windows 节点上运行 Windows 容器
|
||||
* 在 Kubernetes 中突出 Windows 特定的功能
|
||||
|
||||
<!--
|
||||
## Before you begin
|
||||
|
||||
* Create a Kubernetes cluster that includes a
|
||||
control plane and a [worker node running Windows Server](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)
|
||||
* It is important to note that creating and deploying services and workloads on Kubernetes
|
||||
behaves in much the same way for Linux and Windows containers.
|
||||
[Kubectl commands](/docs/reference/kubectl/) to interface with the cluster are identical.
|
||||
The example in the section below is provided to jumpstart your experience with Windows containers.
|
||||
-->
|
||||
## 在你开始之前 {#before-you-begin}
|
||||
|
||||
* 创建一个 Kubernetes 集群，其中包含一个控制平面和一个[运行 Windows Server 的工作节点](/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)
|
||||
* 务必请注意，在 Kubernetes 上创建和部署服务和工作负载的行为方式与 Linux 和 Windows 容器的行为方式大致相同。
|
||||
与集群交互的 [kubectl 命令](/zh/docs/reference/kubectl/)是一致的。
|
||||
下一小节的示例旨在帮助你快速开始使用 Windows 容器。
|
||||
|
||||
<!--
|
||||
## Getting Started: Deploying a Windows container
|
||||
|
||||
The example YAML file below deploys a simple webserver application running inside a Windows container.
|
||||
|
||||
Create a service spec named `win-webserver.yaml` with the contents below:
|
||||
-->
|
||||
## 快速开始：部署 Windows 容器 {#getting-started-deploying-a-windows-container}
|
||||
|
||||
以下示例 YAML 文件部署了一个在 Windows 容器内运行的简单 Web 服务器的应用程序。
|
||||
|
||||
创建一个名为 `win-webserver.yaml` 的 Service 规约，其内容如下：
|
||||
|
||||
```yaml
|
||||
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
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Port mapping is also supported, but for simplicity this example exposes
|
||||
port 80 of the container directly to the Service.
|
||||
-->
|
||||
端口映射也是支持的，但为简单起见，此示例将容器的端口 80 直接暴露给服务。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
1. Check that all nodes are healthy:
|
||||
-->
|
||||
1. 检查所有节点是否健康
|
||||
|
||||
```bash
|
||||
kubectl get nodes
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Deploy the service and watch for pod updates:
|
||||
-->
|
||||
1. 部署 Service 并监视 Pod 更新：
|
||||
|
||||
```bash
|
||||
kubectl apply -f win-webserver.yaml
|
||||
kubectl get pods -o wide -w
|
||||
```
|
||||
|
||||
<!--
|
||||
When the service is deployed correctly both Pods are marked as Ready. To exit the watch command, press Ctrl+C.
|
||||
-->
|
||||
当 Service 被正确部署时，两个 Pod 都被标记为就绪（Ready）。要退出 watch 命令，请按 Ctrl+C。
|
||||
|
||||
<!--
|
||||
1. Check that the deployment succeeded. To verify:
|
||||
|
||||
* Two pods listed from the Linux control plane node, use `kubectl get pods`
|
||||
* Node-to-pod communication across the network, `curl` port 80 of your pod IPs from the Linux control plane node
|
||||
to check for a web server response
|
||||
* Pod-to-pod communication, ping between pods (and across hosts, if you have more than one Windows node)
|
||||
using docker exec or kubectl exec
|
||||
* Service-to-pod communication, `curl` the virtual service IP (seen under `kubectl get services`)
|
||||
from the Linux control plane node and from individual pods
|
||||
* Service discovery, `curl` the service name with the Kubernetes [default DNS suffix](/docs/concepts/services-networking/dns-pod-service/#services)
|
||||
* Inbound connectivity, `curl` the NodePort from the Linux control plane node or machines outside of the cluster
|
||||
* Outbound connectivity, `curl` external IPs from inside the pod using kubectl exec
|
||||
-->
|
||||
1. 检查部署是否成功。请验证：
|
||||
|
||||
* 使用 `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` 下查看）
|
||||
* 服务发现，使用 Kubernetes [默认 DNS 后缀](/zh/docs/concepts/services-networking/dns-pod-service/#services)的服务名称，
|
||||
用 `curl` 访问服务名称
|
||||
* 入站连接，在 Linux 控制平面节点或集群外的机器上执行 `curl` 来访问 NodePort 服务
|
||||
* 出站连接，使用 kubectl exec，从 Pod 内部执行 `curl` 访问外部 IP
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Windows container hosts are not able to access the IP of services scheduled on them due to current platform limitations of the Windows networking stack.
|
||||
Only Windows pods are able to access service IPs.
|
||||
-->
|
||||
由于当前 Windows 平台的网络堆栈限制，Windows 容器主机无法访问调度到其上的 Service 的 IP。
|
||||
只有 Windows Pod 能够访问 Service IP。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## Observability
|
||||
|
||||
### Capturing logs from workloads
|
||||
|
||||
Logs are an important element of observability; they enable users to gain insights
|
||||
into the operational aspect of workloads and are a key ingredient to troubleshooting issues.
|
||||
Because Windows containers and workloads inside Windows containers behave differently from Linux containers,
|
||||
users had a hard time collecting logs, limiting operational visibility.
|
||||
Windows workloads for example are usually configured to log to ETW (Event Tracing for Windows)
|
||||
or push entries to the application event log.
|
||||
[LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor), an open source tool by Microsoft,
|
||||
is the recommended way to monitor configured log sources inside a Windows container.
|
||||
LogMonitor supports monitoring event logs, ETW providers, and custom application logs,
|
||||
piping them to STDOUT for consumption by `kubectl logs <pod>`.
|
||||
|
||||
Follow the instructions in the LogMonitor GitHub page to copy its binaries and configuration files
|
||||
to all your containers and add the necessary entrypoints for LogMonitor to push your logs to STDOUT.
|
||||
-->
|
||||
## 可观察性 {#observability}
|
||||
|
||||
### 捕捉来自工作负载的日志 {#capturing-logs-from-workloads}
|
||||
|
||||
日志是可观察性的重要元素；它们使用户能够深入了解工作负载的运行情况，并且是解决问题的关键因素。
|
||||
由于 Windows 容器和 Windows 容器中的工作负载与 Linux 容器的行为不同，因此用户很难收集日志，从而限制了操作可见性。
|
||||
例如，Windows 工作负载通常配置为记录到 ETW（Windows 事件跟踪）或向应用程序事件日志推送条目。
|
||||
[LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor)
|
||||
是一个微软开源的工具，是监视 Windows 容器内所配置的日志源的推荐方法。
|
||||
LogMonitor 支持监视事件日志、ETW 提供程序和自定义应用程序日志，将它们传送到 STDOUT 以供 `kubectl logs <pod>` 使用。
|
||||
|
||||
按照 LogMonitor GitHub 页面中的说明，将其二进制文件和配置文件复制到所有容器，
|
||||
并为 LogMonitor 添加必要的入口点以将日志推送到标准输出（STDOUT）。
|
||||
|
||||
<!--
|
||||
## Configuring container user
|
||||
|
||||
### Using configurable Container usernames
|
||||
|
||||
Windows containers can be configured to run their entrypoints and processes
|
||||
with different usernames than the image defaults.
|
||||
Learn more about it [here](/docs/tasks/configure-pod-container/configure-runasusername/).
|
||||
-->
|
||||
## 配置容器用户 {#configuring-container-user}
|
||||
|
||||
### 使用可配置的容器用户名 {#using-configurable-container-usernames}
|
||||
|
||||
Windows 容器可以配置为使用不同于镜像默认值的用户名来运行其入口点和进程。
|
||||
[在这里](/zh/docs/tasks/configure-pod-container/configure-runasusername/)了解更多信息。
|
||||
|
||||
<!--
|
||||
### Managing Workload Identity with Group Managed Service Accounts
|
||||
|
||||
Windows container workloads can be configured to use Group Managed Service Accounts (GMSA).
|
||||
Group Managed Service Accounts are a specific type of Active Directory account that provide automatic password management,
|
||||
simplified service principal name (SPN) management, and the ability to delegate the management to other administrators across multiple servers.
|
||||
Containers configured with a GMSA can access external Active Directory Domain resources while carrying the identity configured with the GMSA.
|
||||
Learn more about configuring and using GMSA for Windows containers [here](/docs/tasks/configure-pod-container/configure-gmsa/).
|
||||
-->
|
||||
### 使用组托管服务帐户（GMSA）管理工作负载身份 {#managing-workload-identity-with-group-managed-service-accounts}
|
||||
|
||||
Windows 容器工作负载可以配置为使用组托管服务帐户（Group Managed Service Accounts，GMSA）。
|
||||
组托管服务帐户是一种特定类型的活动目录（Active Directory）帐户，可提供自动密码管理、
|
||||
简化的服务主体名称（Service Principal Name，SPN）管理，以及将管理委派给多个服务器上的其他管理员的能力。
|
||||
配置了 GMSA 的容器可以携带使用 GMSA 配置的身份访问外部活动目录域资源。
|
||||
在[此处](/zh/docs/tasks/configure-pod-container/configure-gmsa/)了解有关为 Windows 容器配置和使用 GMSA 的更多信息。
|
||||
|
||||
<!--
|
||||
## Taints and Tolerations
|
||||
|
||||
Users need to use some combination of taints and node selectors in order to
|
||||
schedule Linux and Windows workloads to their respective OS-specific nodes.
|
||||
The recommended approach is outlined below,
|
||||
with one of its main goals being that this approach should not break compatibility for existing Linux workloads.
|
||||
|
||||
If the `IdentifyPodOS` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is
|
||||
enabled, you can (and should) set `.spec.os.name` for a Pod to indicate the operating system
|
||||
that the containers in that Pod are designed for. For Pods that run Linux containers, set
|
||||
`.spec.os.name` to `linux`. For Pods that run Windows containers, set `.spec.os.name`
|
||||
to Windows.
|
||||
-->
|
||||
## 污点和容忍度 {#taints-and-tolerations}
|
||||
|
||||
用户需要使用某种污点（Taint）和节点选择器的组合，以便将 Linux 和 Windows 工作负载各自调度到特定操作系统的节点。
|
||||
下面概述了推荐的方法，其主要目标之一是该方法不应破坏现有 Linux 工作负载的兼容性。
|
||||
|
||||
如果启用了 `IdentifyPodOS` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
|
||||
你可以（并且应该）将 Pod 的 `.spec.os.name` 设置为该 Pod 中的容器设计所用于的操作系统。
|
||||
对于运行 Linux 容器的 Pod，将 `.spec.os.name` 设置为 `linux`。
|
||||
对于运行 Windows 容器的 Pod，将 `.spec.os.name` 设置为 `Windows`。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Starting from 1.24, the `IdentifyPodOS` feature is in Beta stage and defaults to be enabled.
|
||||
-->
|
||||
从 1.24 开始，`IdentifyPodOS` 特性处于 Beta 阶段，默认启用。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
The scheduler does not use the value of `.spec.os.name` when assigning Pods to nodes. You should
|
||||
use normal Kubernetes mechanisms for
|
||||
[assigning pods to nodes](/docs/concepts/scheduling-eviction/assign-pod-node/)
|
||||
to ensure that the control plane for your cluster places pods onto nodes that are running the
|
||||
appropriate operating system.
|
||||
|
||||
The `.spec.os.name` value has no effect on the scheduling of the Windows pods,
|
||||
so taints and tolerations and node selectors are still required
|
||||
to ensure that the Windows pods land onto appropriate Windows nodes.
|
||||
-->
|
||||
调度器在将 Pod 分配到节点时并不使用 `.spec.os.name` 的值。
|
||||
你应该使用正常的 Kubernetes 机制[将 Pod 分配给节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)，
|
||||
以确保集群的控制平面将 Pod 放置到运行适当操作系统的节点上。
|
||||
|
||||
`.spec.os.name` 值对 Windows Pod 的调度没有影响，
|
||||
因此仍然需要污点和容忍以及节点选择器来确保 Windows Pod 落在适当的 Windows 节点。
|
||||
|
||||
<!--
|
||||
### Ensuring OS-specific workloads land on the appropriate container host
|
||||
|
||||
Users can ensure Windows containers can be scheduled on the appropriate host using Taints and Tolerations.
|
||||
All Kubernetes nodes today have the following default labels:
|
||||
|
||||
* kubernetes.io/os = [windows|linux]
|
||||
* kubernetes.io/arch = [amd64|arm64|...]
|
||||
-->
|
||||
### 确保特定于操作系统的工作负载落到合适的容器主机上 {#ensuring-os-specific-workloads-land-on-the-appropriate-container-host}
|
||||
|
||||
用户可以使用污点（Taint）和容忍度（Toleration）确保将 Windows 容器调度至合适的主机上。
|
||||
现在，所有的 Kubernetes 节点都有以下默认标签：
|
||||
|
||||
* kubernetes.io/os = [windows|linux]
|
||||
* kubernetes.io/arch = [amd64|arm64|...]
|
||||
|
||||
<!--
|
||||
If a Pod specification does not specify a nodeSelector like `"kubernetes.io/os": windows`,
|
||||
it is possible the Pod can be scheduled on any host, Windows or Linux.
|
||||
This can be problematic since a Windows container can only run on Windows and a Linux container can only run on Linux.
|
||||
The best practice is to use a nodeSelector.
|
||||
-->
|
||||
如果 Pod 规约没有指定像 `"kubernetes.io/os": windows` 这样的 nodeSelector，
|
||||
则 Pod 可以被调度到任何主机上，Windows 或 Linux。
|
||||
这可能会有问题，因为 Windows 容器只能在 Windows 上运行，而 Linux 容器只能在 Linux 上运行。
|
||||
最佳实践是使用 nodeSelector。
|
||||
|
||||
<!--
|
||||
However, we understand that in many cases users have a pre-existing large number of deployments for Linux containers,
|
||||
as well as an ecosystem of off-the-shelf configurations, such as community Helm charts, and programmatic Pod generation cases, such as with Operators.
|
||||
In those situations, you may be hesitant to make the configuration change to add nodeSelectors.
|
||||
The alternative is to use Taints. Because the kubelet can set Taints during registration,
|
||||
it could easily be modified to automatically add a taint when running on Windows only.
|
||||
-->
|
||||
但是，我们了解到，在许多情况下，用户已经预先存在大量 Linux 容器部署，
|
||||
以及现成配置的生态系统，例如社区中的 Helm Chart 包和程序化的 Pod 生成案例，例如 Operator。
|
||||
在这些情况下，你可能不愿更改配置来添加节点选择器。
|
||||
另一种方法是使用污点。因为 kubelet 可以在注册过程中设置污点，
|
||||
所以可以很容易地修改为，当只能在 Windows 上运行时，自动添加污点。
|
||||
|
||||
<!--
|
||||
For example: `--register-with-taints='os=windows:NoSchedule'`
|
||||
|
||||
By adding a taint to all Windows nodes, nothing will be scheduled on them (that includes existing Linux Pods).
|
||||
In order for a Windows Pod to be scheduled on a Windows node,
|
||||
it would need both the nodeSelector and the appropriate matching toleration to choose Windows.
|
||||
-->
|
||||
例如：`--register-with-taints='os=windows:NoSchedule'`
|
||||
|
||||
通过向所有 Windows 节点添加污点，任何负载都不会被调度到这些节点上（包括现有的 Linux Pod）。
|
||||
为了在 Windows 节点上调度 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"
|
||||
```
|
||||
|
||||
<!--
|
||||
### Handling multiple Windows versions in the same cluster
|
||||
|
||||
The Windows Server version used by each pod must match that of the node. If you want to use multiple Windows
|
||||
Server versions in the same cluster, then you should set additional node labels and nodeSelectors.
|
||||
|
||||
Kubernetes 1.17 automatically adds a new label `node.kubernetes.io/windows-build` to simplify this.
|
||||
If you're running an older version, then it's recommended to add this label manually to Windows nodes.
|
||||
|
||||
This label reflects the Windows major, minor, and build number that need to match for compatibility.
|
||||
Here are values used today for each Windows Server version.
|
||||
-->
|
||||
### 处理同一集群中的多个 Windows 版本 {#handling-multiple-windows-versions-in-the-same-cluster}
|
||||
|
||||
每个 Pod 使用的 Windows Server 版本必须与节点的版本匹配。
|
||||
如果要在同一个集群中使用多个 Windows Server 版本，则应设置额外的节点标签和节点选择器。
|
||||
|
||||
Kubernetes 1.17 自动添加了一个新标签 `node.kubernetes.io/windows-build` 来简化这一点。
|
||||
如果你运行的是旧版本，则建议手动将此标签添加到 Windows 节点。
|
||||
|
||||
此标签反映了需要匹配以实现兼容性的 Windows 主要、次要和内部版本号。
|
||||
以下是目前用于每个 Windows Server 版本的值。
|
||||
|
||||
<!--
|
||||
| Product Name | Build Number(s) |
|
||||
-->
|
||||
| 产品名称 | 构建号 |
|
||||
|--------------------------------------|------------------------|
|
||||
| Windows Server 2019 | 10.0.17763 |
|
||||
| Windows Server, Version 20H2 | 10.0.19042 |
|
||||
| Windows Server 2022 | 10.0.20348 |
|
||||
|
||||
<!--
|
||||
### Simplifying with RuntimeClass
|
||||
|
||||
[RuntimeClass] can be used to simplify the process of using taints and tolerations.
|
||||
A cluster administrator can create a `RuntimeClass` object which is used to encapsulate these taints and tolerations.
|
||||
|
||||
1. Save this file to `runtimeClasses.yml`. It includes the appropriate `nodeSelector`
|
||||
for the Windows OS, architecture, and version.
|
||||
-->
|
||||
### 使用 RuntimeClass 进行简化 {#simplifying-with-runtimeclass}
|
||||
|
||||
[RuntimeClass] 可用于简化使用污点和容忍度的流程。
|
||||
集群管理员可以创建一个用于封装这些污点和容忍度的 `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"
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Run `kubectl create -f runtimeClasses.yml` using as a cluster administrator
|
||||
1. Add `runtimeClassName: windows-2019` as appropriate to Pod specs
|
||||
|
||||
For example:
|
||||
-->
|
||||
1. 以集群管理员身份运行 `kubectl create -f runtimeClasses.yml`
|
||||
1. 根据情况，向 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
|
||||
```
|
||||
|
||||
[RuntimeClass]: https://kubernetes.io/docs/concepts/containers/runtime-class/
|
||||
Reference in New Issue
Block a user