[zh] Fix links in zh localization (3)

content/zh/docs/tasks/access-application-cluster/access-cluster.md

@@ -5,11 +5,9 @@ content_type: concept
 ---
 
 <!--
----
 title: Accessing Clusters
 weight: 20
 content_type: concept
----
 -->
 
 <!-- overview -->
@@ -19,8 +17,6 @@ This topic discusses multiple ways to interact with clusters.
 -->
 本文阐述多种与集群交互的方法。
 
-
-
 {{< toc >}}
 
 <!-- body -->
@@ -40,20 +36,26 @@ Check the location and credentials that kubectl knows about with this command:
 -->
 ## 使用 kubectl 完成集群的第一次访问
 
-当您第一次访问 Kubernetes API 的时候，我们建议您使用 Kubernetes CLI，`kubectl`。
+当你第一次访问 Kubernetes API 的时候，我们建议你使用 Kubernetes CLI，`kubectl`。
 
-访问集群时，您需要知道集群的地址并且拥有访问的凭证。通常，这些在您通过 [Getting started guide](/zh/docs/setup/) 安装集群时都是自动安装好的，或者其他人安装时也应该提供了凭证和集群地址。
+访问集群时，你需要知道集群的地址并且拥有访问的凭证。通常，这些在你通过
+[启动安装](/zh/docs/setup/)安装集群时都是自动安装好的，或者其他人安装时
+也应该提供了凭证和集群地址。
 
 通过以下命令检查 kubectl 是否知道集群地址及凭证：
 
 ```shell
-$ kubectl config view
+kubectl config view
 ```
 
 <!--
 Many of the [examples](/docs/user-guide/kubectl-cheatsheet) provide an introduction to using
 kubectl and complete documentation is found in the [kubectl manual](/docs/user-guide/kubectl-overview).
+-->
+有许多 [例子](/zh/docs/reference/kubectl/cheatsheet/) 介绍了如何使用 kubectl，
+可以在 [kubectl手册](/zh/docs/reference/kubectl/overview/) 中找到更完整的文档。
 
+<!--
 ## Directly accessing the REST API
 
 Kubectl handles locating and authenticating to the apiserver.
@@ -71,23 +73,22 @@ curl or wget, or a browser, there are several ways to locate and authenticate:
     - Works with some types of client code that are confused by using a proxy.
     - Need to import a root cert into your browser to protect against MITM.
 -->
-有许多 [例子](/zh/docs/reference/kubectl/cheatsheet/) 介绍了如何使用 kubectl，可以在 [kubectl手册](/zh/docs/reference/kubectl/overview/) 中找到更完整的文档。
-
 ## 直接访问 REST API
+
 Kubectl 处理 apiserver 的定位和身份验证。
-如果要使用 curl 或 wget 等 http 客户端或浏览器直接访问 REST API，可以通过多种方式查找和验证：
+如果要使用 curl 或 wget 等 http 客户端或浏览器直接访问 REST API，可以通过
+多种方式查找和验证：
 
-
-  - 以代理模式运行 kubectl。
-    - 推荐此方式。
-    - 使用已存储的 apiserver 地址。
-    - 使用自签名的证书来验证 apiserver 的身份。杜绝 MITM 攻击。
-    - 对 apiserver 进行身份验证。
-    - 未来可能会实现智能化的客户端负载均衡和故障恢复。
-  - 直接向 http 客户端提供位置和凭据。
-    - 可选的方案。
-    - 适用于代理可能引起混淆的某些客户端类型。
-    - 需要引入根证书到您的浏览器以防止 MITM 攻击。
+- 以代理模式运行 kubectl。
+  - 推荐此方式。
+  - 使用已存储的 apiserver 地址。
+  - 使用自签名的证书来验证 apiserver 的身份。杜绝 MITM 攻击。
+  - 对 apiserver 进行身份验证。
+  - 未来可能会实现智能化的客户端负载均衡和故障恢复。
+- 直接向 http 客户端提供位置和凭据。
+  - 可选的方案。
+  - 适用于代理可能引起混淆的某些客户端类型。
+  - 需要引入根证书到你的浏览器以防止 MITM 攻击。
 
 <!--
 ### Using kubectl proxy
@@ -96,13 +97,13 @@ The following command runs kubectl in a mode where it acts as a reverse proxy.
 locating the apiserver and authenticating.
 Run it like this:
 -->
-### 使用 kubectl 代理
+### 使用 kubectl proxy
 
-以下命令以反向代理的模式运行kubectl。它处理 apiserver 的定位和验证。
+以下命令以反向代理的模式运行 kubectl。它处理 apiserver 的定位和验证。
 像这样运行：
 
 ```shell
-$ kubectl proxy --port=8080 &
+kubectl proxy --port=8080 &
 ```
 
 <!--
