[zh] Resync kubeadm files (1)

2021-04-26 10:34:43 +08:00
parent 1869573927
commit c4438bdce2
7 changed files with 2348 additions and 729 deletions
@@ -6,13 +6,13 @@ content_type: task
 weight: 30
 ---

-<!-- ---
+<!--
 reviewers:
 - sig-cluster-lifecycle
 title: Creating a cluster with kubeadm
 content_type: task
 weight: 30
--- -->
+-->

 <!-- overview -->

@@ -346,6 +346,20 @@ Alternatively, if you are the `root` user, you can run:
 export KUBECONFIG=/etc/kubernetes/admin.conf
 ```

+{{< warning >}}
+<!--
+Kubeadm signs the certificate in the `admin.conf` to have `Subject: O = system:masters, CN = kubernetes-admin`.
+`system:masters` is a break-glass, super user group that bypasses the authorization layer (e.g. RBAC).
+Do not share the `admin.conf` file with anyone and instead grant users custom permissions by generating
+them a kubeconfig file using the `kubeadm kubeconfig user` command.
+-->
+kubeadm 对 `admin.conf` 中的证书进行签名时，将其配置为
+`Subject: O = system:masters, CN = kubernetes-admin`。
+`system:masters` 是一个例外的、超级用户组，可以绕过鉴权层（例如 RBAC）。
+不要将 `admin.conf` 文件与任何人共享，应该使用 `kubeadm kubeconfig user`
+命令为其他用户生成 kubeconfig 文件，完成对他们的定制授权。
+{{< /warning >}}
+
 <!--
 Make a record of the `kubeadm join` command that `kubeadm init` outputs. You
 need this command to [join nodes to your cluster](#join-nodes).
@@ -428,13 +442,14 @@ Cluster DNS (CoreDNS) will not start up before a network is installed.**
 {{< /caution >}}

 <!--
-Currently Calico is the only CNI plugin that the kubeadm project performs e2e tests against.
+Kubeadm should be CNI agnostic and the validation of CNI providers is out of the scope of our current e2e testing.
 If you find an issue related to a CNI plugin you should log a ticket in its respective issue
 tracker instead of the kubeadm or kubernetes issue trackers.
 -->
 {{< note >}}
-目前 Calico 是 kubeadm 项目中执行 e2e 测试的唯一 CNI 插件。
-如果你发现与 CNI 插件相关的问题，应在其各自的问题跟踪器中记录而不是在 kubeadm 或 kubernetes 问题跟踪器中记录。
+kubeadm 应该是与 CNI 无关的，对 CNI 驱动进行验证目前不在我们的端到端测试范畴之内。
+如果你发现与 CNI 插件相关的问题，应在其各自的问题跟踪器中记录而不是在 kubeadm
+或 kubernetes 问题跟踪器中记录。
 {{< /note >}}

 <!--
@@ -1,19 +1,15 @@
 ---
-reviewers:
- sig-cluster-lifecycle
 title: 利用 kubeadm 创建高可用集群
 content_type: task
 weight: 60
 ---

 <!--
---
 reviewers:
 - sig-cluster-lifecycle
 title: Creating Highly Available clusters with kubeadm
 content_type: task
 weight: 60
---
 -->

 <!-- overview -->
@@ -42,12 +38,12 @@ in the kubeadm [issue tracker](https://github.com/kubernetes/kubeadm/issues/new)

 See also [The upgrade documentation](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15).
 -->
-在下一步之前，您应该仔细考虑哪种方法更好的满足您的应用程序和环境的需求。 
+在下一步之前，你应该仔细考虑哪种方法更好的满足你的应用程序和环境的需求。 
 [这是对比文档](/zh/docs/setup/production-environment/tools/kubeadm/ha-topology/) 讲述了每种方法的优缺点。

-如果您在安装 HA 集群时遇到问题，请在 kubeadm [问题跟踪](https://github.com/kubernetes/kubeadm/issues/new)里向我们提供反馈。
+如果你在安装 HA 集群时遇到问题，请在 kubeadm [问题跟踪](https://github.com/kubernetes/kubeadm/issues/new)里向我们提供反馈。

-您也可以阅读 [升级文件](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
+你也可以阅读 [升级文件](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
 <!--
 This page does not address running your cluster on a cloud provider. In a cloud
 environment, neither approach documented here works with Service objects of type
@@ -66,7 +62,7 @@ LoadBalancer, or with dynamic PersistentVolumes.
 For both methods you need this infrastructure:

 - Three machines that meet [kubeadm's minimum requirements](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) for
-  the masters
+  the control-plane nodes
 - Three machines that meet [kubeadm's minimum
  requirements](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) for the workers
 - Full network connectivity between all machines in the cluster (public or
@@ -75,44 +71,47 @@ For both methods you need this infrastructure:
 - SSH access from one device to all nodes in the system
 - `kubeadm` and `kubelet` installed on all machines. `kubectl` is optional.
 -->
-对于这两种方法，您都需要以下基础设施：
+对于这两种方法，你都需要以下基础设施：

- 配置三台机器 [kubeadm 的最低要求](/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) 给主节点
- 配置三台机器 [kubeadm 的最低要求](/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) 给工作节点
- 在集群中，所有计算机之间的完全网络连接（公网或私网）
- 所有机器上的 sudo 权限
- 每台设备对系统中所有节点的 SSH 访问
- 在所有机器上安装 `kubeadm` 和 `kubelet`，`kubectl` 是可选的。
+- 配置满足 [kubeadm 的最低要求](/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin)
+  的三台机器作为控制面节点
+- 配置满足 [kubeadm 的最低要求](/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin)
+  的三台机器作为工作节点
+- 在集群中，确保所有计算机之间存在全网络连接（公网或私网）
+- 在所有机器上具有 sudo 权限
+- 从某台设备通过 SSH 访问系统中所有节点的能力
+- 所有机器上已经安装 `kubeadm` 和 `kubelet`，`kubectl` 是可选的。

 <!--
 For the external etcd cluster only, you also need:

 - Three additional machines for etcd members
 -->
-仅对于外部 etcd 集群来说，您还需要：
+仅对于外部 etcd 集群来说，你还需要：

 - 给 etcd 成员使用的另外三台机器

-
-
 <!-- steps -->

-<!-- ## First steps for both methods -->
+<!--
+## First steps for both methods
+
+### Create load balancer for kube-apiserver
+-->
 ## 这两种方法的第一步

-<!-- ### Create load balancer for kube-apiserver -->
 ### 为 kube-apiserver 创建负载均衡器

+{{< note >}}
 <!--
 There are many configurations for load balancers. The following example is only one
 option. Your cluster requirements may need a different configuration.
 -->
-{{< note >}}
-使用负载均衡器需要许多配置。您的集群搭建可能需要不同的配置。下面的例子只是其中的一方面配置。
+使用负载均衡器需要许多配置。你的集群搭建可能需要不同的配置。
+下面的例子只是其中的一方面配置。
 {{< /note >}}

 <!--
-
 1.  Create a kube-apiserver load balancer with a name that resolves to DNS.

    - In a cloud environment you should place your control plane nodes behind a TCP
@@ -135,15 +134,20 @@ option. Your cluster requirements may need a different configuration.
 -->
 1.  创建一个名为 kube-apiserver 的负载均衡器解析 DNS。

-    - 在云环境中，应该将控制平面节点放置在 TCP 后面转发负载平衡。 该负载均衡器将流量分配给目标列表中所有运行状况良好的控制平面节点。健康检查 apiserver 是在 kube-apiserver 监听端口(默认值 `:6443`)上的一个 TCP 检查。
+    - 在云环境中，应该将控制平面节点放置在 TCP 后面转发负载平衡。
+      该负载均衡器将流量分配给目标列表中所有运行状况良好的控制平面节点。
+      API 服务器的健康检查是在 kube-apiserver 的监听端口（默认值 `:6443`）
+      上进行的一个 TCP 检查。

    - 不建议在云环境中直接使用 IP 地址。

-    - 负载均衡器必须能够在 apiserver 端口上与所有控制平面节点通信。它还必须允许其监听端口的传入流量。
+    - 负载均衡器必须能够在 API 服务器端口上与所有控制平面节点通信。
+      它还必须允许其监听端口的入站流量。

    - 确保负载均衡器的地址始终匹配 kubeadm 的 `ControlPlaneEndpoint` 地址。

-    - 阅读[软件负载平衡选项指南](https://github.com/kubernetes/kubeadm/blob/master/docs/ha-considerations.md#options-for-software-load-balancing)以获取更多详细信息。
+    - 阅读[软件负载平衡选项指南](https://github.com/kubernetes/kubeadm/blob/master/docs/ha-considerations.md#options-for-software-load-balancing)
+      以获取更多详细信息。

 <!--
 1.  Add the first control plane nodes to the load balancer and test the
@@ -166,15 +170,19 @@ option. Your cluster requirements may need a different configuration.
    nc -v LOAD_BALANCER_IP PORT
    ```

-    - 由于 apiserver 尚未运行，预期会出现一个连接拒绝错误。然而超时意味着负载均衡器不能和控制平面节点通信。
-   如果发生超时，请重新配置负载均衡器与控制平面节点进行通信。
+    - 由于 apiserver 尚未运行，预期会出现一个连接拒绝错误。
+      然而超时意味着负载均衡器不能和控制平面节点通信。
+      如果发生超时，请重新配置负载均衡器与控制平面节点进行通信。

 3.  将其余控制平面节点添加到负载均衡器目标组。

-<!-- ## Stacked control plane and etcd nodes -->
+<!--
+## Stacked control plane and etcd nodes
+
+### Steps for the first control plane node
+-->
 ## 使用堆控制平面和 etcd 节点

-<!-- ### Steps for the first control plane node -->
 ### 控制平面节点的第一步

 <!--
@@ -183,8 +191,6 @@ option. Your cluster requirements may need a different configuration.
    ```sh
    sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs
    ```
-
-
    - You can use the `--kubernetes-version` flag to set the Kubernetes version to use.
    It is recommended that the versions of kubeadm, kubelet, kubectl and Kubernetes match.
    - The `--control-plane-endpoint` flag should be set to the address or DNS and port of the load balancer.
@@ -196,142 +202,122 @@ option. Your cluster requirements may need a different configuration.
 -->
 1.  初始化控制平面：

