[zh] resyn windows pages: windows/intro.md
Michael
Michael
parent
60c0825a7d
commit
a860229153
|
|
@ -0,0 +1,716 @@
|
|||
---
|
||||
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
|
||||
* TerminationGracePeriod: requires containerD
|
||||
-->
|
||||
## 兼容性与局限性 {#limitations}
|
||||
|
||||
某些节点层面的功能特性仅在使用特定[容器运行时](#container-runtime)时才可用；
|
||||
另外一些特性则在 Windows 节点上不可用，包括：
|
||||
|
||||
* 巨页（HugePages）：Windows 容器当前不支持
|
||||
* 特权容器：Windows 容器当前不支持
|
||||
* 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 and Liveness 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` 字段
|
||||
* Readiness 和 Liveness 探针
|
||||
* 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
|
||||
* A kubelet running on a Windows node does not have memory
|
||||
restrictions. `--kubelet-reserve` and `--system-reserve` do not set limits on
|
||||
kubelet or processes running on the host. This means kubelet or a process on the host
|
||||
could cause memory resource starvation outside the node-allocatable and scheduler.
|
||||
* 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 没有内存限制。
|
||||
`--kubelet-reserve` 和 `--system-reserve` 没有对主机上运行的 kubelet 或进程设置限制。
|
||||
这意味着 kubelet 或主机上的进程使用的内存可能会超过节点可分配内存和调度器设定的内存，
|
||||
从而造成内存资源不足。
|
||||
* 未实现 `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/))
|
||||
is not compatible with Windows.
|
||||
-->
|
||||
### 节点问题检测器 {#node-problem-detector}
|
||||
|
||||
节点问题检测器（参考[节点健康监测](/zh/docs/tasks/debug/debug-cluster/monitor-node-health/)）与 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 %}}
|
||||
|
||||
<!--
|
||||
#### cri-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).
|
||||
-->
|
||||
#### cri-containerd {#cri-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 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 列表，以防之前报告过这个问题，凭你对该问题的经验添加评论，
|
||||
并随附日志信息。
|
||||
SIG Windows Slack 也是一个很好的途径，让你在创建工单之前获得一些初始支持和故障排查的思路。
|
||||
|
||||
## {{% 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)。
|
||||
Loading…
Reference in New Issue