@@ -111,12 +112,16 @@ See [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands/#proxy) f
 Then you can explore the API with curl, wget, or a browser, replacing localhost
 with [::1] for IPv6, like so:
 -->
-参阅 [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands/#proxy) 获取更多详细信息。
+参阅 [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands/#proxy)
+获取更多详细信息。
 
-然后，您可以使用 curl、wget 或浏览器访问 API，如果是 IPv6 则用 [::1] 替换 localhost，如下所示：
+然后，你可以使用 curl、wget 或浏览器访问 API，如果是 IPv6 则用 [::1] 替换 localhost，
+如下所示：
 
 ```shell
-$ curl http://localhost:8080/api/
+curl http://localhost:8080/api/
+```
+```json
 {
   "kind": "APIVersions",
   "versions": [
@@ -131,22 +136,24 @@ $ curl http://localhost:8080/api/
 }
 ```
 
-
 <!--
 ### Without kubectl proxy
 
 In Kubernetes version 1.3 or later, `kubectl config view` no longer displays the token. Use `kubectl describe secret...` to get the token for the default service account, like this:
 -->
-### 不使用 kubectl 代理
+### 不使用 kubectl proxy
 
-在 Kubernetes 1.3 或更高版本中，`kubectl config view` 不再显示 token。使用 `kubectl describe secret ...` 来获取默认服务帐户的 token，如下所示：
+在 Kubernetes 1.3 或更高版本中，`kubectl config view` 不再显示 token。
+使用 `kubectl describe secret ...` 来获取默认服务帐户的 token，如下所示：
 
 `grep/cut` 方法实现：
 
 ```shell
-$ APISERVER=$(kubectl config view | grep server | cut -f 2- -d ":" | tr -d " ")
-$ TOKEN=$(kubectl describe secret $(kubectl get secrets | grep default | cut -f1 -d ' ') | grep -E '^token' | cut -f2 -d':' | tr -d ' ')
-$ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
+APISERVER=$(kubectl config view | grep server | cut -f 2- -d ":" | tr -d " ")
+TOKEN=$(kubectl describe secret $(kubectl get secrets | grep default | cut -f1 -d ' ') | grep -E '^token' | cut -f2 -d':' | tr -d ' ')
+curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
+```
+```json
 {
   "kind": "APIVersions",
   "versions": [
@@ -164,9 +171,12 @@ $ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
 `jsonpath` 方法实现：
 
 ```shell
-$ APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
-$ TOKEN=$(kubectl get secret $(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode )
-$ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
+APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
+TOKEN=$(kubectl get secret $(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode )
+curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
+```
+
+```json
 {
   "kind": "APIVersions",
   "versions": [
@@ -195,9 +205,15 @@ for this.  [Configuring Access to the API](/docs/admin/accessing-the-api)
 describes how a cluster admin can configure this.  Such approaches may conflict
 with future high-availability support.
 -->
-上面的例子使用了 `--insecure` 参数，这使得它很容易受到 MITM 攻击。当 kubectl 访问集群时，它使用存储的根证书和客户端证书来访问服务器（这些安装在 `~/.kube` 目录中）。由于集群证书通常是自签名的，因此可能需要特殊配置才能让您的 http 客户端使用根证书。
+上面的例子使用了 `--insecure` 参数，这使得它很容易受到 MITM 攻击。
+当 kubectl 访问集群时，它使用存储的根证书和客户端证书来访问服务器
+（它们安装在 `~/.kube` 目录中）。
+由于集群证书通常是自签名的，因此可能需要特殊配置才能让你的 http 客户端使用根证书。
 
-在一些集群中，apiserver 不需要身份验证；它可能只服务于 localhost，或者被防火墙保护，这个没有一定的标准。 [配置对 API 的访问](/zh/docs/reference/access-authn-authz/controlling-access/) 描述了集群管理员如何进行配置。此类方法可能与未来的高可用性支持相冲突。
+在一些集群中，apiserver 不需要身份验证；它可能只服务于 localhost，或者被防火墙保护，
+这个没有一定的标准。
+[配置对 API 的访问](/zh/docs/concepts/security/controlling-access/)
+描述了集群管理员如何进行配置。此类方法可能与未来的高可用性支持相冲突。
 
 <!--
 ## Programmatic access to the API
@@ -210,7 +226,7 @@ client libraries.
 * To get the library, run the following command: `go get k8s.io/client-go/<version number>/kubernetes`. See [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go) to see which versions are supported.
 * Write an application atop of the client-go clients. Note that client-go defines its own API objects, so if needed, please import API definitions from client-go rather than from the main repository, e.g., `import "k8s.io/client-go/1.4/pkg/api/v1"` is correct.
 
-The Go client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
+The Go client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
 as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go).
 
 If the application is deployed as a Pod in the cluster, please refer to the [next section](#accessing-the-api-from-a-pod).
@@ -221,12 +237,20 @@ Kubernetes 官方提供对 [Go](#go-client) 和 [Python](#python-client) 的客
 
 ### Go 客户端
 
-* 想要获得这个库，请运行命令：`go get k8s.io/client-go/<version number>/kubernetes`。参阅 [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go) 来查看目前支持哪些版本。
-* 基于这个 client-go 客户端库编写应用程序。 请注意，client-go 定义了自己的 API 对象，因此如果需要，请从 client-go 而不是从主存储库导入 API 定义，例如，`import "k8s.io/client-go/1.4/pkg/api/v1"` 才是对的。
+* 想要获得这个库，请运行命令：`go get k8s.io/client-go/<version number>/kubernetes`。
+  参阅 [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go)
+  来查看目前支持哪些版本。
+* 基于这个 client-go 客户端库编写应用程序。
+  请注意，client-go 定义了自己的 API 对象，因此如果需要，请从 client-go 而不是从主存储库
+  导入 API 定义，例如，`import "k8s.io/client-go/1.4/pkg/api/v1"` 才是对的。
 
-Go 客户端可以像 kubectl CLI 一样使用相同的 [kubeconfig 文件](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 来定位和验证 apiserver。可参阅 [示例](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)。
+Go 客户端可以像 kubectl CLI 一样使用相同的
+[kubeconfig 文件](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+来定位和验证 apiserver。可参阅
+[示例](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)。
 
-如果应用程序以 Pod 的形式部署在集群中，那么请参阅 [下一章](#accessing-the-api-from-a-pod)。
+如果应用程序以 Pod 的形式部署在集群中，那么请参阅
+[下一章](#accessing-the-api-from-a-pod)。
 
 <!--
 ### Python client
@@ -243,13 +267,20 @@ See documentation for other libraries for how they authenticate.
 -->
 ### Python 客户端
 
-如果想要使用 [Python 客户端](https://github.com/kubernetes-client/python)，请运行命令：`pip install kubernetes`。参阅 [Python Client Library page](https://github.com/kubernetes-client/python) 以获得更详细的安装参数。
+如果想要使用 [Python 客户端](https://github.com/kubernetes-client/python)，
+请运行命令：`pip install kubernetes`。参阅
+[Python Client Library page](https://github.com/kubernetes-client/python)
+以获得更详细的安装参数。
 
-Python 客户端可以像 kubectl CLI 一样使用相同的 [kubeconfig 文件](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 来定位和验证 apiserver，可参阅 [示例](https://github.com/kubernetes-client/python/tree/master/examples)。
+Python 客户端可以像 kubectl CLI 一样使用相同的
+[kubeconfig 文件](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+来定位和验证 apiserver，可参阅
+[示例](https://github.com/kubernetes-client/python/tree/master/examples)。
 
 ### 其它语言
 
-目前有多个 [客户端库](/zh/docs/reference/using-api/client-libraries/) 为其它语言提供访问 API 的方法。
+目前有多个[客户端库](/zh/docs/reference/using-api/client-libraries/)
+为其它语言提供访问 API 的方法。
 参阅其它库的相关文档以获取他们是如何验证的。
 
 <!--
@@ -272,10 +303,14 @@ at `/var/run/secrets/kubernetes.io/serviceaccount/token`.
 
 当你从 Pod 中访问 API 时，定位和验证 apiserver 会有些许不同。
 
-在 Pod 中定位 apiserver 的推荐方式是通过 `kubernetes.default.svc` 这个 DNS 名称，该名称将会解析为服务 IP，然后服务 IP 将会路由到 apiserver。
+在 Pod 中定位 apiserver 的推荐方式是通过 `kubernetes.default.svc`
+这个 DNS 名称，该名称将会解析为服务 IP，然后服务 IP 将会路由到 apiserver。
 
-向 apiserver 进行身份验证的推荐方法是使用 [服务帐户](/zh/docs/tasks/configure-pod-container/configure-service-account/) 凭据。
-通过 kube-system，pod 与服务帐户相关联，并且该服务帐户的凭证（token）被放置在该 pod 中每个容器的文件系统中，位于 `/var/run/secrets/kubernetes.io/serviceaccount/token`。
+向 apiserver 进行身份验证的推荐方法是使用
+[服务帐户](/zh/docs/tasks/configure-pod-container/configure-service-account/) 凭据。
+通过 kube-system，Pod 与服务帐户相关联，并且该服务帐户的凭证（token）
+被放置在该 Pod 中每个容器的文件系统中，位于
+`/var/run/secrets/kubernetes.io/serviceaccount/token`。
 
 <!--
 If available, a certificate bundle is placed into the filesystem tree of each
@@ -284,7 +319,16 @@ used to verify the serving certificate of the apiserver.
 
 Finally, the default namespace to be used for namespaced API operations is placed in a file
 at `/var/run/secrets/kubernetes.io/serviceaccount/namespace` in each container.
+-->
+如果可用，则将证书放入每个容器的文件系统中的
+`/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`，
+并且应该用于验证 apiserver 的服务证书。
 
+最后，名字空间作用域的 API 操作所使用的 default 名字空间将被放置在
+每个容器的 `/var/run/secrets/kubernetes.io/serviceaccount/namespace`
+文件中。
+
+<!--
 From within a pod the recommended ways to connect to API are:
 
   - run `kubectl proxy` in a sidecar container in the pod, or as a background
@@ -296,18 +340,17 @@ From within a pod the recommended ways to connect to API are:
 
 In each case, the credentials of the pod are used to communicate securely with the apiserver.
 -->
-如果可用，则将证书放入每个容器的文件系统中的 `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`，并且应该用于验证 apiserver 的服务证书。
+在 Pod 中，建议连接 API 的方法是：
 
-最后，命名空间化的 API 操作所使用的默认命名空间将被放置在每个容器的 `/var/run/secrets/kubernetes.io/serviceaccount/namespace` 文件中。
+- 在 Pod 的边车容器中运行 `kubectl proxy`，或者以后台进程的形式运行。
+  这将把 Kubernetes API 代理到当前 Pod 的 localhost 接口，
+  所以 Pod 中的所有容器中的进程都能访问它。
+- 使用 Go 客户端库，并使用 `rest.InClusterConfig()` 和
+  `kubernetes.NewForConfig()` 函数创建一个客户端。
+  他们处理 apiserver 的定位和身份验证。
+  [示例](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)
 
-在 pod 中，建议连接 API 的方法是：
-
-  - 在 pod 的 sidecar 容器中运行 `kubectl proxy`，或者以后台进程的形式运行。
-    这将把 Kubernetes API 代理到当前 pod 的 localhost interface，所以 pod 中的所有容器中的进程都能访问它。
-  - 使用 Go 客户端库，并使用 `rest.InClusterConfig()` 和 `kubernetes.NewForConfig()` 函数创建一个客户端。
-    他们处理 apiserver 的定位和身份验证。[示例](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)
-
-在每种情况下，pod 的凭证都是为了与 apiserver 安全地通信。
+在每种情况下，Pod 的凭证都是为了与 apiserver 安全地通信。
 
 <!--
 ## Accessing services running on the cluster
@@ -321,9 +364,13 @@ such as your desktop machine.
 -->
 ## 访问集群中正在运行的服务  {#accessing-services-running-on-the-cluster}
 
-上一节介绍了如何连接 Kubernetes API 服务。本节介绍如何连接到 Kubernetes 集群上运行的其他服务。
-在 Kubernetes 中，[节点](/zh/docs/concepts/architecture/nodes/)，[pods](/zh/docs/concepts/workloads/pods/) 和 [服务](/zh/docs/concepts/services-networking/service/) 都有自己的 IP。
-在许多情况下，集群上的节点 IP，pod IP 和某些服务 IP 将无法路由，因此无法从集群外部的计算机（例如桌面计算机）访问它们。
+上一节介绍了如何连接 Kubernetes API 服务。本节介绍如何连接到 Kubernetes
+集群上运行的其他服务。
+在 Kubernetes 中，[节点](/zh/docs/concepts/architecture/nodes/)、
+[pods](/zh/docs/concepts/workloads/pods/) 和
+[服务](/zh/docs/concepts/services-networking/service/) 都有自己的 IP。
+在许多情况下，集群上的节点 IP、Pod IP 和某些服务 IP 将无法路由，
+因此无法从集群外部的计算机（例如桌面计算机）访问它们。
 
 <!--
 ### Ways to connect
@@ -341,6 +388,24 @@ You have several options for connecting to nodes, pods and services from outside
       place a unique label on the pod and create a new service which selects this label.
     - In most cases, it should not be necessary for application developer to directly access
       nodes via their nodeIPs.
+-->
+### 连接的方法   {#ways-to-connect}
+
+有多种方式可以从集群外部连接节点、Pod 和服务：
+
+- 通过公共 IP 访问服务。
+
+  - 类型为 `NodePort` 或 `LoadBalancer` 的服务，集群外部可以访问。
+    请参阅 [服务](/zh/docs/concepts/services-networking/service/) 和
+    [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 文档。
+  - 取决于你的集群环境，该服务可能仅暴露给你的公司网络，或者也可能暴露给
+    整个互联网。
+    请考虑公开该服务是否安全。它是否进行自己的身份验证？
+  - 在服务后端放置 Pod。要从一组副本中访问一个特定的 Pod，例如进行调试，
+    请在 Pod 上设置一个唯一的标签，然后创建一个选择此标签的新服务。
+  - 在大多数情况下，应用程序开发人员不应该通过其 nodeIP 直接访问节点。
+
+<!--
   - Access services, nodes, or pods using the Proxy Verb.
     - Does apiserver authentication and authorization prior to accessing the remote service.
       Use this if the services are not secure enough to expose to the internet, or to gain
@@ -348,6 +413,16 @@ You have several options for connecting to nodes, pods and services from outside
     - Proxies may cause problems for some web applications.
     - Only works for HTTP/HTTPS.
     - Described [here](#manually-constructing-apiserver-proxy-urls).
+-->
+- 使用 proxy 动词访问服务、节点或者 Pod。
+  - 在访问远程服务之前进行 apiserver 身份验证和授权。
+    如果服务不能够安全地暴露到互联网，或者服务不能获得节点 IP 端口的
+    访问权限，或者是为了调试，那么请使用此选项。
+  - 代理可能会给一些 web 应用带来问题。
+  - 只适用于 HTTP/HTTPS。
+  - 更多详细信息在[这里](#manually-constructing-apiserver-proxy-urls)。
+
+<!--
   - Access from a node or pod in the cluster.
     - Run a pod, and then connect to a shell in it using [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec).
       Connect to other nodes, pods, and services from that shell.
@@ -355,29 +430,14 @@ You have several options for connecting to nodes, pods and services from outside
       access cluster services.  This is a non-standard method, and will work on some clusters but
       not others.  Browsers and other tools may or may not be installed.  Cluster DNS may not work.
 -->
-### 连接的方法
+- 从集群中的节点或者 Pod 中访问。
 
-有多种方式可以从集群外部连接节点、pod 和服务：
-
-  - 通过公共 IP 访问服务。
-    - 类型为 `NodePort` 或 `LoadBalancer` 的服务，集群外部可以访问。
-      请参阅 [服务](/zh/docs/concepts/services-networking/service/) 和 [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 文档。
-    - 取决于您的集群环境，该服务可能仅暴露给您的公司网络，或者也可能暴露给整个互联网。
-      请考虑公开该服务是否安全。它是否进行自己的身份验证？
-    - 在服务后端放置 pod。要从一组副本中访问一个特定的 pod，例如进行调试，请在 pod 上放置一个唯一的标签，然后创建一个选择此标签的新服务。
-    - 在大多数情况下，应用程序开发人员不应该通过其 nodeIP 直接访问节点。
-  - 使用 Proxy Verb 访问服务、node 或者 pod。
-    - 在访问远程服务之前进行 apiserver 身份验证和授权。
-      如果服务不能够安全地暴露到互联网，或者服务不能获得节点 IP 端口的访问权限，或者是为了 debug，那么请使用此选项。
-    - 代理可能会给一些 web 应用带来问题。
-    - 只适用于 HTTP/HTTPS。
-    - 更多详细信息在 [这里](#manually-constructing-apiserver-proxy-urls)。
-  - 从集群中的 node 或者 pod 中访问。
-    - 运行一个 pod，然后使用 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec) 来连接 pod 里的 shell。
-      然后从 shell 中连接其它的节点、pod 和服务。
-    - 有些集群可能允许您通过 ssh 连接到 node，从那您可能可以访问集群的服务。
-      这是一个非正式的方式，可能可以运行在个别的集群上。
-      浏览器和其它一些工具可能没有被安装。集群的 DNS 可能无法使用。
+  - 运行一个 Pod，然后使用 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)
+    来连接 Pod 里的 Shell。
+    然后从 Shell 中连接其它的节点、Pod 和服务。
+  - 有些集群可能允许你通过 SSH 连接到节点，从那你可能可以访问集群的服务。
+    这是一个非正式的方式，可能可以运行在个别的集群上。
+    浏览器和其它一些工具可能没有被安装。集群的 DNS 可能无法使用。
 
 <!--
 ### Discovering builtin services
@@ -392,14 +452,16 @@ with the `kubectl cluster-info` command:
 通过 `kubectl cluster-info` 命令获得这些服务列表：
 
 ```shell
-$ kubectl cluster-info
+kubectl cluster-info
+```
 
-  Kubernetes master is running at https://104.197.5.247
-  elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy
-  kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy
-  kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy
-  grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
-  heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
+```
+Kubernetes master is running at https://104.197.5.247
+elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy
+kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy
+kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy
+grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
+heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
 ```
 
 <!--
@@ -410,7 +472,10 @@ at `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-l
 (See [above](#accessing-the-cluster-api) for how to pass credentials or use kubectl proxy.)
 -->
 这展示了访问每个服务的 proxy-verb URL。
-例如，如果集群启动了集群级别的日志（使用 Elasticsearch），并且传递合适的凭证，那么可以通过 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` 进行访问。日志也能通过 kubectl 代理获取，例如：
+例如，如果集群启动了集群级别的日志（使用 Elasticsearch），并且传递合适的凭证，
+那么可以通过
+`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`
+进行访问。日志也能通过 kubectl 代理获取，例如：
 `http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`。
 （参阅 [上面的内容](#accessing-the-cluster-api) 来获取如何使用 kubectl 代理来传递凭证）
 
@@ -434,12 +499,14 @@ The supported formats for the name segment of the URL are:
 -->
 #### 手动构建 apiserver 代理 URL {#manually-constructing-apiserver-proxy-urls}
 
-如上所述，您可以使用 `kubectl cluster-info` 命令来获得服务的代理 URL。要创建包含服务端点、后缀和参数的代理 URL，只需添加到服务的代理 URL：
+如上所述，你可以使用 `kubectl cluster-info` 命令来获得服务的代理 URL。
+要创建包含服务端点、后缀和参数的代理 URL，只需添加到服务的代理 URL：
 `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy`
 
 如果尚未为端口指定名称，则不必在 URL 中指定 *port_name*。
 
-默认情况下，API server 使用 http 代理您的服务。要使用 https，请在服务名称前加上 `https:`：
+默认情况下，API server 使用 HTTP 代理你的服务。
+要使用 HTTPS，请在服务名称前加上 `https:`：
 `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`https:service_name:[port_name]`*`/proxy`
 
 URL 名称段支持的格式为：
@@ -457,8 +524,10 @@ URL 名称段支持的格式为：
 -->
 ##### 示例
 
- * 要访问 Elasticsearch  服务端点 `_search?q=user:kimchy`，您需要使用：`http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`
- * 要访问 Elasticsearch 集群健康信息 `_cluster/health?pretty=true`，您需要使用：`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`
+* 要访问 Elasticsearch  服务端点 `_search?q=user:kimchy`，你需要使用：
+  `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`
+* 要访问 Elasticsearch 集群健康信息 `_cluster/health?pretty=true`，你需要使用：
+  `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`
 
 ```json
   {
@@ -487,10 +556,12 @@ You may be able to put an apiserver proxy url into the address bar of a browser.
 -->
 ### 使用 web 浏览器访问运行在集群上的服务
 
-您可以在浏览器地址栏中输入 apiserver 代理 URL。但是：
+你可以在浏览器地址栏中输入 apiserver 代理 URL。但是：
 
-  - Web 浏览器通常不能传递 token，因此您可能需要使用基本（密码）身份验证。Apiserver 可以配置为接受基本身份验证，但您的集群可能未进行配置。
-  - 某些 Web 应用程序可能无法运行，尤其是那些使用客户端 javascript 以不知道代理路径前缀的方式构建 URL 的应用程序。
+- Web 浏览器通常不能传递令牌，因此你可能需要使用基本（密码）身份验证。
+  Apiserver 可以配置为接受基本身份验证，但你的集群可能未进行配置。
+- 某些 Web 应用程序可能无法运行，尤其是那些使用客户端 javascript 
+  以不知道代理路径前缀的方式构建 URL 的应用程序。
 
 <!--
 ## Requesting redirects
@@ -499,7 +570,7 @@ The redirect capabilities have been deprecated and removed.  Please use a proxy
 -->
 ## 请求重定向
 
-已弃用并删除了重定向功能。请改用代理（见下文）。
+重定向功能已弃用并被删除。请改用代理（见下文）。
 
 <!--
 ## So Many Proxies
@@ -520,14 +591,14 @@ There are several different proxies you may encounter when using Kubernetes:
 
 使用 Kubernetes 时可能会遇到几种不同的代理：
 
-1.  [kubectl 代理](#directly-accessing-the-rest-api)：
+1. [kubectl 代理](#directly-accessing-the-rest-api)：
 
-    - 在用户的桌面或 pod 中运行
-    - 代理从本地主机地址到 Kubernetes apiserver
-    - 客户端到代理将使用 HTTP
-    - 代理到 apiserver 使用 HTTPS
-    - 定位 apiserver
-    - 添加身份验证 header
+   - 在用户的桌面或 Pod 中运行
+   - 代理从本地主机地址到 Kubernetes apiserver
+   - 客户端到代理将使用 HTTP
+   - 代理到 apiserver 使用 HTTPS
+   - 定位 apiserver
+   - 添加身份验证头部
 
 <!--
 1.  The [apiserver proxy](#discovering-builtin-services):
@@ -540,15 +611,15 @@ There are several different proxies you may encounter when using Kubernetes:
     - can be used to reach a Node, Pod, or Service
     - does load balancing when used to reach a Service
 -->
-2.  [apiserver 代理](#discovering-builtin-services)：
+2. [apiserver 代理](#discovering-builtin-services)：
 
-    - 内置于 apiserver 中
-    - 将集群外部的用户连接到集群 IP，否则这些 IP 可能无法访问
-    - 运行在 apiserver 进程中
-    - 客户端代理使用 HTTPS（也可配置为 http）
-    - 代理将根据可用的信息决定使用 HTTP 或者 HTTPS 代理到目标
-    - 可用于访问节点、Pod 或服务
-    - 在访问服务时进行负载平衡
+   - 内置于 apiserver 中
+   - 将集群外部的用户连接到集群 IP，否则这些 IP 可能无法访问
+   - 运行在 apiserver 进程中
+   - 客户端代理使用 HTTPS（也可配置为 http）
+   - 代理将根据可用的信息决定使用 HTTP 或者 HTTPS 代理到目标
+   - 可用于访问节点、Pod 或服务
+   - 在访问服务时进行负载平衡
 
 <!--
 1.  The [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips):
@@ -559,13 +630,13 @@ There are several different proxies you may encounter when using Kubernetes:
     - provides load balancing
     - is just used to reach services
 -->
-3.  [kube proxy](/zh/docs/concepts/services-networking/service/#ips-and-vips)：
+3. [kube proxy](/zh/docs/concepts/services-networking/service/#ips-and-vips)：
 
-    - 运行在每个节点上
-    - 代理 UDP 和 TCP
-    - 不能代理 HTTP
-    - 提供负载均衡
-    - 只能用来访问服务
+   - 运行在每个节点上
+   - 代理 UDP 和 TCP
+   - 不能代理 HTTP
+   - 提供负载均衡
+   - 只能用来访问服务
 
 <!--
 1.  A Proxy/Load-balancer in front of apiserver(s):
@@ -574,11 +645,11 @@ There are several different proxies you may encounter when using Kubernetes:
     - sits between all clients and one or more apiservers
     - acts as load balancer if there are several apiservers.
 -->
-4.  位于 apiserver 之前的 Proxy/Load-balancer：
+4. 位于 apiserver 之前的 Proxy/Load-balancer：
 
-    - 存在和实现因集群而异（例如 nginx）
-    - 位于所有客户和一个或多个 apiserver 之间
-    - 如果有多个 apiserver，则充当负载均衡器
+   - 存在和实现因集群而异（例如 nginx）
+   - 位于所有客户和一个或多个 apiserver 之间
+   - 如果有多个 apiserver，则充当负载均衡器
 
 <!--
 1.  Cloud Load Balancers on external services:
@@ -591,11 +662,13 @@ There are several different proxies you may encounter when using Kubernetes:
 Kubernetes users will typically not need to worry about anything other than the first two types.  The cluster admin
 will typically ensure that the latter types are setup correctly.
 -->
-5.  外部服务上的云负载均衡器：
+5. 外部服务上的云负载均衡器：
 
-    - 由一些云提供商提供（例如 AWS ELB，Google Cloud Load Balancer）
-    - 当 Kubernetes 服务类型为 `LoadBalancer` 时自动创建
-    - 只使用 UDP/TCP
-    - 具体实现因云提供商而异。
+   - 由一些云提供商提供（例如 AWS ELB，Google Cloud Load Balancer）
+   - 当 Kubernetes 服务类型为 `LoadBalancer` 时自动创建
+   - 只使用 UDP/TCP
+   - 具体实现因云提供商而异。
+
+除了前两种类型之外，Kubernetes 用户通常不需要担心任何其他问题。
+集群管理员通常会确保后者的正确配置。
 
-除了前两种类型之外，Kubernetes 用户通常不需要担心任何其他问题。集群管理员通常会确保后者的正确配置。

content/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md

@@ -5,6 +5,7 @@ card:
   name: tasks
   weight: 40
 ---
+
 <!--
 title: Configure Access to Multiple Clusters
 content_type: task
@@ -46,7 +47,7 @@ cluster's API server.
 要检查 {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} 是否安装，
 执行 `kubectl version --client` 命令。
 kubectl 的版本应该与集群的 API 服务器
-[使用同一次版本号](/docs/setup/release/version-skew-policy/#kubectl)。
+[使用同一次版本号](/zh/docs/setup/release/version-skew-policy/#kubectl)。
 
 <!-- steps -->
 <!--
@@ -67,7 +68,9 @@ Create a directory named `config-exercise`. In your
 假设用户有两个集群，一个用于正式开发工作，一个用于其它临时用途（scratch）。
 在 `development` 集群中，前端开发者在名为 `frontend` 的名字空间下工作，
 存储开发者在名为 `storage` 的名字空间下工作。 在 `scratch` 集群中，
-开发人员可能在默认名字空间下工作，也可能视情况创建附加的名字空间。 访问开发集群需要通过证书进行认证。 访问其它临时用途的集群需要通过用户名和密码进行认证。
+开发人员可能在默认名字空间下工作，也可能视情况创建附加的名字空间。 
+访问开发集群需要通过证书进行认证。
+访问其它临时用途的集群需要通过用户名和密码进行认证。
 
 创建名为 `config-exercise` 的目录。 在
 `config-exercise` 目录中，创建名为 `config-demo` 的文件，其内容为：
@@ -103,10 +106,10 @@ has the framework to describe two clusters, two users, and three contexts.
 Go to your `config-exercise` directory. Enter these commands to add cluster details to
 your configuration file:
 -->
+配置文件描述了集群、用户名和上下文。`config-demo` 文件中含有描述两个集群、
+两个用户和三个上下文的框架。
 
-配置文件描述了集群、用户名和上下文。  `config-demo` 文件中含有描述两个集群、两个用户和三个上下文的框架。
-
-进入 `config-exercise` 目录。 输入以下命令，将群集详细信息添加到配置文件中：
+进入 `config-exercise` 目录。输入以下命令，将群集详细信息添加到配置文件中：
 
 ```shell
 kubectl config --kubeconfig=config-demo set-cluster development --server=https://1.2.3.4 --certificate-authority=fake-ca-file
@@ -149,7 +152,8 @@ kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratc
 Open your `config-demo` file to see the added details. As an alternative to opening the
 `config-demo` file, you can use the `config view` command.
 -->
-打开 `config-demo` 文件查看添加的详细信息。 也可以使用 `config view` 命令进行查看：
+打开 `config-demo` 文件查看添加的详细信息。 也可以使用 `config view`
+命令进行查看：
 
 ```shell
 kubectl config --kubeconfig=config-demo view
@@ -369,7 +373,8 @@ For example:
 -->
 ## 设置 KUBECONFIG 环境变量
 
-查看是否有名为 `KUBECONFIG` 的环境变量。 如有，保存 `KUBECONFIG` 环境变量当前的值，以便稍后恢复。
+查看是否有名为 `KUBECONFIG` 的环境变量。
+如有，保存 `KUBECONFIG` 环境变量当前的值，以便稍后恢复。
 例如：
 
 ### Linux
@@ -522,11 +527,13 @@ Return your `KUBECONFIG` environment variable to its original value. For example
 将 `KUBECONFIG` 环境变量还原为原始值。 例如：
 
 ### Linux
+
 ```shell
 export KUBECONFIG=$KUBECONFIG_SAVED
 ```
 
 ### Windows PowerShell
+
 ```shell
 $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
 ```

content/zh/docs/tasks/administer-cluster/access-cluster-services.md

@@ -26,10 +26,9 @@ such as your desktop machine.
 -->
 ## 访问集群上运行的服务
 
-
-在 Kubernetes 里，[Node](/zh/docs/concepts/architecture/nodes/)、
+在 Kubernetes 里，[节点](/zh/docs/concepts/architecture/nodes/)、
 [Pod](/zh/docs/concepts/workloads/pods/) 和
-[Service](/zh/docs/concepts/services-networking/services/) 都有自己的 IP。
+[服务](/zh/docs/concepts/services-networking/service/) 都有自己的 IP。
 许多情况下，集群上的节点 IP、Pod IP 和某些服务 IP 是路由不可达的，
 所以不能从集群之外访问它们，例如从你自己的台式机。
 
@@ -57,7 +56,7 @@ You have several options for connecting to nodes, pods and services from outside
 -->
 - 通过公网 IP 访问服务
   - 使用类型为 `NodePort` 或 `LoadBalancer` 的服务，可以从外部访问它们。
-    请查阅[服务](/zh/docs/concepts/services-networking/services/) 和
+    请查阅[服务](/zh/docs/concepts/services-networking/service/) 和
     [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 文档。
   - 取决于你的集群环境，你可以仅把服务暴露在你的企业网络环境中，也可以将其暴露在
     因特网上。需要考虑暴露的服务是否安全，它是否有自己的用户认证？
@@ -134,13 +133,16 @@ at `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-l
 -->
 这一输出显示了用 proxy 动词访问每个服务时可用的 URL。例如，此集群
 （使用 Elasticsearch）启用了集群层面的日志。如果提供合适的凭据，可以通过
-`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` 访问，或通过一个 `kubectl proxy` 来访问：`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`。
+`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`
+访问，或通过一个 `kubectl proxy` 来访问：
+`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`。
 
 <!--
 See [Access Clusters Using the Kubernetes API](/docs/tasks/administer-cluster/access-cluster-api/#accessing-the-cluster-api) for how to pass credentials or use kubectl proxy.
 -->
 {{< note >}}
-请参阅[使用 Kubernets API 访问集群](/docs/tasks/administer-cluster/access-cluster-api/#accessing-the-cluster-api)了解如何传递凭据或如何使用 `kubectl proxy`。
+请参阅[使用 Kubernets API 访问集群](/zh/docs/tasks/administer-cluster/access-cluster-api/#accessing-the-cluster-api)
+了解如何传递凭据或如何使用 `kubectl proxy`。
 {{< /note >}}
 
 <!--

content/zh/docs/tasks/administer-cluster/change-default-storage-class.md

@@ -30,7 +30,8 @@ for details.
 
 取决于安装模式，你的 Kubernetes 集群可能和一个被标记为默认的已有 StorageClass 一起部署。
 这个默认的 StorageClass 以后将被用于动态的为没有特定存储类需求的 PersistentVolumeClaims 
-配置存储。更多细节请查看 [PersistentVolumeClaim 文档](/zh/docs/user-guide/persistent-volumes/#class-1)。
+配置存储。更多细节请查看
+[PersistentVolumeClaim 文档](/zh/docs/concepts/storage/persistent-volumes/#perspersistentvolumeclaims)。
 
 <!--
 The pre-installed default StorageClass may not fit well with your expected workload;
@@ -138,7 +139,7 @@ for details about addon manager and how to disable individual addons.
    -->
    输出类似这样：
 
-   ```bash
+   ```
    NAME             PROVISIONER               AGE
    standard         kubernetes.io/gce-pd      1d
    gold (default)   kubernetes.io/gce-pd      1d
@@ -149,5 +150,5 @@ for details about addon manager and how to disable individual addons.
 <!--
 * Learn more about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/).
 -->
-* 进一步了解 [StorageClasses](/docs/concepts/storage/persistent-volumes/)
+* 进一步了解 [PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/)
 

content/zh/docs/tasks/administer-cluster/change-pv-reclaim-policy.md

@@ -2,7 +2,9 @@
 title: 更改 PersistentVolume 的回收策略
 content_type: task
 ---
+
 <!-- overview -->
+
 <!--
 This page shows how to change the reclaim policy of a Kubernetes
 PersistentVolume.
@@ -131,8 +133,8 @@ PersistentVolumes 可以有多种回收策略，包括 "Retain"、"Recycle" 和
 * Learn more about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/).
 * Learn more about [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims).
 -->
-* 进一步了解 [PersistentVolumes](/docs/concepts/storage/persistent-volumes/)
-* 进一步了解 [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
+* 进一步了解 [PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/)
+* 进一步了解 [PersistentVolumeClaims](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
 
 ### 参考
 

content/zh/docs/tasks/administer-cluster/highly-available-master.md

@@ -1,53 +1,40 @@
 ---
-reviewers:
-- jszczepkowski
-translaters:
-- Coffey Gao
 title: 搭建高可用的 Kubernetes Masters
 content_type: task
 ---
 
 <!--
----
 reviewers:
 - jszczepkowski
 title: Set up High-Availability Kubernetes Masters
 content_type: task
----
 -->
 
-
 <!-- overview -->
 
 {{< feature-state for_k8s_version="1.5" state="alpha" >}}
+
 <!--
 You can replicate Kubernetes masters in `kube-up` or `kube-down` scripts for Google Compute Engine.
 This document describes how to use kube-up/down scripts to manage highly available (HA) masters and how HA masters are implemented for use with GCE.
 -->
-
-您可以在谷歌计算引擎（GCE）的 `kubeup` 或 `kube-down` 脚本中复制 Kubernetes Master。
-本文描述了如何使用 kube-up/down 脚本来管理高可用（HA）的 Master，以及如何使用 GCE 实现高可用 Master。
-
-
-
+你可以在谷歌计算引擎（GCE）的 `kubeup` 或 `kube-down` 脚本中复制 Kubernetes Master。
+本文描述了如何使用 kube-up/down 脚本来管理高可用（HA）的 Master，
+以及如何使用 GCE 实现高可用控制节点。
 
 ## {{% heading "prerequisites" %}}
 
-
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
-
-
 <!-- steps -->
 <!--
 ## Starting an HA-compatible cluster
 
 To create a new HA-compatible cluster, you must set the following flags in your `kube-up` script:
 -->
-
 ## 启动一个兼容高可用的集群
 
-要创建一个新的兼容高可用的集群，您必须在 `kubeup` 脚本中设置以下标志:
+要创建一个新的兼容高可用的集群，你必须在 `kubeup` 脚本中设置以下标志:
 
 <!--
 * `MULTIZONE=true` - to prevent removal of master replicas kubelets from zones different than server's default zone.
@@ -71,13 +58,16 @@ MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b  ENABLE_ETCD_QUORUM_READS=true ./clu
 Note that the commands above create a cluster with one master;
 however, you can add new master replicas to the cluster with subsequent commands.
 -->
-* `MULTIZONE=true` - 为了防止从不同于 Master 默认区域的区域中删除 kubelets 副本。如果您希望在不同的区域运行 Master 副本，那么这一项是必需并且推荐的。
+* `MULTIZONE=true` - 为了防止从不同于服务器的默认区域的区域中删除 kubelets 副本。
+  如果你希望在不同的区域运行副本，那么这一项是必需并且推荐的。
 
-* `ENABLE_ETCD_QUORUM_READ=true` - 确保从所有 API 服务器读取数据时将返回最新的数据。如果为 true，读操作将被定向到 leader etcd 副本。可以选择将这个值设置为 true，那么读取将更可靠，但也会更慢。
+* `ENABLE_ETCD_QUORUM_READ=true` - 确保从所有 API 服务器读取数据时将返回最新的数据。
+  如果为 true，读操作将被定向到主 etcd 副本。可以选择将这个值设置为 true，
+  那么读取将更可靠，但也会更慢。
 
-您还可以指定一个 GCE 区域，在这里创建第一个 Master 副本。设置以下标志:
+你还可以指定一个 GCE 区域，在这里创建第一个主节点副本。设置以下标志:
 
-* `KUBE_GCE_ZONE=zone` - 将运行第一个 Master 副本的区域。
+* `KUBE_GCE_ZONE=zone` - 将运行第一个主节点副本的区域。
 
 下面的命令演示在 GCE  europe-west1-b 区域中设置一个兼容高可用的集群:
 
@@ -85,8 +75,8 @@ however, you can add new master replicas to the cluster with subsequent commands
 MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b  ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh
 ```
 
-注意，上面的命令创建一个只有单一 Master 的集群;
-但是，您可以使用后续命令将新的 Master 副本添加到集群中。
+注意，上面的命令创建一个只有单一主节点的集群;
+但是，你可以使用后续命令将新的主节点副本添加到集群中。
 
 <!--
 ## Adding a new master replica
@@ -109,17 +99,16 @@ The following sample command replicates the master on an existing HA-compatible
 KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
 ```
 -->
+## 增加一个新的主节点副本
 
-## 增加一个新的 Master 副本
+在创建了兼容高可用的集群之后，可以向其中添加主节点副本。
+你可以使用带有如下标记的 `kubeup` 脚本添加主节点副本:
 
-在创建了兼容高可用的集群之后，可以向其中添加 Master 副本。
-您可以使用带有如下标记的 `kubeup` 脚本添加 Master 副本:
+* `KUBE_REPLICATE_EXISTING_MASTER=true` - 创建一个已经存在的主节点的副本。
 
-* `KUBE_REPLICATE_EXISTING_MASTER=true` - 创建一个已经存在的 Master 的副本。
+* `KUBE_GCE_ZONE=zone` -主节点副本将运行的区域。必须与其他副本位于同一区域。
 
-* `KUBE_GCE_ZONE=zone` - Master 副本将运行的区域。必须与其他副本位于同一区域。
-
-您无需设置 `MULTIZONE` 或 `ENABLE_ETCD_QUORUM_READS` 标志，因为他们可以从兼容高可用的集群中继承。
+你无需设置 `MULTIZONE` 或 `ENABLE_ETCD_QUORUM_READS` 标志，因为他们可以从兼容高可用的集群中继承。
 
 使用下面的命令可以复制现有兼容高可用的集群上的 Master:
 
@@ -144,16 +133,15 @@ The following sample command removes a master replica from an existing HA cluste
 KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh
 ```
 -->
+## 删除主节点副本
 
-## 删除一个 Master 副本
-
-你可以使用一个 `kube-down` 脚本从高可用集群中删除一个 Master 副本，并可以使用以下标记:
+你可以使用一个 `kube-down` 脚本从高可用集群中删除一个主节点副本，并可以使用以下标记:
 
 * `KUBE_DELETE_NODES=false` - 限制删除 kubelets。
 
-* `KUBE_GCE_ZONE=zone` - 将移除 Master 副本的区域。
+* `KUBE_GCE_ZONE=zone` - 将移除主节点副本的区域。
 
-* `KUBE_REPLICA_NAME=replica_name` - （可选）要删除的 Master 副本的名称。
+* `KUBE_REPLICA_NAME=replica_name` - （可选）要删除的主节点副本的名称。
 如果为空：将删除给定区域中的所有副本。
 
 使用下面的命令可以从一个现有的高可用集群中删除一个 Master副本:
@@ -180,10 +168,10 @@ KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_nam
 KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
 ```
 -->
+## 处理主节点副本失败
 
-## 处理 Master 副本失败
-
-如果高可用集群中的一个 Master 副本失败，最佳实践是从集群中删除副本，并在相同的区域中添加一个新副本。
+如果高可用集群中的一个主节点副本失败，最佳实践是从集群中删除副本，
+并在相同的区域中添加一个新副本。
 下面的命令演示了这个过程:
 
 1. 删除失败的副本:
@@ -214,19 +202,22 @@ This operation may be sped up by migrating etcd data directory, as described [he
 (we are considering adding support for etcd data dir migration in future).
 -->
 
-## 高可用集群复制 Master 的最佳实践
-
-* 尝试将 Master 副本放置在不同的区域。在某区域故障时，放置在该区域内的所有主机都将失败。
-为了在区域故障中幸免，请同样将工作节点放置在多区域中（详情请见[多区域](/docs/setup/best-practices/multiple-zones/)）。
-
-* 不要使用具有两个 Master 副本的集群。在双副本集群上达成一致需要在更改持久状态时两个副本都处于运行状态。因此，两个副本都是需要的，任一副本的失败都会将集群带入多数失败状态。因此，就高可用而言，双副本集群不如单个副本集群。
-
-* 添加 Master 副本时，集群状态（etcd）会被复制到一个新实例。如果集群很大，可能需要很长时间才能复制它的状态。
-这个操作可以通过迁移 etcd 数据存储来加速, 详情参见 [这里](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration)
-（我们正在考虑在未来添加对迁移 etcd 数据存储的支持）。
+## 高可用集群复制主节点的最佳实践
 
+* 尝试将主节点副本放置在不同的区域。在某区域故障时，放置在该区域内的所有主机都将失败。
+  为了在区域故障中幸免，请同样将工作节点放置在多区域中
+  （详情请见[多区域](/zh/docs/setup/best-practices/multiple-zones/)）。
 
+* 不要使用具有两个主节点副本的集群。在双副本集群上达成一致需要在更改持久状态时
+  两个副本都处于运行状态。
+  因此，两个副本都是需要的，任一副本的失败都会将集群带入多数失败状态。
+  因此，就高可用而言，双副本集群不如单个副本集群。
 
+* 添加主节点副本时，集群状态（etcd）会被复制到一个新实例。如果集群很大，
+  可能需要很长时间才能复制它的状态。
+  这个操作可以通过迁移 etcd 数据存储来加速, 详情参见
+  [这里](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration)
+  （我们正在考虑在未来添加对迁移 etcd 数据存储的支持）。
 
 <!-- discussion -->
 <!--
@@ -234,8 +225,7 @@ This operation may be sped up by migrating etcd data directory, as described [he
 
 ![ha-master-gce](/images/docs/ha-master-gce.png)
 -->
-
-## 实施注意事项
+## 实现说明
 
 ![ha-master-gce](/images/docs/ha-master-gce.png)
 
@@ -254,10 +244,9 @@ Each of master replicas will run the following components in the following mode:
 
 In addition, there will be a load balancer in front of API servers that will route external and internal traffic to them.
 -->
-
 ### 概述
 
-每个 Master 副本将以以下模式运行以下组件:
+每个主节点副本将以以下模式运行以下组件:
 
 * etcd 实例： 所有实例将会以共识方式组建集群；
 
@@ -265,7 +254,7 @@ In addition, there will be a load balancer in front of API servers that will rou
 
 * 控制器、调度器和集群自动扩缩器：将使用租约机制 —— 每个集群中只有一个实例是可用的；
 
-* add-on manager：每个管理器将独立工作，试图保持插件同步。
+* 插件管理器：每个管理器将独立工作，试图保持插件同步。
 
 此外，在 API 服务器前面将有一个负载均衡器，用于将外部和内部通信路由到他们。
 
@@ -277,15 +266,16 @@ and the IP address of the first replica will be promoted to IP address of load b
 Similarly, after removal of the penultimate master replica, the load balancer will be removed and its IP address will be assigned to the last remaining replica.
 Please note that creation and removal of load balancer are complex operations and it may take some time (~20 minutes) for them to propagate.
 -->
+### 负载均衡
 
-### 负载均衡器
-
-启动第二个 Master 副本时，将创建一个包含两个副本的负载均衡器，并将第一个副本的 IP 地址提升为负载均衡器的 IP 地址。
-类似地，在删除倒数第二个 Master 副本之后，将删除负载均衡器，并将其 IP 地址分配给最后一个剩余的副本。
+启动第二个主节点副本时，将创建一个包含两个副本的负载均衡器，
+并将第一个副本的 IP 地址提升为负载均衡器的 IP 地址。
+类似地，在删除倒数第二个主节点副本之后，将删除负载均衡器，
+并将其 IP 地址分配给最后一个剩余的副本。
 请注意，创建和删除负载均衡器是复杂的操作，可能需要一些时间（约20分钟）来同步。
 
 <!--
-### Master service & kubelets
+###主节点service & kubelets
 
 Instead of trying to keep an up-to-date list of Kubernetes apiserver in the Kubernetes service,
 the system directs all traffic to the external IP:
@@ -296,30 +286,28 @@ the system directs all traffic to the external IP:
 
 Similarly, the external IP will be used by kubelets to communicate with master.
 -->
+### 主节点服务 & kubelets
 
-### Master 服务 & kubelets
+Kubernetes 并不试图在其服务中保持 apiserver 的列表为最新，
+相反，它将将所有访问请求指向外部 IP：
 
-Kubernetes 并不试图在其服务中保持 apiserver 的列表为最新，相反，它将将所有访问请求指向外部 IP：
+* 在拥有一个主节点的集群中，IP 指向单一的主节点，
+* 在拥有多个主节点的集群中，IP 指向主节点前面的负载均衡器。
 
-* 在拥有一个 Master 的集群中，IP 指向单一的 Master，
-
-* 在拥有多个 Master 的集群中，IP 指向 Master 前面的负载均衡器。
-
-类似地，kubelets 将使用外部 IP 与 Master 通信。
+类似地，kubelets 将使用外部 IP 与主节点通信。
 
 <!--
 ### Master certificates
 
-Kubernetes generates Master TLS certificates for the external public IP and local IP for each replica.
+Kubernetes generates主节点TLS certificates for the external public IP and local IP for each replica.
 There are no certificates for the ephemeral public IP for replicas;
 to access a replica via its ephemeral public IP, you must skip TLS verification.
 -->
+### 主节点证书
 
-### Master 证书
-
-Kubernetes 为每个副本的外部公共 IP 和本地 IP 生成 Master TLS 证书。
+Kubernetes 为每个副本的外部公共 IP 和本地 IP 生成主节点 TLS 证书。
 副本的临时公共 IP 没有证书；
-要通过其临时公共 IP 访问副本，必须跳过TLS验证。
+要通过其临时公共 IP 访问副本，必须跳过 TLS 检查。
 
 <!--
 ### Clustering etcd
@@ -327,7 +315,6 @@ Kubernetes 为每个副本的外部公共 IP 和本地 IP 生成 Master TLS 证
 To allow etcd clustering, ports needed to communicate between etcd instances will be opened (for inside cluster communication).
 To make such deployment secure, communication between etcd instances is authorized using SSL.
 -->
-
 ### etcd 集群
 
 为了允许 etcd 组建集群，需开放 etcd 实例之间通信所需的端口（用于集群内部通信）。
@@ -338,9 +325,7 @@ To make such deployment secure, communication between etcd instances is authoriz
 
 [Automated HA master deployment - design doc](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md)
 -->
-
 ## 拓展阅读
 
 [自动化高可用集群部署 - 设计文档](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md)
 
-

content/zh/docs/tasks/administer-cluster/limit-storage-consumption.md

@@ -12,7 +12,7 @@ content_type: task
 <!--
 This example demonstrates an easy way to limit the amount of storage consumed in a namespace.
 -->
-此示例演示了一种限制命名空间中存储使用量的简便方法。
+此示例演示了一种限制名字空间中存储使用量的简便方法。
 
 <!--
 The following resources are used in the demonstration: [ResourceQuota](/docs/concepts/policy/resource-quotas/),
@@ -21,8 +21,7 @@ and [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/).
 -->
 演示中用到了以下资源：[ResourceQuota](/zh/docs/concepts/policy/resource-quotas/)，
 [LimitRange](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) 和
-[PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/)。
-
+[PersistentVolumeClaim](/zh/docs/concepts/storage/persistent-volumes/)。
 
 ## {{% heading "prerequisites" %}}
 
@@ -51,9 +50,9 @@ The admin would like to limit:
 2. The amount of storage each claim can request
 3. The amount of cumulative storage the namespace can have
 -->
-1. 命名空间中持久卷申领（persistent volume claims）的数量
+1. 名字空间中持久卷申领（persistent volume claims）的数量
 2. 每个申领（claim）可以请求的存储量
-3. 命名空间可以具有的累计存储量
+3. 名字空间可以具有的累计存储量
 
 <!--
 ## LimitRange to limit requests for storage
@@ -63,7 +62,9 @@ The admin would like to limit:
 <!--
 Adding a `LimitRange` to a namespace enforces storage request sizes to a minimum and maximum. Storage is requested via `PersistentVolumeClaim`. The admission controller that enforces limit ranges will reject any PVC that is above or below the values set by the admin.
 -->
-将 `LimitRange` 添加到命名空间会为存储请求大小强制设置最小值和最大值。存储是通过 `PersistentVolumeClaim` 来发起请求的。执行限制范围控制的准入控制器会拒绝任何高于或低于管理员所设阈值的 PVC。
+将 `LimitRange` 添加到名字空间会为存储请求大小强制设置最小值和最大值。
+存储是通过 `PersistentVolumeClaim` 来发起请求的。
+执行限制范围控制的准入控制器会拒绝任何高于或低于管理员所设阈值的 PVC。
 
 <!--
 In this example, a PVC requesting 10Gi of storage would be rejected because it exceeds the 2Gi max.
@@ -88,7 +89,8 @@ spec:
 Minimum storage requests are used when the underlying storage provider requires certain minimums. For example,
 AWS EBS volumes have a 1Gi minimum requirement.
 -->
-当底层存储提供程序需要某些最小值时，将会用到所设置最小存储请求值。例如，AWS EBS volumes 的最低要求为 1Gi。
+当底层存储提供程序需要某些最小值时，将会用到所设置最小存储请求值。
+例如，AWS EBS volumes 的最低要求为 1Gi。
 
 <!--
 ## StorageQuota to limit PVC count and cumulative storage capacity
@@ -99,14 +101,18 @@ AWS EBS volumes have a 1Gi minimum requirement.
 Admins can limit the number of PVCs in a namespace as well as the cumulative capacity of those PVCs. New PVCs that exceed
 either maximum value will be rejected.
 -->
-管理员可以限制某个命名空间中的 PVCs 个数以及这些 PVCs 的累计容量。新 PVCs 请求如果超过任一上限值将被拒绝。
+管理员可以限制某个名字空间中的 PVCs 个数以及这些 PVCs 的累计容量。
+新 PVCs 请求如果超过任一上限值将被拒绝。
 
 <!--
 In this example, a 6th PVC in the namespace would be rejected because it exceeds the maximum count of 5. Alternatively,
 a 5Gi maximum quota when combined with the 2Gi max limit above, cannot have 3 PVCs where each has 2Gi. That would be 6Gi requested
  for a namespace capped at 5Gi.
 -->
-在此示例中，命名空间中的第 6 个 PVC 将被拒绝，因为它超过了最大计数 5。或者，当与上面的 2Gi 最大容量限制结合在一起时，意味着 5Gi 的最大配额不能支持 3 个都是 2Gi 的 PVC。后者实际上是向命名空间请求 6Gi 容量，而该命令空间已经设置上限为 5Gi。
+在此示例中，名字空间中的第 6 个 PVC 将被拒绝，因为它超过了最大计数 5。
+或者，当与上面的 2Gi 最大容量限制结合在一起时，意味着 5Gi 的最大配额
+不能支持 3 个都是 2Gi 的 PVC。
+后者实际上是向名字空间请求 6Gi 容量，而该命令空间已经设置上限为 5Gi。
 
 ```
 apiVersion: v1
@@ -119,18 +125,17 @@ spec:
     requests.storage: "5Gi"
 ```
 
-
-
 <!-- discussion -->
 
 <!--
 ## Summary
--->
-## 小结
 
-<!--
 A limit range can put a ceiling on how much storage is requested while a resource quota can effectively cap the storage consumed by a namespace through claim counts and cumulative storage capacity. The allows a cluster-admin to plan their
 cluster's storage budget without risk of any one project going over their allotment.
 -->
-限制范围对象可以用来设置可请求的存储量上限，而资源配额对象则可以通过申领计数和累计存储容量有效地限制命名空间耗用的存储量。这两种机制使得集群管理员能够规划其集群存储预算而不会发生任一项目超量分配的风险。
+## 小结
+
+限制范围对象可以用来设置可请求的存储量上限，而资源配额对象则可以通过申领计数和
+累计存储容量有效地限制名字空间耗用的存储量。
+这两种机制使得集群管理员能够规划其集群存储预算而不会发生任一项目超量分配的风险。
 

content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md

@@ -92,7 +92,7 @@ Each Node has a weave Pod, and all Pods are `Running` and `2/2 READY`. (`2/2` me
 Once you have installed the Weave Net addon, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy. If you have any question, contact us at [#weave-community on Slack or Weave User Group](https://github.com/weaveworks/weave#getting-help).
  -->
 安装 Weave Net 插件后，你可以参考
-[声明网络策略](/zh/docs/tasks/administration-cluster/declare-network-policy/)
+[声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/)
 来试用 Kubernetes NetworkPolicy。
 如果你有任何疑问，请通过
 [Slack 上的 #weave-community 频道或者 Weave 用户组](https://github.com/weaveworks/weave#getting-help)

content/zh/docs/tasks/administer-cluster/safely-drain-node.md

@@ -16,11 +16,13 @@ content_type: task
 <!-- 
 This page shows how to safely drain a node, respecting the PodDisruptionBudget you have defined.
  -->
-本页展示了如何在确保 PodDisruptionBudget 的前提下，安全地清空一个{{< glossary_tooltip text="节点" term_id="node" >}}。
+本页展示了如何在确保 PodDisruptionBudget 的前提下，安全地清空一个
+{{< glossary_tooltip text="节点" term_id="node" >}}。
 
 ## {{% heading "prerequisites" %}}
 
 {{% version-check %}}
+
 <!-- 
 This task assumes that you have met the following prerequisites:
 
@@ -37,7 +39,8 @@ This task assumes that you have met the following prerequisites:
 * 使用的 Kubernetes 版本 >= 1.5。
 * 以下两项，具备其一：
   1. 在节点清空期间，不要求应用程序具有高可用性
-  1. 你已经了解了 [PodDisruptionBudget 的概念](/zh/docs/concepts/workloads/pods/disruptions/)，并为需要它的应用程序[配置了 PodDisruptionBudget](/zh/docs/tasks/run-application/configure-pdb/)。
+  1. 你已经了解了 [PodDisruptionBudget 的概念](/zh/docs/concepts/workloads/pods/disruptions/)，
+     并为需要它的应用程序[配置了 PodDisruptionBudget](/zh/docs/tasks/run-application/configure-pdb/)。
 
 <!-- steps -->
 
@@ -144,7 +147,8 @@ replicas to fall below the specified budget are blocked.
 并设置了一个 `PodDisruptionBudget`，指定 `minAvailable: 2`。
 如果所有的三个 Pod 均就绪，并且你并行地发出多个 drain 命令，
 那么 `kubectl drain` 只会从 StatefulSet 中逐出一个 Pod，
-因为 Kubernetes 会遵守 PodDisruptionBudget 并确保在任何时候只有一个 Pod 不可用（最多不可用 Pod 个数的计算方法：`replicas - minAvailable`）。
+因为 Kubernetes 会遵守 PodDisruptionBudget 并确保在任何时候只有一个 Pod 不可用
+（最多不可用 Pod 个数的计算方法：`replicas - minAvailable`）。
 任何会导致就绪副本数量低于指定预算的清空操作都将被阻止。
 
 <!-- 
@@ -156,7 +160,7 @@ eviction process), you can also programmatically cause evictions using the evict
 -->
 ## 驱逐 API {#the-eviction-api}
 如果你不喜欢使用
-[kubectl drain](/zh/docs/reference/generated/kubectl/kubectl-commands/#drain)
+[kubectl drain](/docs/reference/generated/kubectl/kubectl-commands/#drain)
 （比如避免调用外部命令，或者更细化地控制 pod 驱逐过程），
 你也可以用驱逐 API 通过编程的方式达到驱逐的效果。
 
@@ -172,7 +176,8 @@ itself. To attempt an eviction (perhaps more REST-precisely, to attempt to
 [Kubernetes 语言客户端](/zh/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api)。
 
 Pod 的 Eviction 子资源可以看作是一种策略控制的 DELETE 操作，作用于 Pod 本身。
-要尝试驱逐（更准确地说，尝试 *创建* 一个 Eviction），需要用 POST 发出所尝试的操作。这里有一个例子：
+要尝试驱逐（更准确地说，尝试 *创建* 一个 Eviction），需要用 POST
+发出所尝试的操作。这里有一个例子：
 
 ```json
 {
@@ -254,7 +259,8 @@ application owners and cluster owners to establish an agreement on behavior in t
 ## 驱逐阻塞
 
 在某些情况下，应用程序可能会到达一个中断状态，除了 429 或 500 之外，它将永远不会返回任何内容。
-例如 ReplicaSet 创建的替换 Pod 没有变成就绪状态，或者被驱逐的最后一个 Pod 有很长的终止宽限期，就会发生这种情况。
+例如 ReplicaSet 创建的替换 Pod 没有变成就绪状态，或者被驱逐的最后一个
+Pod 有很长的终止宽限期，就会发生这种情况。
 
 在这种情况下，有两种可能的解决方案：
 
@@ -266,12 +272,9 @@ Kubernetes 并没有具体说明在这种情况下应该采取什么行为，
 
 ## {{% heading "whatsnext" %}}
 
-
 <!-- 
 * Follow steps to protect your application by [configuring a Pod Disruption Budget](/docs/tasks/run-application/configure-pdb/).
-* Learn more about [maintenance on a node](/docs/tasks/administer-cluster/cluster-management/#maintenance-on-a-node).
 -->
-* 跟随以下步骤保护应用程序：[配置 Pod 中断预算](/zh/docs/tasks/run-application/configure-pdb/)。
-* 进一步了解[节点维护](/zh/docs/tasks/administer-cluster/cluster-management/#maintenance-on-a-node)。
-
+* 执行[配置 PDB](/zh/docs/tasks/run-application/configure-pdb/)中的各个步骤，
+  保护你的应用
 

content/zh/docs/tasks/configmap-secret/managing-secret-using-config-file.md

@@ -150,7 +150,7 @@ stringData:
 ## 创建 Secret 对象    {#create-the-secret-object}
 
 <!-- Now create the Secret using [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply): -->
-现在使用 [`kubectl apply`](/zh/docs/reference/generated/kubectl/kubectl-commands#apply) 创建 Secret：
+现在使用 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 创建 Secret：
 
 ```shell
 kubectl apply -f ./secret.yaml

content/zh/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md

@@ -23,9 +23,9 @@ This page shows how to debug Pods and ReplicationControllers.
 
 <!-- 
 * You should be familiar with the basics of
-  [Pods](/docs/concepts/workloads/pods/pod/) and [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/). 
+  [Pods](/docs/concepts/workloads/pods/) and [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/). 
 -->
-* 你应该先熟悉 [Pods](/zh/docs/concepts/workloads/pods/pod/) 和
+* 你应该先熟悉 [Pods](/zh/docs/concepts/workloads/pods/) 和
   [Pod 生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/) 的基础概念。 
 
 <!-- steps -->

content/zh/docs/tasks/debug-application-cluster/debug-running-pod.md

@@ -20,7 +20,8 @@ This page explains how to debug Pods running (or crashing) on a Node.
   need that access to run the standard debug steps that use `kubectl`.
 -->
 * 你的 {{< glossary_tooltip text="Pod" term_id="pod" >}} 应该已经被调度并正在运行中，
-如果你的 Pod 还没有运行，请参阅[应用问题排查](/docs/tasks/debug-application-cluster/debug-application/)。
+  如果你的 Pod 还没有运行，请参阅
+  [应用问题排查](/zh/docs/tasks/debug-application-cluster/debug-application/)。
 
 * 对于一些高级调试步骤，你应该知道 Pod 具体运行在哪个节点上，在该节点上有权限去运行一些命令。
   你不需要任何访问权限就可以使用 `kubectl` 去运行一些标准调试步骤。
@@ -147,7 +148,8 @@ images.
 ## 使用临时容器来调试的例子 {#ephemeral-container-example}
 
 {{< note >}}
-本示例需要你的集群已经开启 `EphemeralContainers` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
+本示例需要你的集群已经开启 `EphemeralContainers`
+[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
 `kubectl` 版本为 v1.18 或者更高。
 {{< /note >}}
 

content/zh/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md

@@ -20,7 +20,7 @@ in the [Logging With Stackdriver Logging](/docs/user-guide/logging/stackdriver).
 -->
 在 Google Compute Engine (GCE) 平台上，默认的日志管理支持目标是
 [Stackdriver Logging](https://cloud.google.com/logging/)，
-在[使用 Stackdriver Logging 管理日志](/docs/tasks/debug-application-cluster/logging-stackdriver/)
+在[使用 Stackdriver Logging 管理日志](/zh/docs/tasks/debug-application-cluster/logging-stackdriver/)
 中详细描述了这一点。
 
 <!--
@@ -49,7 +49,8 @@ To use Elasticsearch and Kibana for cluster logging, you should set the
 following environment variable as shown below when creating your cluster with
 kube-up.sh:
 -->
-要使用 Elasticsearch 和 Kibana 处理集群日志，你应该在使用 kube-up.sh 脚本创建集群时设置下面所示的环境变量：
+要使用 Elasticsearch 和 Kibana 处理集群日志，你应该在使用 kube-up.sh
+脚本创建集群时设置下面所示的环境变量：
 
 ```shell
 KUBE_LOGGING_DESTINATION=elasticsearch
@@ -96,7 +97,7 @@ all be running in the kube-system namespace soon after the cluster comes to
 life.
 -->
 每个节点的 Fluentd Pod、Elasticsearch Pod 和 Kibana Pod 都应该在集群启动后不久运行在
-kube-system 命名空间中。
+kube-system 名字空间中。
 
 ```shell
 kubectl get pods --namespace=kube-system
@@ -137,8 +138,8 @@ and are not directly exposed via a publicly reachable IP address. To reach them,
 follow the instructions for [Accessing services running in a cluster](/docs/concepts/cluster-administration/access-cluster/#accessing-services-running-on-the-cluster).
 -->
 
-Elasticsearch 和 Kibana 服务都位于 `kube-system` 命名空间中，并且没有通过可公开访问的 IP 地址直接暴露。
-要访问它们，请参照
+Elasticsearch 和 Kibana 服务都位于 `kube-system` 名字空间中，并且没有通过
+可公开访问的 IP 地址直接暴露。要访问它们，请参照
 [访问集群中运行的服务](/zh/docs/tasks/access-application-cluster/access-cluster/#accessing-services-running-on-the-cluster)
 的说明进行操作。
 
@@ -156,7 +157,8 @@ like. See [Elasticsearch's documentation](https://www.elastic.co/guide/en/elasti
 for more details on how to do so.
 -->
 现在你可以直接在浏览器中输入 Elasticsearch 查询，如果你愿意的话。
-请参考 [Elasticsearch 的文档](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html) 以了解这样做的更多细节。
+请参考 [Elasticsearch 的文档](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html)
+以了解这样做的更多细节。
 
 <!--
 Alternatively, you can view your cluster's logs using Kibana (again using the
@@ -192,3 +194,4 @@ ideas on how to dig into it, check out [Kibana's documentation](https://www.elas
 -->
 Kibana 为浏览你的日志提供了各种强大的选项！有关如何深入研究它的一些想法，
 请查看 [Kibana 的文档](https://www.elastic.co/guide/en/kibana/current/discover.html)。
+

content/zh/docs/tasks/debug-application-cluster/logging-stackdriver.md

@@ -367,7 +367,8 @@ log names:
 <!--
 You can learn more about viewing logs on [the dedicated Stackdriver page](https://cloud.google.com/logging/docs/view/logs_viewer).
 -->
-你可以在[专用 Stackdriver 页面](https://cloud.google.com/logging/docs/view/overview)上了解有关查看日志的更多信息。
+你可以在[Stackdriver 专用页面](https://cloud.google.com/logging/docs/view/overview)
+上了解有关查看日志的更多信息。
 
 <!--
 One of the possible ways to view logs is using the
@@ -376,8 +377,11 @@ command line interface from the [Google Cloud SDK].
 It uses Stackdriver Logging [filtering syntax](https://cloud.google.com/logging/docs/view/advanced_filters)
 to query specific logs. For example, you can run the following command:
 -->
-查看日志的一种可能方法是使用 [Google Cloud SDK]((https://cloud.google.com/sdk/)) 中的 [`gcloud logging`](https://cloud.google.com/logging/docs/reference/tools/gcloud-logging) 命令行接口。
-它使用 Stackdriver 日志机制的[过滤语法](https://cloud.google.com/logging/docs/view/advanced_filters)查询特定日志。
+查看日志的一种可能方法是使用 [Google Cloud SDK](https://cloud.google.com/sdk/)
+中的 [`gcloud logging`](https://cloud.google.com/logging/docs/reference/tools/gcloud-logging)
+命令行接口。
+它使用 Stackdriver 日志机制的
+[过滤语法](https://cloud.google.com/logging/docs/view/advanced_filters)查询特定日志。
 例如，你可以运行以下命令：
 
 ```none
@@ -399,7 +403,8 @@ As you can see, it outputs messages for the count container from both
 the first and second runs, despite the fact that the kubelet already deleted
 the logs for the first container.
 -->
-如你所见，尽管 kubelet 已经删除了第一个容器的日志，日志中仍会包含 counter 容器第一次和第二次运行时输出的消息。
+如你所见，尽管 kubelet 已经删除了第一个容器的日志，日志中仍会包含 counter
+容器第一次和第二次运行时输出的消息。
 
 <!--
 ### Exporting logs
@@ -416,7 +421,8 @@ the Stackdriver [Exporting Logs page](https://cloud.google.com/logging/docs/expo
 你可以将日志导出到 [Google Cloud Storage](https://cloud.google.com/storage/) 或
 [BigQuery](https://cloud.google.com/bigquery/) 进行进一步的分析。
 Stackdriver 日志机制提供了接收器（Sink）的概念，你可以在其中指定日志项的存放地。
-可在 Stackdriver [导出日志页面](https://cloud.google.com/logging/docs/export/configure_export_v2)上获得更多信息。
+可在 Stackdriver [导出日志页面](https://cloud.google.com/logging/docs/export/configure_export_v2)
+上获得更多信息。
 
 <!--
 ## Configuring Stackdriver Logging Agents
@@ -453,14 +459,14 @@ If you're using GKE and Stackdriver Logging is enabled in your cluster, you
 cannot change its configuration, because it's managed and supported by GKE.
 However, you can disable the default integration and deploy your own.
 -->
-如果使用的是 GKE，并且集群中启用了 Stackdriver 日志机制，则无法更改其配置，因为它是由 GKE 管理和支持的。
+如果使用的是 GKE，并且集群中启用了 Stackdriver 日志机制，则无法更改其配置，
+因为它是由 GKE 管理和支持的。
 但是，你可以禁用默认集成的日志机制并部署自己的。
 
 <!--
 You will have to support and maintain a newly deployed configuration
 yourself: update the image and configuration, adjust the resources and so on.
 -->
-
 {{< note >}}
 你将需要自己支持和维护新部署的配置了：更新映像和配置、调整资源等等。
 {{< /note >}}
@@ -478,7 +484,8 @@ gcloud beta container clusters update --logging-service=none CLUSTER
 You can find notes on how to then install Stackdriver Logging agents into
 a running cluster in the [Deploying section](#deploying).
 -->
-你可以在[部署部分](#deploying)中找到有关如何将 Stackdriver 日志代理安装到正在运行的集群中的说明​​。
+你可以在[部署部分](#deploying)中找到有关如何将 Stackdriver 日志代理安装到
+正在运行的集群中的说明。
 
 <!--
 ### Changing `DaemonSet` parameters
@@ -491,7 +498,8 @@ When you have the Stackdriver Logging `DaemonSet` in your cluster, you can just
 let's assume you've just installed the Stackdriver Logging as described above. Now you want to
 change the memory limit to give fluentd more memory to safely process more logs.
 -->
-当集群中有 Stackdriver 日志机制的 `DaemonSet` 时，你只需修改其 spec 中的 `template` 字段，daemonset 控制器将为你更新 pod。
+当集群中有 Stackdriver 日志机制的 `DaemonSet` 时，你只需修改其 spec 中的
+`template` 字段，daemonset 控制器将为你更新 Pod。
 例如，假设你按照上面的描述已经安装了 Stackdriver 日志机制。
 现在，你想更改内存限制，来给 fluentd 提供的更多内存，从而安全地处理更多日志。
 
@@ -616,4 +624,6 @@ Fluentd 用 Ruby 编写，并允许使用 [plugins](https://www.fluentd.org/plug
 Then run `make build push` from this directory. After updating `DaemonSet` to pick up the
 new image, you can use the plugin you installed in the fluentd configuration.
 -->
-然后在该目录运行 `make build push`。在更新 `DaemonSet` 以使用新镜像后，你就可以使用在 fluentd 配置中安装的插件了。
+然后在该目录运行 `make build push`。
+在更新 `DaemonSet` 以使用新镜像后，你就可以使用在 fluentd 配置中安装的插件了。
+

content/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer.md

@@ -18,8 +18,9 @@ weight: 10
 <!--
 Configuring the [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs.
 -->
-配置 [聚合层](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 允许
-Kubernetes apiserver 使用其它 API 扩展，这些 API 不是核心 Kubernetes API 的一部分。
+配置[聚合层](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
+可以允许 Kubernetes apiserver 使用其它 API 扩展，这些 API 不是核心
+Kubernetes API 的一部分。
 
 ## {{% heading "prerequisites" %}}
 
@@ -29,7 +30,7 @@ Kubernetes apiserver 使用其它 API 扩展，这些 API 不是核心 Kubernete
 There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the master CA.
 -->
 {{< note >}}
-要使聚合层在您的环境中正常工作以支持代理服务器和扩展 apiserver 之间的相互 TLS 身份验证，
+要使聚合层在你的环境中正常工作以支持代理服务器和扩展 apiserver 之间的相互 TLS 身份验证，
 需要满足一些设置要求。Kubernetes 和 kube-apiserver 具有多个 CA，
 因此请确保代理是由聚合层 CA 签名的，而不是由主 CA 签名的。
 {{< /note >}}
@@ -38,8 +39,8 @@ There are a few setup requirements for getting the aggregation layer working in
 Reusing the same CA for different client types can negatively impact the cluster's ability to function. For more information, see [CA Reusage and Conflicts](#ca-reusage-and-conflicts).
 -->
 {{< caution >}}
-对不同的客户端类型重复使用相同的 CA 会对群集的功能产生负面影响。有关更多信息，请参见
-[CA 重用和冲突](#ca-reusage-and-conflicts)。
+对不同的客户端类型重复使用相同的 CA 会对群集的功能产生负面影响。
+有关更多信息，请参见 [CA 重用和冲突](#ca-reusage-and-conflicts)。
 {{< /caution >}}
 
 <!-- steps -->
@@ -53,7 +54,11 @@ This section describes how the authentication and authorization flows work, and
 -->
 ## 身份认证流程
 
-与自定义资源定义（CRD）不同，除标准的 Kubernetes apiserver 外，Aggregation API 还涉及另一个服务器：扩展 apiserver。Kubernetes apiserver 将需要与您的扩展 apiserver 通信，并且您的扩展 apiserver 也需要与 Kubernetes apiserver 通信。为了确保此通信的安全，Kubernetes apiserver 使用 x509 证书向扩展 apiserver 认证。
+与自定义资源定义（CRD）不同，除标准的 Kubernetes apiserver 外，Aggregation API
+还涉及另一个服务器：扩展 apiserver。
+Kubernetes apiserver 将需要与你的扩展 apiserver 通信，并且你的扩展 apiserver 
+也需要与 Kubernetes apiserver 通信。
+为了确保此通信的安全，Kubernetes apiserver 使用 x509 证书向扩展 apiserver 认证。
 
 本节介绍身份认证和鉴权流程的工作方式以及如何配置它们。
 
@@ -65,14 +70,6 @@ The high-level flow is as follows:
 3. Extension apiserver: authenticate the request from the Kubernetes apiserver
 4. Extension apiserver: authorize the request from the original user
 5. Extension apiserver: execute
-
-The rest of this section describes these steps in detail.
-
-The flow can be seen in the following diagram.
-
-![aggregation auth flows](/images/docs/aggregation-api-auth-flow.png).
-
-The source for the above swimlanes can be found in the source of this document.
 -->
 大致流程如下：
 
@@ -82,11 +79,18 @@ The source for the above swimlanes can be found in the source of this document.
 4. 扩展 apiserver：对来自原始用户的请求鉴权
 5. 扩展 apiserver：执行
 
+<!--
+The rest of this section describes these steps in detail.
+
+The flow can be seen in the following diagram.
+
+The source for the above swimlanes can be found in the source of this document.
+-->
 本节的其余部分详细描述了这些步骤。
 
 该流程可以在下图中看到。
 
-![aggregation auth flows](/images/docs/aggregation-api-auth-flow.png).
+![聚合层认证流程](/images/docs/aggregation-api-auth-flow.png).
 
 以上泳道的来源可以在本文档的源码中找到。
 
@@ -167,9 +171,11 @@ note:
 kube-apiserver / aggregator -> 聚合的 apiserver:
 
 note:
-4.aggregator 使用`--proxy-client-cert-file`，`--proxy-client-key-file`客户端证书/密钥打开与聚合 Apiserver 的连接以保护通道
+4.aggregator 使用 `--proxy-client-cert-file`，`--proxy-client-key-file`
+  客户端证书/密钥打开与聚合 Apiserver 的连接以保护通道
 
-5.aggregator 将步骤 1 中的用户信息作为 http 标头发送到聚合的 Apiserver，如以下标志所定义：
+5.aggregator 将步骤 1 中的用户信息作为 http 标头发送到聚合的 Apiserver，
+  如以下标志所定义：
 
   * `--requestheader-username-headers`
   * `--requestheader-group-headers`
@@ -183,7 +189,10 @@ note:
   * 验证请求是否具有公认的身份验证代理客户端证书
   * 从传入请求的 HTTP 标头中提取用户信息
 
-默认情况下，它从 kube-apiserver 发布的 kube-system 命名空间中的 configmap 中获取配置信息，其中包含提供给 kube-apiserver 的`--requestheader-...`标志中的信息（要使用的 CA 包，要允许的身份验证代理客户端证书名称，要使用的 HTTP 标头名称等）
+默认情况下，它从 kube-apiserver 发布的 kube-system 命名空间中的 configmap
+中获取配置信息，其中包含提供给 kube-apiserver 的`--requestheader-...`
+标志中的信息（要使用的 CA 包，要允许的身份验证代理客户端证书名称，
+要使用的 HTTP 标头名称等）
 
 kube-apiserver / aggregator -> 聚合的 apiserver: 鉴权
 
@@ -193,7 +202,9 @@ note:
 kube-apiserver / aggregator -> 聚合的 apiserver: 准入
 
 note:
-8.对于可变请求，聚合的 apiserver 运行准入检查。默认情况下，namespace 生命周期准入插件可确保在 kube-apiserver 中存在的 namespace 中创建指定 namespace 下的资源
+8.对于可变请求，聚合的 apiserver 运行准入检查。
+  默认情况下，namespace 生命周期准入插件可确保在 kube-apiserver
+  中存在的 namespace 中创建指定 namespace 下的资源
 -----END-----
 
 -->
@@ -213,11 +224,17 @@ The Kubernetes apiserver now is prepared to send the request to the extension ap
 -->
 ### Kubernetes Apiserver 认证和授权
 
-由扩展 apiserver 服务的对 API 路径的请求以与所有API请求相同的方式开始：与 Kubernetes apiserver 的通信。该路径已通过扩展 apiserver 在 Kubernetes apiserver 中注册。
+由扩展 apiserver 服务的对 API 路径的请求以与所有 API 请求相同的方式开始：
+与 Kubernetes apiserver 的通信。该路径已通过扩展 apiserver 在
+Kubernetes apiserver 中注册。
 
-用户与 Kubernetes apiserver 通信，请求访问 path 。Kubernetes apiserver 使用它的标准认证和授权配置来对用户认证，以及对特定 path 的鉴权。
+用户与 Kubernetes apiserver 通信，请求访问路径。
+Kubernetes apiserver 使用它的标准认证和授权配置来对用户认证，以及对特定路径的鉴权。
 
-有关对 Kubernetes 集群认证的概述，请参见 [对集群认证](/zh/docs/reference/access-authn-authz/authentication/)。有关对Kubernetes群集资源的访问鉴权的概述，请参见 [鉴权概述](/zh/docs/reference/access-authn-authz/authorization/)。
+有关对 Kubernetes 集群认证的概述，请参见
+[对集群认证](/zh/docs/reference/access-authn-authz/authentication/)。
+有关对Kubernetes群集资源的访问鉴权的概述，请参见
+[鉴权概述](/zh/docs/reference/access-authn-authz/authorization/)。
 
 到目前为止，所有内容都是标准的 Kubernetes API 请求，认证与鉴权。
 
@@ -235,13 +252,16 @@ In order to provide for these two, you must configure the Kubernetes apiserver u
 -->
 ### Kubernetes Apiserver 代理请求
 
-Kubernetes apiserver 现在将请求发送或代理到注册以处理该请求的扩展 apiserver。为此，它需要了解几件事：
+Kubernetes apiserver 现在将请求发送或代理到注册以处理该请求的扩展 apiserver。
+为此，它需要了解几件事：
 
-1. Kubernetes apiserver 应该如何向扩展 apiserver 认证，以通知扩展 apiserver 通过网络发出的请求来自有效的 Kubernetes apiserver？
+1. Kubernetes apiserver 应该如何向扩展 apiserver 认证，以通知扩展
+   apiserver 通过网络发出的请求来自有效的 Kubernetes apiserver？
 
-2. Kubernetes apiserver 应该如何通知扩展 apiserver 原始请求已通过认证的用户名和组？
+2. Kubernetes apiserver 应该如何通知扩展 apiserver 原始请求
+   已通过认证的用户名和组？
 
-为提供这两条信息，您必须使用若干标志来配置 Kubernetes apiserver。
+为提供这两条信息，你必须使用若干标志来配置 Kubernetes apiserver。
 
 <!--
 #### Kubernetes Apiserver Client Authentication
@@ -255,7 +275,8 @@ The Kubernetes apiserver connects to the extension apiserver over TLS, authentic
 -->
 #### Kubernetes Apiserver 客户端认证
 
-Kubernetes apiserver 通过 TLS 连接到扩展 apiserver，并使用客户端证书认证。您必须在启动时使用提供的标志向 Kubernetes apiserver 提供以下内容：
+Kubernetes apiserver 通过 TLS 连接到扩展 apiserver，并使用客户端证书认证。
+你必须在启动时使用提供的标志向 Kubernetes apiserver 提供以下内容：
 
 * 通过 `--proxy-client-key-file` 指定私钥文件
 * 通过 `--proxy-client-cert-file` 签名的客户端证书文件
@@ -268,13 +289,15 @@ The Kubernetes apiserver will use the files indicated by `--proxy-client-*-file`
 1. The connection must be made using a client certificate that is signed by the CA whose certificate is in `--requestheader-client-ca-file`.
 2. The connection must be made using a client certificate whose CN is one of those listed in `--requestheader-allowed-names`. **Note:** You can set this option to blank as `--requestheader-allowed-names=""`. This will indicate to an extension apiserver that _any_ CN is acceptable.
 -->
-Kubernetes apiserver 将使用由 `--proxy-client-*-file` 指示的文件来验证扩展 apiserver。为了使合规的扩展 apiserver 能够将该请求视为有效，必须满足以下条件：
+Kubernetes apiserver 将使用由 `--proxy-client-*-file` 指示的文件来验证扩展 apiserver。
+为了使合规的扩展 apiserver 能够将该请求视为有效，必须满足以下条件：
 
 1. 连接必须使用由 CA 签署的客户端证书，该证书的证书位于 `--requestheader-client-ca-file` 中。
 2. 连接必须使用客户端证书，该客户端证书的 CN 是 `--requestheader-allowed-names` 中列出的证书之一。
 
 {{< note >}}
-您可以将此选项设置为空白，即为`--requestheader-allowed-names`。这将向扩展 apiserver 指示任何 CN 是可接受的。
+你可以将此选项设置为空白，即为`--requestheader-allowed-names`。
+这将向扩展 apiserver 指示任何 CN 是可接受的。
 {{< /note >}}
 
 <!--
@@ -288,9 +311,14 @@ Note that the same client certificate is used by the Kubernetes apiserver to aut
 使用这些选项启动时，Kubernetes apiserver 将：
 
 1. 使用它们向扩展 apiserver 认证。
-2. 在名为 `extension-apiserver-authentication` 的 `kube-system` 命名空间中创建一个 configmap，它将在其中放置 CA 证书和允许的 CN。反过来，扩展 apiserver 可以检索这些内容以验证请求。
+2. 在 `kube-system` 命名空间中
+   创建一个名为 `extension-apiserver-authentication` 的 ConfigMap，
+   它将在其中放置 CA 证书和允许的 CN。
+   反过来，扩展 apiserver 可以检索这些内容以验证请求。
 
-请注意，Kubernetes apiserver 使用相同的客户端证书对所有扩展 apiserver 认证。它不会为每个扩展 apiserver 创建一个客户端证书，而是创建一个证书作为 Kubernetes apiserver 认证。所有扩展 apiserver 请求都重复使用相同的请求。
+请注意，Kubernetes apiserver 使用相同的客户端证书对所有扩展 apiserver 认证。
+它不会为每个扩展 apiserver 创建一个客户端证书，而是创建一个证书作为
+Kubernetes apiserver 认证。所有扩展 apiserver 请求都重复使用相同的请求。
 
 <!--
 #### Original Request Username and Group
@@ -303,16 +331,19 @@ When the Kubernetes apiserver proxies the request to the extension apiserver, it
 
 These header names are also placed in the `extension-apiserver-authentication` configmap, so they can be retrieved and used by extension apiservers.
 -->
-
 #### 原始请求用户名和组
 
-当 Kubernetes apiserver 将请求代理到扩展 apiserver 时，它将向扩展 apiserver 通知原始请求已成功通过其验证的用户名和组。它在其代理请求的 http 标头中提供这些。您必须将要使用的标头名称告知 Kubernetes apiserver。
+当 Kubernetes apiserver 将请求代理到扩展 apiserver 时，
+它将向扩展 apiserver 通知原始请求已成功通过其验证的用户名和组。
+它在其代理请求的 HTTP 头部中提供这些。你必须将要使用的标头名称告知
+Kubernetes apiserver。
 
 * 通过`--requestheader-username-headers` 标明用来保存用户名的头部
 * 通过`--requestheader-group-headers` 标明用来保存 group 的头部
 * 通过`--requestheader-extra-headers-prefix` 标明用来保存拓展信息前缀的头部
 
-这些标头名称也放置在`extension-apiserver-authentication` 的 configmap 中，因此扩展 apiserver 可以检索和使用它们。
+这些头部名称也放置在 `extension-apiserver-authentication` ConfigMap 中，
+因此扩展 apiserver 可以检索和使用它们。
 
 <!--
 ### Extension Apiserver Authenticates the Request
@@ -331,17 +362,21 @@ The extension apiserver, upon receiving a proxied request from the Kubernetes ap
 -->
 ### 扩展 Apiserver 认证
 
-扩展 apiserver 在收到来自 Kubernetes apiserver 的代理请求后，必须验证该请求确实确实来自有效的身份验证代理，该认证代理由 Kubernetes apiserver 履行。扩展 apiserver 通过以下方式对其认证：
+扩展 apiserver 在收到来自 Kubernetes apiserver 的代理请求后，
+必须验证该请求确实确实来自有效的身份验证代理，
+该认证代理由 Kubernetes apiserver 履行。扩展 apiserver 通过以下方式对其认证：
 
-1.如上所述，从`kube-system`中的 configmap 中检索以下内容：
-    * 客户端 CA 证书
-    * 允许名称（CN）列表
-    * 用户名，组和其他信息的头部
+1. 如上所述，从`kube-system`中的 configmap 中检索以下内容：
 
-2.使用以下证书检查 TLS 连接是否已通过认证：
-    * 由其证书与检索到的 CA 证书匹配的 CA 签名。
-    * 在允许的 CN 列表中有一个 CN，除非列表为空，在这种情况下允许所有 CN。
-    * 从适当的头部中提取用户名和组
+   * 客户端 CA 证书
+   * 允许名称（CN）列表
+   * 用户名，组和其他信息的头部
+
+2. 使用以下证书检查 TLS 连接是否已通过认证：
+
+   * 由其证书与检索到的 CA 证书匹配的 CA 签名。
+   * 在允许的 CN 列表中有一个 CN，除非列表为空，在这种情况下允许所有 CN。
+   * 从适当的头部中提取用户名和组
 
 <!--
 If the above passes, then the request is a valid proxied request from a legitimate authenticating proxy, in this case the Kubernetes apiserver.
@@ -350,11 +385,16 @@ Note that it is the responsibility of the extension apiserver implementation to
 
 In order to have permission to retrieve the configmap, an extension apiserver requires the appropriate role. There is a default role named `extension-apiserver-authentication-reader` in the `kube-system` namespace which can be assigned.
 -->
-如果以上均通过，则该请求是来自合法认证代理（在本例中为 Kubernetes apiserver）的有效代理请求。
+如果以上均通过，则该请求是来自合法认证代理（在本例中为 Kubernetes apiserver）
+的有效代理请求。
 
-请注意，扩展 apiserver 实现负责提供上述内容。默认情况下，许多扩展 apiserver 实现利用 `k8s.io/apiserver/` 软件包来做到这一点。也有一些实现可能支持使用命令行选项来覆盖这些配置。
+请注意，扩展 apiserver 实现负责提供上述内容。
+默认情况下，许多扩展 apiserver 实现利用 `k8s.io/apiserver/` 软件包来做到这一点。
+也有一些实现可能支持使用命令行选项来覆盖这些配置。
 
-为了具有检索 configmap 的权限，扩展 apiserver 需要适当的角色。在 `kube-system` 名字空间中有一个默认角色`extension-apiserver-authentication-reader` 可用于设置。
+为了具有检索 configmap 的权限，扩展 apiserver 需要适当的角色。
+在 `kube-system` 名字空间中有一个默认角色
+`extension-apiserver-authentication-reader` 可用于设置。
 
 <!--
 ### Extension Apiserver Authorizes the Request
@@ -369,7 +409,10 @@ In order for the extension apiserver to be authorized itself to submit the `Subj
 通过向 Kubernetes apiserver 发送标准
 [SubjectAccessReview](/zh/docs/reference/access-authn-authz/authorization/) 请求来实现。
 
-为了使扩展 apiserver 本身被鉴权可以向 Kubernetes apiserver 提交 SubjectAccessReview 请求，它需要正确的权限。Kubernetes 包含一个具有相应权限的名为`system：auth-delegator` 的默认 `ClusterRole`，可以将其授予扩展 apiserver 的服务帐户。
+为了使扩展 apiserver 本身被鉴权可以向 Kubernetes apiserver 提交 SubjectAccessReview 请求，
+它需要正确的权限。
+Kubernetes 包含一个具有相应权限的名为 `system:auth-delegator` 的默认 `ClusterRole`，
+可以将其授予扩展 apiserver 的服务帐户。
 
 <!--
 ### Extension Apiserver Executes
@@ -386,7 +429,8 @@ Enable the aggregation layer via the following kube-apiserver flags. They may ha
 
 ## 启用 Kubernetes Apiserver 标志
 
-通过以下 kube-apiserver 标志启用聚合层。您的服务提供商可能已经为您完成了这些工作：
+通过以下 kube-apiserver 标志启用聚合层。
+你的服务提供商可能已经为你完成了这些工作：
 
 ```
     --requestheader-client-ca-file=<path to aggregator CA cert>
@@ -418,31 +462,53 @@ Each of these functions independently and can conflict with each other, if not u
 -->
 这些功能中的每个功能都是独立的；如果使用不正确，可能彼此冲突。
 
-* `--client-ca-file`：当请求到达 Kubernetes apiserver 时，如果启用了此选项，则 Kubernetes apiserver 会检查请求的证书。如果它是由 `--client-ca-file` 引用的文件中的 CA 证书之一签名的，并且用户是公用名`CN=`的值，而组是组织`O=` 的取值，则该请求被视为合法请求。请参阅 [关于 TLS 身份验证的文档](/docs/reference/access-authn-authz/authentication/#x509-client-certs)。
+* `--client-ca-file`：当请求到达 Kubernetes apiserver 时，如果启用了此选项，
+  则 Kubernetes apiserver 会检查请求的证书。
+  如果它是由 `--client-ca-file` 引用的文件中的 CA 证书之一签名的，
+  并且用户是公用名`CN=`的值，而组是组织`O=` 的取值，则该请求被视为合法请求。
+  请参阅[关于 TLS 身份验证的文档](/zh/docs/reference/access-authn-authz/authentication/#x509-client-certs)。
 
-* `--requestheader-client-ca-file`：当请求到达 Kubernetes apiserver 时，如果启用此选项，则 Kubernetes apiserver 会检查请求的证书。如果它是由文件引用中的 --requestheader-client-ca-file 所签署的 CA 证书之一签名的，则该请求将被视为潜在的合法请求。然后，Kubernetes apiserver 检查通用名称`CN=`是否是 --requestheader-allowed-names 提供的列表中的名称之一。如果名称允许，则请求被批准；如果不是，则请求被拒绝。
+* `--requestheader-client-ca-file`：当请求到达 Kubernetes apiserver 时，
+  如果启用此选项，则 Kubernetes apiserver 会检查请求的证书。
+  如果它是由文件引用中的 --requestheader-client-ca-file 所签署的 CA 证书之一签名的，
+  则该请求将被视为潜在的合法请求。
+  然后，Kubernetes apiserver 检查通用名称 `CN=` 是否是
+  `--requestheader-allowed-names` 提供的列表中的名称之一。
+  如果名称允许，则请求被批准；如果不是，则请求被拒绝。
 
 <!--
 If _both_ `--client-ca-file` and `--requestheader-client-ca-file` are provided, then the request first checks the `--requestheader-client-ca-file` CA and then the `--client-ca-file`. Normally, different CAs, either root CAs or intermediate CAs, are used for each of these options; regular client requests match against `--client-ca-file`, while aggregation requests match against `--requestheader-client-ca-file`. However, if both use the _same_ CA, then client requests that normally would pass via `--client-ca-file` will fail, because the CA will match the CA in `--requestheader-client-ca-file`, but the common name `CN=` will **not** match one of the acceptable common names in `--requestheader-allowed-names`. This can cause your kubelets and other control plane components, as well as end-users, to be unable to authenticate to the Kubernetes apiserver.
 
 For this reason, use different CA certs for the `--client-ca-file` option - to authorize control plane components and end-users - and the `--requestheader-client-ca-file` option - to authorize aggregation apiserver requests.
 -->
-如果同时提供了 `--client-ca-file` 和`--requestheader-client-ca-file`，则首先检查 `--requestheader-client-ca-file` CA，然后再检查`--client-ca-file`。通常，这些选项中的每一个都使用不同的 CA（根 CA 或中间 CA）。常规客户端请求与 --client-ca-file 相匹配，而聚合请求与 `--requestheader-client-ca-file` 相匹配。但是，如果两者都使用同一个 CA，则通常会通过 `--client-ca-file` 传递的客户端请求将失败，因为 CA 将与
- `--requestheader-client-ca-file` 中的 CA 匹配，但是通用名称 `CN=` 将不匹配 `--requestheader-allowed-names` 中可接受的通用名称之一。这可能导致您的 kubelet 和其他控制平面组件以及最终用户无法向 Kubernetes apiserver 认证。
+如果同时提供了 `--client-ca-file` 和 `--requestheader-client-ca-file`，
+则首先检查 `--requestheader-client-ca-file` CA，然后再检查`--client-ca-file`。
+通常，这些选项中的每一个都使用不同的 CA（根 CA 或中间 CA）。
+常规客户端请求与 `--client-ca-file` 相匹配，而聚合请求要与
+`--requestheader-client-ca-file` 相匹配。
+但是，如果两者都使用同一个 CA，则通常会通过 `--client-ca-file`
+传递的客户端请求将失败，因为 CA 将与 `--requestheader-client-ca-file`
+中的 CA 匹配，但是通用名称 `CN=` 将不匹配 `--requestheader-allowed-names`
+中可接受的通用名称之一。
+这可能导致你的 kubelet 和其他控制平面组件以及最终用户无法向 Kubernetes
+apiserver 认证。
 
-因此，请对用于控制平面组件和最终用户鉴权的 `--client-ca-file` 选项和用于聚合 apiserver 鉴权的 `--requestheader-client-ca-file` 选项使用不同的 CA 证书。
+因此，请对用于控制平面组件和最终用户鉴权的 `--client-ca-file` 选项和
+用于聚合 apiserver 鉴权的 `--requestheader-client-ca-file` 选项使用
+不同的 CA 证书。
 
 <!--
 Do **not** reuse a CA that is used in a different context unless you understand the risks and the mechanisms to protect the CA's usage.
 -->
 {{< warning >}}
-除非您了解风险和保护 CA 用法的机制，否则 *不要* 重用在不同上下文中使用的 CA。
+除非你了解风险和保护 CA 用法的机制，否则 *不要* 重用在不同上下文中使用的 CA。
 {{< /warning >}}
 
 <!--
 If you are not running kube-proxy on a host running the API server, then you must make sure that the system is enabled with the following `kube-apiserver` flag:
 -->
-如果您未在运行 API 服务器的主机上运行 kube-proxy，则必须确保使用以下 `kube-apiserver` 标志启用系统：
+如果你未在运行 API 服务器的主机上运行 kube-proxy，则必须确保使用以下
+`kube-apiserver` 标志启用系统：
 
 ```
 --enable-aggregator-routing=true
@@ -456,22 +522,22 @@ apiserver. The following is an example registration:
 -->
 ### 注册 APIService 对象
 
-您可以动态配置将哪些客户端请求代理到扩展 apiserver。以下是注册示例：
+你可以动态配置将哪些客户端请求代理到扩展 apiserver。以下是注册示例：
 
 ```yaml
 apiVersion: apiregistration.k8s.io/v1
 kind: APIService
 metadata:
-  name: < 注释对象名称 >
+  name: <注释对象名称>
 spec:
-  group: < 拓展 Apiserver 的 API group 名称 >
-  version: < 拓展 Apiserver 的 API version>
-  groupPriorityMinimum: < APIService 对对应 group 的优先级, 参考 API 文档 >
-  versionPriority: < 优先考虑 version 在 group 中的排序, 参考 API 文档 >
+  group: <扩展 Apiserver 的 API 组名>
+  version: <扩展 Apiserver 的 API 版本>
+  groupPriorityMinimum: <APIService 对应组的优先级, 参考 API 文档>
+  versionPriority: <版本在组中的优先排序, 参考 API 文档>
   service:
-    namespace: < 拓展 Apiserver 服务的 namespace >
-    name: < 拓展 Apiserver 服务的 name >
-  caBundle: < PEM 编码的 CA 证书，用于对 Webhook 服务器的证书签名 >
+    namespace: <拓展 Apiserver 服务的名字空间>
+    name: <拓展 Apiserver 服务的名称>
+  caBundle: <PEM 编码的 CA 证书，用于对 Webhook 服务器的证书签名>
 ```
 
 <!--
@@ -497,14 +563,16 @@ at the subpath "/my-path", and to verify the TLS connection against the ServerNa
 -->
 #### 调用扩展 apiserver
 
-一旦 Kubernetes apiserver 确定应将请求发送到扩展 apiserver，它需要知道如何调用它。
+一旦 Kubernetes apiserver 确定应将请求发送到扩展 apiserver，
+它需要知道如何调用它。
 
 `service` 部分是对扩展 apiserver 的服务的引用。
-服务的 namespace 和 name 是必需的。port 是可选的，默认为 443。
-path 配置是可选的，默认为`/`。
+服务的名字空间和名字是必需的。端口是可选的，默认为 443。
+路径配置是可选的，默认为 `/`。
 
 下面是为可在端口 `1234` 上调用的扩展 apiserver 的配置示例
-服务位于子路径 `/my-path` 下，并针对 ServerName `my-service-name.my-service-namespace.svc`
+服务位于子路径 `/my-path` 下，并针对 ServerName
+`my-service-name.my-service-namespace.svc`
 使用自定义的 CA 包来验证 TLS 连接
 使用自定义 CA 捆绑包的`my-service-name.my-service-namespace.svc`。
 
@@ -532,4 +600,4 @@ spec:
 
 * 使用聚合层[安装扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/)。
 * 有关高级概述，请参阅[使用聚合层扩展 Kubernetes API](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)。
-* 了解如何 [使用自定义资源扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。
+* 了解如何[使用自定义资源扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。

content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md

@@ -814,7 +814,7 @@ CustomResourceDefinition and migrating your objects from one version to another.
 
 关于如何为你的 CustomResourceDefinition 提供多个版本的支持，以及如何将你的对象
 从一个版本迁移到另一个版本， 详细信息可参阅
-[定制资源定义的版本](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/)。
+[定制资源定义的版本](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/)。
 
 <!-- discussion -->
 

content/zh/docs/tasks/extend-kubernetes/setup-extension-api-server.md

@@ -19,7 +19,8 @@ weight: 15
 <!--
 Setting up an extension API server to work the aggregation layer allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs.
 -->
-安装扩展的 API 服务器来使用聚合层以让 Kubernetes API 服务器使用其它 API 进行扩展，
+安装扩展的 API 服务器来使用聚合层以让 Kubernetes API 服务器使用
+其它 API 进行扩展，
 这些 API 不是核心 Kubernetes API 的一部分。
 
 ## {{% heading "prerequisites" %}}
@@ -112,5 +113,5 @@ Alternatively, you can use an existing 3rd party solution, such as [apiserver-bu
 * 如果你还未配置，请[配置聚合层](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
   并启用 apiserver 的相关参数。
 * 高级概述，请参阅[使用聚合层扩展 Kubernetes API](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation)。
-* 了解如何[使用 Custom Resource Definition 扩展 Kubernetes API](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。
+* 了解如何[使用 Custom Resource Definition 扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。
 

content/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md

@@ -32,7 +32,7 @@ There are two ways to expose Pod and Container fields to a running Container:
 
 有两种方式可以将 Pod 和 Container 字段呈现给运行中的容器：
 
-* [环境变量](/docs/tasks/configure-pod-container/environment-variable-expose-pod-information/)
+* [环境变量](/zh/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#the-downward-api)
 * 卷文件
 
 这两种呈现 Pod 和 Container 字段的方式都称为 *Downward API*。
@@ -394,7 +394,6 @@ API 服务器来获得。
 
 ## {{% heading "whatsnext" %}}
 
-
 * [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
 * [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)
 * [DownwardAPIVolumeSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumesource-v1-core)

content/zh/docs/tasks/manage-daemon/update-daemon-set.md

@@ -261,13 +261,13 @@ make room for new DaemonSet pods.
 
 <!--
 This will cause service disruption when deleted pods are not controlled by any controllers or pods are not
-replicated. This does not respect [PodDisruptionBudget](/docs/tasks/configure-pod-container/configure-pod-disruption-budget/)
+replicated. This does not respect [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/)
 either.
 -->
 {{< note >}}
 当所删除的 Pod 不受任何控制器管理，也不是多副本的 Pod时，上述操作将导致服务中断。
 同时，上述操作也不会考虑
-[PodDisruptionBudget](/zh/docs/tasks/configure-pod-container/configure-pod-disruption-budget/)
+[PodDisruptionBudget](/zh/docs/tasks/run-application/configure-pdb/)
 所施加的约束。
 {{< /note >}}
 

content/zh/docs/tasks/run-application/configure-pdb.md

@@ -34,7 +34,7 @@ nodes.
   Pod Disruption Budgets.
 -->
 * 你是 Kubernetes 集群中某应用的所有者，该应用有高可用要求。
-* 你应了解如何部署[无状态应用](.zh/docs/tasks/run-application/run-stateless-application-deployment/)
+* 你应了解如何部署[无状态应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)
   和/或[有状态应用](/zh/docs/tasks/run-application/run-replicated-stateful-application/)。
 * 你应当已经阅读过关于 [Pod 干扰](/zh/docs/concepts/workloads/pods/disruptions/) 的文档。
 * 用户应当与集群所有者或服务提供者确认其遵从 Pod 干扰预算（Pod Disruption Budgets）的规则。

content/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md

@@ -674,7 +674,8 @@ HorizontalPodAutoscaler.
 首先，`AbleToScale` 表明 HPA 是否可以获取和更新扩缩信息，以及是否存在阻止扩缩的各种回退条件。
 其次，`ScalingActive` 表明 HPA 是否被启用（即目标的副本数量不为零） 以及是否能够完成扩缩计算。
 当这一状态为 `False` 时，通常表明获取度量指标存在问题。
-最后一个条件 `ScalingLimitted` 表明所需扩缩的值被 HorizontalPodAutoscaler 所定义的最大或者最小值所限制（即已经达到最大或者最小扩缩值）。
+最后一个条件 `ScalingLimitted` 表明所需扩缩的值被 HorizontalPodAutoscaler
+所定义的最大或者最小值所限制（即已经达到最大或者最小扩缩值）。
 这通常表明你可能需要调整 HorizontalPodAutoscaler 所定义的最大或者最小副本数量的限制了。
 
 <!--
@@ -696,7 +697,6 @@ HorizontalPodAutoscaler 和 度量指标 API 中的所有的度量指标使用 K
 例如，数量 `10500m` 用十进制表示为 `10.5`。
 如果可能的话，度量指标 API 将返回没有后缀的整数，否则返回以千分单位的数量。
 这意味着你可能会看到你的度量指标在 `1` 和 `1500m` （也就是在十进制记数法中的 `1` 和 `1.5`）之间波动。
-更多信息，请参阅[度量术语](/docs/reference/glossary?core-object=true#term-quantity)。
 
 <!--
 ## Appendix: Other possible scenarios

content/zh/docs/tasks/service-catalog/install-service-catalog-using-sc.md

@@ -26,7 +26,7 @@ Use the [Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-s
 ## {{% heading "prerequisites" %}}
 
 <!--
-* Understand the key concepts of [Service Catalog](/docs/concepts/service-catalog/).
+* Understand the key concepts of [Service Catalog](/docs/concepts/extend-kubernetes/service-catalog/).
 * Install [Go 1.6+](https://golang.org/dl/) and set the `GOPATH`.
 * Install the [cfssl](https://github.com/cloudflare/cfssl) tool needed for generating SSL artifacts.
 * Service Catalog requires Kubernetes version 1.7+.
@@ -35,7 +35,8 @@ Use the [Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-s
 
         kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=<user-name>
 -->
-* 了解[服务目录](/zh/docs/concepts/service-catalog/)的主要概念。
+* 了解[服务目录](/zh/docs/concepts/extend-kubernetes/service-catalog/)
+  的主要概念。
 * 安装 [Go 1.6+](https://golang.org/dl/) 以及设置 `GOPATH`。
 * 安装生成 SSL 工件所需的 [cfssl](https://github.com/cloudflare/cfssl) 工具。
 * 服务目录需要 Kubernetes 1.7+ 版本。