-    ```sh
+    ```shell
    sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs
    ```

-    - 您可以使用 `--kubernetes-version` 标志来设置要使用的 Kubernetes 版本。建议将 kubeadm、kebelet、kubectl 和 Kubernetes 的版本匹配。
+    - 你可以使用 `--kubernetes-version` 标志来设置要使用的 Kubernetes 版本。
+      建议将 kubeadm、kebelet、kubectl 和 Kubernetes 的版本匹配。
    - 这个 `--control-plane-endpoint` 标志应该被设置成负载均衡器的地址或 DNS 和端口。
-    - 这个 `--upload-certs` 标志用来将在所有控制平面实例之间的共享证书上传到集群。如果正好相反，你更喜欢手动地通过控制平面节点或者使用自动化
-   工具复制证书，请删除此标志并参考如下部分[证书分配手册](#manual-certs)。
+    - 这个 `--upload-certs` 标志用来将在所有控制平面实例之间的共享证书上传到集群。
+      如果正好相反，你更喜欢手动地通过控制平面节点或者使用自动化
+      工具复制证书，请删除此标志并参考如下部分[证书分配手册](#manual-certs)。

-<!--
-The `kubeadm init` flags `--config` and `--certificate-key` cannot be mixed, therefore if you want
-to use the [kubeadm configuration](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2) you must add the `certificateKey` field in the appropriate config locations (under `InitConfiguration` and `JoinConfiguration: controlPlane`).
-->
-{{< note >}}
-标志 `kubeadm init`、`--config` 和 `--certificate-key` 不能混合使用，因此如果您要使用[kubeadm 配置](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)，您必须在相应的配置文件（位于 `InitConfiguration` 和 `JoinConfiguration: controlPlane`）添加 `certificateKey` 字段。
-{{< /note >}}
+    {{< note >}}
+    <!--
+    The `kubeadm init` flags `--config` and `--certificate-key` cannot be mixed, therefore if you want
+    to use the [kubeadm configuration](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2) you must add the `certificateKey` field in the appropriate config locations (under `InitConfiguration` and `JoinConfiguration: controlPlane`).
+    -->
+    标志 `kubeadm init`、`--config` 和 `--certificate-key` 不能混合使用，
+    因此如果你要使用
+    [kubeadm 配置](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)，
+    你必须在相应的配置文件
+    （位于 `InitConfiguration` 和 `JoinConfiguration: controlPlane`）添加 `certificateKey` 字段。
+    {{< /note >}}

-<!--
-Some CNI network plugins like Calico require a CIDR such as `192.168.0.0/16` and
-some like Weave do not. See the [CNI network documentation](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network).
-To add a pod CIDR pass the flag `--pod-network-cidr`, or if you are using a kubeadm configuration file
-set the `podSubnet` field under the `networking` object of `ClusterConfiguration`.
-->
-{{< note >}}
-一些 CNI 网络插件如 Calico 需要 CIDR 例如 `192.168.0.0/16` 和一些像 Weave 没有。参考
-[CNI 网络文档](/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)。
-通过传递 `--pod-network-cidr` 标志添加 pod CIDR，或者您可以使用 kubeadm 配置文件，在 `ClusterConfiguration` 的 `networking` 对象下设置 `podSubnet` 字段。
-{{< /note >}}
+    {{< note >}}
+    <!--
+    Some CNI network plugins like Calico require a CIDR such as `192.168.0.0/16` and
+    some like Weave do not. See the [CNI network documentation](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network).
+    To add a pod CIDR pass the flag `--pod-network-cidr`, or if you are using a kubeadm configuration file
+    set the `podSubnet` field under the `networking` object of `ClusterConfiguration`.
+    -->
+    一些 CNI 网络插件如 Calico 需要 CIDR 例如 `192.168.0.0/16` 和一些像 Weave 没有。参考
+    [CNI 网络文档](/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)。
+    通过传递 `--pod-network-cidr` 标志添加 pod CIDR，或者你可以使用 kubeadm
+    配置文件，在 `ClusterConfiguration` 的 `networking` 对象下设置 `podSubnet` 字段。
+    {{< /note >}}

-<!--
-    After the command completes you should see something like so:
+    <!--
+    - The output looks similar to:
+    -->
+    - 输出类似于：

-    ```sh
-    ...
-    You can now join any number of control-plane node by running the following command on each as a root:
-    kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
+      ```sh
+      ...
+      You can now join any number of control-plane node by running the following command on each as a root:
+      kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07

-    Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
-    As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs to reload certs afterward.
+      Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
+      As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs to reload certs afterward.

-    Then you can join any number of worker nodes by running the following on each as root:
-    kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
-    ```
+      Then you can join any number of worker nodes by running the following on each as root:
+        kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
+      ```

+    <!--
    - Copy this output to a text file. You will need it later to join control plane and worker nodes to the cluster.
    - When `--upload-certs` is used with `kubeadm init`, the certificates of the primary control plane
    are encrypted and uploaded in the `kubeadm-certs` Secret.
    - To re-upload the certificates and generate a new decryption key, use the following command on a control plane
    node that is already joined to the cluster:
-
-      ```sh
-      sudo kubeadm init phase upload-certs --upload-certs
-      ```
-
-    - You can also specify a custom `--certificate-key` during `init` that can later be used by `join`.
-    To generate such a key you can use the following command:
-
-      ```sh
-      kubeadm alpha certs certificate-key
-      ```
-
-->
-
- 命令完成后，您应该会看到类似以下内容：
-
-    ```sh
-    ...
-    现在，您可以通过在根目录上运行以下命令来加入任意数量的控制平面节点：
-    kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
-
-    请注意，证书密钥可以访问集群内敏感数据，请保密！
-    为了安全起见，将在两个小时内删除上传的证书； 如有必要，您可以使用 kubeadm 初始化上传证书阶段，之后重新加载证书。
-
-    然后，您可以通过在根目录上运行以下命令来加入任意数量的工作节点：
-    kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
-    ```
-
-    - 将此输出复制到文本文件。 稍后您将需要它来将控制平面节点和辅助节点加入集群。
-    - 当 `--upload-certs` 与 `kubeadm init` 一起使用时，主控制平面的证书被加密并上传到 `kubeadm-certs` 密钥中。
+    -->
+    - 将此输出复制到文本文件。 稍后你将需要它来将控制平面节点和工作节点加入集群。
+    - 当 `--upload-certs` 与 `kubeadm init` 一起使用时，主控制平面的证书
+      被加密并上传到 `kubeadm-certs` Secret 中。
    - 要重新上传证书并生成新的解密密钥，请在已加入集群节点的控制平面上使用以下命令：

-      ```sh
+      ```shell
      sudo kubeadm init phase upload-certs --upload-certs
      ```
+    <!--
+    - You can also specify a custom `--certificate-key` during `init` that can later be used by `join`.
+      To generate such a key you can use the following command:
+    -->
+    - 你还可以在 `init` 期间指定自定义的 `--certificate-key`，以后可以由 `join` 使用。
+      要生成这样的密钥，可以使用以下命令：

-    - 您还可以在 `init` 期间指定自定义的 `--certificate-key`，以后可以由 `join` 使用。
-    要生成这样的密钥，可以使用以下命令：
-
-      ```sh
-      kubeadm alpha certs certificate-key
+      ```shell
+      kubeadm certs certificate-key
      ```

-<!--
-The `kubeadm-certs` Secret and decryption key expire after two hours.
-->
-{{< note >}}
-`kubeadm-certs` 密钥和解密密钥会在两个小时后失效。
-{{< /note >}}
+    {{< note >}}
+    <!--
+    The `kubeadm-certs` Secret and decryption key expire after two hours.
+    -->
+    `kubeadm-certs` 密钥和解密密钥会在两个小时后失效。
+    {{< /note >}}

-<!--
-As stated in the command output, the certificate key gives access to cluster sensitive data, keep it secret!
-->
-{{< caution >}}
-正如命令输出中所述，证书密钥可访问群集敏感数据，并将其保密！
-{{< /caution >}}
+    {{< caution >}}
+    <!--
+    As stated in the command output, the certificate key gives access to cluster sensitive data, keep it secret!
+    -->
+    正如命令输出中所述，证书密钥可访问群集敏感数据。请妥善保管！
+    {{< /caution >}}

 <!--
 1.  Apply the CNI plugin of your choice:
    [Follow these instructions](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network) to install the CNI provider. Make sure the configuration corresponds to the Pod CIDR specified in the kubeadm configuration file if applicable.

    In this example we are using Weave Net:
-
-    ```sh
-    kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
-    ```
-
-1.  Type the following and watch the pods of the control plane components get started:
-
-    ```sh
-    kubectl get pod -n kube-system -w
-    ```
-
 -->
-1.  应用您选择的 CNI 插件：
+2.  应用你所选择的 CNI 插件：
    [请遵循以下指示](/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)
-    安装 CNI 提供程序。如果适用，请确保配置与 kubeadm 配置文件中指定的 Pod CIDR 相对应。
+    安装 CNI 提供程序。如果适用，请确保配置与 kubeadm 配置文件中指定的 Pod
+    CIDR 相对应。

    在此示例中，我们使用 Weave Net：

-    ```sh
+    ```shell
    kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
    ```

-1.  输入以下内容，并查看 pods 的控制平面组件启动：
+<!--
+1.  Type the following and watch the pods of the control plane components get started:
+-->
+3.  输入以下内容，并查看控制平面组件的 Pods 启动：

-    ```sh
+    ```shell
    kubectl get pod -n kube-system -w
    ```

@@ -340,14 +326,14 @@ As stated in the command output, the certificate key gives access to cluster sen
 -->
 ### 其余控制平面节点的步骤

+{{< note >}}
 <!--
 Since kubeadm version 1.15 you can join multiple control-plane nodes in parallel.
 Prior to this version, you must join new control plane nodes sequentially, only after
 the first node has finished initializing.
 -->
-{{< note >}}
-从 kubeadm 1.15 版本开始，您可以并行加入多个控制平面节点。
-在此版本之前，您必须在第一个节点初始化后才能依序的增加新的控制平面节点。
+从 kubeadm 1.15 版本开始，你可以并行加入多个控制平面节点。
+在此版本之前，你必须在第一个节点初始化后才能依序的增加新的控制平面节点。
 {{< /note >}}

 <!--
@@ -365,9 +351,9 @@ For each additional control plane node you should:
    from the `kubeadm-certs` Secret in the cluster and be decrypted using the given key.

 -->
-对于每个其他控制平面节点，您应该：
+对于每个其他控制平面节点，你应该：

-1.  执行先前由第一个节点上的 `kubeadm init` 输出提供给您的 join 命令。
+1.  执行先前由第一个节点上的 `kubeadm init` 输出提供给你的 join 命令。
    它看起来应该像这样：

    ```sh
@@ -375,7 +361,8 @@ For each additional control plane node you should:
    ```

    - 这个 `--control-plane` 命令通知 `kubeadm join` 创建一个新的控制平面。
-    - `--certificate-key ...` 将导致从集群中的 `kubeadm-certs` 秘钥下载控制平面证书并使用给定的密钥进行解密。
+    - `--certificate-key ...` 将导致从集群中的 `kubeadm-certs` Secret 下载
+      控制平面证书并使用给定的密钥进行解密。

 <!--
 ## External etcd nodes
@@ -384,11 +371,10 @@ Setting up a cluster with external etcd nodes is similar to the procedure used f
 with the exception that you should setup etcd first, and you should pass the etcd information
 in the kubeadm config file.
 -->
-
 ## 外部 etcd 节点

 使用外部 etcd 节点设置集群类似于用于堆叠 etcd 的过程，
-不同之处在于您应该首先设置 etcd，并在 kubeadm 配置文件中传递 etcd 信息。
+不同之处在于你应该首先设置 etcd，并在 kubeadm 配置文件中传递 etcd 信息。

 <!--
 ### Set up the etcd cluster
@@ -406,19 +392,18 @@ in the kubeadm config file.
    scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}":
    ```

-    - Replace the value of `CONTROL_PLANE` with the `user@host` of the first control plane machine.
-
+    - Replace the value of `CONTROL_PLANE` with the `user@host` of the first control-plane machine.
 -->
-
 ### 设置 ectd 集群

-1.  按照 [这些指示](/zh/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) 去设置 etcd 集群。
+1.  按照 [这些指示](/zh/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) 
+    去设置 etcd 集群。

