Merge pull request #23730 from tengqm/zh-links-setup-3

[zh] fix links in setup section (3)
2020-09-13 18:40:58 -07:00
parent c901c84e55 e592fc15f5
commit 2e834dfa69
5 changed files with 234 additions and 222 deletions
@@ -1,18 +1,12 @@
 ---
-reviewers:
- sig-cluster-lifecycle
 title: 配置您的 kubernetes 集群以自托管控制平台
 content_type: concept
 weight: 100
 ---
 <!--
---
-reviewers:
- sig-cluster-lifecycle
 title: Configuring your kubernetes cluster to self-host the control plane
 content_type: concept
 weight: 100
---
 -->

 <!-- overview -->
@@ -30,15 +24,17 @@ configured via the Kubernetes API instead of [static pods](/docs/tasks/administe
 configured in the kubelet via static files.
 -->
 kubeadm 允许您实验性地创建 _self-hosted_ Kubernetes 控制平面。
-这意味着 API 服务器，控制管理器和调度程序之类的关键组件将通过配置 Kubernetes API 以 [DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/) 的身份运行，而不是通过静态文件将 [static pods](/docs/tasks/administer-cluster/static-pod/) 在 kubelet 中配置。
+这意味着 API 服务器，控制管理器和调度程序之类的关键组件将通过配置 Kubernetes API 以
+[DaemonSet Pods](/zh/docs/concepts/workloads/controllers/daemonset/) 的身份运行，
+而不是通过静态文件在 kubelet 中配置[静态 Pods](/zh/docs/tasks/configure-pod-container/static-pod/)。

 <!--
 To create a self-hosted cluster see the
 [kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting) command.
 -->
-要创建自托管集群，请参见 [kubeadm alpha 自托管枢纽](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting) 命令。
-
-
+要创建自托管集群，请参见
+[kubeadm alpha selfhosting pivot](/zh/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting)
+命令。

 <!-- body -->

@@ -47,11 +43,11 @@ To create a self-hosted cluster see the
 -->
 #### 警告

-{{< caution >}}
 <!--
 This feature pivots your cluster into an unsupported state, rendering kubeadm unable
 to manage you cluster any longer. This includes `kubeadm upgrade`.
 -->
+{{< caution >}}
 此功能将您的集群设置为不受支持的状态，从而使 kubeadm 无法再管理您的集群。
 这包括 `kubeadm 升级` 。
 {{< /caution >}}
@@ -62,7 +58,7 @@ to manage you cluster any longer. This includes `kubeadm upgrade`.
  without manual intervention.
 -->
 1. 1.8及更高版本中的自托管功能有一些重要限制。
-特别是，自托管集群在没有人工干预的情况下_无法从控制平面节点的重新启动中恢复_ 。
+   特别是，自托管集群在没有人工干预的情况下_无法从控制平面节点的重新启动中恢复_ 。

 <!--
 1. By default, self-hosted control plane Pods rely on credentials loaded from
@@ -70,30 +66,30 @@ to manage you cluster any longer. This includes `kubeadm upgrade`.
  volumes. Except for initial creation, these credentials are not managed by
  kubeadm.
 -->
-1. 默认情况下，自托管的控制平面 Pod 依赖于从  [`hostPath`](/docs/concepts/storage/volumes/#hostpath) 卷加载的凭据。
-除初始创建外，这些凭据不由 kubeadm 管理。
+2. 默认情况下，自托管的控制平面 Pod 依赖于从
+   [`hostPath`](/zh/docs/concepts/storage/volumes/#hostpath) 卷加载的凭据。
+   除初始创建外，这些凭据不由 kubeadm 管理。

 <!--
 1. The self-hosted portion of the control plane does not include etcd,
  which still runs as a static Pod.
 -->
-1. 控制平面的自托管部分不包括 etcd，后者仍作为静态 Pod 运行。
+3. 控制平面的自托管部分不包括 etcd，后者仍作为静态 Pod 运行。

 <!--
 #### Process
-->
-#### 处理

-<!--
 The self-hosting bootstrap process is documented in the [kubeadm design
 document](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting).
 -->
-自托管引导过程记录在 [kubeadm 设计文档](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting) 中。
+#### 过程
+
+自托管引导过程描述于 [kubeadm 设计文档](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting) 中。

 <!--
 In summary, `kubeadm alpha selfhosting` works as follows:
 -->
-总而言之，`kubeadm alpha 自托管` 的工作原理如下：
+总体而言，`kubeadm alpha 自托管` 的工作原理如下：

 <!--
  1. Waits for this bootstrap static control plane to be running and
@@ -107,28 +103,27 @@ In summary, `kubeadm alpha selfhosting` works as follows:
    It also modifies these manifests where necessary, for example adding new volumes
    for secrets.
 -->
-  1. 使用静态控制平面 Pod 清单来构造一组 DaemonSet 清单，这些清单将运行自托管的控制平面。
+  2. 使用静态控制平面 Pod 清单来构造一组 DaemonSet 清单，这些清单将运行自托管的控制平面。
     它还会在必要时修改这些清单，例如添加新的秘密卷。

 <!--
  1. Creates DaemonSets in the `kube-system` namespace and waits for the
     resulting Pods to be running.
 -->
-  1. 在 `kube-system` 名称空间中创建 DaemonSets ，并等待生成的 Pod 运行。
+  3. 在 `kube-system` 名称空间中创建 DaemonSets ，并等待生成的 Pod 运行。

 <!--
  1. Once self-hosted Pods are operational, their associated static Pods are deleted
     and kubeadm moves on to install the next component. This triggers kubelet to
     stop those static Pods.
 -->
- 1. 自托管 Pod 运行后，将删除其关联的静态 Pod，然后 kubeadm 继续安装下一个组件。
-    这将触发 kubelet 停止那些静态 Pod 。
+  4. 自托管 Pod 运行后，将删除其关联的静态 Pod，然后 kubeadm 继续安装下一个组件。
+     这将触发 kubelet 停止那些静态 Pod 。

 <!--
  1. When the original static control plane stops, the new self-hosted control
    plane is able to bind to listening ports and become active.
 -->
-  1. 当原始静态控制平面停止时，新的自托管控制平面能够绑定到侦听端口并变为活动状态。
-
+  5. 当原始静态控制平面停止时，新的自托管控制平面能够绑定到侦听端口并变为活动状态。


@@ -5,11 +5,9 @@ weight: 20
 ---

 <!--
---
 title: Troubleshooting kubeadm
 content_type: concept
 weight: 20
---
 -->
 <!-- overview -->

@@ -26,19 +24,18 @@ If your problem is not listed below, please follow the following steps:
 - If you are unsure about how kubeadm works, you can ask on [Slack](http://slack.k8s.io/) in #kubeadm, or open a question on [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Please include
  relevant tags like `#kubernetes` and `#kubeadm` so folks can help you.
 -->
-与任何程序一样，您可能会在安装或者运行 kubeadm 时遇到错误。
-本文列举了一些常见的故障场景，并提供可帮助您理解和解决这些问题的步骤。
+与任何程序一样，你可能会在安装或者运行 kubeadm 时遇到错误。
+本文列举了一些常见的故障场景，并提供可帮助你理解和解决这些问题的步骤。

-如果您的问题未在下面列出，请执行以下步骤：
+如果你的问题未在下面列出，请执行以下步骤：

- 如果您认为问题是 kubeadm 的错误：
+- 如果你认为问题是 kubeadm 的错误：
  - 转到 [github.com/kubernetes/kubeadm](https://github.com/kubernetes/kubeadm/issues) 并搜索存在的问题。
  - 如果没有问题，请 [打开](https://github.com/kubernetes/kubeadm/issues/new) 并遵循问题模板。

- 如果您对 kubeadm 的工作方式有疑问，可以在 [Slack](http://slack.k8s.io/) 上的 #kubeadm 频道提问，
+- 如果你对 kubeadm 的工作方式有疑问，可以在 [Slack](https://slack.k8s.io/) 上的 #kubeadm 频道提问，
 或者在 [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes) 上提问。
-请加入相关标签，例如 `#kubernetes` 和 `#kubeadm`，这样其他人可以帮助您。
-
+请加入相关标签，例如 `#kubernetes` 和 `#kubeadm`，这样其他人可以帮助你。


 <!-- body -->
@@ -67,8 +64,8 @@ Then you may be missing `ebtables`, `ethtool` or a similar executable on your no
 [preflight] WARNING: ethtool not found in system path
 ```

-那么或许在您的节点上缺失 `ebtables`、`ethtool` 或者类似的可执行文件。
-您可以使用以下命令安装它们：
+那么或许在你的节点上缺失 `ebtables`、`ethtool` 或者类似的可执行文件。
+你可以使用以下命令安装它们：

 - 对于 Ubuntu/Debian 用户，运行 `apt install ebtables ethtool` 命令。
 - 对于 CentOS/Fedora 用户，运行 `yum install ebtables ethtool` 命令。
@@ -84,7 +81,7 @@ If you notice that `kubeadm init` hangs after printing out the following line:
 -->
 ## 在安装过程中，kubeadm 一直等待控制平面就绪

-如果您注意到 `kubeadm init` 在打印以下行后挂起：
+如果你注意到 `kubeadm init` 在打印以下行后挂起：

 ```sh
 [apiclient] Created API client, waiting for the control plane to become ready
@@ -114,9 +111,9 @@ This may be caused by a number of problems. The most common are:
 -->
 这可能是由许多问题引起的。最常见的是：

- 网络连接问题。在继续之前，请检查您的计算机是否具有全部联通的网络连接。
+- 网络连接问题。在继续之前，请检查你的计算机是否具有全部联通的网络连接。
 - kubelet 的默认 cgroup 驱动程序配置不同于 Docker 使用的配置。
-  检查系统日志文件 (例如 `/var/log/message`) 或检查 `journalctl -u kubelet` 的输出。 如果您看见以下内容：
+  检查系统日志文件 (例如 `/var/log/message`) 或检查 `journalctl -u kubelet` 的输出。 如果你看见以下内容：

  ```shell
  error: failed to run Kubelet: failed to create kubelet:
@@ -125,12 +122,12 @@ This may be caused by a number of problems. The most common are:

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

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

- 1. 更改 kubelet 配置以手动匹配 Docker cgroup 驱动程序，您可以参考
-    [在主节点上配置 kubelet 要使用的 cgroup 驱动程序](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)
+  1. 更改 kubelet 配置以手动匹配 Docker cgroup 驱动程序，你可以参考
+     [在主节点上配置 kubelet 要使用的 cgroup 驱动程序](/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)

- 控制平面上的 Docker 容器持续进入崩溃状态或（因其他原因）挂起。您可以运行 `docker ps` 命令来检查以及 `docker logs` 命令来检视每个容器的运行日志。
+- 控制平面上的 Docker 容器持续进入崩溃状态或（因其他原因）挂起。你可以运行 `docker ps` 命令来检查以及 `docker logs` 命令来检视每个容器的运行日志。

 <!--
 ## kubeadm blocks when removing managed containers
@@ -181,7 +178,7 @@ sudo kubeadm reset

 检查 docker 的日志也可能有用：

-```sh
+```shell
 journalctl -ul docker
 ```

@@ -209,15 +206,17 @@ 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`
  或 `Error` 状态之一，并且`coredns` （或者 `kube-dns`）仍处于 `Pending` 状态，
-  那很可能是您安装的网络解决方案由于某种原因无法工作。您或许需要授予它更多的
+  那很可能是你安装的网络解决方案由于某种原因无法工作。你或许需要授予它更多的
  RBAC 特权或使用较新的版本。请在 Pod Network 提供商的问题跟踪器中提交问题，
  然后在此处分类问题。
- 如果您安装的 Docker 版本早于 1.12.1，请在使用 `systemd` 来启动 `dockerd` 和重启 `docker` 时，
+
+- 如果你安装的 Docker 版本早于 1.12.1，请在使用 `systemd` 来启动 `dockerd` 和重启 `docker` 时，
  删除 `MountFlags=slave` 选项。
-  您可以在 `/usr/lib/systemd/system/docker.service` 中看到 MountFlags。
+  你可以在 `/usr/lib/systemd/system/docker.service` 中看到 MountFlags。
  MountFlags 可能会干扰 Kubernetes 挂载的卷， 并使 Pods 处于 `CrashLoopBackOff` 状态。
  当 Kubernetes 不能找到 `var/run/secrets/kubernetes.io/serviceaccount` 文件时会发生错误。

@@ -232,8 +231,8 @@ before CoreDNS may be deployed fully. Hence the `Pending` state before the netwo
 ## `coredns` （或 `kube-dns`）停滞在 `Pending` 状态

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

 <!--
@@ -252,14 +251,16 @@ 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。

 有关更多信息，请参考 [CNI portmap 文档](https://github.com/containernetworking/plugins/blob/master/plugins/meta/portmap/README.md).

-如果您的网络提供商不支持 portmap CNI 插件，您或许需要使用 [NodePort 服务的功能](/docs/concepts/services-networking/service/#nodeport) 或者使用 `HostNetwork=true`。
+如果你的网络提供商不支持 portmap CNI 插件，你或许需要使用
+[NodePort 服务的功能](/zh/docs/concepts/services-networking/service/#nodeport)
+或者使用 `HostNetwork=true`。

 <!--
 ## Pods are not accessible via their Service IP
@@ -277,10 +278,11 @@ services](/docs/concepts/services-networking/service/#nodeport) or use `HostNetw
 -->
 ## 无法通过其服务 IP 访问 Pod

- 许多网络附加组件尚未启用 [hairpin 模式](/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip)
-  该模式允许 Pod 通过其服务 IP 进行访问。这是与 [CNI](https://github.com/containernetworking/cni/issues/476) 有关的问题。请与网络附加组件提供商联系，以获取他们所提供的 hairpin 模式的最新状态。
+- 许多网络附加组件尚未启用 [hairpin 模式](/zh/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip)
+  该模式允许 Pod 通过其服务 IP 进行访问。这是与 [CNI](https://github.com/containernetworking/cni/issues/476) 有关的问题。
+  请与网络附加组件提供商联系，以获取他们所提供的 hairpin 模式的最新状态。

- 如果您正在使用 VirtualBox (直接使用或者通过 Vagrant 使用)，您需要
+- 如果你正在使用 VirtualBox (直接使用或者通过 Vagrant 使用)，你需要
  确保 `hostname -i` 返回一个可路由的 IP 地址。默认情况下，第一个接口连接不能路由的仅主机网络。
  解决方法是修改 `/etc/hosts`，请参考示例 [Vagrantfile](https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11)。

@@ -334,19 +336,19 @@ Unable to connect to the server: x509: certificate signed by unknown authority (
  可以用于查看证书信息。
 - 使用如下方法取消设置 `KUBECONFIG` 环境变量的值：

-  ```sh
+  ```shell
  unset KUBECONFIG
  ```

  或者将其设置为默认的 `KUBECONFIG` 位置：

-  ```sh
+  ```shell
  export KUBECONFIG=/etc/kubernetes/admin.conf
  ```

 - 另一个方法是覆盖 `kubeconfig` 的现有用户 "管理员" ：

-  ```sh
+  ```shell
  mv  $HOME/.kube $HOME/.kube.bak
  mkdir $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
@@ -366,7 +368,7 @@ Error from server (NotFound): the server could not find the requested resource

  Vagrant typically assigns two interfaces to all VMs. The first, for which all hosts are assigned the IP address `10.0.2.15`, is for external traffic that gets NATed.

-  This may lead to problems with flannel, which defaults to the first interface on a host. This leads to all hosts thinking they have the same public IP address. To prevent this, pass the `--iface eth1` flag to flannel so that the second interface is chosen.
+  This may lead to problems with flannel, which defaults to the first interface on a host. This leads to all hosts thinking they have the same public IP address. To prevent this, pass the `-iface eth1` flag to flannel so that the second interface is chosen.
 -->
 ## 在 Vagrant 中使用 flannel 作为 pod 网络时的默认 NIC

@@ -401,7 +403,7 @@ Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc6
  curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address
  ```

-  The workaround is to tell `kubelet` which IP to use using `--node-ip`. When using Digital Ocean, it can be the public one (assigned to `eth0`) or the private one (assigned to `eth1`) should you want to use the optional private network. The [`KubeletExtraArgs` section of the kubeadm `NodeRegistrationOptions` structure](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) can be used for this.
+  The workaround is to tell `kubelet` which IP to use using `-node-ip`. When using Digital Ocean, it can be the public one (assigned to `eth0`) or the private one (assigned to `eth1`) should you want to use the optional private network. The [`KubeletExtraArgs` section of the kubeadm `NodeRegistrationOptions` structure](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) can be used for this.

  Then restart `kubelet`:

@@ -433,14 +435,15 @@ Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc6

  解决方法是通知 `kubelet` 使用哪个 `--node-ip`。当使用 Digital Ocean 时，可以是公网IP（分配给 `eth0`的），
  或者是私网IP（分配给 `eth1` 的）。私网 IP 是可选的。
-  这个 [`KubeletExtraArgs` section of the kubeadm `NodeRegistrationOptions` structure](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) 被用来处理这种情况。
+  [kubadm `NodeRegistrationOptions` 结构的 `KubeletExtraArgs` 部分](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) 被用来处理这种情况。

  然后重启 `kubelet`：

-  ```sh
+  ```shell
  systemctl daemon-reload
  systemctl restart kubelet
  ```
+
 <!--
 ## `coredns` pods have `CrashLoopBackOff` or `Error` state

@@ -463,15 +466,16 @@ are available to avoid Kubernetes trying to restart the CoreDNS Pod every time C
 -->
 ## `coredns` pods 有 `CrashLoopBackOff` 或者 `Error` 状态

-如果有些节点运行的是旧版本的 Docker，同时启用了 SELinux，您或许会遇到 `coredns` pods 无法启动的情况。
-要解决此问题，您可以尝试以下选项之一：
+如果有些节点运行的是旧版本的 Docker，同时启用了 SELinux，你或许会遇到 `coredns` pods 无法启动的情况。
+要解决此问题，你可以尝试以下选项之一：

- 升级到 [Docker 的较新版本](/docs/setup/production-environment/container-runtimes/#docker)。
+- 升级到 [Docker 的较新版本](/zh/docs/setup/production-environment/container-runtimes/#docker)。

 - [禁用 SELinux](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-enabling_and_disabling_selinux-disabling_selinux).
+
 - 修改 `coredns` 部署以设置 `allowPrivilegeEscalation` 为 `true`：

-```bash
+```shell
 kubectl -n kube-system get deployment coredns -o yaml | \
  sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | \
  kubectl apply -f -
@@ -481,11 +485,11 @@ CoreDNS 处于 `CrashLoopBackOff` 时的另一个原因是当 Kubernetes 中部
 到环路时。[有许多解决方法](https://github.com/coredns/coredns/tree/master/plugin/loop#troubleshooting-loops-in-kubernetes-clusters)
 可以避免在每次 CoreDNS 监测到循环并退出时，Kubernetes 尝试重启 CoreDNS Pod 的情况。

-{{< warning >}}
 <!--
 Disabling SELinux or setting `allowPrivilegeEscalation` to `true` can compromise
 the security of your cluster.
 -->
+{{< warning >}}
 禁用 SELinux 或设置 `allowPrivilegeEscalation` 为 `true` 可能会损害集群的安全性。
 {{< /warning >}}

@@ -510,65 +514,72 @@ yum downgrade docker-1.13.1-75.git8633870.el7.centos.x86_64 docker-client-1.13.1

 - Install one of the more recent recommended versions, such as 18.06:
 ```bash
-sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
+sudo yum-config-manager -add-repo https://download.docker.com/linux/centos/docker-ce.repo
 yum install docker-ce-18.06.1.ce-3.el7.x86_64
 ```
 -->
 ## etcd pods 持续重启

-如果您遇到以下错误：
+如果你遇到以下错误：

 ```
 rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:247: starting container process caused "process_linux.go:110: decoding init error from pipe caused \"read parent: connection reset by peer\""
 ```

-如果您使用 Docker 1.13.1.84 运行 CentOS 7 就会出现这种问题。
+如果你使用 Docker 1.13.1.84 运行 CentOS 7 就会出现这种问题。
 此版本的 Docker 会阻止 kubelet 在 etcd 容器中执行。

 为解决此问题，请选择以下选项之一：

 - 回滚到早期版本的 Docker，例如 1.13.1-75
-```
-yum downgrade docker-1.13.1-75.git8633870.el7.centos.x86_64 docker-client-1.13.1-75.git8633870.el7.centos.x86_64 docker-common-1.13.1-75.git8633870.el7.centos.x86_64
-```
+
+  ```shell
+  yum downgrade docker-1.13.1-75.git8633870.el7.centos.x86_64 docker-client-1.13.1-75.git8633870.el7.centos.x86_64 docker-common-1.13.1-75.git8633870.el7.centos.x86_64
+  ```

 - 安装较新的推荐版本之一，例如 18.06:
-```bash
-sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
-yum install docker-ce-18.06.1.ce-3.el7.x86_64
-```
+
+  ```shell
+  sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
+  yum install docker-ce-18.06.1.ce-3.el7.x86_64
+  ```

 <!--
-## Not possible to pass a comma separated list of values to arguments inside a `--component-extra-args` flag
+## Not possible to pass a comma separated list of values to arguments inside a `-component-extra-args` flag

-`kubeadm init` flags such as `--component-extra-args` allow you to pass custom arguments to a control-plane
+`kubeadm init` flags such as `-component-extra-args` allow you to pass custom arguments to a control-plane
 component like the kube-apiserver. However, this mechanism is limited due to the underlying type used for parsing
 the values (`mapStringString`).

 If you decide to pass an argument that supports multiple, comma-separated values such as
-`--apiserver-extra-args "enable-admission-plugins=LimitRanger,NamespaceExists"` this flag will fail with
+`-apiserver-extra-args "enable-admission-plugins=LimitRanger,NamespaceExists"` this flag will fail with
 `flag: malformed pair, expect string=string`. This happens because the list of arguments for
-`--apiserver-extra-args` expects `key=value` pairs and in this case `NamespacesExists` is considered
+`-apiserver-extra-args` expects `key=value` pairs and in this case `NamespacesExists` is considered
 as a key that is missing a value.

 Alternatively, you can try separating the `key=value` pairs like so:
-`--apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists"`
+`-apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists"`
 but this will result in the key `enable-admission-plugins` only having the value of `NamespaceExists`.

 A known workaround is to use the kubeadm [configuration file](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#apiserver-flags).
 -->
 ## 无法将以逗号分隔的值列表传递给 `--component-extra-args` 标志内的参数

-`kubeadm init` 标志例如 `--component-extra-args` 允许您将自定义参数传递给像 kube-apiserver 这样的控制平面组件。然而，由于解析 (`mapStringString`) 的基础类型值，此机制将受到限制。
+`kubeadm init` 标志例如 `--component-extra-args` 允许你将自定义参数传递给像
+kube-apiserver 这样的控制平面组件。然而，由于解析 (`mapStringString`) 的基础类型值，此机制将受到限制。

-如果您决定传递一个支持多个逗号分隔值（例如 `--apiserver-extra-args "enable-admission-plugins=LimitRanger,NamespaceExists"`）参数，将出现 `flag: malformed pair, expect string=string` 错误。
-发生这种问题是因为参数列表 `--apiserver-extra-args` 预期的是 `key=value` 形式，而这里的 `NamespacesExists` 被误认为是缺少取值的键名。
+如果你决定传递一个支持多个逗号分隔值（例如
+`--apiserver-extra-args "enable-admission-plugins=LimitRanger,NamespaceExists"`）参数，
+将出现 `flag: malformed pair, expect string=string` 错误。
+发生这种问题是因为参数列表 `--apiserver-extra-args` 预期的是 `key=value` 形式，
+而这里的 `NamespacesExists` 被误认为是缺少取值的键名。

 一种解决方法是尝试分离 `key=value` 对，像这样：
 `--apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists"`
 但这将导致键 `enable-admission-plugins` 仅有值 `NamespaceExists`。

-已知的解决方法是使用 kubeadm [配置文件](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#apiserver-flags)。
+已知的解决方法是使用 kubeadm
+[配置文件](/zh/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#apiserver-flags)。

 <!--
 ## kube-proxy scheduled before node is initialized by cloud-controller-manager
@@ -599,17 +610,20 @@ The tracking issue for this problem is [here](https://github.com/kubernetes/kube
 这会导致 kube-proxy 无法正确获取节点的 IP 地址，并对管理负载平衡器的代理功能产生连锁反应。

 在 kube-proxy Pod 中可以看到以下错误：
+
 ```
 server.go:610] Failed to retrieve node IP: host IP unknown; known addresses: []
 proxier.go:340] invalid nodeIP, initializing kube-proxy with 127.0.0.1 as nodeIP
 ```

-一种已知的解决方案是修补 kube-proxy DaemonSet，以允许在控制平面节点上调度它，而不管它们的条件如何，将其与其他节点保持隔离，直到它们的初始保护条件消除：
-```
+一种已知的解决方案是修补 kube-proxy DaemonSet，以允许在控制平面节点上调度它，
+而不管它们的条件如何，将其与其他节点保持隔离，直到它们的初始保护条件消除：
+
+```shell
 kubectl -n kube-system patch ds kube-proxy -p='{ "spec": { "template": { "spec": { "tolerations": [ { "key": "CriticalAddonsOnly", "operator": "Exists" }, { "effect": "NoSchedule", "key": "node-role.kubernetes.io/master" } ] } } } }'
 ```

-此问题的跟踪 [在这里](https://github.com/kubernetes/kubeadm/issues/1027)。
+此问题的跟踪[在这里](https://github.com/kubernetes/kubeadm/issues/1027)。

 <!--
 ## The NodeRegistration.Taints field is omitted when marshalling kubeadm configuration
@@ -631,20 +645,21 @@ kubectl taint nodes NODE_NAME node-role.kubernetes.io/master:NoSchedule-
 -->
 ## NodeRegistration.Taints 字段在编组 kubeadm 配置时丢失

-*注意：这个 [问题](https://github.com/kubernetes/kubeadm/issues/1358) 仅适用于操控 kubeadm 数据类型的工具（例如，YAML 配置文件）。它将在 kubeadm API v1beta2 修复。*
+*注意：这个 [问题](https://github.com/kubernetes/kubeadm/issues/1358) 
+仅适用于操控 kubeadm 数据类型的工具（例如，YAML 配置文件）。它将在 kubeadm API v1beta2 修复。*

 默认情况下，kubeadm 将 `node-role.kubernetes.io/master:NoSchedule` 污点应用于控制平面节点。
-如果您希望 kubeadm 不污染控制平面节点，并将 `InitConfiguration.NodeRegistration.Taints` 设置成空切片，则应在编组时省略该字段。
+如果你希望 kubeadm 不污染控制平面节点，并将 `InitConfiguration.NodeRegistration.Taints` 设置成空切片，则应在编组时省略该字段。
 如果省略该字段，则 kubeadm 将应用默认污点。

 至少有两种解决方法：

 1. 使用 `node-role.kubernetes.io/master:PreferNoSchedule` 污点代替空切片。
-除非其他节点具有容量，[否则将在主节点上调度 Pods](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/)。
+  除非其他节点具有容量，[否则将在主节点上调度 Pods](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。

 2. 在 kubeadm init 退出后删除污点：
-```bash
-kubectl taint nodes NODE_NAME node-role.kubernetes.io/master:NoSchedule-
-```

+   ```shell
+   kubectl taint nodes NODE_NAME node-role.kubernetes.io/master:NoSchedule-
+   ```