whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Switch language name 'zh' to 'zh-cn'

Browse Source 
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
2022-06-10 20:25:27 +08:00
parent 3d345b1816
commit c52818c03d
1347 changed files with 8 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md
+90
View File
@@ -0,0 +1,90 @@
---
title: "从 dockershim 迁移"
weight: 10
content_type: task
no_list: true
---
<!--
title: "Migrating from dockershim"
weight: 10
content_type: task
-->
<!-- overview -->
<!--
This section presents information you need to know when migrating from
dockershim to other container runtimes.
-->
本节提供从 dockershim 迁移到其他容器运行时的必备知识。
<!--
Since the announcement of [dockershim deprecation](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)
in Kubernetes 1.20, there were questions on how this will affect various workloads and Kubernetes
installations. Our [Dockershim Removal FAQ](/blog/2022/02/17/dockershim-faq/) is there to help you
to understand the problem better.
-->
自从 Kubernetes 1.20 宣布
[弃用 dockershim](/zh/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)，
各类疑问随之而来：这对各类工作负载和 Kubernetes 部署会产生什么影响。
我们的[弃用 Dockershim 常见问题](/blog/2022/02/17/dockershim-faq/)可以帮助你更好地理解这个问题。
<!--
Dockershim was removed from Kubernetes with the release of v1.24.
If you use Docker via dockershim as your container runtime, and wish to upgrade to v1.24,
it is recommended that you either migrate to another runtime or find an alternative means to obtain Docker Engine support.
-->
Dockershim 在 Kubernetes v1.24 版本已经被移除。
如果你集群内是通过 dockershim 使用 Docker 作为容器运行时，并希望 Kubernetes 升级到 v1.24，
建议你迁移到其他容器运行时或使用其他方法以获得 Docker 引擎支持。
<!--
Check out [container runtimes](/docs/setup/production-environment/container-runtimes/)
section to know your options. Make sure to
[report issues](https://github.com/kubernetes/kubernetes/issues) you encountered
with the migration. So the issue can be fixed in a timely manner and your cluster would be
ready for dockershim removal.
-->
建议从 dockershim 迁移到其他替代的容器运行时。
请参阅[容器运行时](/zh/docs/setup/production-environment/container-runtimes/)
一节以了解可用的备选项。
当在迁移过程中遇到麻烦，请[上报问题](https://github.com/kubernetes/kubernetes/issues)。
那么问题就可以及时修复，你的集群也可以进入移除 dockershim 前的就绪状态。
<!--
Your cluster might have more than one kind of node, although this is not a common
configuration.
These tasks will help you to migrate:
* [Check whether Dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)
* [Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/)
* [Migrating telemetry and security agents from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/)
-->
你的集群中可以有不止一种类型的节点，尽管这不是常见的情况。
下面这些任务可以帮助你完成迁移：
* [检查弃用 Dockershim 对你的影响](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)
* [dockershim 迁移](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/)
* [从 dockershim 迁移遥测和安全代理](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/)
<!--
## {{% heading "whatsnext" %}}
* Check out [container runtimes](/docs/setup/production-environment/container-runtimes/)
to understand your options for a container runtime.
* There is a
[GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917)
to track discussion about the deprecation and removal of dockershim.
* If you found a defect or other technical concern relating to migrating away from dockershim,
you can [report an issue](https://github.com/kubernetes/kubernetes/issues/new/choose)
to the Kubernetes project.
-->
## 下一步
* 查看[容器运行时](/zh/docs/setup/production-environment/container-runtimes/)了解可选的容器运行时。
* [GitHub 问题](https://github.com/kubernetes/kubernetes/issues/106917)跟踪有关 dockershim 的弃用和删除的讨论。
* 如果你发现与 dockershim 迁移相关的缺陷或其他技术问题，
可以在 Kubernetes 项目[报告问题](https://github.com/kubernetes/kubernetes/issues/new/choose)。
content/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd.md
+265
View File
@@ -0,0 +1,265 @@
---
title: 将节点上的容器运行时从 Docker Engine 改为 containerd
weight: 8
content_type: task
---
<!--
title: "Changing the Container Runtime on a Node from Docker Engine to containerd"
weight: 8
content_type: task
-->
<!--
This task outlines the steps needed to update your container runtime to containerd from Docker. It
is applicable for cluster operators running Kubernetes 1.23 or earlier. Also this covers an
example scenario for migrating from dockershim to containerd and alternative container runtimes
can be picked from this [page](/docs/setup/production-environment/container-runtimes/).
-->
本任务给出将容器运行时从 Docker 改为 containerd 所需的步骤。
此任务适用于运行 1.23 或更早版本 Kubernetes 的集群操作人员。
同时，此任务也涉及从 dockershim 迁移到 containerd 的示例场景，
以及可以从[此页面](/zh/docs/setup/production-environment/container-runtimes/)
获得的其他容器运行时列表。
## {{% heading "prerequisites" %}}
{{% thirdparty-content %}}
<!--
Install containerd. For more information see
[containerd's installation documentation](https://containerd.io/docs/getting-started/)
and for specific prerequisite follow
[the containerd guide](/docs/setup/production-environment/container-runtimes/#containerd).
-->
安装 containerd。进一步的信息可参见
[containerd 的安装文档](https://containerd.io/docs/getting-started/)。
关于一些特定的环境准备工作，请遵循 [containerd 指南](/zh/docs/setup/production-environment/container-runtimes/#containerd)。
<!--
## Drain the node
```shell
kubectl drain <node-to-drain> --ignore-daemonsets
```
Replace `<node-to-drain>` with the name of your node you are draining.
-->
## 腾空节点 {#drain-the-node}
```shell
kubectl drain <node-to-drain> --ignore-daemonsets
```
将 `<node-to-drain>` 替换为你所要腾空的节点的名称
<!--
## Stop the Docker daemon
-->
## 停止 Docker 守护进程 {#stop-the-docker-daemon}
```shell
systemctl stop kubelet
systemctl disable docker.service --now
```
<!--
## Install Containerd
Follow the [guide](/docs/setup/production-environment/container-runtimes/#containerd)
for detailed steps to install containerd.
-->
## 安装 Containerd {#install-containerd}
遵循此[指南](/zh/docs/setup/production-environment/container-runtimes/#containerd)
了解安装 containerd 的详细步骤。
{{< tabs name="tab-cri-containerd-installation" >}}
{{% tab name="Linux" %}}
<!--
1. Install the `containerd.io` package from the official Docker repositories.
Instructions for setting up the Docker repository for your respective Linux distribution and
installing the `containerd.io` package can be found at
[Getting started with containerd](https://github.com/containerd/containerd/blob/main/docs/getting-started.md).
-->
1. 从官方的 Docker 仓库安装 `containerd.io` 包。关于为你所使用的 Linux 发行版来设置
Docker 仓库，以及安装 `containerd.io` 包的详细说明，可参见
[开始使用 containerd](https://github.com/containerd/containerd/blob/main/docs/getting-started.md)。
<!--
1. Configure containerd:
-->
2. 配置 containerd：
```shell
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml
```
<!--
1. Restart containerd:
-->
3. 重启 containerd：
```shell
sudo systemctl restart containerd
```
{{% /tab %}}
{{% tab name="Windows (PowerShell)" %}}
<!--
Start a Powershell session, set `$Version` to the desired version (ex: `$Version="1.4.3"`), and
then run the following commands:
-->
启动一个 Powershell 会话，将 `$Version` 设置为期望的版本（例如：`$Version="1.4.3"`），
之后运行下面的命令：
<!--
1. Download containerd:
-->
1. 下载 containerd：
```powershell
curl.exe -L https://github.com/containerd/containerd/releases/download/v$Version/containerd-$Version-windows-amd64.tar.gz -o containerd-windows-amd64.tar.gz
tar.exe xvf .\containerd-windows-amd64.tar.gz
```
<!--
2. Extract and configure:
-->
2. 解压缩并执行配置：
```powershell
Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force
cd $Env:ProgramFiles\containerd\
.\containerd.exe config default | Out-File config.toml -Encoding ascii
# 请审查配置信息。取决于你的安装环境，你可能需要调整：
# - the sandbox_image （Kubernetes pause 镜像）
# - cni bin_dir 和 conf_dir 的位置
Get-Content config.toml
# （可选步骤，但强烈建议执行）将 containerd 排除在 Windows Defender 扫描之外
Add-MpPreference -ExclusionProcess "$Env:ProgramFiles\containerd\containerd.exe"
```
<!--
3. Start containerd:
-->
3. 启动 containerd：
```powershell
.\containerd.exe --register-service
Start-Service containerd
```
{{% /tab %}}
{{< /tabs >}}
<!--
## Configure the kubelet to use containerd as its container runtime
Edit the file `/var/lib/kubelet/kubeadm-flags.env` and add the containerd runtime to the flags.
`--container-runtime=remote` and
`--container-runtime-endpoint=unix:///run/containerd/containerd.sock"`.
-->
## 配置 kubelet 使用 containerd 作为其容器运行时
编辑文件 `/var/lib/kubelet/kubeadm-flags.env`，将 containerd 运行时添加到标志中：
`--container-runtime=remote` 和 `--container-runtime-endpoint=unix:///run/containerd/containerd.sock"`。
<!--
For users using kubeadm should consider the following:
Users using kubeadm should be aware that the `kubeadm` tool stores the CRI socket for each host as
an annotation in the Node object for that host. To change it you can execute the following command
on a machine that has the kubeadm `/etc/kubernetes/admin.conf` file.
-->
对于使用 kubeadm 的用户，可以考虑下面的问题：
`kubeadm` 工具将每个主机的 CRI 套接字保存在该主机对应的 Node 对象的注解中。
使用 `kubeadm` 的用户应该知道，`kubeadm` 工具将每个主机的 CRI 套接字保存在该主机对应的 Node 对象的注解中。
要更改这一注解信息，你可以在一台包含 kubeadm `/etc/kubernetes/admin.conf` 文件的机器上执行以下命令：
```shell
kubectl edit no <node-name>
```
<!--
This will start a text editor where you can edit the Node object.
To choose a text editor you can set the `KUBE_EDITOR` environment variable.
- Change the value of `kubeadm.alpha.kubernetes.io/cri-socket` from `/var/run/dockershim.sock`
to the CRI socket path of your choice (for example `unix:///run/containerd/containerd.sock`).
Note that new CRI socket paths must be prefixed with `unix://` ideally.
- Save the changes in the text editor, which will update the Node object.
-->
这一命令会打开一个文本编辑器，供你在其中编辑 Node 对象。
要选择不同的文本编辑器，你可以设置 `KUBE_EDITOR` 环境变量。
- 更改 `kubeadm.alpha.kubernetes.io/cri-socket` 值，将其从
`/var/run/dockershim.sock` 改为你所选择的 CRI 套接字路径
（例如：`unix:///run/containerd/containerd.sock`）。
注意新的 CRI 套接字路径必须带有 `unix://` 前缀。
- 保存文本编辑器中所作的修改，这会更新 Node 对象。
<!--
## Restart the kubelet
-->
## 重启 kubelet {#restart-the-kubelet}
```shell
systemctl start kubelet
```
<!--
## Verify that the node is healthy
Run `kubectl get nodes -o wide` and containerd appears as the runtime for the node we just changed.
## Remove Docker Engine
-->
## 验证节点处于健康状态 {#verify-that-the-node-is-healthy}
运行 `kubectl get nodes -o wide`，containerd 会显示为我们所更改的节点上的运行时。
{{% thirdparty-content %}}
<!--
Finally if everything goes well, remove Docker.
-->
最后，在一切顺利时删除 Docker。
{{< tabs name="tab-remove-docker-enigine" >}}
{{% tab name="CentOS" %}}
```shell
sudo yum remove docker-ce docker-ce-cli
```
{{% /tab %}}
{{% tab name="Debian" %}}
```shell
sudo apt-get purge docker-ce docker-ce-cli
```
{{% /tab %}}
{{% tab name="Fedora" %}}
```shell
sudo dnf remove docker-ce docker-ce-cli
```
{{% /tab %}}
{{% tab name="Ubuntu" %}}
```shell
sudo apt-get purge docker-ce docker-ce-cli
```
{{% /tab %}}
{{< /tabs >}}
content/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you.md
+188
View File
@@ -0,0 +1,188 @@
---
title: 检查弃用 Dockershim 是否对你有影响
content_type: task
weight: 20
---
<!--
title: Check whether Dockershim deprecation affects you
content_type: task
reviewers:
- SergeyKanzhelev
weight: 20
-->
<!-- overview -->
<!--
The `dockershim` component of Kubernetes allows to use Docker as a Kubernetes's
{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}.
Kubernetes' built-in `dockershim` component was removed in release v1.24.
-->
Kubernetes 的 `dockershim` 组件使得你可以把 Docker 用作 Kubernetes 的
{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}。
在 Kubernetes v1.24 版本中，内建组件 `dockershim` 被移除。
<!--
This page explains how your cluster could be using Docker as a container runtime,
provides details on the role that `dockershim` plays when in use, and shows steps
you can take to check whether any workloads could be affected by `dockershim` removal.
-->
本页讲解你的集群把 Docker 用作容器运行时的运作机制，
并提供使用 `dockershim` 时，它所扮演角色的详细信息，
继而展示了一组操作，可用来检查弃用 `dockershim` 对你的工作负载是否有影响。
<!--
## Finding if your app has a dependencies on Docker {#find-docker-dependencies}
-->
## 检查你的应用是否依赖于 Docker {#find-docker-dependencies}
<!--
If you are using Docker for building your application containers, you can still
run these containers on any container runtime. This use of Docker does not count
as a dependency on Docker as a container runtime.
-->
即使你是通过 Docker 创建的应用容器，也不妨碍你在其他任何容器运行时上运行这些容器。
这种使用 Docker 的方式并不构成对 Docker 作为一个容器运行时的依赖。
<!--
When alternative container runtime is used, executing Docker commands may either
not work or yield unexpected output. This is how you can find whether you have a
dependency on Docker:
-->
当用了别的容器运行时之后，Docker 命令可能不工作，或者产生意外的输出。
下面是判定你是否依赖于 Docker 的方法。
<!--
1. Make sure no privileged Pods execute Docker commands (like `docker ps`),
restart the Docker service (commands such as `systemctl restart docker.service`),
or modify Docker-specific files such as `/etc/docker/daemon.json`.
1. Check for any private registries or image mirror settings in the Docker
configuration file (like `/etc/docker/daemon.json`). Those typically need to
be reconfigured for another container runtime.
1. Check that scripts and apps running on nodes outside of your Kubernetes
infrastructure do not execute Docker commands. It might be:
- SSH to nodes to troubleshoot;
- Node startup scripts;
- Monitoring and security agents installed on nodes directly.
-->
1. 确认没有特权 Pod 执行 Docker 命令（如 `docker ps`）、重新启动 Docker
服务（如 `systemctl restart docker.service`）或修改 Docker 配置文件
`/etc/docker/daemon.json`。
2. 检查 Docker 配置文件（如 `/etc/docker/daemon.json`）中容器镜像仓库的镜像（mirror）站点设置。
这些配置通常需要针对不同容器运行时来重新设置。
3. 检查确保在 Kubernetes 基础设施之外的节点上运行的脚本和应用程序没有执行 Docker 命令。
可能的情况有：
- SSH 到节点排查故障；
- 节点启动脚本；
- 直接安装在节点上的监控和安全代理。
<!--
1. Third-party tools that perform above mentioned privileged operations. See
[Migrating telemetry and security agents from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents)
for more information.
1. Make sure there is no indirect dependencies on dockershim behavior.
This is an edge case and unlikely to affect your application. Some tooling may be configured
to react to Docker-specific behaviors, for example, raise alert on specific metrics or search for
a specific log message as part of troubleshooting instructions.
If you have such tooling configured, test the behavior on test
cluster before migration.
-->
4. 检查执行上述特权操作的第三方工具。
详细操作请参考[从 dockershim 迁移遥测和安全代理](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents)。
5. 确认没有对 dockershim 行为的间接依赖。这是一种极端情况，不太可能影响你的应用。
一些工具很可能被配置为使用了 Docker 特性，比如，基于特定指标发警报，
或者在故障排查指令的一个环节中搜索特定的日志信息。
如果你有此类配置的工具，需要在迁移之前，在测试集群上测试这类行为。
<!--
## Dependency on Docker explained {#role-of-dockershim}
-->
## Docker 依赖详解 {#role-of-dockershim}
<!--
A [container runtime](/docs/concepts/containers/#container-runtimes) is software that can
execute the containers that make up a Kubernetes pod. Kubernetes is responsible for orchestration
and scheduling of Pods; on each node, the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}
uses the container runtime interface as an abstraction so that you can use any compatible
container runtime.
-->
[容器运行时](/zh/docs/concepts/containers/#container-runtimes)是一个软件，
用来运行组成 Kubernetes Pod 的容器。
Kubernetes 负责编排和调度 Pod；在每一个节点上，{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}
使用抽象的容器运行时接口，所以你可以任意选用兼容的容器运行时。
<!--
In its earliest releases, Kubernetes offered compatibility with one container runtime: Docker.
Later in the Kubernetes project's history, cluster operators wanted to adopt additional container runtimes.
The CRI was designed to allow this kind of flexibility - and the kubelet began supporting CRI. However,
because Docker existed before the CRI specification was invented, the Kubernetes project created an
adapter component, `dockershim`. The dockershim adapter allows the kubelet to interact with Docker as
if Docker were a CRI compatible runtime.
-->
在早期版本中，Kubernetes 提供的兼容性支持一个容器运行时：Docker。
在 Kubernetes 后来的发展历史中，集群运营人员希望采用别的容器运行时。
于是 CRI 被设计出来满足这类灵活性需求 - 而 kubelet 亦开始支持 CRI。
然而，因为 Docker 在 CRI 规范创建之前就已经存在，Kubernetes 就创建了一个适配器组件 `dockershim`。
dockershim 适配器允许 kubelet 与 Docker 交互，就好像 Docker 是一个 CRI 兼容的运行时一样。
<!--
You can read about it in [Kubernetes Containerd integration goes GA](/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/) blog post.
-->
你可以阅读博文
[Kubernetes 正式支持集成 Containerd](/zh/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/)。
<!-- Dockershim vs. CRI with Containerd -->
![Dockershim 和 Containerd CRI 的实现对比图](/images/blog/2018-05-24-kubernetes-containerd-integration-goes-ga/cri-containerd.png)
<!--
Switching to Containerd as a container runtime eliminates the middleman. All the
same containers can be run by container runtimes like Containerd as before. But
now, since containers schedule directly with the container runtime, they are not visible to Docker.
So any Docker tooling or fancy UI you might have used
before to check on these containers is no longer available.
-->
切换到 Containerd 容器运行时可以消除掉中间环节。
所有相同的容器都可由 Containerd 这类容器运行时来运行。
但是现在，由于直接用容器运行时调度容器，它们对 Docker 是不可见的。
因此，你以前用来检查这些容器的 Docker 工具或漂亮的 UI 都不再可用。
<!--
You cannot get container information using `docker ps` or `docker inspect`
commands. As you cannot list containers, you cannot get logs, stop containers,
or execute something inside container using `docker exec`.
-->
你不能再使用 `docker ps` 或 `docker inspect` 命令来获取容器信息。
由于你不能列出容器，因此你不能获取日志、停止容器，甚至不能通过 `docker exec` 在容器中执行命令。
{{< note >}}
<!--
If you're running workloads via Kubernetes, the best way to stop a container is through
the Kubernetes API rather than directly through the container runtime (this advice applies
for all container runtimes, not only Docker).
-->
如果你在用 Kubernetes 运行工作负载，最好通过 Kubernetes API 停止容器，
而不是通过容器运行时来停止它们
（此建议适用于所有容器运行时，不仅仅是针对 Docker）。
{{< /note >}}
<!--
You can still pull images or build them using `docker build` command. But images
built or pulled by Docker would not be visible to container runtime and
Kubernetes. They needed to be pushed to some registry to allow them to be used
by Kubernetes.
-->
你仍然可以下载镜像，或者用 `docker build` 命令创建它们。
但用 Docker 创建、下载的镜像，对于容器运行时和 Kubernetes，均不可见。
为了在 Kubernetes 中使用，需要把镜像推送（push）到某镜像仓库。
## {{% heading "whatsnext" %}}
<!--
- Read [Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/) to understand your next steps
- Read the [dockershim deprecation FAQ](/blog/2020/12/02/dockershim-faq/) article for more information.
-->
- 阅读[从 dockershim 迁移](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/)，
以了解你的下一步工作。
- 阅读[dockershim 弃用常见问题解答](/zh/blog/2020/12/02/dockershim-faq/)文章，了解更多信息。
content/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md
+186
View File
@@ -0,0 +1,186 @@
---
title: 查明节点上所使用的容器运行时
content_type: task
weight: 10
---
<!--
title: Find Out What Container Runtime is Used on a Node
content_type: task
reviewers:
- SergeyKanzhelev
weight: 10
-->
<!-- overview -->
<!--
This page outlines steps to find out what [container runtime](/docs/setup/production-environment/container-runtimes/)
the nodes in your cluster use.
-->
本页面描述查明集群中节点所使用的[容器运行时](/zh/docs/setup/production-environment/container-runtimes/)
的步骤。
<!--
Depending on the way you run your cluster, the container runtime for the nodes may
have been pre-configured or you need to configure it. If you're using a managed
Kubernetes service, there might be vendor-specific ways to check what container runtime is
configured for the nodes. The method described on this page should work whenever
the execution of `kubectl` is allowed.
-->
取决于你运行集群的方式，节点所使用的容器运行时可能是事先配置好的，
也可能需要你来配置。如果你在使用托管的 Kubernetes 服务，
可能存在特定于厂商的方法来检查节点上配置的容器运行时。
本页描述的方法应该在能够执行 `kubectl` 的场合下都可以工作。
## {{% heading "prerequisites" %}}
<!--
Install and configure `kubectl`. See [Install Tools](/docs/tasks/tools/#kubectl) section for details.
-->
安装并配置 `kubectl`。参见[安装工具](/zh/docs/tasks/tools/#kubectl) 节了解详情。
<!--
## Find out the container runtime used on a Node
Use `kubectl` to fetch and show node information:
-->
## 查明节点所使用的容器运行时 {#find-out-the-container-runtime-used-on-a-node}
使用 `kubectl` 来读取并显示节点信息：
```shell
kubectl get nodes -o wide
```
<!--
The output is similar to the following. The column `CONTAINER-RUNTIME` outputs
the runtime and its version.
For Docker Engine, the output is similar to this:
-->
输出如下面所示。`CONTAINER-RUNTIME` 列给出容器运行时及其版本。
对于 Docker Engine，输出类似于：
```none
NAME STATUS VERSION CONTAINER-RUNTIME
node-1 Ready v1.16.15 docker://19.3.1
node-2 Ready v1.16.15 docker://19.3.1
node-3 Ready v1.16.15 docker://19.3.1
```
<!--
If your runtime shows as Docker Engine, you still might not be affected by the
removal of dockershim in Kubernetes 1.24. [Check the runtime
endpoint](#which-endpoint) to see if you use dockershim. If you don't use
dockershim, you aren't affected.
For containerd, the output is similar to this:
-->
如果你的容器运行时显示为 Docker Engine，你仍然可能不会被 1.24 中 dockershim 的移除所影响。
通过[检查运行时端点](#which-endpoint)，可以查看你是否在使用 dockershim。
如果你没有使用 dockershim，你就不会被影响。
看下是否是使用的 dockershim，如何是 dockershim 则会受到在 Kubernetes 1.24 中移除 dockershim 的影响。
反之则不会受到影响。
对于 containerd，输出类似于这样：
```none
# For containerd
NAME STATUS VERSION CONTAINER-RUNTIME
node-1 Ready v1.19.6 containerd://1.4.1
node-2 Ready v1.19.6 containerd://1.4.1
node-3 Ready v1.19.6 containerd://1.4.1
```
<!--
Find out more information about container runtimes
on [Container Runtimes](/docs/setup/production-environment/container-runtimes/)
page.
-->
你可以在[容器运行时](/zh/docs/setup/production-environment/container-runtimes/)
页面找到与容器运行时相关的更多信息。
<!--
## Find out what container runtime endpoint you use {#which-endpoint}
-->
## 检查当前使用的运行时端点 {#which-endpoint}
<!--
The container runtime talks to the kubelet over a Unix socket using the [CRI
protocol](/docs/concepts/architecture/cri/), which is based on the gRPC
framework. The kubelet acts as a client, and the runtime acts as the server.
In some cases, you might find it useful to know which socket your nodes use. For
example, with the removal of dockershim in Kubernetes 1.24 and later, you might
want to know whether you use Docker Engine with dockershim.
-->
容器运行时使用 Unix Socket 与 kubelet 通信，这一通信使用基于 gRPC 框架的
[CRI 协议](/zh/docs/concepts/architecture/cri/)。kubelet 扮演客户端，运行时扮演服务器端。
在某些情况下，你可能想知道你的节点使用的是哪个 socket。
如若集群是 Kubernetes 1.24 及以后的版本，
或许你想知道当前运行时是否是使用 dockershim 的 Docker Engine。
<!--
{{<note>}}
If you currently use Docker Engine in your nodes with `cri-dockerd`, you aren't
affected by the dockershim removal.
{{</note>}}
-->
{{<note>}}
如果你的节点在通过 `cri-dockerd` 使用 Docker Engine，
那么集群不会受到 Kubernetes 移除 dockershim 的影响。
{{</note>}}
<!--
You can check which socket you use by checking the kubelet configuration on your
nodes.
-->
可以通过检查 kubelet 的参数得知当前使用的是哪个 socket。
<!--
1. Read the starting commands for the kubelet process:
```
tr \\0 ' ' < /proc/"$(pgrep kubelet)"/cmdline
```
If you don't have `tr` or `pgrep`, check the command line for the kubelet
process manually.
-->
1. 查看 kubelet 进程的启动命令
```
tr \\0 ' ' < /proc/"$(pgrep kubelet)"/cmdline
```
如有节点上没有 `tr` 或者 `pgrep`，就需要手动检查 kubelet 的启动命令
<!--
1. In the output, look for the `--container-runtime` flag and the
`--container-runtime-endpoint` flag.
* If your nodes use Kubernetes v1.23 and earlier and these flags aren't
present or if the `--container-runtime` flag is not `remote`,
you use the dockershim socket with Docker Engine.
* If the `--container-runtime-endpoint` flag is present, check the socket
name to find out which runtime you use. For example,
`unix:///run/containerd/containerd.sock` is the containerd endpoint.
-->
2. 在命令的输出中，查找 `--container-runtime` 和 `--container-runtime-endpoint` 标志。
* 如果 Kubernetes 集群版本是 v1.23 或者更早的版本，并且这两个参数不存在，
或者 `container-runtime` 标志值不是 `remote`，则你在通过 dockershim 套接字使用
Docker Engine。
或者如果集群使用的 Docker engine 和 dockershim socket，则输出结果中 `--container-runtime` 不是 `remote`,
* 如果设置了 `--container-runtime-endpoint` 参数，查看套接字名称即可得知当前使用的运行时。
如若套接字 `unix:///run/containerd/containerd.sock` 是 containerd 的端点。
<!--
If you use Docker Engine with the dockershim, [migrate to a different runtime](/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/),
or, if you want to continue using Docker Engine in v1.24 and later, migrate to a
CRI-compatible adapter like [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd).
-->
如果你通过 dockershim 来使用 Docker Engine，可在
[迁移到不同的运行时](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/)
找到更多信息。或者，如果你想在 Kubernetes v1.24 及以后的版本仍使用 Docker Engine，
可以安装 CRI 兼容的适配器实现，如 [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd)。
[`cri-dockerd`](https://github.com/Mirantis/cri-dockerd)。
content/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd.md
+233
View File
@@ -0,0 +1,233 @@
---
title: 将 Docker Engine 节点从 dockershim 迁移到 cri-dockerd
weight: 9
content_type: task
---
<!--
title: "Migrate Docker Engine nodes from dockershim to cri-dockerd"
weight: 9
content_type: task
-->
{{% thirdparty-content %}}
<!--
This page shows you how to migrate your Docker Engine nodes to use `cri-dockerd`
instead of dockershim. You should follow these steps in these scenarios:
* You want to switch away from dockershim and still use Docker Engine to run
containers in Kubernetes.
* You want to upgrade to Kubernetes v{{< skew currentVersion >}} and your
existing cluster relies on dockershim, in which case you must migrate
from dockershim and `cri-dockerd` is one of your options.
To learn more about the removal of dockershim, read the [FAQ page](/dockershim).
-->
本页面为你展示如何迁移你的 Docker Engine 节点，使之使用 `cri-dockerd` 而不是 dockershim。
在以下场景中，你可以遵从这里的步骤执行操作：
* 你期望不再使用 dockershim，但仍然使用 Docker Engine 来在 Kubernetes 中运行容器。
* 你希望升级到 Kubernetes v{{< skew currentVersion >}} 且你的现有集群依赖于 dockershim，
因此你必须放弃 dockershim，而 `cri-dockerd` 是你的一种选项。
要进一步了解 dockershim 的移除，请阅读 [FAQ 页面](/zh/dockershim)。
<!--
## What is cri-dockerd? {#what-is-cri-dockerd}
In Kubernetes 1.23 and earlier, you could use Docker Engine with Kubernetes,
relying on a built-in component of Kubernetes named _dockershim_.
The dockershim component was removed in the Kubernetes 1.24 release; however,
a third-party replacement, `cri-dockerd`, is available. The `cri-dockerd` adapter
lets you use Docker Engine through the {{<glossary_tooltip term_id="cri" text="Container Runtime Interface">}}.
-->
## cri-dockerd 是什么？ {#what-is-cri-dockerd}
在 Kubernetes v1.24 及更早版本中，你可以在 Kubernetes 中使用 Docker Engine，
依赖于一个称作 _dockershim_ 的内置 Kubernetes 组件。
dockershim 组件在 Kubernetes v1.24 发行版本中已被移除；不过，一种来自第三方的替代品，
`cri-dockerd` 是可供使用的。`cri-dockerd` 适配器允许你通过
{{<glossary_tooltip term_id="cri" text="容器运行时接口（Container Runtime Interface，CRI）">}}
来使用 Docker Engine。
{{<note>}}
<!--
If you already use `cri-dockerd`, you aren't affected by the dockershim removal.
Before you begin, [Check whether your nodes use the dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/).
-->
如果你已经在使用 `cri-dockerd`，那么你不会被 dockershim 的移除影响到。
在开始之前，[检查你的节点是否在使用 dockershim](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/)。
{{</note>}}
<!--
If you want to migrate to `cri-dockerd` so that you can continue using Docker
Engine as your container runtime, you should do the following for each affected
node:
1. Install `cri-dockerd`.
1. Cordon and drain the node.
1. Configure the kubelet to use `cri-dockerd`.
1. Restart the kubelet.
1. Verify that the node is healthy.
-->
如果你想要迁移到 `cri-dockerd` 以便继续使用 Docker Engine 作为你的容器运行时，
你需要在所有被影响的节点上执行以下操作：
1. 安装 `cri-dockerd`；
1. 隔离（Cordon）并腾空（Drain）该节点；
1. 配置 kubelet 使用 `cri-dockerd`；
1. 重新启动 kubelet；
1. 验证节点处于健康状态。
<!--
Test the migration on non-critical nodes first.
You should perform the following steps for each node that you want to migrate
to `cri-dockerd`.
-->
首先在非关键节点上测试这一迁移过程。
你应该针对所有希望迁移到 `cri-dockerd` 的节点执行以下步骤。
## {{% heading "prerequisites" %}}
<!--
* [`cri-dockerd`](https://github.com/mirantis/cri-dockerd#build-and-install)
installed and started on each node.
* A [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/).
-->
* 安装了 [`cri-dockerd`](https://github.com/mirantis/cri-dockerd#build-and-install)
并且该服务已经在各节点上启动；
* 一个[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)。
<!--
## Cordon and drain the node
1. Cordon the node to stop new Pods scheduling on it:
```shell
kubectl cordon <NODE_NAME>
```
Replace `<NODE_NAME>` with the name of the node.
-->
## 隔离并腾空节点 {#cordon-and-drain-the-node}
1. 隔离节点，阻止新的 Pod 被调度到节点上：
```shell
kubectl cordon <NODE_NAME>
```
将 `<NODE_NAME>` 替换为节点名称。
<!--
1. Drain the node to safely evict running Pods:
-->
2. 腾空节点以安全地逐出所有运行中的 Pod：
```shell
kubectl drain <NODE_NAME> --ignore-daemonsets
```
<!--
## Configure the kubelet to use cri-dockerd
The following steps apply to clusters set up using the kubeadm tool. If you use
a different tool, you should modify the kubelet using the configuration
instructions for that tool.
-->
## 配置 kubelet 使用 cri-dockerd {#configure-the-kubelet-to-use-cri-dockerd}
下面的步骤适用于用 kubeadm 工具安装的集群。如果你使用不同的工具，
你需要使用针对该工具的配置指令来修改 kubelet。
<!--
1. Open `/var/lib/kubelet/kubeadm-flags.env` on each affected node.
1. Modify the `--container-runtime-endpoint` flag to
`unix:///var/run/cri-dockerd.sock`.
-->
1. 在每个被影响的节点上，打开 `/var/lib/kubelet/kubeadm-flags.env` 文件；
1. 将 `--container-runtime-endpoint` 标志，将其设置为 `unix:///var/run/cri-dockerd.sock`。
<!--
The kubeadm tool stores the node's socket as an annotation on the `Node` object
in the control plane. To modify this socket for each affected node:
-->
kubeadm 工具将节点上的套接字存储为控制面上 `Node` 对象的注解。
要为每个被影响的节点更改此套接字：
<!--
1. Edit the YAML representation of the `Node` object:
```shell
KUBECONFIG=/path/to/admin.conf kubectl edit no <NODE_NAME>
```
Replace the following:
* `/path/to/admin.conf`: the path to the kubectl configuration file,
`admin.conf`.
* `<NODE_NAME>`: the name of the node you want to modify.
1. Change `kubeadm.alpha.kubernetes.io/cri-socket` from
`/var/run/dockershim.sock` to `unix:///var/run/cri-dockerd.sock`.
1. Save the changes. The `Node` object is updated on save.
-->
1. 编辑 `Node` 对象的 YAML 表示：
```shell
KUBECONFIG=/path/to/admin.conf kubectl edit no <NODE_NAME>
```
根据下面的说明执行替换：
* `/path/to/admin.conf`：指向 kubectl 配置文件 `admin.conf` 的路径；
* `<NODE_NAME>`：你要修改的节点的名称。
1. 将 `kubeadm.alpha.kubernetes.io/cri-socket` 标志从
`/var/run/dockershim.sock` 更改为 `unix:///var/run/cri-dockerd.sock`；
1. 保存所作更改。保存时，`Node` 对象被更新
<!--
## Restart the kubelet
-->
## 重启 kubelet {#restart-the-kubelet}
```shell
systemctl restart kubelet
```
<!--
## Verify that the node is healthy
To check whether the node uses the `cri-dockerd` endpoint, follow the
instructions in [Find out which runtime you use](/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/).
The `--container-runtime-endpoint` flag for the kubelet should be `unix:///var/run/cri-dockerd.sock`.
-->
## 验证节点处于健康状态 {#verify-that-the-node-is-healthy}
要检查节点是否在使用 `cri-dockerd` 端点，
按照[找出你所使用的运行时](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/)页面所给的指令操作。
kubelet 的 `--container-runtime-endpoint` 标志取值应该是 `unix:///var/run/cri-dockerd.sock`。
<!--
## Uncordon the node
Uncordon the node to let Pods schedule on it:
-->
## 解除节点隔离 {#uncordon-the-node}
```shell
kubectl uncordon <NODE_NAME>
```
## {{% heading "whatsnext" %}}
<!--
* Read the [dockershim removal FAQ](/dockershim/).
* [Learn how to migrate from Docker Engine with dockershim to containerd](/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/).
-->
* 阅读 [dockershim 移除常见问题](/zh/dockershim)。
* [了解如何从基于 dockershim 的 Docker Engine 迁移到 containerd](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/)。
content/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md
+157
View File
@@ -0,0 +1,157 @@
---
title: 从 dockershim 迁移遥测和安全代理
content_type: task
weight: 70
---
<!--
title: Migrating telemetry and security agents from dockershim
content_type: task
reviewers:
- SergeyKanzhelev
weight: 70
-->
<!-- overview -->
<!--
Kubernetes' support for direct integration with Docker Engine is deprecated, and will be removed. Most apps do not have a direct dependency on runtime hosting containers. However, there are still a lot of telemetry and monitoring agents that has a dependency on docker to collect containers metadata, logs and metrics. This document aggregates information on how to detect these dependencies and links on how to migrate these agents to use generic tools or alternative runtimes.
-->
Kubernetes 对与 Docker Engine 直接集成的支持已被弃用并将被删除。
大多数应用程序不直接依赖于托管容器的运行时。但是，仍然有大量的遥测和监控代理依赖
docker 来收集容器元数据、日志和指标。
本文汇总了一些信息和链接：信息用于阐述如何探查这些依赖，链接用于解释如何迁移这些代理去使用通用的工具或其他容器运行。
<!--
## Telemetry and security agents
-->
## 遥测和安全代理 {#telemetry-and-security-agents}
<!--
Within a Kubernetes cluster there are a few different ways to run telemetry or security agents.
Some agents have a direct dependency on Docker Engine when they run as DaemonSets or
directly on nodes.
-->
在 Kubernetes 集群中，有几种不同的方式来运行遥测或安全代理。
一些代理在以 DaemonSet 的形式运行或直接在节点上运行时，直接依赖于 Docker Engine。
<!--
### Why do some telemetry agents communicate with Docker Engine?
-->
### 为什么有些遥测代理会与 Docker Engine 通信？
<!--
Historically, Kubernetes was written to work specifically with Docker Engine.
Kubernetes took care of networking and scheduling, relying on Docker Engine for launching
and running containers (within Pods) on a node. Some information that is relevant to telemetry,
such as a pod name, is only available from Kubernetes components. Other data, such as container
metrics, is not the responsibility of the container runtime. Early telemetry agents needed to query the
container runtime **and** Kubernetes to report an accurate picture. Over time, Kubernetes gained
the ability to support multiple runtimes, and now supports any runtime that is compatible with
the container runtime interface.
-->
从历史上看，Kubernetes 是专门为与 Docker Engine 一起工作而编写的。
Kubernetes 负责网络和调度，依靠 Docker Engine
在节点上启动并运行容器（在 Pod 内）。一些与遥测相关的信息，例如 pod 名称，
只能从 Kubernetes 组件中获得。其他数据，例如容器指标，不是容器运行时的责任。
早期遥测代理需要查询容器运行时**和** Kubernetes 以报告准确的信息。
随着时间的推移，Kubernetes 获得了支持多种运行时的能力，现在支持任何兼容容器运行时接口的运行时。
<!--
Some telemetry agents rely specifically on Docker Engine tooling. For example, an agent
might run a command such as
[`docker ps`](https://docs.docker.com/engine/reference/commandline/ps/)
or [`docker top`](https://docs.docker.com/engine/reference/commandline/top/) to list
containers and processes or [`docker logs`](https://docs.docker.com/engine/reference/commandline/logs/)
+to receive streamed logs. If nodes in your existing cluster use
+Docker Engine, and you switch to a different container runtime,
these commands will not work any longer.
-->
一些代理和 Docker 工具紧密绑定。比如代理会用到
[`docker ps`](https://docs.docker.com/engine/reference/commandline/ps/)
或 [`docker top`](https://docs.docker.com/engine/reference/commandline/top/)
这类命令来列出容器和进程，用
[`docker logs`](https://docs.docker.com/engine/reference/commandline/logs/)
订阅 Docker 的日志。
如果现有集群中的节点使用 Docker Engine，在你切换到其它容器运行时的时候，
这些命令将不再起作用。
<!--
### Identify DaemonSets that depend on Docker Engine {#identify-docker-dependency}
-->
### 识别依赖于 Docker Engine 的 DaemonSet {#identify-docker-dependency}
<!--
If a pod wants to make calls to the `dockerd` running on the node, the pod must either:
- mount the filesystem containing the Docker daemon's privileged socket, as a
{{< glossary_tooltip text="volume" term_id="volume" >}}; or
- mount the specific path of the Docker daemon's privileged socket directly, also as a volume.
-->
如果某 Pod 想调用运行在节点上的 `dockerd`，该 Pod 必须满足以下两个条件之一：
- 将包含 Docker 守护进程特权套接字的文件系统挂载为一个{{< glossary_tooltip text="卷" term_id="volume" >}}；或
- 直接以卷的形式挂载 Docker 守护进程特权套接字的特定路径。
<!--
For example: on COS images, Docker exposes its Unix domain socket at
`/var/run/docker.sock` This means that the pod spec will include a
`hostPath` volume mount of `/var/run/docker.sock`.
-->
举例来说：在 COS 镜像中，Docker 通过 `/var/run/docker.sock` 开放其 Unix 域套接字。
这意味着 Pod 的规约中需要包含 `hostPath` 卷以挂载 `/var/run/docker.sock`。
<!--
Here's a sample shell script to find Pods that have a mount directly mapping the
Docker socket. This script outputs the namespace and name of the pod. You can
remove the `grep '/var/run/docker.sock'` to review other mounts.
-->
下面是一个 shell 示例脚本，用于查找包含直接映射 Docker 套接字的挂载点的 Pod。
你也可以删掉 `grep '/var/run/docker.sock'` 这一代码片段以查看其它挂载信息。
```bash
kubectl get pods --all-namespaces \
-o=jsonpath='{range .items[*]}{"\n"}{.metadata.namespace}{":\t"}{.metadata.name}{":\t"}{range .spec.volumes[*]}{.hostPath.path}{", "}{end}{end}' \
| sort \
| grep '/var/run/docker.sock'
```
<!--
There are alternative ways for a pod to access Docker on the host. For instance, the parent
directory `/var/run` may be mounted instead of the full path (like in [this
example](https://gist.github.com/itaysk/7bc3e56d69c4d72a549286d98fd557dd)).
The script above only detects the most common uses.
-->
{{< note >}}
对于 Pod 来说，访问宿主机上的 Docker 还有其他方式。
例如，可以挂载 `/var/run` 的父目录而非其完整路径
（就像[这个例子](https://gist.github.com/itaysk/7bc3e56d69c4d72a549286d98fd557dd)）。
上述脚本只检测最常见的使用方式。
{{< /note >}}
<!--
### Detecting Docker dependency from node agents
-->
### 检测节点代理对 Docker 的依赖性 {#detecting-docker-dependency-from-node-agents}
<!--
In case your cluster nodes are customized and install additional security and
telemetry agents on the node, make sure to check with the vendor of the agent whether it has dependency on Docker.
-->
在你的集群节点被定制、且在各个节点上均安装了额外的安全和遥测代理的场景下，
一定要和代理的供应商确认：该代理是否依赖于 Docker。
<!--
### Telemetry and security agent vendors
-->
### 遥测和安全代理的供应商 {#telemetry-and-security-agent-vendors}
<!--
We keep the work in progress version of migration instructions for various telemetry and security agent vendors
in [Google doc](https://docs.google.com/document/d/1ZFi4uKit63ga5sxEiZblfb-c23lFhvy6RXVPikS8wf0/edit#).
Please contact the vendor to get up to date instructions for migrating from dockershim.
-->
我们通过
[谷歌文档](https://docs.google.com/document/d/1ZFi4uKit63ga5sxEiZblfb-c23lFhvy6RXVPikS8wf0/edit#)
提供了为各类遥测和安全代理供应商准备的持续更新的迁移指导。
请与供应商联系，获取从 dockershim 迁移的最新说明。