Merge pull request #23192 from tengqm/zh-links-tasks-2

[zh] Tidy up and fix links in tasks section (2/10)

content/zh/docs/tasks/debug-application-cluster/debug-init-containers.md

@@ -1,18 +1,9 @@
 ---
-reviewers:
-- bprashanth
-- enisoc
-- erictune
-- foxish
-- janetkuo
-- kow3ns
-- smarterclayton
 title: 调试 Init 容器
 content_type: task
 ---
 
 <!--
----
 reviewers:
 - bprashanth
 - enisoc
@@ -23,7 +14,6 @@ reviewers:
 - smarterclayton
 title: Debug Init Containers
 content_type: task
----
 -->
 
 <!-- overview -->
@@ -34,15 +24,12 @@ Init Containers. The example command lines below refer to the Pod as
   `<pod-name>` and the Init Containers as `<init-container-1>` and
   `<init-container-2>`.
 -->
-
-此页显示如何核查与 init 容器执行相关的问题。
-下面的示例命令行将 Pod 称为 `<pod-name>`，而 init 容器称为 `<init-container-1>` 和 `<init-container-2>`。
-
-
+此页显示如何核查与 Init 容器执行相关的问题。
+下面的示例命令行将 Pod 称为 `<pod-name>`，而 Init 容器称为 `<init-container-1>` 和
+`<init-container-2>`。
 
 ## {{% heading "prerequisites" %}}
 
-
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
 <!--
@@ -51,10 +38,8 @@ Init Containers. The example command lines below refer to the Pod as
 * You should have [Configured an Init Container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/).
 -->
 
-* 您应该熟悉 [Init 容器](/docs/concepts/abstractions/init-containers/)的基础知识。
-* 您应该已经[配置好一个 Init 容器](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/)。
-
-
+* 你应该熟悉 [Init 容器](/zh/docs/concepts/workloads/pods/init-containers/)的基础知识。
+* 你应该已经[配置好一个 Init 容器](/zh/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/)。
 
 <!-- steps -->
 