-1.  设置 SSH 在 [这](#manual-certs)描述。
+1.  根据[这里](#manual-certs)的描述配置 SSH。

 1.  将以下文件从集群中的任何 etcd 节点复制到第一个控制平面节点：

-    ```sh
+    ```shell
    export CONTROL_PLANE="ubuntu@10.0.0.7"
    scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}":
    scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}":
@@ -432,93 +417,86 @@ in the kubeadm config file.

 1.  Create a file called `kubeadm-config.yaml` with the following contents:

-        apiVersion: kubeadm.k8s.io/v1beta2
-        kind: ClusterConfiguration
-        kubernetesVersion: stable
-        controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
-        etcd:
-            external:
-                endpoints:
-                - https://ETCD_0_IP:2379
-                - https://ETCD_1_IP:2379
-                - https://ETCD_2_IP:2379
-                caFile: /etc/kubernetes/pki/etcd/ca.crt
-                certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
-                keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
-
+    ```yaml
+    apiVersion: kubeadm.k8s.io/v1beta2
+    kind: ClusterConfiguration
+    kubernetesVersion: stable
+    controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
+    etcd:
+        external:
+            endpoints:
+            - https://ETCD_0_IP:2379
+            - https://ETCD_1_IP:2379
+            - https://ETCD_2_IP:2379
+            caFile: /etc/kubernetes/pki/etcd/ca.crt
+            certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
+            keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
+    ```
 -->

 ### 设置第一个控制平面节点

 1.  用以下内容创建一个名为 `kubeadm-config.yaml` 的文件：

-        apiVersion: kubeadm.k8s.io/v1beta2
-        kind: ClusterConfiguration
-        kubernetesVersion: stable
-        controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
-        etcd:
-            external:
-                endpoints:
-                - https://ETCD_0_IP:2379
-                - https://ETCD_1_IP:2379
-                - https://ETCD_2_IP:2379
-                caFile: /etc/kubernetes/pki/etcd/ca.crt
-                certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
-                keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
+    ```yaml
+    apiVersion: kubeadm.k8s.io/v1beta2
+    kind: ClusterConfiguration
+    kubernetesVersion: stable
+    controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
+    etcd:
+        external:
+            endpoints:
+            - https://ETCD_0_IP:2379
+            - https://ETCD_1_IP:2379
+            - https://ETCD_2_IP:2379
+            caFile: /etc/kubernetes/pki/etcd/ca.crt
+            certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
+            keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
+    ```

-<!--
-The difference between stacked etcd and external etcd here is that the external etcd setup requires
-a configuration file with the etcd endpoints under the `external` object for `etcd`.
-In the case of the stacked etcd topology this is managed automatically.
-->
-{{< note >}}
-这里堆 etcd 和外部 etcd 之前的区别在于设置外部 etcd 需要一个 `etcd` 的 `external` 对象下带有 etcd 端点的配置文件。
-如果是堆 etcd 技术，是自动管理的。
-{{< /note >}}
-
-<!--
+    {{< note >}}
+    <!--
+    The difference between stacked etcd and external etcd here is that the external etcd setup requires
+    a configuration file with the etcd endpoints under the `external` object for `etcd`.
+    In the case of the stacked etcd topology this is managed automatically.
+    -->
+    这里的内部（stacked） etcd 和外部 etcd 之前的区别在于设置外部 etcd
+    需要一个 `etcd` 的 `external` 对象下带有 etcd 端点的配置文件。
+    如果是内部 etcd，是自动管理的。
+    {{< /note >}}

+    <!--
    -  Replace the following variables in the config template with the appropriate values for your cluster:
+    -->
+    - 在你的集群中，将配置模板中的以下变量替换为适当值：

-        - `LOAD_BALANCER_DNS`
-        - `LOAD_BALANCER_PORT`
-        - `ETCD_0_IP`
-        - `ETCD_1_IP`
-        - `ETCD_2_IP`
+      - `LOAD_BALANCER_DNS`
+      - `LOAD_BALANCER_PORT`
+      - `ETCD_0_IP`
+      - `ETCD_1_IP`
+      - `ETCD_2_IP`

+<!--
 The following steps are similar to the stacked etcd setup:
+-->
+以下的步骤与设置内置 etcd 的集群是相似的：

+<!--
 1.  Run `sudo kubeadm init --config kubeadm-config.yaml --upload-certs` on this node.

 1.  Write the output join commands that are returned to a text file for later use.

 1.  Apply the CNI plugin of your choice. The given example is for Weave Net:
-
-    ```sh
-    kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
-    ```
-
 -->
+1. 在节点上运行 `sudo kubeadm init --config kubeadm-config.yaml --upload-certs` 命令。

-  在您的集群中，将配置模板中的以下变量替换为适当值：
+1. 记下输出的 join 命令，这些命令将在以后使用。

-    - `LOAD_BALANCER_DNS`
-    - `LOAD_BALANCER_PORT`
-    - `ETCD_0_IP`
-    - `ETCD_1_IP`
-    - `ETCD_2_IP`
+1. 应用你选择的 CNI 插件。以下示例适用于 Weave Net：

-以下的步骤与设置堆集群是相似的：
-
-1.  在节点上运行 `sudo kubeadm init --config kubeadm-config.yaml --upload-certs` 命令。
-
-1.  编写输出联接命令，这些命令将返回到文本文件以供以后使用。
-
-1.  应用您选择的 CNI 插件。 给定以下示例适用于 Weave Net：
-
-    ```sh
-    kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
-    ```
+   ```shell
+   kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
+   ```

 <!--
 ### Steps for the rest of the control plane nodes
@@ -529,34 +507,30 @@ The steps are the same as for the stacked etcd setup:
 - Join each control plane node with the join command you saved to a text file. It's recommended
 to join the control plane nodes one at a time.
 - Don't forget that the decryption key from `--certificate-key` expires after two hours, by default.
-
 -->
-
 ### 其他控制平面节点的步骤

-步骤与设置堆 etcd 相同：
+步骤与设置内置 etcd 相同：

 - 确保第一个控制平面节点已完全初始化。
- 使用保存到文本文件的连接命令将每个控制平面节点连接在一起。建议一次加入一个控制平面节点。
+- 使用保存到文本文件的 join 命令将每个控制平面节点连接在一起。
+  建议一次加入一个控制平面节点。
 - 不要忘记默认情况下，`--certificate-key` 中的解密秘钥会在两个小时后过期。

-<!-- ## Common tasks after bootstrapping control plane -->
+<!--
+## Common tasks after bootstrapping control plane
+
+### Install workers
+-->
 ## 列举控制平面之后的常见任务

-<!-- ### Install workers -->
 ### 安装工作节点

 <!--
 Worker nodes can be joined to the cluster with the command you stored previously
 as the output from the `kubeadm init` command:
-
-```sh
-sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
-```
-
 -->
