[zh] fix links in setup section (3)

content/zh/docs/setup/release/version-skew-policy.md

@@ -1,12 +1,5 @@
 ---
-reviewers:
-- sig-api-machinery
-- sig-architecture
-- sig-cli
-- sig-cluster-lifecycle
-- sig-node
-- sig-release
-title: Kubernetes 版本及版本倾斜支持策略
+title: Kubernetes 版本及版本偏差支持策略
 content_type: concept
 weight: 30
 ---
@@ -16,7 +9,7 @@ weight: 30
 This document describes the maximum version skew supported between various Kubernetes components.
 Specific cluster deployment tools may place additional restrictions on version skew.
 -->
-本文描述 Kubernetes 各组件之间版本倾斜支持策略。
+本文描述 Kubernetes 各组件之间版本偏差支持策略。
 特定的集群部署工具可能会有额外的限制。
 
 
@@ -34,7 +27,7 @@ For more information, see [Kubernetes Release Versioning](https://github.com/kub
 -->
 Kubernetes 版本号格式为 **x.y.z**，其中 **x** 为大版本号，**y** 为小版本号，**z** 为补丁版本号。
 版本号格式遵循 [Semantic Versioning](https://semver.org/) 规则。
-更多信息，请参阅 [Kubernetes Release Versioning](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning)。
+更多信息，请参阅 [Kubernetes 发布版本](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning)。
 
 <!--
 The Kubernetes project maintains release branches for the most recent three minor releases.
@@ -48,9 +41,11 @@ This decision is owned by the [patch release manager](https://github.com/kuberne
 The patch release manager is a member of the [release team for each release](https://github.com/kubernetes/sig-release/tree/master/release-team).
 -->
 一些 bug 修复，包括安全修复，根据其安全性和可用性，有可能会回合到这些分支。
-补丁版本会定期或根据需要从这些分支中发布。
-最终是否发布是由[patch release team](https://github.com/kubernetes/sig-release/blob/master/release-engineering/role-handbooks/patch-release-manager.md#release-timing)
-来决定的。Patch release team同时也是[release managers](https://github.com/kubernetes/sig-release/blob/master/release-managers.md). 如需了解更多信息，请查看 [Kubernetes Patch releases](https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md).
+补丁版本会定期或根据需要从这些分支中发布。 最终是否发布是由
+[补丁发布团队](https://github.com/kubernetes/sig-release/blob/master/release-engineering/role-handbooks/patch-release-manager.md#release-timing)
+来决定的。补丁发布团队同时也是
+[发布管理者](https://github.com/kubernetes/sig-release/blob/master/release-managers.md)。
+如需了解更多信息，请查看 [Kubernetes 补丁发布](https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md)。
 
 <!--
 Minor releases occur approximately every 3 months, so each minor release branch is maintained for approximately 9 months.
@@ -60,14 +55,14 @@ Minor releases occur approximately every 3 months, so each minor release branch
 <!--
 ## Supported version skew
 -->
-## 版本倾斜策略
+## 版本偏差策略
 
 ### kube-apiserver
 
 <!--
 In [highly-available (HA) clusters](/docs/setup/production-environment/tools/kubeadm/high-availability/), the newest and oldest `kube-apiserver` instances must be within one minor version.
 -->
-在 [高可用（HA）集群](/docs/setup/production-environment/tools/kubeadm/high-availability/) 中，
+在 [高可用（HA）集群](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/) 中，
 多个 `kube-apiserver` 实例小版本号最多差1。
 
 <!--
@@ -100,10 +95,11 @@ Example:
 * `kube-apiserver` 版本号如果是 **1.13**
 * `kubelet` 只能是 **1.13** 、 **1.12** 和 **1.11**
 
-{{< note >}}
 <!--
-If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the allowed `kubelet` versions.-->如果
-HA集群中多个 `kube-apiserver` 实例版本号不一致，相应的 `kubelet` 版本号可选范围也要减小。
+If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the allowed `kubelet` versions.
+-->
+{{< note >}}
+如果 HA 集群中多个 `kube-apiserver` 实例版本号不一致，相应的 `kubelet` 版本号可选范围也要减小。
 {{</ note >}}
 
 <!--
@@ -139,9 +135,11 @@ Example:
 * 如果 `kube-apiserver` 版本号为 **1.13**
 * `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 版本支持 **1.13** 和 **1.12**
 
-{{< note >}}
 <!--
-If version skew exists between `kube-apiserver` instances in an HA cluster, and these components can communicate with any `kube-apiserver` instance in the cluster (for example, via a load balancer), this narrows the allowed versions of these components.-->如果在 HA 集群中，多个 `kube-apiserver` 实例版本号不一致，他们也可以跟任意一个 `kube-apiserver` 实例通信（例如，通过 load balancer），
+If version skew exists between `kube-apiserver` instances in an HA cluster, and these components can communicate with any `kube-apiserver` instance in the cluster (for example, via a load balancer), this narrows the allowed versions of these components.
+-->
+{{< note >}}
+如果在 HA 集群中，多个 `kube-apiserver` 实例版本号不一致，他们也可以跟任意一个 `kube-apiserver` 实例通信（例如，通过 load balancer），
 但 `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 版本可用范围会相应的减小。
 {{< /note >}}
 
@@ -176,9 +174,10 @@ Example:
 * 如果 `kube-apiserver` 当前是 **1.13** 版本
 * `kubectl` 则支持 **1.14** 、**1.13** 和 **1.12**
 
-{{< note >}}
 <!--
-If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the supported `kubectl` versions.-->
+If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the supported `kubectl` versions.
+-->
+{{< note >}}
 如果 HA 集群中的多个 `kube-apiserver` 实例版本号不一致，相应的 `kubectl` 可用版本范围也会减小。
 {{< /note >}}
 
@@ -202,7 +201,7 @@ Example:
 The supported version skew between components has implications on the order in which components must be upgraded.
 This section describes the order in which components must be upgraded to transition an existing cluster from version **1.n** to version **1.(n+1)**.
 -->
-组件之间支持的版本倾斜会影响组件升级的顺序。
+组件之间支持的版本偏差会影响组件升级的顺序。
 本节描述组件从版本 **1.n** 到 **1.(n+1)** 的升级次序。
 
 ### kube-apiserver
@@ -226,7 +225,9 @@ Pre-requisites:
 * `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 版本号必须为 **1.n**（确保不高于 API server 的版本，且版本号相差不大于1）
 * `kubelet` 实例版本号必须是 **1.n** 或 **1.(n-1)**（确保版本号不高于 API server，且版本号相差不大于2）
 * 注册的 admission 插件必须能够处理新的 `kube-apiserver` 实例发送过来的数据：
-  * `ValidatingWebhookConfiguration` 和 `MutatingWebhookConfiguration` 对象必须升级到可以处理 **1.(n+1)** 版本新加的 REST 资源(或使用1.15版本提供的 [`matchPolicy: Equivalent` 选项](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy))
+  * `ValidatingWebhookConfiguration` 和 `MutatingWebhookConfiguration` 对象必须升级到可以处理
+    **1.(n+1)** 版本新加的 REST 资源（或使用 1.15 版本提供的
+    [`matchPolicy: Equivalent` 选项](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy)）
   * 插件可以处理任何 **1.(n+1)** 版本新的 REST 资源数据和新加的字段
 
 <!--
@@ -238,7 +239,10 @@ Upgrade `kube-apiserver` to **1.(n+1)**
 <!--
 Project policies for [API deprecation](/docs/reference/using-api/deprecation-policy/) and
 [API change guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md)
-require `kube-apiserver` to not skip minor versions when upgrading, even in single-instance clusters.-->跟据 [API deprecation](/docs/reference/using-api/deprecation-policy/) 和 [API change guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md) 规则，
+require `kube-apiserver` to not skip minor versions when upgrading, even in single-instance clusters.
+-->
+跟据 [API 弃用策略](/zh/docs/reference/using-api/deprecation-policy/) 和
+[API 变更指南](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md)，
 `kube-apiserver` 不能跨小版本号升级，即使是单实例集群也不可以。
 
 {{< /note >}}
@@ -246,7 +250,7 @@ require `kube-apiserver` to not skip minor versions when upgrading, even in sing
 <!--
 ### kube-controller-manager, kube-scheduler, and cloud-controller-manager
 -->
-### kube-controller-manager、 kube-scheduler 和 cloud-controller-manager
+### kube-controller-manager、kube-scheduler 和 cloud-controller-manager
 
 <!--
 Pre-requisites:
@@ -277,15 +281,15 @@ Optionally upgrade `kubelet` instances to **1.(n+1)** (or they can be left at **
 
 `kubelet` 可以升级到 **1.(n+1)**（或者停留在 **1.n** 或 **1.(n-1)**）
 
-{{< warning >}}
 <!--
 Running a cluster with `kubelet` instances that are persistently two minor versions behind `kube-apiserver` is not recommended:
--->集群中 `kubelet` 版本号不建议比 `kube-apiserver` 低两个版本号：
 
-<!--
 * they must be upgraded within one minor version of `kube-apiserver` before the control plane can be upgraded
 * it increases the likelihood of running `kubelet` versions older than the three maintained minor releases
 -->
-* 他们必须升级到与 `kube-apiserver` 相差不超过1个小版本，才可以升级其他控制面组件
-* 有可能使用低于3个在维护的小版本
+{{< warning >}}
+集群中 `kubelet` 版本号不建议比 `kube-apiserver` 低两个版本号：
+
+* 它们必须升级到与 `kube-apiserver` 相差不超过 1 个小版本，才可以升级其他控制面组件
+* 有可能使用低于 3 个在维护的小版本
 {{</ warning >}}