@@ -88,18 +73,14 @@ NAME         READY     STATUS     RESTARTS   AGE
 See [Understanding Pod status](#understanding-pod-status) for more examples of
 status values and their meanings.
 -->
-
-更多状态值及其含义请参考[了解 Pod 的状态](#understanding-pod-status)。
+更多状态值及其含义请参考[理解 Pod 的状态](#understanding-pod-status)。
 
 <!--
 ## Getting details about Init Containers
--->
 
-## 获取 Init 容器详情
-
-<!--
 View more detailed information about Init Container execution:
 -->
+## 获取 Init 容器详情   {#getting-details-about-init-containers}
 
 查看 Init 容器运行的更多详情：
 
@@ -110,8 +91,7 @@ kubectl describe pod <pod-name>
 <!--
 For example, a Pod with two Init Containers might show the following:
 -->
-
-例如，对于包含两个 Init 容器的 Pod 应该显示如下信息：
+例如，对于包含两个 Init 容器的 Pod 可能显示如下信息：
 
 ```
 Init Containers:
@@ -145,8 +125,7 @@ Init Containers:
 You can also access the Init Container statuses programmatically by reading the
 `status.initContainerStatuses` field on the Pod Spec:
 -->
-
-您还可以通过读取 Pod Spec 上的 `status.initContainerStatuses` 字段以编程方式了解 Init 容器的状态：
+你还可以通过编程方式读取 Pod Spec 上的 `status.initContainerStatuses` 字段，了解 Init 容器的状态：
 
 ```shell
 kubectl get pod nginx --template '{{.status.initContainerStatuses}}'
@@ -155,21 +134,17 @@ kubectl get pod nginx --template '{{.status.initContainerStatuses}}'
 <!--
 This command will return the same information as above in raw JSON.
 -->
-
 此命令将返回与原始 JSON 中相同的信息.
 
 <!--
 ## Accessing logs from Init Containers
--->
 
-## 通过 Init 容器访问日志
-
-<!--
 Pass the Init Container name along with the Pod name
 to access its logs.
 -->
+## 通过 Init 容器访问日志   {#accessing-logs-from-init-containers}
 
-一起传递 Init 容器名称与 Pod 名称来访问它的日志。
+与 Pod 名称一起传递 Init 容器名称，以访问容器的日志。
 
 ```shell
 kubectl logs <pod-name> -c <init-container-2>
@@ -180,25 +155,19 @@ Init Containers that run a shell script print
 commands as they're executed. For example, you can do this in Bash by running
 `set -x` at the beginning of the script.
 -->
-
-运行 shell 脚本打印命令的init容器,执行 shell 脚本。
-例如，您可以在 Bash 中通过在脚本的开头运行 `set -x` 来实现。
-
-
+运行 Shell 脚本的 Init 容器在执行 Shell 脚本时输出命令本身。
+例如，你可以在 Bash 中通过在脚本的开头运行 `set -x` 来实现。
 
 <!-- discussion -->
 
 <!--
 ## Understanding Pod status
--->
 
-## 了解 Pod 的状态
-
-<!--
 A Pod status beginning with `Init:` summarizes the status of Init Container
 execution. The table below describes some example status values that you might
 see while debugging Init Containers.
 -->
+## 理解 Pod 的状态   {#understanding-pod-status}
 
 以 `Init:` 开头的 Pod 状态汇总了 Init 容器执行的状态。
 下表介绍调试 Init 容器时可能看到的一些状态值示例。
@@ -213,13 +182,11 @@ Status | Meaning
 `PodInitializing` or `Running` | The Pod has already finished executing Init Containers.
 -->
 
-状态 | 含义
+状态   | 含义
 ------ | -------
 `Init:N/M` | Pod 包含 `M` 个 Init 容器，其中 `N` 个已经运行完成。
 `Init:Error` | Init 容器已执行失败。
-`Init:CrashLoopBackOff` | Init 容器反复执行失败。
+`Init:CrashLoopBackOff` | Init 容器执行总是失败。
 `Pending` | Pod 还没有开始执行 Init 容器。
 `PodInitializing` or `Running` | Pod 已经完成执行 Init 容器。
 
-
-

content/zh/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md

@@ -4,10 +4,8 @@ content_type: task
 ---
 
 <!--
----
 title: Determine the Reason for Pod Failure
 content_type: task
----
 -->
 
 <!-- overview -->
@@ -16,33 +14,24 @@ content_type: task
 This page shows how to write and read a Container
 termination message.
 -->
-
 本文介绍如何编写和读取容器的终止消息。
 
 <!--
-Termination messages provide a way for containers to write information about 
-fatal events to a location where it can be easily retrieved and surfaced by 
-tools like dashboards and monitoring software. In most cases, information that 
-you put in a termination message should also be written to the general 
+Termination messages provide a way for containers to write information about
+fatal events to a location where it can be easily retrieved and surfaced by
+tools like dashboards and monitoring software. In most cases, information that
+you put in a termination message should also be written to the general
 [Kubernetes logs](/docs/concepts/cluster-administration/logging/).
 -->
-
-终止消息为容器提供了一种方法，可以将有关致命事件的信息写入某个位置，在该位置可以通过仪表板和监控软件等工具轻松检索和显示致命事件。
-在大多数情况下，您放入终止消息中的信息也应该写入[常规 Kubernetes 日志](/docs/concepts/cluster-administration/logging/)。
-
-
-
-
-
+终止消息为容器提供了一种方法，可以将有关致命事件的信息写入某个位置，
+在该位置可以通过仪表板和监控软件等工具轻松检索和显示致命事件。
+在大多数情况下，您放入终止消息中的信息也应该写入
+[常规 Kubernetes 日志](/zh/docs/concepts/cluster-administration/logging/)。
 
 ## {{% heading "prerequisites" %}}
 
-
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
-
-
-
 <!-- steps -->
 
 <!--
@@ -52,7 +41,6 @@ In this exercise, you create a Pod that runs one container.
 The configuration file specifies a command that runs when
 the container starts.
 -->
-
 ## 读写终止消息
 
 在本练习中，您将创建运行一个容器的 Pod。
@@ -62,59 +50,69 @@ the container starts.
 
 1. <!--Create a Pod based on the YAML configuration file:-->基于 YAML 配置文件创建 Pod：
 
-        kubectl create -f https://k8s.io/examples/debug/termination.yaml
+   ```shell
+   kubectl create -f https://k8s.io/examples/debug/termination.yaml
+   ``` 
 
-    <!--In the YAML file, in the `cmd` and `args` fields, you can see that the
-    container sleeps for 10 seconds and then writes "Sleep expired" to
-    the `/dev/termination-log` file. After the container writes
-    the "Sleep expired" message, it terminates.-->
-    YAML 文件中，在 `cmd` 和 `args` 字段，你可以看到容器休眠 10 秒然后将 "Sleep expired" 写入 `/dev/termination-log` 文件。
-    容器写完 "Sleep expired" 消息后，它就终止了。
+   <!--In the YAML file, in the `cmd` and `args` fields, you can see that the
+   container sleeps for 10 seconds and then writes "Sleep expired" to
+   the `/dev/termination-log` file. After the container writes
+   the "Sleep expired" message, it terminates.-->
+   YAML 文件中，在 `cmd` 和 `args` 字段，你可以看到容器休眠 10 秒然后将 "Sleep expired"
+   写入 `/dev/termination-log` 文件。
+   容器写完 "Sleep expired" 消息后就终止了。
 
 1. <!--Display information about the Pod:-->显示 Pod 的信息：
 
-        kubectl get pod termination-demo
+   ```shell
+   kubectl get pod termination-demo
+   ```
 
-    <!--Repeat the preceding command until the Pod is no longer running.-->
-    重复前面的命令直到 Pod 不再运行。
+   <!--Repeat the preceding command until the Pod is no longer running.-->
+   重复前面的命令直到 Pod 不再运行。
 
-1. <!--Display detailed information about the Pod:-->显示 Pod 的详细信息：
+1. <!--Display detailed information about the Pod:-->
+   显示 Pod 的详细信息：
 
-        kubectl get pod --output=yaml
+   ```shell
+   kubectl get pod --output=yaml
+   ```
 
-    <!--The output includes the "Sleep expired" message:-->输出结果包含 "Sleep expired" 消息：
+   <!--The output includes the "Sleep expired" message:-->输出结果包含 "Sleep expired" 消息：
+   ```yaml
+   apiVersion: v1
+   kind: Pod
+   ...
+       lastState:
+         terminated:
+           containerID: ...
+           exitCode: 0
+           finishedAt: ...
+           message: |
+             Sleep expired
+           ...
+   ```
 
-        apiVersion: v1
-        kind: Pod
-        ...
-            lastState:
-              terminated:
-                containerID: ...
-                exitCode: 0
-                finishedAt: ...
-                message: |
-                  Sleep expired
-                ...
+1. <!--Use a Go template to filter the output so that it includes only the termination message:-->
+   使用 Go 模板过滤输出结果，使其只含有终止消息：
 
-1. <!--Use a Go template to filter the output so that it includes only the termination message:-->使用 Go 模板过滤输出结果，使其只含有终止消息：
-
-        kubectl get pod termination-demo -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}"
+   ```shell
+   kubectl get pod termination-demo -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}"
+   ```
 
 <!--
 ## Customizing the termination message
--->
 
-## 定制终止消息
-
-<!--
 Kubernetes retrieves termination messages from the termination message file
 specified in the `terminationMessagePath` field of a Container, which as a default
 value of `/dev/termination-log`. By customizing this field, you can tell Kubernetes
 to use a different file. Kubernetes use the contents from the specified file to
 populate the Container's status message on both success and failure.
 -->
+## 定制终止消息
 
-Kubernetes 从容器的 `terminationMessagePath` 字段中指定的终止消息文件中检索终止消息，默认值为 `/dev/termination-log`。
+Kubernetes 从容器的 `terminationMessagePath` 字段中指定的终止消息文件中检索终止消息，
+默认值为 `/dev/termination-log`。
 通过定制这个字段，您可以告诉 Kubernetes 使用不同的文件。
 Kubernetes 使用指定文件中的内容在成功和失败时填充容器的状态消息。
 
@@ -122,7 +120,6 @@ Kubernetes 使用指定文件中的内容在成功和失败时填充容器的状
 In the following example, the container writes termination messages to
 `/tmp/my-log` for Kubernetes to retrieve:
 -->
-
 在下例中，容器将终止消息写入 `/tmp/my-log` 给 Kubernetes 来接收：
 
 ```yaml
@@ -152,11 +149,8 @@ is empty and the container exited with an error. The log output is limited to
 通过将 `terminationMessagePolicy` 设置为 "`FallbackToLogsOnError`"，你就可以告诉 Kubernetes，在容器因错误退出时，如果终止消息文件为空，则使用容器日志输出的最后一块作为终止消息。
 日志输出限制为 2048 字节或 80 行，以较小者为准。
 
-
-
 ## {{% heading "whatsnext" %}}
 
-
 <!--
 * See the `terminationMessagePath` field in
   [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core).
@@ -164,11 +158,8 @@ is empty and the container exited with an error. The log output is limited to
 * Learn about [Go templates](https://golang.org/pkg/text/template/).
 -->
 
-* 参考[容器](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)的 `terminationMessagePath` 字段。
-* 了解[接收日志](/docs/concepts/cluster-administration/logging/)。
+* 参考 [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
+  资源的 `terminationMessagePath` 字段。
+* 了解[接收日志](/zh/docs/concepts/cluster-administration/logging/)。
 * 了解 [Go 模版](https://golang.org/pkg/text/template/)。
 
-
-
-
-

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

@@ -1,19 +1,14 @@
 ---
-reviewers:
-- piosz
-- x13n
 content_type: concept
 title: StackDriver 中的事件
 ---
 
 <!--
----
 reviewers:
 - piosz
 - x13n
 content_type: concept
 title: Events in Stackdriver
----
 -->
 
 <!-- overview -->
@@ -27,8 +22,10 @@ for debugging your application in the [Application Introspection and Debugging
 section.
 -->
 
-Kubernetes 事件是一种对象，它为用户提供了洞察集群内发生的事情的能力，例如调度程序做出了什么决定，或者为什么某些 Pod 被逐出节点。
-您可以在[应用程序自检和调试](/docs/tasks/debug-application-cluster/debug-application-introspection/)中阅读有关使用事件调试应用程序的更多信息。
+Kubernetes 事件是一种对象，它为用户提供了洞察集群内发生的事情的能力，
+例如调度程序做出了什么决定，或者为什么某些 Pod 被逐出节点。
+你可以在[应用程序自检和调试](/zh/docs/tasks/debug-application-cluster/debug-application-introspection/)
+中阅读有关使用事件调试应用程序的更多信息。
 
 <!--
 Since events are API objects, they are stored in the apiserver on master. To
@@ -37,8 +34,7 @@ removed one hour after the last occurrence. To provide longer history
 and aggregation capabilities, a third party solution should be installed
 to capture events.
 -->
-
-因为事件是 API 对象，所以它们存储在主节点上的 apiserver 中。
+因为事件是 API 对象，所以它们存储在主控节点上的 API 服务器中。
 为了避免主节点磁盘空间被填满，将强制执行保留策略：事件在最后一次发生的一小时后将会被删除。
 为了提供更长的历史记录和聚合能力，应该安装第三方解决方案来捕获事件。
 
@@ -46,10 +42,8 @@ to capture events.
 This article describes a solution that exports Kubernetes events to
 Stackdriver Logging, where they can be processed and analyzed.
 -->
-
 本文描述了一个将 Kubernetes 事件导出为 Stackdriver Logging 的解决方案，在这里可以对它们进行处理和分析。
 
-{{< note >}}
 <!--
 It is not guaranteed that all events happening in a cluster will be
 exported to Stackdriver. One possible scenario when events will not be
@@ -58,24 +52,21 @@ upgrade). In most cases it's fine to use events for purposes like setting up
 [metrics][sdLogMetrics] and [alerts][sdAlerts], but you should be aware
 of the potential inaccuracy.
 -->
+{{< note >}}
 不能保证集群中发生的所有事件都将导出到 Stackdriver。
 事件不能导出的一种可能情况是事件导出器没有运行（例如，在重新启动或升级期间）。
-在大多数情况下，可以将事件用于设置 [metrics][sdLogMetrics] 和 [alerts][sdAlerts] 等目的，但您应该注意潜在的不准确性。
+在大多数情况下，可以将事件用于设置
+[metrics](https://cloud.google.com/logging/docs/view/logs_based_metrics) 和
+[alerts](https://cloud.google.com/logging/docs/view/logs_based_metrics#creating_an_alerting_policy)
+等目的，但你应该注意其潜在的不准确性。
 {{< /note >}}
 
-[sdLogMetrics]: https://cloud.google.com/logging/docs/view/logs_based_metrics
-[sdAlerts]: https://cloud.google.com/logging/docs/view/logs_based_metrics#creating_an_alerting_policy
-
-
-
-
 <!-- body -->
 
 <!--
 ## Deployment
 -->
-
-## 部署
+## 部署  {#deployment}
 
 ### Google Kubernetes Engine
 
@@ -91,21 +82,18 @@ average, approximately 100Mb RAM and 100m CPU is needed.
 -->
 
 在 Google Kubernetes Engine 中，如果启用了云日志，那么事件导出器默认部署在主节点运行版本为 1.7 及更高版本的集群中。
-为了防止干扰您的工作负载，事件导出器没有设置资源，并且处于尽力而为的 QoS 类型中，这意味着它将在资源匮乏的情况下第一个被杀死。
+为了防止干扰你的工作负载，事件导出器没有设置资源，并且处于尽力而为的 QoS 类型中，这意味着它将在资源匮乏的情况下第一个被杀死。
 如果要导出事件，请确保有足够的资源给事件导出器 Pod 使用。
 这可能会因为工作负载的不同而有所不同，但平均而言，需要大约 100MB 的内存和 100m 的 CPU。
 
 <!--
 ### Deploying to the Existing Cluster
--->
 
-### 部署到现有集群
-
-<!--
 Deploy event exporter to your cluster using the following command:
 -->
+### 部署到现有集群
 
-使用下面的命令将事件导出器部署到您的集群：
+使用下面的命令将事件导出器部署到你的集群：
 
 ```shell
 kubectl create -f https://k8s.io/examples/debug/event-exporter.yaml
@@ -123,27 +111,27 @@ requests. As mentioned earlier, 100Mb RAM and 100m CPU should be enough.
 由于事件导出器访问 Kubernetes API，因此它需要权限才能访问。
 以下的部署配置为使用 RBAC 授权。
 它设置服务帐户和集群角色绑定，以允许事件导出器读取事件。
-为了确保事件导出器 Pod 不会从节点中退出，您可以另外设置资源请求。
+为了确保事件导出器 Pod 不会从节点中退出，你可以另外设置资源请求。
 如前所述，100MB 内存和 100m CPU 应该就足够了。
 
 {{< codenew file="debug/event-exporter.yaml" >}}
 
 <!--
 ## User Guide
--->
 
-## 用户指南
-
-<!--
 Events are exported to the `GKE Cluster` resource in Stackdriver Logging.
 You can find them by selecting an appropriate option from a drop-down menu
 of available resources:
 -->
+## 用户指南   {#user-guide}
 
 事件在 Stackdriver Logging 中被导出到 `GKE Cluster` 资源。
-您可以通过从可用资源的下拉菜单中选择适当的选项来找到它们：
+你可以通过从可用资源的下拉菜单中选择适当的选项来找到它们：
 
+<!--
 <img src="/images/docs/stackdriver-event-exporter-resource.png" alt="Events location in the Stackdriver Logging interface" width="500">
+-->
+<img src="/images/docs/stackdriver-event-exporter-resource.png" alt="Stackdriver 日志接口中事件的位置" width="500">
 
 <!--
 You can filter based on the event object fields using Stackdriver Logging
@@ -151,8 +139,9 @@ You can filter based on the event object fields using Stackdriver Logging
 For example, the following query will show events from the scheduler
 about pods from deployment `nginx-deployment`:
 -->
-
-您可以使用 Stackdriver Logging 的[过滤机制](https://cloud.google.com/logging/docs/view/advanced_filters)基于事件对象字段进行过滤。
+你可以使用 Stackdriver Logging 的
+[过滤机制](https://cloud.google.com/logging/docs/view/advanced_filters)
+基于事件对象字段进行过滤。
 例如，下面的查询将显示调度程序中有关 Deployment `nginx-deployment` 中的 Pod 的事件：
 
 ```
@@ -162,6 +151,6 @@ jsonPayload.source.component="default-scheduler"
 jsonPayload.involvedObject.name:"nginx-deployment"
 ```
 
-{{< figure src="/images/docs/stackdriver-event-exporter-filter.png" alt="Filtered events in the Stackdriver Logging interface" width="500" >}}
+{{< figure src="/images/docs/stackdriver-event-exporter-filter.png" alt="在 Stackdriver 接口中过滤的事件" width="500" >}}
 
 

content/zh/docs/tasks/debug-application-cluster/local-debugging.md

@@ -4,10 +4,8 @@ content_type: task
 ---
 
 <!--
----
 title: Developing and debugging services locally
 content_type: task
----
 -->
 
 <!-- overview -->
@@ -15,28 +13,25 @@ content_type: task
 <!--
 Kubernetes applications usually consist of multiple, separate services, each running in its own container. Developing and debugging these services on a remote Kubernetes cluster can be cumbersome, requiring you to [get a shell on a running container](/docs/tasks/debug-application-cluster/get-shell-running-container/) and running your tools inside the remote shell.
 -->
-
 Kubernetes 应用程序通常由多个独立的服务组成，每个服务都在自己的容器中运行。
-在远端的 Kubernetes 集群上开发和调试这些服务可能很麻烦，需要[在运行的容器上打开 shell](/docs/tasks/debug-application-cluster/get-shell-running-container/)，然后在远端 shell 中运行您所需的工具。
+在远端的 Kubernetes 集群上开发和调试这些服务可能很麻烦，需要
+[在运行的容器上打开 Shell](/zh/docs/tasks/debug-application-cluster/get-shell-running-container/)，
+然后在远端 Shell 中运行你所需的工具。
 
 <!--
 `telepresence` is a tool to ease the process of developing and debugging services locally, while proxying the service to a remote Kubernetes cluster. Using `telepresence` allows you to use custom tools, such as a debugger and IDE, for a local service and provides the service full access to ConfigMap, secrets, and the services running on the remote cluster.
 -->
-
 `telepresence` 是一种工具，用于在本地轻松开发和调试服务，同时将服务代理到远程 Kubernetes 集群。
-使用 `telepresence` 可以为本地服务使用自定义工具（如调试器和 IDE），并提供对 Configmap、Secrets 和远程集群上运行的服务的完全访问。
+使用 `telepresence` 可以为本地服务使用自定义工具（如调试器和 IDE），
+并提供对 Configmap、Secret 和远程集群上运行的服务的完全访问。
 
 <!--
 This document describes using `telepresence` to develop and debug services running on a remote cluster locally.
---
-
+-->
 本文档描述如何在本地使用 `telepresence` 开发和调试远程集群上运行的服务。
 
-
-
 ## {{% heading "prerequisites" %}}
 
-
 <!--
 * Kubernetes cluster is installed
 * `kubectl` is configured to communicate with the cluster
@@ -47,8 +42,6 @@ This document describes using `telepresence` to develop and debug services runni
 * 配置好 `kubectl` 与集群交互
 * [Telepresence](https://www.telepresence.io/reference/install) 安装完毕
 
-
-
 <!-- steps -->
 
 <!--
@@ -56,40 +49,39 @@ This document describes using `telepresence` to develop and debug services runni
 
 Open a terminal and run `telepresence` with no arguments to get a `telepresence` shell. This shell runs locally, giving you full access to your local filesystem.
 -->
-
-打开终端，不带参数运行 `telepresence`，以打开 `telepresence` shell。这个 shell 在本地运行，使您可以完全访问本地文件系统。
+打开终端，不带参数运行 `telepresence`，以打开 `telepresence` Shell。
+这个 Shell 在本地运行，使你可以完全访问本地文件系统。
 
 <!--
 The `telepresence` shell can be used in a variety of ways. For example, write a shell script on your laptop, and run it directly from the shell in real time. You can do this on a remote shell as well, but you might not be able to use your preferred code editor, and the script is deleted when the container is terminated.
 
 Enter `exit` to quit and close the shell.
 -->
-
-`telepresence` shell 的使用方式多种多样。
-例如，在你的笔记本电脑上写一个 shell 脚本，然后直接在 shell 中实时运行它。
-您也可以在远端 shell 上执行此操作，但这样可能无法使用首选的代码编辑器，并且在容器终止时脚本将被删除。
+`telepresence` Shell 的使用方式多种多样。
+例如，在你的笔记本电脑上写一个 Shell 脚本，然后直接在 Shell 中实时运行它。
+你也可以在远端 Shell 上执行此操作，但这样可能无法使用首选的代码编辑器，并且在容器终止时脚本将被删除。
 
 <!--
 ## Developing or debugging an existing service
 
 When developing an application on Kubernetes, you typically program or debug a single service. The service might require access to other services for testing and debugging. One option is to use the continuous deployment pipeline, but even the fastest deployment pipeline introduces a delay in the program or debug cycle.
 -->
-
 ## 开发和调试现有的服务
 
 在 Kubernetes 上开发应用程序时，通常对单个服务进行编程或调试。
 服务可能需要访问其他服务以进行测试和调试。
-一种选择是使用连续部署管道，但即使最快的部署管道也会在程序或调试周期中引入延迟。
+一种选择是使用连续部署流水线，但即使最快的部署流水线也会在程序或调试周期中引入延迟。
 
 <!--
 Use the `--swap-deployment` option to swap an existing deployment with the Telepresence proxy. Swapping allows you to run a service locally and connect to the remote Kubernetes cluster. The services in the remote cluster can now access the locally running instance.
 
 To run telepresence with `--swap-deployment`, enter:
 -->
+使用 `--swap-deployment` 选项将现有部署与 Telepresence 代理交换。
+交换允许你在本地运行服务并能够连接到远端的 Kubernetes 集群。
+远端集群中的服务现在就可以访问本地运行的实例。
 
-使用 `--swap-deployment` 选项将现有部署与 Telepresence 代理交换。交换允许您在本地运行服务并能够连接到远端的 Kubernetes 集群。远端的集群中的服务现在就可以访问本地运行的实例。
-
-到运行 telepresence 并带有 `--swap-deployment` 选项，请输入：
+要运行 telepresence 并带有 `--swap-deployment` 选项，请输入：
 
 `telepresence --swap-deployment $DEPLOYMENT_NAME`
 
@@ -98,31 +90,25 @@ where $DEPLOYMENT_NAME is the name of your existing deployment.
 
 Running this command spawns a shell. In the shell, start your service. You can then make edits to the source code locally, save, and see the changes take effect immediately. You can also run your service in a debugger, or any other local development tool.
 -->
+这里的 `$DEPLOYMENT_NAME` 是你现有的部署名称。
 
-这里的 $DEPLOYMENT_NAME 是您现有的部署名称。
-
-运行此命令将生成 shell。在 shell 中，启动您的服务。
-然后，您就可以在本地对源代码进行编辑、保存并能看到更改立即生效。您还可以在调试器或任何其他本地开发工具中运行服务。
-
-
+运行此命令将生成 Shell。在该 Shell 中，启动你的服务。
+然后，你就可以在本地对源代码进行编辑、保存并能看到更改立即生效。
+你还可以在调试器或任何其他本地开发工具中运行服务。
 
 ## {{% heading "whatsnext" %}}
 
-
 <!--
 If you're interested in a hands-on tutorial, check out [this tutorial](https://cloud.google.com/community/tutorials/developing-services-with-k8s) that walks through locally developing the Guestbook application on Google Kubernetes Engine.
 -->
-
-如果您对实践教程感兴趣，请查看[本教程](https://cloud.google.com/community/tutorials/developing-services-with-k8s)，其中介绍了在 Google Kubernetes Engine 上本地开发 Guestbook 应用程序。
+如果你对实践教程感兴趣，请查看[本教程](https://cloud.google.com/community/tutorials/developing-services-with-k8s)，其中介绍了在 Google Kubernetes Engine 上本地开发 Guestbook 应用程序。
 
 <!--
 Telepresence has [numerous proxying options](https://www.telepresence.io/reference/methods), depending on your situation.
 
 For further reading, visit the [Telepresence website](https://www.telepresence.io).
 -->
-
-Telepresence 有[多种代理选项](https://www.telepresence.io/reference/methods)，以满足您的各种情况。
+Telepresence 有[多种代理选项](https://www.telepresence.io/reference/methods)，以满足你的各种情况。
 
 要了解更多信息，请访问 [Telepresence 网站](https://www.telepresence.io)。
 
-

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

@@ -1,19 +1,14 @@
 ---
-reviewers:
-- piosz
-- x13n
 content_type: concept
 title: 使用 ElasticSearch 和 Kibana 进行日志管理
 ---
 
 <!--
----
 reviewers:
 - piosz
 - x13n
 content_type: concept
 title: Logging Using Elasticsearch and Kibana
----
 -->
 
 <!-- overview -->
@@ -23,8 +18,10 @@ On the Google Compute Engine (GCE) platform, the default logging support targets
 [Stackdriver Logging](https://cloud.google.com/logging/), which is described in detail
 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/user-guide/logging/stackdriver)中详细描述了这一点。
+在 Google Compute Engine (GCE) 平台上，默认的日志管理支持目标是
+[Stackdriver Logging](https://cloud.google.com/logging/)，
+在[使用 Stackdriver Logging 管理日志](/zh/docs/tasks/debug-application-cluster/logging-stackdriver/)
+中详细描述了这一点。
 
 <!--
 This article describes how to set up a cluster to ingest logs into
@@ -32,18 +29,19 @@ This article describes how to set up a cluster to ingest logs into
 them using [Kibana](https://www.elastic.co/products/kibana), as an alternative to
 Stackdriver Logging when running on GCE. 
 -->
+本文介绍了如何设置一个集群，将日志导入
+[Elasticsearch](https://www.elastic.co/products/elasticsearch)，并使用
+[Kibana](https://www.elastic.co/products/kibana) 查看日志，作为在 GCE 上
+运行应用时使用 Stackdriver Logging 管理日志的替代方案。
 
-本文介绍了如何设置一个集群，将日志导入[Elasticsearch](https://www.elastic.co/products/elasticsearch)，并使用 [Kibana](https://www.elastic.co/products/kibana) 查看日志，作为在 GCE 上运行应用时使用 Stackdriver Logging 管理日志的替代方案。
-
-{{< note >}}
 <!--
 You cannot automatically deploy Elasticsearch and Kibana in the Kubernetes cluster hosted on Google Kubernetes Engine. You have to deploy them manually.
 -->
-您不能在 Google Kubernetes Engine 平台运行的 Kubernetes 集群上自动的部署 Elasticsearch 和 Kibana。您必须手动部署它们。
+{{< note >}}
+你不能在 Google Kubernetes Engine 平台运行的 Kubernetes 集群上自动部署
+Elasticsearch 和 Kibana。你必须手动部署它们。
 {{< /note >}}
 
-
-
 <!-- body -->
 
 <!--
@@ -51,8 +49,7 @@ 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
@@ -61,18 +58,20 @@ KUBE_LOGGING_DESTINATION=elasticsearch
 <!--
 You should also ensure that `KUBE_ENABLE_NODE_LOGGING=true` (which is the default for the GCE platform).
 -->
-
-您还应该确保设置了 `KUBE_ENABLE_NODE_LOGGING=true` （这是 GCE 平台的默认设置）。
+你还应该确保设置了 `KUBE_ENABLE_NODE_LOGGING=true` （这是 GCE 平台的默认设置）。
 
 <!--
 Now, when you create a cluster, a message will indicate that the Fluentd log
 collection daemons that run on each node will target Elasticsearch:
 -->
-
-现在，当您创建集群时，将有一条消息将指示每个节点上运行的 Fluentd 日志收集守护进程以 ElasticSearch 为日志输出目标：
+现在，当你创建集群时，将有一条消息将指示每个节点上运行的 fluentd 日志收集守护进程
+以 ElasticSearch 为日志输出目标：
 
 ```shell
-$ cluster/kube-up.sh
+cluster/kube-up.sh
+```
+
+```
 ...
 Project: kubernetes-satnam
 Zone: us-central1-b
@@ -96,11 +95,14 @@ The per-node Fluentd pods, the Elasticsearch pods, and the Kibana pods should
 all be running in the kube-system namespace soon after the cluster comes to
 life.
 -->
-
-每个节点的 Fluentd pod、Elasticsearch pod 和 Kibana pod 都应该在集群启动后不久运行在 kube-system 命名空间中。
+每个节点的 Fluentd Pod、Elasticsearch Pod 和 Kibana Pod 都应该在集群启动后不久运行在
+kube-system 命名空间中。
 
 ```shell
-$ kubectl get pods --namespace=kube-system
+kubectl get pods --namespace=kube-system
+```
+
+```
 NAME                                           READY     STATUS    RESTARTS   AGE
 elasticsearch-logging-v1-78nog                 1/1       Running   0          2h
 elasticsearch-logging-v1-nj2nb                 1/1       Running   0          2h
@@ -122,10 +124,12 @@ Elasticsearch pods store the logs and expose them via a REST API.
 The `kibana-logging` pod provides a web UI for reading the logs stored in
 Elasticsearch, and is part of a service named `kibana-logging`.
 -->
-
-`fluentd-elasticsearch` pod 从每个节点收集日志并将其发送到 `elasticsearch-logging` pods，该 pod 是名为 `elasticsearch-logging` 的[服务](/docs/concepts/services-networking/service/)的一部分。
+`fluentd-elasticsearch` Pod 从每个节点收集日志并将其发送到 `elasticsearch-logging` Pod，
+该 Pod 是名为 `elasticsearch-logging` 的
+[服务](/zh/docs/concepts/services-networking/service/)的一部分。
 这些 ElasticSearch pod 存储日志，并通过 REST API 将其公开。
-`kibana-logging` pod 提供了一个用于读取 ElasticSearch 中存储的日志的 Web UI，它是名为 `kibana-logging` 的服务的一部分。
+`kibana-logging` pod 提供了一个用于读取 ElasticSearch 中存储的日志的 Web UI，
+它是名为 `kibana-logging` 的服务的一部分。
 
 <!--
 The Elasticsearch and Kibana services are both in the `kube-system` namespace
@@ -134,13 +138,14 @@ follow the instructions for [Accessing services running in a cluster](/docs/conc
 -->
 
 Elasticsearch 和 Kibana 服务都位于 `kube-system` 命名空间中，并且没有通过可公开访问的 IP 地址直接暴露。
-要访问它们，请参照[访问集群中运行的服务](/docs/concepts/cluster-administration/access-cluster/#accessing-services-running-on-the-cluster)的说明进行操作。
+要访问它们，请参照
+[访问集群中运行的服务](/zh/docs/tasks/access-application-cluster/access-cluster/#accessing-services-running-on-the-cluster)
+的说明进行操作。
 
 <!--
 If you try accessing the `elasticsearch-logging` service in your browser, you'll
 see a status page that looks something like this:
 -->
-
 如果你想在浏览器中访问 `elasticsearch-logging` 服务，你将看到类似下面的状态页面：
 
 ![Elasticsearch Status](/images/docs/es-browser.png)
@@ -150,7 +155,6 @@ You can now type Elasticsearch queries directly into the browser, if you'd
 like. See [Elasticsearch's documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html)
 for more details on how to do so.
 -->
-
 现在你可以直接在浏览器中输入 Elasticsearch 查询，如果你愿意的话。
 请参考 [Elasticsearch 的文档](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html) 以了解这样做的更多细节。
 
@@ -165,11 +169,12 @@ You can set the refresh interval to 5 seconds to have the logs
 regularly refreshed.
 -->
 
-或者，您可以使用 Kibana 查看集群的日志（再次使用[访问集群中运行的服务的说明](/docs/user-guide/accessing-the-cluster/#accessing-services-running-on-the-cluster)）。
-第一次访问 Kibana URL 时，将显示一个页面，要求您配置所接收日志的视图。
+或者，你可以使用 Kibana 查看集群的日志（再次使用
+[访问集群中运行的服务的说明](/zh/docs/tasks/access-application-cluster/access-cluster/#accessing-services-running-on-the-cluster)）。
+第一次访问 Kibana URL 时，将显示一个页面，要求你配置所接收日志的视图。
 选择时间序列值的选项，然后选择 `@timestamp`。
-在下面的页面中选择 `Discover` 选项卡，然后您应该能够看到所摄取的日志。
-您可以将刷新间隔设置为 5 秒，以便定期刷新日志。
+在下面的页面中选择 `Discover` 选项卡，然后你应该能够看到所摄取的日志。
+你可以将刷新间隔设置为 5 秒，以便定期刷新日志。
 
 <!--
 Here is a typical view of ingested logs from the Kibana viewer:
@@ -179,16 +184,12 @@ Here is a typical view of ingested logs from the Kibana viewer:
 
 ![Kibana logs](/images/docs/kibana-logs.png)
 
-
-
 ## {{% heading "whatsnext" %}}
 
-
 <!--
 Kibana opens up all sorts of powerful options for exploring your logs! For some
 ideas on how to dig into it, check out [Kibana's documentation](https://www.elastic.co/guide/en/kibana/current/discover.html).
 -->
-
-Kibana 为浏览您的日志提供了各种强大的选项！有关如何深入研究它的一些想法，请查看 [Kibana 的文档](https://www.elastic.co/guide/en/kibana/current/discover.html)。
-
+Kibana 为浏览你的日志提供了各种强大的选项！有关如何深入研究它的一些想法，
+请查看 [Kibana 的文档](https://www.elastic.co/guide/en/kibana/current/discover.html)。
 

content/zh/docs/tasks/debug-application-cluster/monitor-node-health.md

@@ -3,18 +3,14 @@ content_type: task
 title: 节点健康监测
 ---
 <!-- 
----
 reviewers:
 - Random-Liu
 - dchen1107
 content_type: task
 title: Monitor Node Health
---- 
 -->
 
 <!-- overview -->
-
-*节点问题探测器* 是一个 [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) 用来监控节点健康。它从各种守护进程收集节点问题，并以[NodeCondition](/docs/concepts/architecture/nodes/#condition) 和 [Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core) 的形式报告给 apiserver 。 
 <!-- 
 *Node problem detector* is a [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) monitoring the
 node health. It collects node problems from various daemons and reports them
@@ -22,6 +18,12 @@ to the apiserver as [NodeCondition](/docs/concepts/architecture/nodes/#condition
 and [Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core). 
 -->
 
+*节点问题探测器* 是一个 [DaemonSet](/zh/docs/concepts/workloads/controllers/daemonset/)，
+用来监控节点健康。它从各种守护进程收集节点问题，并以
+[NodeCondition](/zh/docs/concepts/architecture/nodes/#condition) 和
+[Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core)
+的形式报告给 API 服务器。 
+
 <!-- 
 It supports some known kernel issue detection now, and will detect more and
 more node problems over time. 
@@ -33,7 +35,8 @@ Currently Kubernetes won't take any action on the node conditions and events
 generated by node problem detector. In the future, a remedy system could be
 introduced to deal with node problems. 
 -->
-目前，Kubernetes 不会对节点问题检测器监测到的节点状态和事件采取任何操作。将来可能会引入一个补救系统来处理这些节点问题。
+目前，Kubernetes 不会对节点问题检测器监测到的节点状态和事件采取任何操作。
+将来可能会引入一个补救系统来处理这些节点问题。
 
 <!-- 
 See more information
@@ -41,75 +44,71 @@ See more information
 -->
 更多信息请参阅 [这里](https://github.com/kubernetes/node-problem-detector)。
 
-
-
 ## {{% heading "prerequisites" %}}
 
-
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
-
-
 <!-- steps -->
 
 <!-- 
 ## Limitations 
--->
-## 局限性
 
-<!-- 
 * The kernel issue detection of node problem detector only supports file based
 kernel log now. It doesn't support log tools like journald. 
 -->
-* 节点问题检测器的内核问题检测现在只支持基于文件类型的内核日志。 它不支持像 journald 这样的命令行日志工具。
+## 局限性  {#limitations}
+
+* 节点问题检测器的内核问题检测现在只支持基于文件类型的内核日志。
+  它不支持像 journald 这样的命令行日志工具。
 
 <!-- 
 * The kernel issue detection of node problem detector has assumption on kernel
-log format, and now it only works on Ubuntu and Debian. However, it is easy to extend
-it to [support other log format](/docs/tasks/debug-application-cluster/monitor-node-health/#support-other-log-format). 
+  log format, and now it only works on Ubuntu and Debian. However, it is easy to extend
+  it to [support other log format](/docs/tasks/debug-application-cluster/monitor-node-health/#support-other-log-format). 
 -->
-* 节点问题检测器的内核问题检测对内核日志格式有一定要求，现在它只适用于 Ubuntu 和 Debian。但是，将其扩展为 [支持其它日志格式](/docs/tasks/debug-application-cluster/monitor-node-health/#support-other-log-format) 也很容易。
+* 节点问题检测器的内核问题检测对内核日志格式有一定要求，现在它只适用于 Ubuntu 和 Debian。
+  不过将其扩展为[支持其它日志格式](#support-other-log-format) 也很容易。
 
 <!-- 
 ## Enable/Disable in GCE cluster 
--->
-## 在 GCE 集群中启用/禁用
 
-<!-- 
 Node problem detector is [running as a cluster addon](/docs/setup/cluster-large/#addon-resources) enabled by default in the
 gce cluster. 
 -->
-节点问题检测器在 gce 集群中以[集群插件的形式](/docs/setup/cluster-large/#addon-resources)默认启用。
+## 在 GCE 集群中启用/禁用
+
+节点问题检测器在 gce 集群中以
+[集群插件的形式](/zh/docs/setup/best-practices/cluster-large/#addon-resources)
+默认启用。
 
 <!-- 
 You can enable/disable it by setting the environment variable
 `KUBE_ENABLE_NODE_PROBLEM_DETECTOR` before `kube-up.sh`. 
 -->
-您可以在运行 `kube-up.sh` 之前，以设置环境变量 `KUBE_ENABLE_NODE_PROBLEM_DETECTOR` 的形式启用/禁用它。
+你可以在运行 `kube-up.sh` 之前，以设置环境变量 `KUBE_ENABLE_NODE_PROBLEM_DETECTOR` 的形式启用/禁用它。
 
 <!-- 
 ## Use in Other Environment 
--->
-## 在其它环境中使用
 
-<!-- 
 To enable node problem detector in other environment outside of GCE, you can use
 either `kubectl` or addon pod. 
 -->
-要在 GCE 之外的其他环境中启用节点问题检测器，您可以使用 `kubectl` 或插件 pod。
+## 在其它环境中使用  {#use-in-other-environment}
+
+要在 GCE 之外的其他环境中启用节点问题检测器，你可以使用 `kubectl` 或插件 pod。
 
 <!-- 
 ### Kubectl 
--->
-### Kubectl
 
-<!-- 
 This is the recommended way to start node problem detector outside of GCE. It
 provides more flexible management, such as overwriting the default
 configuration to fit it into your environment or detect
 customized node problems. 
 -->
-这是在 GCE 之外启动节点问题检测器的推荐方法。它的管理更加灵活，例如覆盖默认配置以使其适合您的环境或检测自定义节点问题。
+### Kubectl
+
+这是在 GCE 之外启动节点问题检测器的推荐方法。
+它的管理更加灵活，例如覆盖默认配置以使其适合你的环境或检测自定义节点问题。
 
 <!-- 
 * **Step 1:** `node-problem-detector.yaml`: 
@@ -118,12 +117,11 @@ customized node problems.
 
 {{< codenew file="debug/node-problem-detector.yaml" >}}
 
-
 <!-- 
 ***Notice that you should make sure the system log directory is right for your
 OS distro.*** 
 -->
-***请注意保证您的系统日志路径与您的 OS 发行版相对应。***
+***请注意保证你的系统日志路径与你的 OS 发行版相对应。***
 
 <!-- 
 * **Step 2:** Start node problem detector with `kubectl`: 
@@ -136,39 +134,40 @@ OS distro.***
 
 <!-- 
 ### Addon Pod 
--->
-### 插件 Pod
 
-<!-- 
 This is for those who have their own cluster bootstrap solution, and don't need
 to overwrite the default configuration. They could leverage the addon pod to
 further automate the deployment. 
 -->
-这适用于拥有自己的集群引导程序解决方案的用户，并且不需要覆盖默认配置。 他们可以利用插件 Pod 进一步自动化部署。
+### 插件 Pod  {#addon-pod}
+
+这适用于拥有自己的集群引导程序解决方案的用户，并且不需要覆盖默认配置。
+他们可以利用插件 Pod 进一步自动化部署。
 
 <!-- 
 Just create `node-problem-detector.yaml`, and put it under the addon pods directory
 `/etc/kubernetes/addons/node-problem-detector` on master node. 
 -->
-只需创建 `node-problem-detector.yaml`，并将其放在主节点上的插件 pod 目录 `/etc/kubernetes/addons/node-problem-detector` 下。
-
+只需创建 `node-problem-detector.yaml`，并将其放在主节点上的插件 pod 目录
+`/etc/kubernetes/addons/node-problem-detector` 下。
 
 <!-- 
 ## Overwrite the Configuration 
--->
-## 覆盖配置文件
 
-<!-- 
 The [default configuration](https://github.com/kubernetes/node-problem-detector/tree/v0.1/config)
 is embedded when building the docker image of node problem detector. 
 -->
-构建节点问题检测器的 docker 镜像时，会嵌入[默认配置](https://github.com/kubernetes/node-problem-detector/tree/v0.1/config)。
+## 覆盖配置文件
+
+构建节点问题检测器的 docker 镜像时，会嵌入
+[默认配置](https://github.com/kubernetes/node-problem-detector/tree/v0.1/config)。
 
 <!-- 
 However, you can use [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to overwrite it
 following the steps: 
 -->
-不过，您可以像下面这样使用 [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) 将其覆盖：
+不过，你可以像下面这样使用 [ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)
+将其覆盖：
 
 <!-- 
 * **Step 1:** Change the config files in `config/`.
@@ -182,7 +181,6 @@ node-problem-detector-config --from-file=config/`.
 
 {{< codenew file="debug/node-problem-detector-configmap.yaml" >}}
 
-
 <!-- 
 * **Step 4:** Re-create the node problem detector with the new yaml file: 
 -->
@@ -206,13 +204,12 @@ ConfigMap, configuration overwriting is not supported now.
 
 <!-- 
 ## Kernel Monitor 
--->
-## 内核监视器
 
-<!-- 
 *Kernel Monitor* is a problem daemon in node problem detector. It monitors kernel log
 and detects known kernel issues following predefined rules. 
 -->
+## 内核监视器
+
 *内核监视器* 是节点问题检测器中的问题守护进程。它监视内核日志并按照预定义规则检测已知内核问题。
 
 <!-- 
@@ -222,18 +219,17 @@ The rule list is extensible, and you can always extend it by overwriting the
 configuration. 
 -->
 内核监视器根据 [`config/kernel-monitor.json`](https://github.com/kubernetes/node-problem-detector/blob/v0.1/config/kernel-monitor.json) 中的一组预定义规则列表匹配内核问题。
-规则列表是可扩展的，您始终可以通过覆盖配置来扩展它。
+规则列表是可扩展的，你始终可以通过覆盖配置来扩展它。
 
 <!-- 
 ### Add New NodeConditions 
--->
-### 添加新的 NodeCondition
 
-<!-- 
 To support new node conditions, you can extend the `conditions` field in
 `config/kernel-monitor.json` with new condition definition: 
 -->
-您可以使用新的状态描述来扩展 `config/kernel-monitor.json` 中的 `conditions` 字段以支持新的节点状态。
+### 添加新的 NodeCondition
+
+你可以使用新的状态描述来扩展 `config/kernel-monitor.json` 中的 `conditions` 字段以支持新的节点状态。
 
 ```json
 {
@@ -245,14 +241,13 @@ To support new node conditions, you can extend the `conditions` field in
 
 <!-- 
 ### Detect New Problems 
--->
-### 检测新的问题
 
-<!-- 
 To detect new problems, you can extend the `rules` field in `config/kernel-monitor.json`
 with new rule definition: 
 -->
-您可以使用新的规则描述来扩展 `config/kernel-monitor.json` 中的 `rules` 字段以检测新问题。
+### 检测新的问题
+
+你可以使用新的规则描述来扩展 `config/kernel-monitor.json` 中的 `rules` 字段以检测新问题。
 
 ```json
 {
@@ -265,42 +260,40 @@ with new rule definition:
 
 <!-- 
 ### Change Log Path 
--->
-### 更改日志路径
 
-<!-- 
 Kernel log in different OS distros may locate in different path. The `log`
 field in `config/kernel-monitor.json` is the log path inside the container.
 You can always configure it to match your OS distro. 
 -->
-不同操作系统发行版的内核日志的可能不同。 `config/kernel-monitor.json` 中的 `log` 字段是容器内的日志路径。您始终可以修改配置使其与您的 OS 发行版匹配。
+### 更改日志路径
+
+不同操作系统发行版的内核日志的可能不同。 `config/kernel-monitor.json` 中的 `log` 字段是容器内的日志路径。你始终可以修改配置使其与你的 OS 发行版匹配。
 
 <!-- 
 ### Support Other Log Format 
--->
-### 支持其它日志格式
 
-<!-- 
 Kernel monitor uses [`Translator`](https://github.com/kubernetes/node-problem-detector/blob/v0.1/pkg/kernelmonitor/translator/translator.go)
 plugin to translate kernel log the internal data structure. It is easy to
 implement a new translator for a new log format. 
 -->
-内核监视器使用 [`Translator`] 插件将内核日志转换为内部数据结构。我们可以很容易为新的日志格式实现新的翻译器。
+### 支持其它日志格式  {#support-other-log-format}
 
+内核监视器使用 [`Translator`] 插件将内核日志转换为内部数据结构。
+我们可以很容易为新的日志格式实现新的翻译器。
 
 <!-- discussion -->
 
 <!-- 
 ## Caveats 
--->
-## 注意事项 
 
-<!-- 
 It is recommended to run the node problem detector in your cluster to monitor
 the node health. However, you should be aware that this will introduce extra
 resource overhead on each node. Usually this is fine, because: 
 -->
-我们建议在集群中运行节点问题检测器来监视节点运行状况。但是，您应该知道这将在每个节点上引入额外的资源开销。一般情况下没有影响，因为：
+## 注意事项   {#caveats}
+
+我们建议在集群中运行节点问题检测器来监视节点运行状况。
+但是，你应该知道这将在每个节点上引入额外的资源开销。一般情况下没有影响，因为：
 
 <!-- 
 * The kernel log is generated relatively slowly.

content/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md

@@ -1,47 +1,41 @@
 ---
-reviewers:
-- fgrzadkowski
-- piosz
 title: 资源指标管道
 content_type: concept
 ---
 <!--
----
 reviewers:
 - fgrzadkowski
 - piosz
 title: Resource metrics pipeline
 content_type: concept
----
 -->
 
 <!-- overview -->
 
 <!--
-Starting from Kubernetes 1.8, resource usage metrics, such as container CPU and memory usage,
+Resource usage metrics, such as container CPU and memory usage,
 are available in Kubernetes through the Metrics API. These metrics can be either accessed directly
 by user, for example by using `kubectl top` command, or used by a controller in the cluster, e.g.
 Horizontal Pod Autoscaler, to make decisions.
 -->
-从 Kubernetes 1.8开始，资源使用指标，例如容器 CPU 和内存使用率，可通过 Metrics API 在 Kubernetes 中获得。这些指标可以直接被用户访问，比如使用`kubectl top`命令行，或者这些指标由集群中的控制器使用，例如，Horizontal Pod Autoscaler，使用这些指标来做决策。
-
-
-
+资源使用指标，例如容器 CPU 和内存使用率，可通过 Metrics API 在 Kubernetes 中获得。
+这些指标可以直接被用户访问，比如使用 `kubectl top` 命令行，或者这些指标由集群中的控制器使用，
+例如，Horizontal Pod Autoscaler，使用这些指标来做决策。
 
 <!-- body -->
 
 <!--
 ## The Metrics API
--->
-## Metrics API
 
-<!--
 Through the Metrics API you can get the amount of resource currently used
 by a given node or a given pod. This API doesn't store the metric values,
 so it's not possible for example to get the amount of resources used by a
 given node 10 minutes ago.
 -->
-通过 Metrics API，您可以获得指定节点或 pod 当前使用的资源量。此 API 不存储指标值，因此想要获取某个指定节点10分钟前的资源使用量是不可能的。
+## Metrics API   {#the-metrics-api}
+
+通过 Metrics API，你可以获得指定节点或 Pod 当前使用的资源量。
+此 API 不存储指标值，因此想要获取某个指定节点 10 分钟前的资源使用量是不可能的。
 
 <!--
 The API is no different from any other API:
@@ -52,15 +46,16 @@ The API is no different from any other API:
 - it is discoverable through the same endpoint as the other Kubernetes APIs under `/apis/metrics.k8s.io/` path
 - it offers the same security, scalability and reliability guarantees
 -->
-- 此 API 和其它 Kubernetes API 一起位于同一端点（endpoint）之下，是可发现的，路径为`/apis/metrics.k8s.io/` 
+- 此 API 和其它 Kubernetes API 一起位于同一端点（endpoint）之下，是可发现的，
+  路径为 `/apis/metrics.k8s.io/` 
 - 它提供相同的安全性、可扩展性和可靠性保证
 
 <!--
 The API is defined in [k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go)
 repository. You can find more information about the API there.
 -->
-Metrics API 在[k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go)
-仓库中定义。您可以在那里找到有关 Metrics API 的更多信息。
+Metrics API 在 [k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go)
+仓库中定义。你可以在那里找到有关 Metrics API 的更多信息。
 
 <!--
 The API requires metrics server to be deployed in the cluster. Otherwise it will be not available.
@@ -70,36 +65,66 @@ Metrics API 需要在集群中部署 Metrics Server。否则它将不可用。
 {{< /note >}}
 
 <!--
-## Metrics Server
+## Measuring Resource Usage
+
+### CPU
+
+CPU is reported as the average usage, in [CPU cores](/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu), over a period of time. This value is derived by taking a rate over a cumulative CPU counter provided by the kernel (in both Linux and Windows kernels). The kubelet chooses the window  for the rate calculation.
 -->
-## Metrics Server
+## 度量资源用量   {#measuring-resource-usage}
+
+### CPU
+
+CPU 用量按其一段时间内的平均值统计，单位为
+[CPU 核](/zh/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu)。
+此度量值通过在内核（包括 Linux 和 Windows）提供的累积 CPU 计数器乘以一个系数得到。
+`kubelet` 组件负责选择计算系数所使用的窗口大小。
+
+### 内存  {#memory}
+
+内存用量按工作集（Working Set）的大小字节数统计，其数值为收集度量值的那一刻的内存用量。
+如果一切都很理想化，“工作集” 是任务在使用的内存总量，该内存是不可以在内存压力较大
+的情况下被释放的。
+不过，具体的工作集计算方式取决于宿主 OS，有很大不同，且通常都大量使用启发式
+规则来给出一个估计值。
+其中包含所有匿名内存使用（没有后台文件提供存储者），因为 Kubernetes 不支持交换分区。
+度量值通常包含一些高速缓存（有后台文件提供存储）内存，因为宿主操作系统并不是总能
+回收这些页面。
 
 <!--
+## Metrics Server
+
 [Metrics Server](https://github.com/kubernetes-incubator/metrics-server) is a cluster-wide aggregator of resource usage data.
 Starting from Kubernetes 1.8 it's deployed by default in clusters created by `kube-up.sh` script
 as a Deployment object. If you use a different Kubernetes setup mechanism you can deploy it using the provided
 [deployment yamls](https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy).
 It's supported in Kubernetes 1.7+ (see details below).
 -->
-[Metrics Server](https://github.com/kubernetes-incubator/metrics-server)是集群范围资源使用数据的聚合器。
-从 Kubernetes 1.8开始，它作为 Deployment 对象，被默认部署在由`kube-up.sh`脚本创建的集群中。
-如果您使用不同的 Kubernetes 安装方法，则可以使用提供的[deployment yamls](https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy)来部署。它在 Kubernetes 1.7+中得到支持（详见下文）。
+## Metrics 服务器    {#metrics-server}
+
+[Metrics 服务器](https://github.com/kubernetes-incubator/metrics-server)是集群范围资源使用数据的聚合器。
+在由 `kube-up.sh` 脚本创建的集群中默认会以 Deployment 的形式被部署。
+如果你使用其他 Kubernetes 安装方法，则可以使用提供的
+[deployment yamls](https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy)
+来部署。
 
 <!--
 Metric server collects metrics from the Summary API, exposed by [Kubelet](/docs/admin/kubelet/) on each node.
 -->
-Metric server 从每个节点上的 [Kubelet](/docs/admin/kubelet/) 公开的 Summary API 中采集指标信息。
+Metric server 从每个节点上的 [Kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/)
+公开的 Summary API 中采集指标信息。
 
 <!--
 Metrics Server registered in the main API server through
 [Kubernetes aggregator](/docs/concepts/api-extension/apiserver-aggregation/),
 which was introduced in Kubernetes 1.7.
 -->
-通过在主 API server 中注册的 Metrics Server [Kubernetes 聚合器](/docs/concepts/api-extension/apiserver-aggregation/) 来采集指标信息， 这是在 Kubernetes 1.7 中引入的。
+Metrics 服务器通过
+[Kubernetes 聚合器](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 
+注册到主 API 服务器。
 
 <!--
 Learn more about the metrics server in [the design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md).
 -->
-在[设计文档](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)中可以了解到有关 Metrics Server 的更多信息。
-
+在[设计文档](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)中可以了解到有关 Metrics 服务器的更多信息。
 

content/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring.md

@@ -1,16 +1,12 @@
 ---
-reviewers:
-- mikedanese
 content_type: concept
 title: 资源监控工具
 ---
 <!--
----
 reviewers:
 - mikedanese
 content_type: concept
 title: Tools for Monitoring Resources
----
 -->
 
 <!-- overview -->
@@ -25,12 +21,12 @@ information about an application's resource usage at each of these levels.
 This information allows you to evaluate your application's performance and
 where bottlenecks can be removed to improve overall performance.
 -->
-要扩展应用程序并提供可靠的服务，您需要了解应用程序在部署时的行为。
-您可以通过检测容器检查 Kubernetes 集群中的应用程序性能，[pods](/docs/user-guide/pods), [服务](/docs/user-guide/services)和整个集群的特征。
+要扩展应用程序并提供可靠的服务，你需要了解应用程序在部署时的行为。
+你可以通过检测容器检查 Kubernetes 集群中的应用程序性能，
+[Pods](/zh/docs/concepts/workloads/pods), [服务](/zh/docs/concepts/services-networking/service/)
+和整个集群的特征。
 Kubernetes 在每个级别上提供有关应用程序资源使用情况的详细信息。
-此信息使您可以评估应用程序的性能，以及在何处可以消除瓶颈以提高整体性能。
-
-
+此信息使你可以评估应用程序的性能，以及在何处可以消除瓶颈以提高整体性能。
 
 <!-- body -->
 
@@ -38,22 +34,26 @@ Kubernetes 在每个级别上提供有关应用程序资源使用情况的详细
 In Kubernetes, application monitoring does not depend on a single monitoring solution. On new clusters, you can use [resource metrics](#resource-metrics-pipeline) or [full metrics](#full-metrics-pipeline) pipelines to collect monitoring statistics.
 -->
 在 Kubernetes 中，应用程序监控不依赖单个监控解决方案。
-在新集群上，您可以使用[资源度量](#资源度量管道)或[完整度量](#完整度量管道)管道来收集监视统计信息。
+在新集群上，你可以使用[资源度量](#resource-metrics-pipeline)或
+[完整度量](#full-metrics-pipeline)管道来收集监视统计信息。
 
 <!--
 ## Resource metrics pipeline
--->
-## 资源度量管道
 
-<!--
 The resource metrics pipeline provides a limited set of metrics related to
 cluster components such as the [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale) controller, as well as the `kubectl top` utility.
 These  metrics are collected by the lightweight, short-term, in-memory 
 [metrics-server](https://github.com/kubernetes-incubator/metrics-server) and
  are exposed via the `metrics.k8s.io` API. 
 -->
-资源指标管道提供了一组与集群组件，例如[Horizontal Pod Autoscaler]控制器(/docs/tasks/run-application/horizontal-pod-autoscale)，以及 `kubectl top` 实用程序相关的有限度量。
-这些指标是由轻量级的、短期内存[度量服务器](https://github.com/kubernetes-incubator/metrics-server)收集的，通过 `metrics.k8s.io` 公开。
+## 资源度量管道  {#resource-metrics-pipeline}
+
+资源指标管道提供了一组与集群组件，例如
+[Horizontal Pod Autoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale/)控制器，
+以及 `kubectl top` 实用程序相关的有限度量。
+这些指标是由轻量级的、短期、内存存储的
+[度量服务器](https://github.com/kubernetes-incubator/metrics-server)收集的，
+通过 `metrics.k8s.io` 公开。
 
 <!--
 metrics-server discovers all nodes on the cluster and 
@@ -69,7 +69,8 @@ resource usage statistics through the metrics-server Resource Metrics API.
 This API is served at `/metrics/resource/v1beta1` on the kubelet's authenticated and 
 read-only ports. 
 -->
-度量服务器发现集群中的所有节点，并且查询每个节点的[kubelet](/docs/reference/command-line-tools-reference/kubelet)以获取 CPU 和内存使用情况。
+度量服务器发现集群中的所有节点，并且查询每个节点的
+[kubelet](/zh/docs/reference/command-line-tools-reference/kubelet)以获取 CPU 和内存使用情况。
 Kubelet 充当 Kubernetes 主节点与节点之间的桥梁，管理机器上运行的 Pod 和容器。
 kubelet 将每个 pod 转换为其组成的容器，并在容器运行时通过容器运行时界面获取各个容器使用情况统计信息。
 kubelet 从集成的 cAdvisor 获取此信息，以进行旧式 Docker 集成。
@@ -78,10 +79,7 @@ kubelet 从集成的 cAdvisor 获取此信息，以进行旧式 Docker 集成。
 
 <!--
 ## Full metrics pipeline
--->
-## 完整度量管道
 
-<!--
 A full metrics pipeline gives you access to richer metrics. Kubernetes can
 respond to these metrics by  automatically scaling or adapting the cluster
 based on its current state, using mechanisms such as the Horizontal Pod
@@ -89,17 +87,18 @@ Autoscaler. The monitoring pipeline fetches metrics from the kubelet and
 then exposes them to Kubernetes via an adapter by implementing either the
 `custom.metrics.k8s.io` or `external.metrics.k8s.io` API. 
 -->
-一个完整度量管道可以让您访问更丰富的度量。
+## 完整度量管道  {#full-metrics-pipeline}
+
+一个完整度量管道可以让你访问更丰富的度量。
 Kubernetes 还可以根据集群的当前状态，使用 Pod 水平自动扩缩器等机制，通过自动调用扩展或调整集群来响应这些度量。
-监控管道从 kubelet 获取度量，然后通过适配器将它们公开给 Kubernetes，方法是实现 `custom.metrics.k8s.io` 或 `external.metrics.k8s.io` API。
+监控管道从 kubelet 获取度量值，然后通过适配器将它们公开给 Kubernetes，
+方法是实现 `custom.metrics.k8s.io` 或 `external.metrics.k8s.io` API。
 
 <!--
 [Prometheus](https://prometheus.io), a CNCF project, can natively monitor Kubernetes, nodes, and Prometheus itself.
 Full metrics pipeline projects that are not part of the CNCF are outside the scope of Kubernetes documentation.  
 -->
-[Prometheus](https://prometheus.io)，一个 CNCF 项目，可以原生监控 Kubernetes、节点和 
+[Prometheus](https://prometheus.io) 是一个 CNCF 项目，可以原生监控 Kubernetes、节点和 
 Prometheus 本身。
 完整度量管道项目不属于 CNCF 的一部分，不在 Kubernetes 文档的范围之内。
 
-
-