-您可以使用之前存储的命令将工作节点加入集群中
-作为 `kubeadm init` 命令的输出：
+你可以使用之前存储的 `kubeadm init` 命令的输出将工作节点加入集群中：

 ```sh
 sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
@@ -573,11 +547,10 @@ There are many ways to do this. In the following example we are using `ssh` and

 SSH is required if you want to control all nodes from a single machine.
 -->
-
 ## 手动证书分发 {#manual-certs}

-如果您选择不将 `kubeadm init` 与 `--upload-certs` 命令一起使用，
-则意味着您将必须手动将证书从主控制平面节点复制到
+如果你选择不将 `kubeadm init` 与 `--upload-certs` 命令一起使用，
+则意味着你将必须手动将证书从主控制平面节点复制到
 将要加入的控制平面节点上。

 有许多方法可以实现这种操作。在下面的例子中我们使用 `ssh` 和 `scp`：
@@ -585,147 +558,106 @@ SSH is required if you want to control all nodes from a single machine.
 如果要在单独的一台计算机控制所有节点，则需要 SSH。

 <!--
-1.  Enable ssh-agent on your main device that has access to all other nodes in
-    the system:
-
-    ```
-    eval $(ssh-agent)
-    ```
-
-1.  Add your SSH identity to the session:
-
-    ```
-    ssh-add ~/.ssh/path_to_private_key
-    ```
-
-1.  SSH between nodes to check that the connection is working correctly.
-
-    - When you SSH to any node, make sure to add the `-A` flag:
-
-        ```
-        ssh -A 10.0.0.7
-        ```
-
-    - When using sudo on any node, make sure to preserve the environment so SSH
-      forwarding works:
-
-        ```
-        sudo -E -s
-        ```
-
+1. Enable ssh-agent on your main device that has access to all other nodes in
+   the system:
 -->
+1. 在你的主设备上启用 ssh-agent，要求该设备能访问系统中的所有其他节点：

-1.  在您的主设备上启动 ssh-agent，要求该设备能访问系统中的所有其他节点：
+   ```shell
+   eval $(ssh-agent)
+   ```

-    ```
-    eval $(ssh-agent)
-    ```
+<!--
+1. Add your SSH identity to the session:
+-->
+2. 将 SSH 身份添加到会话中：

-1.  将 SSH 身份添加到会话中：
+   ```shell
+   ssh-add ~/.ssh/path_to_private_key
+   ```

-    ```
-    ssh-add ~/.ssh/path_to_private_key
-    ```
+<!--
+1. SSH between nodes to check that the connection is working correctly.
+-->
+3. 检查节点间的 SSH 以确保连接是正常运行的

-1.  检查节点间的 SSH 以确保连接是正常运行的
+   <!--
+   - When you SSH to any node, make sure to add the `-A` flag:
+   -->
+   - SSH 到任何节点时，请确保添加 `-A` 标志：

-    - SSH 到任何节点时，请确保添加 `-A` 标志：
+     ```shell
+     ssh -A 10.0.0.7
+     ```

-        ```
-        ssh -A 10.0.0.7
-        ```
-
-    - 当在任何节点上使用 sudo 时，请确保环境完善，以便使用 SSH
-      转发任务：
-
-        ```
-        sudo -E -s
-        ```
+   <!--
+   - When using sudo on any node, make sure to preserve the environment so SSH
+     forwarding works:
+   -->
+   - 当在任何节点上使用 sudo 时，请确保保持环境变量设置，以便 SSH
+     转发能够正常工作：

+     ```shell
+     sudo -E -s
+     ```
 <!--
 1. After configuring SSH on all the nodes you should run the following script on the first control plane node after
   running `kubeadm init`. This script will copy the certificates from the first control plane node to the other
   control plane nodes:
-
-    In the following example, replace `CONTROL_PLANE_IPS` with the IP addresses of the
-    other control plane nodes.
-    ```sh
-    USER=ubuntu # customizable
-    CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8"
-    for host in ${CONTROL_PLANE_IPS}; do
-        scp /etc/kubernetes/pki/ca.crt "${USER}"@$host:
-        scp /etc/kubernetes/pki/ca.key "${USER}"@$host:
-        scp /etc/kubernetes/pki/sa.key "${USER}"@$host:
-        scp /etc/kubernetes/pki/sa.pub "${USER}"@$host:
-        scp /etc/kubernetes/pki/front-proxy-ca.crt "${USER}"@$host:
-        scp /etc/kubernetes/pki/front-proxy-ca.key "${USER}"@$host:
-        scp /etc/kubernetes/pki/etcd/ca.crt "${USER}"@$host:etcd-ca.crt
-        scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key
-    done
-    ```
-
 -->
-
-1. 在所有节点上配置 SSH 之后，您应该在运行过 `kubeadm init` 命令的第一个控制平面节点上运行以下脚本。
+4. 在所有节点上配置 SSH 之后，你应该在运行过 `kubeadm init` 命令的第一个
+   控制平面节点上运行以下脚本。
   该脚本会将证书从第一个控制平面节点复制到另一个控制平面节点：

-    在以下示例中，用其他控制平面节点的 IP 地址替换 `CONTROL_PLANE_IPS`。
+   <!--
+   In the following example, replace `CONTROL_PLANE_IPS` with the IP addresses of the
+   other control plane nodes.
+   -->
+   在以下示例中，用其他控制平面节点的 IP 地址替换 `CONTROL_PLANE_IPS`。

-    ```sh
-    USER=ubuntu # 可自己设置
-    CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8"
-    for host in ${CONTROL_PLANE_IPS}; do
-        scp /etc/kubernetes/pki/ca.crt "${USER}"@$host:
-        scp /etc/kubernetes/pki/ca.key "${USER}"@$host:
-        scp /etc/kubernetes/pki/sa.key "${USER}"@$host:
-        scp /etc/kubernetes/pki/sa.pub "${USER}"@$host:
-        scp /etc/kubernetes/pki/front-proxy-ca.crt "${USER}"@$host:
-        scp /etc/kubernetes/pki/front-proxy-ca.key "${USER}"@$host:
-        scp /etc/kubernetes/pki/etcd/ca.crt "${USER}"@$host:etcd-ca.crt
-        scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key
-    done
-    ```
+   ```sh
+   USER=ubuntu # 可定制
+   CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8"
+   for host in ${CONTROL_PLANE_IPS}; do
+       scp /etc/kubernetes/pki/ca.crt "${USER}"@$host:
+       scp /etc/kubernetes/pki/ca.key "${USER}"@$host:
+       scp /etc/kubernetes/pki/sa.key "${USER}"@$host:
+       scp /etc/kubernetes/pki/sa.pub "${USER}"@$host:
+       scp /etc/kubernetes/pki/front-proxy-ca.crt "${USER}"@$host:
+       scp /etc/kubernetes/pki/front-proxy-ca.key "${USER}"@$host:
+       scp /etc/kubernetes/pki/etcd/ca.crt "${USER}"@$host:etcd-ca.crt
+       scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key
+   done
+   ```

-<!--
-Copy only the certificates in the above list. kubeadm will take care of generating the rest of the certificates
-with the required SANs for the joining control-plane instances. If you copy all the certificates by mistake,
-the creation of additional nodes could fail due to a lack of required SANs.
-->
-{{< caution >}}
-只需要复制上面列表中的证书。kubeadm 将负责生成其余证书以及加入控制平面实例所需的 SAN。
-如果您错误地复制了所有证书，由于缺少所需的 SAN，创建其他节点可能会失败。
-{{< /caution >}}
+   {{< caution >}}
+   <!--
+   Copy only the certificates in the above list. kubeadm will take care of generating the rest of the certificates
+   with the required SANs for the joining control-plane instances. If you copy all the certificates by mistake,
+   the creation of additional nodes could fail due to a lack of required SANs.
+   -->
+   只需要复制上面列表中的证书。kubeadm 将负责生成其余证书以及加入控制平面实例所需的 SAN。
+   如果你错误地复制了所有证书，由于缺少所需的 SAN，创建其他节点可能会失败。
+   {{< /caution >}}

 <!--
 1. Then on each joining control plane node you have to run the following script before running `kubeadm join`.
   This script will move the previously copied certificates from the home directory to `/etc/kubernetes/pki`:
-
-    ```sh
-    USER=ubuntu # customizable
-    mkdir -p /etc/kubernetes/pki/etcd
-    mv /home/${USER}/ca.crt /etc/kubernetes/pki/
-    mv /home/${USER}/ca.key /etc/kubernetes/pki/
-    mv /home/${USER}/sa.pub /etc/kubernetes/pki/
-    mv /home/${USER}/sa.key /etc/kubernetes/pki/
-    mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/
-    mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/
-    mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt
-    mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key
-    ```
 -->
-
-1. 然后，在每个连接控制平面节点上，您必须先运行以下脚本，然后再运行 `kubeadm join`。
+5. 然后，在每个即将加入集群的控制平面节点上，你必须先运行以下脚本，然后
+   再运行 `kubeadm join`。
   该脚本会将先前复制的证书从主目录移动到 `/etc/kubernetes/pki`：

-    ```sh
-    USER=ubuntu # 可自己设置
-    mkdir -p /etc/kubernetes/pki/etcd
-    mv /home/${USER}/ca.crt /etc/kubernetes/pki/
-    mv /home/${USER}/ca.key /etc/kubernetes/pki/
-    mv /home/${USER}/sa.pub /etc/kubernetes/pki/
-    mv /home/${USER}/sa.key /etc/kubernetes/pki/
-    mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/
-    mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/
-    mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt
-    mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key
-    ```
+   ```shell
+   USER=ubuntu # 可定制
+   mkdir -p /etc/kubernetes/pki/etcd
+   mv /home/${USER}/ca.crt /etc/kubernetes/pki/
+   mv /home/${USER}/ca.key /etc/kubernetes/pki/
+   mv /home/${USER}/sa.pub /etc/kubernetes/pki/
+   mv /home/${USER}/sa.key /etc/kubernetes/pki/
+   mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/
+   mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/
+   mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt
+   mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key
+   ```
+
@@ -495,66 +495,36 @@ kubeadm to tell it what to do.
 kubelet 现在每隔几秒就会重启，因为它陷入了一个等待 kubeadm 指令的死循环。

 <!--
-## Configure cgroup driver used by kubelet on control-plane node
+## Configure cgroup driver

-When using Docker, kubeadm will automatically detect the cgroup driver for the kubelet
-and set it in the `/var/lib/kubelet/kubeadm-flags.env` file during runtime.
-
-If you are using a different CRI, you must pass your `cgroupDriver` value to `kubeadm init`, like so:
+Both the container runtime and the kubelet have a property called
+["cgroup driver"](/docs/setup/production-environment/container-runtimes/), which is important
+for the management of cgroups on Linux machines.
 -->
-## 在控制平面节点上配置 kubelet 使用的 cgroup 驱动程序  {#configure-cgroup-driver-used-by-kubelet-on-contol-plane-node}
+## 配置 cgroup 驱动程序  {#configure-cgroup-driver}

-使用 Docker 时，kubeadm 会自动为其检测 cgroup 驱动并在运行时对
-`/var/lib/kubelet/kubeadm-flags.env` 文件进行配置。
-
-如果你在使用不同的 CRI，你必须为 `kubeadm init` 传递 `cgroupDriver`
-值，像这样：
-
-```yaml
-apiVersion: kubelet.config.k8s.io/v1beta1
-kind: KubeletConfiguration
-cgroupDriver: <value>
-```
+容器运行时和 kubelet 都具有名字为 
+["cgroup driver"](/zh/docs/setup/production-environment/container-runtimes/)
+的属性，该属性对于在 Linux 机器上管理 CGroups 而言非常重要。

+{{< warning >}}
 <!--
-For further details, please read [Using kubeadm init with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file)
-and the [`KubeletConfiguration` reference](/docs/reference/config-api/kubelet-config.v1beta1/)
+Matching the container runtime and kubelet cgroup drivers is required or otherwise the kubelet process will fail.

-Please mind, that you **only** have to do that if the cgroup driver of your CRI
-is not `cgroupfs`, because that is the default value in the kubelet already.
+See [Configuring a cgroup driver](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/) for more details.
 -->
-进一步的相关细节，可参阅
-[使用配置文件来执行 kubeadm init](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file) 以及 [KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/)。
+你需要确保容器运行时和 kubelet 所使用的是相同的 cgroup 驱动，否则 kubelet
+进程会失败。

-请注意，你只需要在你的 cgroup 驱动程序不是 `cgroupfs` 时这么做，
-因为它已经是 kubelet 中的默认值。
-
-{{< note >}}
-<!--
-Since `--cgroup-driver` flag has been deprecated by the kubelet, if you have that in `/var/lib/kubelet/kubeadm-flags.env`
-or `/etc/default/kubelet`(`/etc/sysconfig/kubelet` for RPMs), please remove it and use the KubeletConfiguration instead
-(stored in `/var/lib/kubelet/config.yaml` by default).
-->
-由于 kubelet 已经弃用了 `--cgroup-driver` 标志，如果你在配置文件
-`/var/lib/kubelet/kubeadm-flags.env` 或者 `/etc/default/kubelet`
-（对于 RPM 而言是 `/etc/sysconfig/kubelet`）包含此设置，请将其删除
-并使用 KubeletConfiguration 作为替代（默认存储于
-`/var/lib/kubelet/config.yaml` 文件中）。
-{{< /note >}}
-
-<!--
-The automatic detection of cgroup driver for other container runtimes
-like CRI-O and containerd is work in progress.
-->
-自动检测其他容器运行时（例如 CRI-O 和 containerd）的 cgroup 驱动的相关
-工作扔在进行中。
+相关细节可参见[配置 cgroup 驱动](/zh/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)。
+{{< /warning >}}

 <!--
 ## Troubleshooting

 If you are running into difficulties with kubeadm, please consult our [troubleshooting docs](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/).
 -->
-## 故障排查
+## 故障排查   {#troubleshooting}

 如果你在使用 kubeadm 时遇到困难，请参阅我们的
 [故障排查文档](/zh/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/)。
@@ -6,13 +6,11 @@ content_type: concept
 weight: 80
 ---
 <!--
---
 reviewers:
 - sig-cluster-lifecycle
 title: Configuring each kubelet in your cluster using kubeadm
 content_type: concept
 weight: 80
---
 -->

 <!-- overview -->
@@ -33,10 +31,11 @@ manager instead, but you need to configure it manually.
 Some kubelet configuration details need to be the same across all kubelets involved in the cluster, while
 other configuration aspects need to be set on a per-kubelet basis to accommodate the different
 characteristics of a given machine (such as OS, storage, and networking). You can manage the configuration
-of your kubelets manually, but kubeadm now provides a `KubeletConfiguration` API type for [managing your
-kubelet configurations centrally](#configure-kubelets-using-kubeadm).
+of your kubelets manually, but kubeadm now provides a `KubeletConfiguration` API type for
+[managing your kubelet configurations centrally](#configure-kubelets-using-kubeadm).
 -->
-kubeadm CLI 工具的生命周期与 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet)解耦，它是一个守护程序，在 Kubernetes 集群中的每个节点上运行。
+kubeadm CLI 工具的生命周期与 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet)
+解耦；kubelet 是一个守护程序，在 Kubernetes 集群中的每个节点上运行。
 当 Kubernetes 初始化或升级时，kubeadm CLI 工具由用户执行，而 kubelet 始终在后台运行。

 由于kubelet是守护程序，因此需要通过某种初始化系统或服务管理器进行维护。
@@ -48,8 +47,6 @@ kubeadm CLI 工具的生命周期与 [kubelet](/zh/docs/reference/command-line-t
 你可以手动地管理 kubelet 的配置，但是 kubeadm 现在提供一种 `KubeletConfiguration` API 类型
 用于[集中管理 kubelet 的配置](#configure-kubelets-using-kubeadm)。

-
-
 <!-- body -->

 <!--
@@ -80,8 +77,9 @@ Virtual IPs for services are now allocated from this subnet. You also need to se
 by the kubelet, using the `--cluster-dns` flag. This setting needs to be the same for every kubelet
 on every manager and Node in the cluster. The kubelet provides a versioned, structured API object
 that can configure most parameters in the kubelet and push out this configuration to each running
-kubelet in the cluster. This object is called **the kubelet's ComponentConfig**.
-The ComponentConfig allows the user to specify flags such as the cluster DNS IP addresses expressed as
+kubelet in the cluster. This object is called
+[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/). 
+The `KubeletConfiguration` allows the user to specify flags such as the cluster DNS IP addresses expressed as
 a list of values to a camelCased key, illustrated by the following example:

 ```yaml
@@ -90,6 +88,8 @@ kind: KubeletConfiguration
 clusterDNS:
 - 10.96.0.10
 ```
+
+For more details on the `KubeletConfiguration` have a look at [this section](#configure-kubelets-using-kubeadm).
 -->
 ### 将集群级配置传播到每个 kubelet 中

@@ -106,8 +106,8 @@ kubeadm init --service-cidr 10.96.0.0/12
 你还需要通过 kubelet 使用 `--cluster-dns` 标志设置 DNS 地址。
 在集群中的每个管理器和节点上的 kubelet 的设置需要相同。
 kubelet 提供了一个版本化的结构化 API 对象，该对象可以配置 kubelet 中的大多数参数，并将此配置推送到集群中正在运行的每个 kubelet 上。
-此对象被称为 **kubelet 的配置组件**。
-该配置组件允许用户指定标志，例如用骆峰值代表集群的 DNS IP 地址，如下所示：
+此对象被称为 [`KubeletConfiguration`](/zh/docs/reference/config-api/kubelet-config.v1beta1/)。
+`KubeletConfiguration` 允许用户指定标志，例如用骆峰值代表集群的 DNS IP 地址，如下所示：

 ```yaml
 apiVersion: kubelet.config.k8s.io/v1beta1
@@ -116,7 +116,7 @@ clusterDNS:
 - 10.96.0.10
 ```

-有关组件配置的更多详细信息，亲参阅 [本节](#configure-kubelets-using-kubeadm)。
+有关 `KubeletConfiguration` 的更多详细信息，亲参阅[本节](#configure-kubelets-using-kubeadm)。

 <!--
 ### Providing instance-specific configuration details
@@ -175,8 +175,8 @@ API object is passed with a configuration file like so `kubeadm ... --config som
 By calling `kubeadm config print init-defaults --component-configs KubeletConfiguration` you can
 see all the default values for this structure.

-Also have a look at the [API reference for the
-kubelet ComponentConfig](https://godoc.org/k8s.io/kubernetes/pkg/kubelet/apis/config#KubeletConfiguration)
+Also have a look at the
+[reference for the KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/)
 for more information on the individual fields.
 -->
 ## 使用 kubeadm 配置 kubelet
@@ -186,7 +186,8 @@ for more information on the individual fields.
 通过调用 `kubeadm config print init-defaults --component-configs KubeletConfiguration`，
 你可以看到此结构中的所有默认值。

-也可以阅读 [kubelet 配置组件的 API 参考](https://godoc.org/k8s.io/kubernetes/pkg/kubelet/apis/config#KubeletConfiguration)来获取有关各个字段的更多信息。
+也可以阅读 [KubeletConfiguration 参考](/docs/reference/config-api/kubelet-config.v1beta1/)
+来获取有关各个字段的更多信息。

 <!--
 ### Workflow when using `kubeadm init`
@@ -291,9 +292,13 @@ kubelet 使用这些证书执行 TLS 引导程序并获取唯一的凭据，该
 `kubeadm` ships with configuration for how systemd should run the kubelet.
 Note that the kubeadm CLI command never touches this drop-in file.

-This configuration file installed by the `kubeadm` [DEB](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf) or [RPM package](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/rpm/kubeadm/10-kubeadm.conf) is written to
+This configuration file installed by the `kubeadm`
+[DEB](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf) or
+[RPM package](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/rpm/kubeadm/10-kubeadm.conf) is written to
 `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` and is used by systemd.
-It augments the basic [`kubelet.service` for RPM](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/rpm/kubelet/kubelet.service) or [`kubelet.service` for DEB](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service):
+It augments the basic
+[`kubelet.service` for RPM](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/rpm/kubelet/kubelet.service) or
+[`kubelet.service` for DEB](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service):

 ```none
 [Service]
@@ -365,14 +370,14 @@ ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELE

 The DEB and RPM packages shipped with the Kubernetes releases are:

-| Package name | Description |
-|--------------|-------------|
-| `kubeadm`    | Installs the `/usr/bin/kubeadm` CLI tool and the [kubelet drop-in file](#the-kubelet-drop-in-file-for-systemd) for the kubelet. |
-| `kubelet`    | Installs the kubelet binary in `/usr/bin` and CNI binaries in `/opt/cni/bin`. |
-| `kubectl`    | Installs the `/usr/bin/kubectl` binary. |
-| `cri-tools` | Installs the `/usr/bin/crictl` binary from the [cri-tools git repository](https://github.com/kubernetes-sigs/cri-tools). |
+| Package name   | Description |
+|----------------|-------------|
+| `kubeadm`      | Installs the `/usr/bin/kubeadm` CLI tool and the [kubelet drop-in file](#the-kubelet-drop-in-file-for-systemd) for the kubelet. |
+| `kubelet`      | Installs the kubelet binary in `/usr/bin` and CNI binaries in `/opt/cni/bin`. |
+| `kubectl`      | Installs the `/usr/bin/kubectl` binary. |
+| `cri-tools`    | Installs the `/usr/bin/crictl` binary from the [cri-tools git repository](https://github.com/kubernetes-sigs/cri-tools). |
 -->
-## Kubernetes 二进制文件和软件包内容
+## Kubernetes 可执行文件和软件包内容

 Kubernetes 版本对应的 DEB 和 RPM 软件包是：

@@ -383,4 +388,3 @@ Kubernetes 版本对应的 DEB 和 RPM 软件包是：
 | `kubectl`    | 安装 `/usr/bin/kubectl` 可执行文件。 |
 | `cri-tools` | 从 [cri-tools git 仓库](https://github.com/kubernetes-sigs/cri-tools)中安装 `/usr/bin/crictl` 可执行文件。 |

-
@@ -5,13 +5,11 @@ weight: 70
 ---

 <!--
---
 reviewers:
 - sig-cluster-lifecycle
 title: Set up a High Availability etcd cluster with kubeadm
 content_type: task
 weight: 70
---
 -->

 <!-- overview -->
@@ -35,7 +33,7 @@ becoming unavailable. This task walks through the process of creating a high
 availability etcd cluster of three members that can be used as an external etcd
 when using kubeadm to set up a kubernetes cluster.
 -->
-默认情况下，kubeadm 运行单成员的 etcd 集群，该集群由控制面节点上的 kubelet 以静态 Pod 的方式进行管理。由于 etcd 集群只包含一个成员且不能在任一成员不可用时保持运行，所以这不是一种高可用设置。本任务，将告诉您如何在使用 kubeadm 创建一个 kubernetes 集群时创建一个外部 etcd：有三个成员的高可用 etcd 集群。
+默认情况下，kubeadm 运行单成员的 etcd 集群，该集群由控制面节点上的 kubelet 以静态 Pod 的方式进行管理。由于 etcd 集群只包含一个成员且不能在任一成员不可用时保持运行，所以这不是一种高可用设置。本任务，将告诉你如何在使用 kubeadm 创建一个 kubernetes 集群时创建一个外部 etcd：有三个成员的高可用 etcd 集群。



@@ -85,334 +83,287 @@ kubeadm 包含生成下述证书所需的所有必要的密码学工具；在这

 <!--
 1. Configure the kubelet to be a service manager for etcd.
-
-    Since etcd was created first, you must override the service priority by creating a new unit file
-    that has higher precedence than the kubeadm-provided kubelet unit file.
+ 
+   {{< note >}}You must do this on every host where etcd should be running.{{< /note >}}
+   Since etcd was created first, you must override the service priority by creating a new unit file
+   that has higher precedence than the kubeadm-provided kubelet unit file.
 -->
 1. 将 kubelet 配置为 etcd 的服务管理器。

-    由于 etcd 是首先创建的，因此您必须通过创建具有更高优先级的新文件来覆盖 kubeadm 提供的 kubelet 单元文件。
+   {{< note >}}
+   你必须在要运行 etcd 的所有主机上执行此操作。
+   {{< /note >}}
+   由于 etcd 是首先创建的，因此你必须通过创建具有更高优先级的新文件来覆盖
+   kubeadm 提供的 kubelet 单元文件。

-    ```sh
-    cat << EOF > /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf
-    [Service]
-    ExecStart=
-    #  Replace "systemd" with the cgroup driver of your container runtime. The default value in the kubelet is "cgroupfs".
-    ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests --cgroup-driver=systemd
-    Restart=always
-    EOF
+   ```sh
+   cat << EOF > /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf
+   [Service]
+   ExecStart=
+   # 将下面的 "systemd" 替换为你的容器运行时所使用的 cgroup 驱动。
+   # kubelet 的默认值为 "cgroupfs"。
+   ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests --cgroup-driver=systemd
+   Restart=always
+   EOF

-    systemctl daemon-reload
-    systemctl restart kubelet
-    ```
+   systemctl daemon-reload
+   systemctl restart kubelet
+   ```

-    <!--
-    1.Create configuration files for kubeadm.
+   <!--
+   Check the kubelet status to ensure it is running.
+   -->
+   检查 kubelet 的状态以确保其处于运行状态：

-        Generate one kubeadm configuration file for each host that will have an etcd
-        member running on it using the following script.
-    -->

-1. 为 kubeadm 创建配置文件。
+   ```shell
+   systemctl status kubelet
+   ```

-    使用以下脚本为每个将要运行 etcd 成员的主机生成一个 kubeadm 配置文件。
+<!--
+1. Create configuration files for kubeadm.

-    <!--
-    ```sh
-    # Update HOST0, HOST1, and HOST2 with the IPs or resolvable names of your hosts
-    export HOST0=10.0.0.6
-    export HOST1=10.0.0.7
-    export HOST2=10.0.0.8
+   Generate one kubeadm configuration file for each host that will have an etcd
+   member running on it using the following script.
+-->
+2. 为 kubeadm 创建配置文件。

-    # Create temp directories to store files that will end up on other hosts.
-    mkdir -p /tmp/${HOST0}/ /tmp/${HOST1}/ /tmp/${HOST2}/
+   使用以下脚本为每个将要运行 etcd 成员的主机生成一个 kubeadm 配置文件。

-    ETCDHOSTS=(${HOST0} ${HOST1} ${HOST2})
-    NAMES=("infra0" "infra1" "infra2")
+   ```sh
+   # 使用 IP 或可解析的主机名替换 HOST0、HOST1 和 HOST2
+   export HOST0=10.0.0.6
+   export HOST1=10.0.0.7
+   export HOST2=10.0.0.8

-    for i in "${!ETCDHOSTS[@]}"; do
-    HOST=${ETCDHOSTS[$i]}
-    NAME=${NAMES[$i]}
-    cat << EOF > /tmp/${HOST}/kubeadmcfg.yaml
-    apiVersion: "kubeadm.k8s.io/v1beta2"
-    kind: ClusterConfiguration
-    etcd:
-        local:
-            serverCertSANs:
-            - "${HOST}"
-            peerCertSANs:
-            - "${HOST}"
-            extraArgs:
-                initial-cluster: infra0=https://${ETCDHOSTS[0]}:2380,infra1=https://${ETCDHOSTS[1]}:2380,infra2=https://${ETCDHOSTS[2]}:2380
-                initial-cluster-state: new
-                name: ${NAME}
-                listen-peer-urls: https://${HOST}:2380
-                listen-client-urls: https://${HOST}:2379
-                advertise-client-urls: https://${HOST}:2379
-                initial-advertise-peer-urls: https://${HOST}:2380
-    EOF
-    done
-    ```
-    -->
-    ```sh
-    # 使用 IP 或可解析的主机名替换 HOST0、HOST1 和 HOST2
-    export HOST0=10.0.0.6
-    export HOST1=10.0.0.7
-    export HOST2=10.0.0.8
+   # 创建临时目录来存储将被分发到其它主机上的文件
+   mkdir -p /tmp/${HOST0}/ /tmp/${HOST1}/ /tmp/${HOST2}/

-    # 创建临时目录来存储将被分发到其它主机上的文件
-    mkdir -p /tmp/${HOST0}/ /tmp/${HOST1}/ /tmp/${HOST2}/
+   ETCDHOSTS=(${HOST0} ${HOST1} ${HOST2})
+   NAMES=("infra0" "infra1" "infra2")

-    ETCDHOSTS=(${HOST0} ${HOST1} ${HOST2})
-    NAMES=("infra0" "infra1" "infra2")
+   for i in "${!ETCDHOSTS[@]}"; do
+   HOST=${ETCDHOSTS[$i]}
+   NAME=${NAMES[$i]}
+   cat << EOF > /tmp/${HOST}/kubeadmcfg.yaml
+   apiVersion: "kubeadm.k8s.io/v1beta2"
+   kind: ClusterConfiguration
+   etcd:
+       local:
+           serverCertSANs:
+           - "${HOST}"
+           peerCertSANs:
+           - "${HOST}"
+           extraArgs:
+               initial-cluster: infra0=https://${ETCDHOSTS[0]}:2380,infra1=https://${ETCDHOSTS[1]}:2380,infra2=https://${ETCDHOSTS[2]}:2380
+               initial-cluster-state: new
+               name: ${NAME}
+               listen-peer-urls: https://${HOST}:2380
+               listen-client-urls: https://${HOST}:2379
+               advertise-client-urls: https://${HOST}:2379
+               initial-advertise-peer-urls: https://${HOST}:2380
+   EOF
+   done
+   ```

-    for i in "${!ETCDHOSTS[@]}"; do
-    HOST=${ETCDHOSTS[$i]}
-    NAME=${NAMES[$i]}
-    cat << EOF > /tmp/${HOST}/kubeadmcfg.yaml
-    apiVersion: "kubeadm.k8s.io/v1beta2"
-    kind: ClusterConfiguration
-    etcd:
-        local:
-            serverCertSANs:
-            - "${HOST}"
-            peerCertSANs:
-            - "${HOST}"
-            extraArgs:
-                initial-cluster: infra0=https://${ETCDHOSTS[0]}:2380,infra1=https://${ETCDHOSTS[1]}:2380,infra2=https://${ETCDHOSTS[2]}:2380
-                initial-cluster-state: new
-                name: ${NAME}
-                listen-peer-urls: https://${HOST}:2380
-                listen-client-urls: https://${HOST}:2379
-                advertise-client-urls: https://${HOST}:2379
-                initial-advertise-peer-urls: https://${HOST}:2380
-    EOF
-    done
-    ```
+<!--
+1. Generate the certificate authority

-    <!--
-    1.Generate the certificate authority
+   If you already have a CA then the only action that is copying the CA's `crt` and
+   `key` file to `/etc/kubernetes/pki/etcd/ca.crt` and
+   `/etc/kubernetes/pki/etcd/ca.key`. After those files have been copied,
+   proceed to the next step, "Create certificates for each member".
+-->
+3. 生成证书颁发机构

-        If you already have a CA then the only action that is copying the CA's `crt` and
-        `key` file to `/etc/kubernetes/pki/etcd/ca.crt` and
-        `/etc/kubernetes/pki/etcd/ca.key`. After those files have been copied,
-        proceed to the next step, "Create certificates for each member".
-    -->
-1. 生成证书颁发机构
+   如果你已经拥有 CA，那么唯一的操作是复制 CA 的 `crt` 和 `key` 文件到
+   `etc/kubernetes/pki/etcd/ca.crt` 和 `/etc/kubernetes/pki/etcd/ca.key`。
+   复制完这些文件后继续下一步，“为每个成员创建证书”。

-    如果您已经拥有 CA，那么唯一的操作是复制 CA 的 `crt` 和 `key` 文件到 `etc/kubernetes/pki/etcd/ca.crt` 和 `/etc/kubernetes/pki/etcd/ca.key`。复制完这些文件后继续下一步，“为每个成员创建证书”。
+   <!--
+   If you do not already have a CA then run this command on `$HOST0` (where you generated the configuration files for kubeadm).
+   -->
+   如果你还没有 CA，则在 `$HOST0`（你为 kubeadm 生成配置文件的位置）上运行此命令。

-    <!--
-    If you do not already have a CA then run this command on `$HOST0` (where you generated the configuration files for kubeadm).
-    -->
-    如果您还没有 CA，则在 `$HOST0`（您为 kubeadm 生成配置文件的位置）上运行此命令。
+   ```
+   kubeadm init phase certs etcd-ca
+   ```

-    ```
-    kubeadm init phase certs etcd-ca
-    ```
+   <!--
+   This creates two files
+   -->
+   这一操作创建如下两个文件

-    <!--
-    This creates two files
-    -->
-    创建了如下两个文件
+   - `/etc/kubernetes/pki/etcd/ca.crt`
+   - `/etc/kubernetes/pki/etcd/ca.key`

-    - `/etc/kubernetes/pki/etcd/ca.crt`
-    - `/etc/kubernetes/pki/etcd/ca.key`
+<!--
+1. Create certificates for each member
+-->
+4. 为每个成员创建证书

-    <!--
-    1. Create certificates for each member
-    -->
-1. 为每个成员创建证书
+   ```shell
+   kubeadm init phase certs etcd-server --config=/tmp/${HOST2}/kubeadmcfg.yaml
+   kubeadm init phase certs etcd-peer --config=/tmp/${HOST2}/kubeadmcfg.yaml
+   kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
+   kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
+   cp -R /etc/kubernetes/pki /tmp/${HOST2}/
+   # 清理不可重复使用的证书
+   find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete

-    <!--
-    ```sh
-    kubeadm init phase certs etcd-server --config=/tmp/${HOST2}/kubeadmcfg.yaml
-    kubeadm init phase certs etcd-peer --config=/tmp/${HOST2}/kubeadmcfg.yaml
-    kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
-    kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
-    cp -R /etc/kubernetes/pki /tmp/${HOST2}/
-    # cleanup non-reusable certificates
-    find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
+   kubeadm init phase certs etcd-server --config=/tmp/${HOST1}/kubeadmcfg.yaml
+   kubeadm init phase certs etcd-peer --config=/tmp/${HOST1}/kubeadmcfg.yaml
+   kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
+   kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
+   cp -R /etc/kubernetes/pki /tmp/${HOST1}/
+   find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete

-    kubeadm init phase certs etcd-server --config=/tmp/${HOST1}/kubeadmcfg.yaml
-    kubeadm init phase certs etcd-peer --config=/tmp/${HOST1}/kubeadmcfg.yaml
-    kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
-    kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
-    cp -R /etc/kubernetes/pki /tmp/${HOST1}/
-    find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
+   kubeadm init phase certs etcd-server --config=/tmp/${HOST0}/kubeadmcfg.yaml
+   kubeadm init phase certs etcd-peer --config=/tmp/${HOST0}/kubeadmcfg.yaml
+   kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
+   kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
+   # 不需要移动 certs 因为它们是给 HOST0 使用的

-    kubeadm init phase certs etcd-server --config=/tmp/${HOST0}/kubeadmcfg.yaml
-    kubeadm init phase certs etcd-peer --config=/tmp/${HOST0}/kubeadmcfg.yaml
-    kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
-    kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
-    # No need to move the certs because they are for HOST0
+   # 清理不应从此主机复制的证书
+   find /tmp/${HOST2} -name ca.key -type f -delete
+   find /tmp/${HOST1} -name ca.key -type f -delete
+   ```

-    # clean up certs that should not be copied off this host
-    find /tmp/${HOST2} -name ca.key -type f -delete
-    find /tmp/${HOST1} -name ca.key -type f -delete
-    ```
-    -->
-    ```sh
-    kubeadm init phase certs etcd-server --config=/tmp/${HOST2}/kubeadmcfg.yaml
-    kubeadm init phase certs etcd-peer --config=/tmp/${HOST2}/kubeadmcfg.yaml
-    kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
-    kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
-    cp -R /etc/kubernetes/pki /tmp/${HOST2}/
-    # 清理不可重复使用的证书
-    find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
+<!--
+1. Copy certificates and kubeadm configs
+   The certificates have been generated and now they must be moved to their
+   respective hosts.
+-->
+5. 复制证书和 kubeadm 配置

-    kubeadm init phase certs etcd-server --config=/tmp/${HOST1}/kubeadmcfg.yaml
-    kubeadm init phase certs etcd-peer --config=/tmp/${HOST1}/kubeadmcfg.yaml
-    kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
-    kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
-    cp -R /etc/kubernetes/pki /tmp/${HOST1}/
-    find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
+   证书已生成，现在必须将它们移动到对应的主机。

-    kubeadm init phase certs etcd-server --config=/tmp/${HOST0}/kubeadmcfg.yaml
-    kubeadm init phase certs etcd-peer --config=/tmp/${HOST0}/kubeadmcfg.yaml
-    kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
-    kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
-    # 不需要移动 certs 因为它们是给 HOST0 使用的
+   ```shell
+   USER=ubuntu
+   HOST=${HOST1}
+   scp -r /tmp/${HOST}/* ${USER}@${HOST}:
+   ssh ${USER}@${HOST}
+   USER@HOST $ sudo -Es
+   root@HOST $ chown -R root:root pki
+   root@HOST $ mv pki /etc/kubernetes/
+   ```

-    # 清理不应从此主机复制的证书
-    find /tmp/${HOST2} -name ca.key -type f -delete
-    find /tmp/${HOST1} -name ca.key -type f -delete
-    ```
+<!--
+1. Ensure all expected files exist

-    <!--
-    1.Copy certificates and kubeadm configs
+   The complete list of required files on `$HOST0` is:
+-->
+6. 确保已经所有预期的文件都存在

-        The certificates have been generated and now they must be moved to their
-        respective hosts.
-    -->
-1. 复制证书和 kubeadm 配置
+   `$HOST0` 所需文件的完整列表如下：

-    证书已生成，现在必须将它们移动到对应的主机。
+   ```none
+   /tmp/${HOST0}
+   └── kubeadmcfg.yaml
+   ---
+   /etc/kubernetes/pki
+   ├── apiserver-etcd-client.crt
+   ├── apiserver-etcd-client.key
+   └── etcd
+       ├── ca.crt
+       ├── ca.key
+       ├── healthcheck-client.crt
+       ├── healthcheck-client.key
+       ├── peer.crt
+       ├── peer.key
+       ├── server.crt
+       └── server.key
+   ```

-    ```sh
-    USER=ubuntu
-    HOST=${HOST1}
-    scp -r /tmp/${HOST}/* ${USER}@${HOST}:
-    ssh ${USER}@${HOST}
-    USER@HOST $ sudo -Es
-    root@HOST $ chown -R root:root pki
-    root@HOST $ mv pki /etc/kubernetes/
-    ```
+   <!--
+   On `$HOST1`:
+   -->
+   在 `$HOST1` 上：

-    <!--
-    1.Ensure all expected files exist
+   ```
+   $HOME
+   └── kubeadmcfg.yaml
+   ---
+   /etc/kubernetes/pki
+   ├── apiserver-etcd-client.crt
+   ├── apiserver-etcd-client.key
+   └── etcd
+       ├── ca.crt
+       ├── healthcheck-client.crt
+       ├── healthcheck-client.key
+       ├── peer.crt
+       ├── peer.key
+       ├── server.crt
+       └── server.key
+   ```

-        The complete list of required files on `$HOST0` is:
-    -->
-1. 确保已经所有预期的文件都存在
+   <!--
+   On `$HOST2`
+   -->
+   在 `$HOST2` 上：

-    `$HOST0` 所需文件的完整列表如下：
+   ```
+   $HOME
+   └── kubeadmcfg.yaml
+   ---
+   /etc/kubernetes/pki
+   ├── apiserver-etcd-client.crt
+   ├── apiserver-etcd-client.key
+   └── etcd
+       ├── ca.crt
+       ├── healthcheck-client.crt
+       ├── healthcheck-client.key
+       ├── peer.crt
+       ├── peer.key
+       ├── server.crt
+       └── server.key
+   ```

-    ```
-    /tmp/${HOST0}
-    └── kubeadmcfg.yaml
-    ---
-    /etc/kubernetes/pki
-    ├── apiserver-etcd-client.crt
-    ├── apiserver-etcd-client.key
-    └── etcd
-        ├── ca.crt
-        ├── ca.key
-        ├── healthcheck-client.crt
-        ├── healthcheck-client.key
-        ├── peer.crt
-        ├── peer.key
-        ├── server.crt
-        └── server.key
-    ```
+<!--
+1. Create the static pod manifests

-    <!--
-    On `$HOST1`:
-    -->
-    在 `$HOST1`:
+   Now that the certificates and configs are in place it's time to create the
+   manifests. On each host run the `kubeadm` command to generate a static manifest
+   for etcd.
+-->
+7. 创建静态 Pod 清单

-    ```
-    $HOME
-    └── kubeadmcfg.yaml
-    ---
-    /etc/kubernetes/pki
-    ├── apiserver-etcd-client.crt
-    ├── apiserver-etcd-client.key
-    └── etcd
-        ├── ca.crt
-        ├── healthcheck-client.crt
-        ├── healthcheck-client.key
-        ├── peer.crt
-        ├── peer.key
-        ├── server.crt
-        └── server.key
-    ```
+   既然证书和配置已经就绪，是时候去创建清单了。
+   在每台主机上运行 `kubeadm` 命令来生成 etcd 使用的静态清单。

-    <!--
-    On `$HOST2`
-    -->
-    在 `$HOST2`
+   ```shell
+   root@HOST0 $ kubeadm init phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml
+   root@HOST1 $ kubeadm init phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml
+   root@HOST2 $ kubeadm init phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml
+   ```

-    ```
-    $HOME
-    └── kubeadmcfg.yaml
-    ---
-    /etc/kubernetes/pki
-    ├── apiserver-etcd-client.crt
-    ├── apiserver-etcd-client.key
-    └── etcd
-        ├── ca.crt
-        ├── healthcheck-client.crt
-        ├── healthcheck-client.key
-        ├── peer.crt
-        ├── peer.key
-        ├── server.crt
-        └── server.key
-    ```
+<!--
+1. Optional: Check the cluster health
+-->
+8. 可选：检查群集运行状况

-    <!--
-    1.Create the static pod manifests
-
-        Now that the certificates and configs are in place it's time to create the
-        manifests. On each host run the `kubeadm` command to generate a static manifest
-        for etcd.
-    -->
-1. 创建静态 Pod 清单
-
-    既然证书和配置已经就绪，是时候去创建清单了。在每台主机上运行 `kubeadm` 命令来生成 etcd 使用的静态清单。
-
-    ```sh
-    root@HOST0 $ kubeadm init phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml
-    root@HOST1 $ kubeadm init phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml
-    root@HOST2 $ kubeadm init phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml
-    ```
-
-    <!--
-    1.Optional: Check the cluster health
-    -->
-1. 可选：检查群集运行状况
-
-    ```sh
-    docker run --rm -it \
-    --net host \
-    -v /etc/kubernetes:/etc/kubernetes k8s.gcr.io/etcd:${ETCD_TAG} etcdctl \
-    --cert /etc/kubernetes/pki/etcd/peer.crt \
-    --key /etc/kubernetes/pki/etcd/peer.key \
-    --cacert /etc/kubernetes/pki/etcd/ca.crt \
-    --endpoints https://${HOST0}:2379 endpoint health --cluster
-    ...
-    https://[HOST0 IP]:2379 is healthy: successfully committed proposal: took = 16.283339ms
-    https://[HOST1 IP]:2379 is healthy: successfully committed proposal: took = 19.44402ms
-    https://[HOST2 IP]:2379 is healthy: successfully committed proposal: took = 35.926451ms
-    ```
-    <!--
-    Set ${ETCD_TAG} to the version tag of your etcd image. For example 3.4.3-0. To see the etcd image and tag that             kubeadm uses execute kubeadm config images list --kubernetes-version ${K8S_VERSION}, where ${K8S_VERSION} is for           example v1.17.0
-    --> 
-    - 将 `${ETCD_TAG}` 设置为你的 etcd 镜像的版本标签，例如 `3.4.3-0`。要查看 kubeadm 使用的 etcd 镜像和标签，请执行 `kubeadm config images list --kubernetes-version ${K8S_VERSION}`，其中 `${K8S_VERSION}` 是 `v1.17.0` 作为例子。
-    <!--
-    Set ${HOST0}to the IP address of the host you are testing.
-    -->
-    - 将 `${HOST0}` 设置为要测试的主机的 IP 地址
+   ```shell
+   docker run --rm -it \
+   --net host \
+   -v /etc/kubernetes:/etc/kubernetes k8s.gcr.io/etcd:${ETCD_TAG} etcdctl \
+   --cert /etc/kubernetes/pki/etcd/peer.crt \
+   --key /etc/kubernetes/pki/etcd/peer.key \
+   --cacert /etc/kubernetes/pki/etcd/ca.crt \
+   --endpoints https://${HOST0}:2379 endpoint health --cluster
+   ...
+   https://[HOST0 IP]:2379 is healthy: successfully committed proposal: took = 16.283339ms
+   https://[HOST1 IP]:2379 is healthy: successfully committed proposal: took = 19.44402ms
+   https://[HOST2 IP]:2379 is healthy: successfully committed proposal: took = 35.926451ms
+   ```
+   <!--
+   Set ${ETCD_TAG} to the version tag of your etcd image. For example 3.4.3-0. To see the etcd image and tag that             kubeadm uses execute kubeadm config images list --kubernetes-version ${K8S_VERSION}, where ${K8S_VERSION} is for           example v1.17.0
+   Set ${HOST0}to the IP address of the host you are testing.
+   -->
+   - 将 `${ETCD_TAG}` 设置为你的 etcd 镜像的版本标签，例如 `3.4.3-0`。
+     要查看 kubeadm 使用的 etcd 镜像和标签，请执行
+     `kubeadm config images list --kubernetes-version ${K8S_VERSION}`，
+     例如，其中的 `${K8S_VERSION}` 可以是 `v1.17.0`。
+   - 将 `${HOST0}` 设置为要测试的主机的 IP 地址。

 ## {{% heading "whatsnext" %}}

@@ -422,7 +373,6 @@ highly available control plane using the [external etcd method with
 kubeadm](/docs/setup/independent/high-availability/).
 -->
 一旦拥有了一个正常工作的 3 成员的 etcd 集群，你就可以基于
-[使用 kubeadm 的外部 etcd 方法](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/)，
+[使用 kubeadm 外部 etcd 的方法](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/)，
 继续部署一个高可用的控制平面。

-
@@ -101,11 +101,11 @@ This may be caused by a number of problems. The most common are:

  There are two common ways to fix the cgroup driver problem:

- 1. Install Docker again following instructions
+  1. Install Docker again following instructions
  [here](/docs/setup/production-environment/container-runtimes/#docker).

- 1. Change the kubelet config to match the Docker cgroup driver manually, you can refer to
-    [Configure cgroup driver used by kubelet on control-plane node](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node)
+  1. Change the kubelet config to match the Docker cgroup driver manually, you can refer to
+     [Configure cgroup driver used by kubelet on control-plane node](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node)

 - control plane Docker containers are crashlooping or hanging. You can check this by running `docker ps` and investigating each container by running `docker logs`.
 -->
@@ -122,7 +122,8 @@ This may be caused by a number of problems. The most common are:

  有两种常见方法可解决 cgroup 驱动程序问题：

-  1. 按照 [此处](/zh/docs/setup/production-environment/container-runtimes/#docker) 的说明再次安装 Docker。
+  1. 按照[此处](/zh/docs/setup/production-environment/container-runtimes/#docker) 的说明
+     重新安装 Docker。

  1. 更改 kubelet 配置以手动匹配 Docker cgroup 驱动程序，你可以参考
     [在主节点上配置 kubelet 要使用的 cgroup 驱动程序](/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node)
@@ -134,8 +135,11 @@ This may be caused by a number of problems. The most common are:

 The following could happen if Docker halts and does not remove any Kubernetes-managed containers:

-```bash
+```shell
 sudo kubeadm reset
+```
+
+```console
 [preflight] Running pre-flight checks
 [reset] Stopping the kubelet service
 [reset] Unmounting mounted directories in "/var/lib/kubelet"
@@ -145,14 +149,14 @@ sudo kubeadm reset

 A possible solution is to restart the Docker service and then re-run `kubeadm reset`:

-```bash
+```shell
 sudo systemctl restart docker.service
 sudo kubeadm reset
 ```

 Inspecting the logs for docker may also be useful:

-```sh
+```shell
 journalctl -ul docker
 ```
 -->
@@ -160,8 +164,11 @@ journalctl -ul docker

 如果 Docker 停止并且不删除 Kubernetes 所管理的所有容器，可能发生以下情况：

-```bash
+```shell
 sudo kubeadm reset
+```
+
+```none
 [preflight] Running pre-flight checks
 [reset] Stopping the kubelet service
 [reset] Unmounting mounted directories in "/var/lib/kubelet"
@@ -171,7 +178,7 @@ sudo kubeadm reset

 一个可行的解决方案是重新启动 Docker 服务，然后重新运行 `kubeadm reset`：

-```bash
+```shell
 sudo systemctl restart docker.service
 sudo kubeadm reset
 ```
@@ -189,10 +196,10 @@ Right after `kubeadm init` there should not be any pods in these states.

 - If there are pods in one of these states _right after_ `kubeadm init`, please open an
  issue in the kubeadm repo. `coredns` (or `kube-dns`) should be in the `Pending` state
-  until you have deployed the network solution.
+  until you have deployed the network add-on.
 - If you see Pods in the `RunContainerError`, `CrashLoopBackOff` or `Error` state
-  after deploying the network solution and nothing happens to `coredns` (or `kube-dns`),
-  it's very likely that the Pod Network solution that you installed is somehow broken.
+  after deploying the network add-on and nothing happens to `coredns` (or `kube-dns`),
+  it's very likely that the Pod Network add-on that you installed is somehow broken.
  You might have to grant it more RBAC privileges or use a newer version. Please file
  an issue in the Pod Network providers' issue tracker and get the issue triaged there.
 - If you install a version of Docker older than 1.12.1, remove the `MountFlags=slave` option
@@ -206,11 +213,11 @@ Right after `kubeadm init` there should not be any pods in these states.

 - 在 `kubeadm init` 命令执行完后，如果有 pods 处于这些状态之一，请在 kubeadm
  仓库提起一个 issue。`coredns` (或者 `kube-dns`) 应该处于 `Pending` 状态，
-  直到你部署了网络解决方案为止。
+  直到你部署了网络插件为止。

- 如果在部署完网络解决方案之后，有 Pods 处于 `RunContainerError`、`CrashLoopBackOff`
+- 如果在部署完网络插件之后，有 Pods 处于 `RunContainerError`、`CrashLoopBackOff`
  或 `Error` 状态之一，并且`coredns` （或者 `kube-dns`）仍处于 `Pending` 状态，
-  那很可能是你安装的网络解决方案由于某种原因无法工作。你或许需要授予它更多的
+  那很可能是你安装的网络插件由于某种原因无法工作。你或许需要授予它更多的
  RBAC 特权或使用较新的版本。请在 Pod Network 提供商的问题跟踪器中提交问题，
  然后在此处分类问题。

@@ -221,17 +228,18 @@ Right after `kubeadm init` there should not be any pods in these states.
  当 Kubernetes 不能找到 `var/run/secrets/kubernetes.io/serviceaccount` 文件时会发生错误。

 <!--
-## `coredns` (or `kube-dns`) is stuck in the `Pending` state
+## `coredns` is stuck in the `Pending` state

 This is **expected** and part of the design. kubeadm is network provider-agnostic, so the admin
-should [install the pod network solution](/docs/concepts/cluster-administration/addons/)
+should [install the pod network add-on](/docs/concepts/cluster-administration/addons/)
 of choice. You have to install a Pod Network
 before CoreDNS may be deployed fully. Hence the `Pending` state before the network is set up.
 -->
-## `coredns` （或 `kube-dns`）停滞在 `Pending` 状态
+## `coredns` 停滞在 `Pending` 状态

 这一行为是 **预期之中** 的，因为系统就是这么设计的。
-kubeadm 的网络供应商是中立的，因此管理员应该选择 [安装 pod 的网络解决方案](/zh/docs/concepts/cluster-administration/addons/)。
+kubeadm 的网络供应商是中立的，因此管理员应该选择
+[安装 pod 的网络插件](/zh/docs/concepts/cluster-administration/addons/)。
 你必须完成 Pod 的网络配置，然后才能完全部署 CoreDNS。
 在网络被配置好之前，DNS 组件会一直处于 `Pending` 状态。

@@ -239,7 +247,7 @@ kubeadm 的网络供应商是中立的，因此管理员应该选择 [安装 pod
 ## `HostPort` services do not work

 The `HostPort` and `HostIP` functionality is available depending on your Pod Network
-provider. Please contact the author of the Pod Network solution to find out whether
+provider. Please contact the author of the Pod Network add-on to find out whether
 `HostPort` and `HostIP` functionality are available.

 Calico, Canal, and Flannel CNI providers are verified to support HostPort.
@@ -251,7 +259,7 @@ services](/docs/concepts/services-networking/service/#nodeport) or use `HostNetw
 -->
 ## `HostPort` 服务无法工作

-此 `HostPort` 和 `HostIP` 功能是否可用取决于你的 Pod 网络配置。请联系 Pod 解决方案的作者，
+此 `HostPort` 和 `HostIP` 功能是否可用取决于你的 Pod 网络配置。请联系 Pod 网络插件的作者，
 以确认 `HostPort` 和 `HostIP` 功能是否可用。

 已验证 Calico、Canal 和 Flannel CNI 驱动程序支持 HostPort。
@@ -663,3 +671,139 @@ kubectl taint nodes NODE_NAME node-role.kubernetes.io/master:NoSchedule-
   kubectl taint nodes NODE_NAME node-role.kubernetes.io/master:NoSchedule-
   ```

+<!--
+## `/usr` is mounted read-only on nodes {#usr-mounted-read-only}
+
+On Linux distributions such as Fedora CoreOS or Flatcar Container Linux, the directory `/usr` is mounted as a read-only filesystem.
+For [flex-volume support](https://github.com/kubernetes/community/blob/ab55d85/contributors/devel/sig-storage/flexvolume.md),
+Kubernetes components like the kubelet and kube-controller-manager use the default path of
+`/usr/libexec/kubernetes/kubelet-plugins/volume/exec/`, yet the flex-volume directory _must be writeable_
+for the feature to work.
+-->
+## 节点上的 `/usr` 被以只读方式挂载 {#usr-mounted-read-only}
+
+在类似 Fedora CoreOS 或者 Flatcar Container Linux 这类 Linux 发行版本中，
+目录 `/usr` 是以只读文件系统的形式挂载的。 
+在支持 [FlexVolume](https://github.com/kubernetes/community/blob/ab55d85/contributors/devel/sig-storage/flexvolume.md)时，
+类似 kubelet 和 kube-controller-manager 这类 Kubernetes 组件使用默认路径
+`/usr/libexec/kubernetes/kubelet-plugins/volume/exec/`，
+而 FlexVolume 的目录 _必须是可写入的_，该功能特性才能正常工作。
+
+<!--
+To workaround this issue you can configure the flex-volume directory using the kubeadm
+[configuration file](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2).
+
+On the primary control-plane Node (created using `kubeadm init`) pass the following
+file using `--config`:
+-->
+为了解决这个问题，你可以使用 kubeadm 的[配置文件](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)
+来配置 FlexVolume 的目录。
+
+在（使用 `kubeadm init` 创建的）主控制节点上，使用 `-config`
+参数传入如下文件：
+
+```yaml
+apiVersion: kubeadm.k8s.io/v1beta2
+kind: InitConfiguration
+nodeRegistration:
+  kubeletExtraArgs:
+    volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"
+---
+apiVersion: kubeadm.k8s.io/v1beta2
+kind: ClusterConfiguration
+controllerManager:
+  extraArgs:
+    flex-volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"
+```
+
+<!--
+On joining Nodes:
+-->
+在加入到集群中的节点上，使用下面的文件：
+
+```yaml
+apiVersion: kubeadm.k8s.io/v1beta2
+kind: JoinConfiguration
+nodeRegistration:
+  kubeletExtraArgs:
+    volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"
+```
+
+<!--
+Alternatively, you can modify `/etc/fstab` to make the `/usr` mount writeable, but please
+be advised that this is modifying a design principle of the Linux distribution.
+-->
+或者，你要可以更改 `/etc/fstab` 使得 `/usr` 目录能够以可写入的方式挂载，不过
+请注意这样做本质上是在更改 Linux 发行版的某种设计原则。
+
+<!--
+## `kubeadm upgrade plan` prints out `context deadline exceeded` error message
+
+This error message is shown when upgrading a Kubernetes cluster with `kubeadm` in the case of running an external etcd. This is not a critical bug and happens because older versions of kubeadm perform a version check on the external etcd cluster. You can proceed with `kubeadm upgrade apply ...`.
+
+This issue is fixed as of version 1.19.
+-->
+## `kubeadm upgrade plan` 输出错误信息 `context deadline exceeded`
+
+在使用 `kubeadm` 来升级某运行外部 etcd 的 Kubernetes 集群时可能显示这一错误信息。
+这并不是一个非常严重的一个缺陷，之所以出现此错误信息，原因是老的 kubeadm
+版本会对外部 etcd 集群执行版本检查。你可以继续执行 `kubeadm upgrade apply ...`。
+
+这一问题已经在 1.19 版本中得到修复。
+
+<!--
+## `kubeadm reset` unmounts `/var/lib/kubelet`
+
+If `/var/lib/kubelet` is being mounted, performing a `kubeadm reset` will effectively unmount it.
+
+To workaround the issue, re-mount the `/var/lib/kubelet` directory after performing the `kubeadm reset` operation.
+
+This is a regression introduced in kubeadm 1.15. The issue is fixed in 1.20.
+-->
+## `kubeadm reset` 会卸载 `/var/lib/kubelet`
+
+如果已经挂载了 `/var/lib/kubelet` 目录，执行 `kubeadm reset` 操作的时候
+会将其卸载。
+
+要解决这一问题，可以在执行了 `kubeadm reset` 操作之后重新挂载
+`/var/lib/kubelet` 目录。
+
+这是一个在 1.15 中引入的故障，已经在 1.20 版本中修复。
+
+<!--
+## Cannot use the metrics-server securely in a kubeadm cluster
+
+In a kubeadm cluster, the [metrics-server](https://github.com/kubernetes-sigs/metrics-server)
+can be used insecurely by passing the `--kubelet-insecure-tls` to it. This is not recommended for production clusters.
+-->
+## 无法在 kubeadm 集群中安全地使用 metrics-server
+
+在 kubeadm 集群中可以通过为 [metrics-server](https://github.com/kubernetes-sigs/metrics-server)
+设置 `--kubelet-insecure-tls` 来以不安全的形式使用该服务。
+建议不要在生产环境集群中这样使用。
+
+<!--
+If you want to use TLS between the metrics-server and the kubelet there is a problem,
+since kubeadm deploys a self-signed serving certificate for the kubelet. This can cause the following errors
+on the side of the metrics-server:
+-->
+如果你需要在 metrics-server 和 kubelt 之间使用 TLS，会有一个问题，
+kubeadm 为 kubelt 部署的是自签名的服务证书。这可能会导致 metrics-server
+端报告下面的错误信息：
+
+```
+x509: certificate signed by unknown authority
+x509: certificate is valid for IP-foo not IP-bar
+```
+
+<!--
+See [Enabling signed kubelet serving certificates](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#kubelet-serving-certs)
+to understand how to configure the kubelets in a kubeadm cluster to have properly signed serving certificates.
+
+Also see [How to run the metrics-server securely](https://github.com/kubernetes-sigs/metrics-server/blob/master/FAQ.md#how-to-run-metrics-server-securely).
+-->
+参见[为 kubelet 启用签名的服务证书](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#kubelet-serving-certs)
+以进一步了解如何在 kubeadm 集群中配置 kubelet 使用正确签名了的服务证书。
+
+另请参阅[How to run the metrics-server securely](https://github.com/kubernetes-sigs/metrics-server/blob/master/FAQ.md#how-to-run-metrics-server-securely)。
+