From b6a1a29963266598bf551f5877d83d164b5be071 Mon Sep 17 00:00:00 2001 From: Mengjiao Liu Date: Fri, 27 Aug 2021 15:37:51 +0800 Subject: [PATCH] [zh] Setup files to sync for 1.22(windows & runtime) --- .../container-runtimes.md | 58 ++++++++++++ .../windows/intro-windows-in-kubernetes.md | 89 ++++++++++--------- .../windows/user-guide-windows-containers.md | 27 +++--- 3 files changed, 117 insertions(+), 57 deletions(-) diff --git a/content/zh/docs/setup/production-environment/container-runtimes.md b/content/zh/docs/setup/production-environment/container-runtimes.md index a57d93fa5e..655db08c84 100644 --- a/content/zh/docs/setup/production-environment/container-runtimes.md +++ b/content/zh/docs/setup/production-environment/container-runtimes.md @@ -106,6 +106,64 @@ configuration, or reinstall it using automation. 如果你有切实可行的自动化方案，使用其他已更新配置的节点来替换该节点， 或者使用自动化方案来重新安装。 + +## Cgroup v2 +Cgroup v2 是 cgroup Linux API 的下一个版本。与 cgroup v1 不同的是， +Cgroup v2 只有一个层次结构，而不是每个控制器有一个不同的层次结构。 + + +新版本对 cgroup v1 进行了多项改进，其中一些改进是： + +- 更简洁、更易于使用的 API +- 可将安全子树委派给容器 +- 更新的功能，如压力失速信息（Pressure Stall Information） + + +尽管内核支持混合配置，即其中一些控制器由 cgroup v1 管理，另一些由 cgroup v2 管理， +Kubernetes 仅支持使用同一 cgroup 版本来管理所有控制器。 + +如果 systemd 默认不使用 cgroup v2，你可以通过在内核命令行中添加 +`systemd.unified_cgroup_hierarchy=1` 来配置系统去使用它。 + +```shell +# dnf install -y grubby && \ + sudo grubby \ + --update-kernel=ALL \ + --args=”systemd.unified_cgroup_hierarchy=1" +``` + + +要应用配置，必须重新启动节点。 + +切换到 cgroup v2 时，用户体验不应有任何明显差异， +除非用户直接在节点上或在容器内访问 cgroup 文件系统。 +为了使用它，CRI 运行时也必须支持 cgroup v2。 + diff --git a/content/zh/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/zh/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md index 5935f09bb7..286ede85a4 100644 --- a/content/zh/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md +++ b/content/zh/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md @@ -124,9 +124,9 @@ Windows 容器仅能调度到 Windows 节点，Linux 容器则只能调度到 Li | Kubernetes 版本 | Windows Server LTSC 版本 | Windows Server SAC 版本 | | --- | --- | --- | --- | -| *Kubernetes v1.19* | Windows Server 2019 | Windows Server ver 1909, Windows Server ver 2004 | | *Kubernetes v1.20* | Windows Server 2019 | Windows Server ver 1909, Windows Server ver 2004 | | *Kubernetes v1.21* | Windows Server 2019 | Windows Server ver 2004, Windows Server ver 20H2 | +| *Kubernetes v1.22* | Windows Server 2019 | Windows Server ver 2004, Windows Server ver 20H2 | #### Pause 镜像 {#pause-image} -Microsoft 在 `mcr.microsoft.com/oss/kubernetes/pause:3.4.1` 处维护 -一个 pause 基础设施容器镜像。 +Kubernetes 维护着一个多体系结构镜像，其中包括对 Windows 的支持。 +对于 Kubernetes v1.22，推荐的 pause 镜像是 `k8s.gcr.io/pause:3.5`。 +[源代码](https://github.com/kubernetes/kubernetes/tree/master/build/pause)可在 GitHub 上找到。 + +Microsoft 维护了一个支持 Linux 和 Windows amd64 的多体系结构镜像： `mcr.microsoft.com/oss/kubernetes/pause:3.5`。 +此镜像与 Kubernetes 维护的镜像是从同一来源构建，但所有 Windows 二进制文件 +均由 Microsoft [签名](https://docs.microsoft.com/en-us/windows-hardware/drivers/install/authenticode)。 +当生产环境需要被签名的二进制文件时，建议使用 Microsoft 维护的镜像。 ##### CSI 插件 {#csi-plugins} -{{< feature-state for_k8s_version="v1.19" state="beta" >}} +{{< feature-state for_k8s_version="v1.22" state="stable" >}} 与 {{< glossary_tooltip text="CSI" term_id="csi" >}} 插件相关联的代码作为 树外脚本和可执行文件来发布且通常发布为容器镜像形式，并使用 DaemonSet 和 @@ -438,30 +448,26 @@ StatefulSet 这类标准的 Kubernetes 构造体来部署。 CSI 插件处理 Kubernetes 中的很多卷管理操作：对卷的配备、去配和调整大小， 将卷挂接到 Kubernetes 节点或从节点上解除挂接，将卷挂载到需要持久数据的 Pod 中的某容器或从容器上卸载，使用快照和克隆来备份或恢复持久数据。 -CSI 插件通常包含节点插件（以 DaemonSet 形式运行于各节点上）和控制器插件。 -CSI 节点插件（尤其是那些通过块设备或者共享文件系统形式来提供持久卷的插件） -需要执行很多特权级操作，例如扫描磁盘设备、挂载文件系统等等。 -这些操作在不同的宿主操作系统上差别较大。对于 Linux 工作节点而言，容器化的 -CSI 节点插件通常部署为特权级的容器。对于 Windows 工作节点而言，容器化的 -CSI 节点插件的特权操作通过 -[csi-proxy](https://github.com/kubernetes-csi/csi-proxy) 来支持；csi-proxy 是一个社区管理的、独立的可执行文件，需要预安装在每个 Windows 节点之上。请参考你要部署的 CSI 插件的部署指南以进一步了解其细节。 +CSI 插件与执行本地存储操作的 CSI 节点插件通信。 +在 Windows 节点上，CSI 节点插件通常调用处理本地存储操作的 [csi-proxy](https://github.com/kubernetes-csi/csi-proxy) +公开的 API, csi-proxy 由社区管理。 + +有关安装的更多详细信息，请参阅你要部署的 Windows CSI 插件的环境部署指南。 +你也可以参考以下[安装步骤](https://github.com/kubernetes-csi/csi-proxy#installation) 。 + * `kubectl port-forward` 失败，错误信息为 "unable to do port forwarding: wincat not found" @@ -2190,6 +2194,10 @@ Kubernetes 中日志是故障排查的一个重要元素。确保你在尝试从 请确保你使用的是这些版本或者更新版本。 如果你想要自行构造你自己的 pause 基础设施容器，要确保其中包含了 [wincat](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat) + + Windows 的端口转发支持需要在 [pause 基础设施容器](#pause-image) 中提供 wincat.exe。 + 确保你使用的是与你的 Windows 操作系统版本兼容的受支持镜像。 + 如果你想构建自己的 pause 基础架构容器，请确保包含 [wincat](https://github.com/kubernetes/kubernetes/tree/master/build/pause/windows/wincat).。 * `pause` 容器是什么？ @@ -2228,10 +2234,7 @@ Kubernetes 中日志是故障排查的一个重要元素。确保你在尝试从 网络名字空间和端点（相同的 IP 和端口空间）。我们需要 pause 容器来工作容器崩溃或 重启的状况，以确保不会丢失任何网络配置。 - "pause" （基础设施）镜像托管在 Microsoft Container Registry (MCR) 上。 - 你可以使用 `mcr.microsoft.com/oss/kubernetes/pause:3.4.1` 来访问它。 - 要了解进一步的细节，可参阅 - [DOCKERFILE](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)。 + 请参阅 [pause 镜像](#pause-image) 部分以查找 pause 镜像的推荐版本。 ## 在你开始之前 -* 创建一个 Kubernetes 集群，其中包括一个 - [运行 Windows 服务器的主节点和工作节点](/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/) +* 创建一个 Kubernetes 集群，其中包括一个控制平面和 + [运行 Windows 服务器的工作节点](/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/) * 重要的是要注意，对于 Linux 和 Windows 容器，在 Kubernetes 上创建和部署服务和工作负载的行为几乎相同。 与集群接口的 [kubectl 命令](/zh/docs/reference/kubectl/overview/)相同。 @@ -139,15 +139,15 @@ the container port 80 is exposed directly to the service. 1. Check that the deployment succeeded. To verify: * Two containers per pod on the Windows node, use `docker ps` - * Two pods listed from the Linux master, use `kubectl get pods` - * Node-to-pod communication across the network, `curl` port 80 of your pod IPs from the Linux master + * 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 master and from individual pods + 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 master or machines outside of the cluster + * 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. 检查所有节点是否健康： @@ -168,15 +168,15 @@ the container port 80 is exposed directly to the service. 1. 检查部署是否成功。验证： * Windows 节点上每个 Pod 有两个容器，使用 `docker ps` - * Linux 主机列出两个 Pod，使用 `kubectl get pods` - * 跨网络的节点到 Pod 通信，从 Linux 主服务器 `curl` 您的 pod IPs 的端口80，以检查 Web 服务器响应 + * 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 + * 服务到 Pod 的通信，从 Linux 控制平面节点和各个 Pod 中 `curl` 虚拟服务 IP （在 `kubectl get services` 下可见） * 服务发现，使用 Kubernetes `curl` 服务名称 [默认 DNS 后缀](/zh/docs/concepts/services-networking/dns-pod-service/#services) - * 入站连接，从 Linux 主服务器或集群外部的计算机 `curl` NodePort + * 入站连接，从 Linux 控制平面节点或集群外部的计算机 `curl` NodePort * 出站连接，使用 kubectl exec 从 Pod 内部 curl 外部 IP 向所有 Windows 节点添加污点后，Kubernetes 将不会在它们上调度任何负载（包括现有的 Linux Pod）。 -为了使某 Windows Pod 调度到 Windows 节点上，该 Pod 既需要 nodeSelector 选择 Windows， -也需要合适的匹配的容忍度设置。 +为了使某 Windows Pod 调度到 Windows 节点上，该 Pod 需要 nodeSelector 和合适的匹配的容忍度设置来选择 Windows， ```yaml nodeSelector: