diff --git a/content/zh/docs/tasks/debug-application-cluster/audit.md b/content/zh/docs/tasks/debug-application-cluster/audit.md
index 1e8f12388c..595d4d66e2 100644
--- a/content/zh/docs/tasks/debug-application-cluster/audit.md
+++ b/content/zh/docs/tasks/debug-application-cluster/audit.md
@@ -82,22 +82,34 @@ Each request can be recorded with an associated _stage_. The defined stages are:
 - `ResponseComplete` - 当响应消息体完成并且没有更多数据需要传输的时候。
 - `Panic` - 当 panic 发生时生成。
 
+<!-- 
+The configuration of an
+[Audit Event configuration](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)
+is different from the
+[Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core)
+API object.
+-->
+{{< note >}}
+[审计事件配置](/zh/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)
+的配置与 [Event](/zh/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core)
+API 对象不同。
+{{< /note >}}
+
 <!--
 The audit logging feature increases the memory consumption of the API server
 because some context required for auditing is stored for each request.
 Additionally, memory consumption depends on the audit logging configuration.
 -->
-{{< note >}}
 审计日志记录功能会增加 API server 的内存消耗，因为需要为每个请求存储审计所需的某些上下文。
 此外，内存消耗取决于审计日志记录的配置。
-{{< /note >}}
 
 <!--
 ## Audit Policy
 
 Audit policy defines rules about what events should be recorded and what data
 they should include. The audit policy object structure is defined in the
-[`audit.k8s.io` API group][auditing-api]. When an event is processed, it's
+[`audit.k8s.io` API group](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy).
+When an event is processed, it's
 compared against the list of rules in order. The first matching rule sets the
 _audit level_ of the event. The defined audit levels are:
 -->
@@ -105,7 +117,7 @@ _audit level_ of the event. The defined audit levels are:
 
 审计政策定义了关于应记录哪些事件以及应包含哪些数据的规则。
 审计策略对象结构定义在
-[`audit.k8s.io` API 组](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go)
+[`audit.k8s.io` API 组](/zh/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)
 处理事件时，将按顺序与规则列表进行比较。第一个匹配规则设置事件的
 _审计级别（Audit Level）_。已定义的审计级别有：
 
@@ -158,12 +170,18 @@ rules:
 If you're crafting your own audit profile, you can use the audit profile for Google Container-Optimized OS as a starting point. You can check the
 [configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)
 script, which generates the audit policy file. You can see most of the audit policy file by looking directly at the script.
+
+You can also refer to the [`Policy` configuration reference](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)
+for details about the fields defined.
 -->
 如果你在打磨自己的审计配置文件，你可以使用为 Google Container-Optimized OS
 设计的审计配置作为出发点。你可以参考
 [configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)
 脚本，该脚本能够生成审计策略文件。你可以直接在脚本中看到审计策略的绝大部份内容。
 
+你也可以参考 [`Policy` 配置参考](/zh/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)
+以获取有关已定义字段的详细信息。
+
 <!--
 ## Audit backends
 
@@ -173,10 +191,8 @@ Out of the box, the kube-apiserver provides two backends:
 - Log backend, which writes events into the filesystem
 - Webhook backend, which sends events to an external HTTP API
 
-In both cases, audit events structure is defined by the API in the
-`audit.k8s.io` API group. For Kubernetes {{< param "fullversion" >}}, that
-API is at version
-[`v1`](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go).
+In all cases, audit events follow a structure defined by the Kubernetes API in the
+[`audit.k8s.io` API group](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event).
 -->
 
 ## 审计后端   {#audit-backends}
@@ -186,9 +202,9 @@ API is at version
 - Log 后端，将事件写入到文件系统
 - Webhook 后端，将事件发送到外部 HTTP API
 
-在这两种情况下，审计事件结构均由 `audit.k8s.io` API 组中的 API 定义。
-对于 Kubernetes {{< param "fullversion" >}}，该 API 的当前版本是
-[`v1`](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go).
+在这所有情况下，审计事件均遵循 Kubernetes API 在
+[`audit.k8s.io` API 组](/zh/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)
+中定义的结构。
 
 <!--
 In case of patches, request body is a JSON array with patch operations, not a JSON object
diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-application-introspection.md b/content/zh/docs/tasks/debug-application-cluster/debug-application-introspection.md
index 51e1f353b8..7210356959 100644
--- a/content/zh/docs/tasks/debug-application-cluster/debug-application-introspection.md
+++ b/content/zh/docs/tasks/debug-application-cluster/debug-application-introspection.md
@@ -257,8 +257,7 @@ The message tells us that there were not enough resources for the Pod on any of
 其 message 部分表明没有任何节点拥有足够多的资源。
 
 <!--
-To correct this situation, you can use `kubectl scale` to update your Deployment to specify four or fewer replicas. 
-(Or you could just leave the one Pod pending, which is harmless.)
+To correct this situation, you can use `kubectl scale` to update your Deployment to specify four or fewer replicas. (Or you could leave the one Pod pending, which is harmless.)
 -->
 要纠正这种情况，可以使用 `kubectl scale` 更新 Deployment，以指定 4 个或更少的副本。
 (或者你可以让 Pod 继续保持这个状态，这是无害的。)
diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-application.md b/content/zh/docs/tasks/debug-application-cluster/debug-application.md
index 10c7264e4f..d2e95ab2b4 100644
--- a/content/zh/docs/tasks/debug-application-cluster/debug-application.md
+++ b/content/zh/docs/tasks/debug-application-cluster/debug-application.md
@@ -265,42 +265,18 @@ kubectl get pods --selector=name=nginx,type=frontend
 ```
 
 <!--
-If the list of pods matches expectations, but your endpoints are still empty, it's possible that you don't
-have the right ports exposed.  If your service has a `containerPort` specified, but the Pods that are
-selected don't have that port listed, then they won't be added to the endpoints list.
-
 Verify that the pod's `containerPort` matches up with the Service's `targetPort`
 -->
-如果 Pod 列表符合预期，但是 Endpoints 仍然为空，那么可能暴露的端口不正确。
-如果服务指定了 `containerPort`，但是所选中的 Pod 没有列出该端口，这些 Pod
-不会被添加到 Endpoints 列表。
-
 验证 Pod 的 `containerPort` 与服务的 `targetPort` 是否匹配。
 
 <!--
 #### Network traffic is not forwarded
 
-If you can connect to the service, but the connection is immediately dropped, and there are endpoints
-in the endpoints list, it's likely that the proxy can't contact your pods.
-
-There are three things to
-check:
-
-   * Are your pods working correctly?  Look for restart count, and [debug pods](#debugging-pods).
-   * Can you connect to your pods directly?  Get the IP address for the Pod, and try to connect directly to that IP.
-   * Is your application serving on the port that you configured?  Kubernetes doesn't do port remapping, so if your application serves on 8080, the `containerPort` field needs to be 8080.
+Please see [debugging service](/docs/tasks/debug-application-cluster/debug-service/) for more information.
 -->
 #### 网络流量未被转发
 
-如果你可以连接到服务上，但是连接立即被断开了，并且在 Endpoints 列表中有末端表项，
-可能是代理无法连接到 Pod。
-
-要检查的有以下三项：
-
-* Pod 工作是否正常？ 看一下重启计数，并参阅[调试 Pod](#debugging-pods)；
-* 是否可以直接连接到 Pod？获取 Pod 的 IP 地址，然后尝试直接连接到该 IP；
-* 应用是否在配置的端口上进行服务？Kubernetes 不进行端口重映射，所以如果应用在
-  8080 端口上服务，那么 `containerPort` 字段就要设定为 8080。
+请参阅[调试 service](/zh/docs/tasks/debug-application-cluster/debug-service/) 了解更多信息。
 
 ## {{% heading "whatsnext" %}}
 
diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/zh/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
index 8792bf89fb..d3de42728c 100644
--- a/content/zh/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
+++ b/content/zh/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
@@ -87,7 +87,7 @@ case you can try several things:
   will never be scheduled.
 
     You can check node capacities with the `kubectl get nodes -o <format>`
-    command. Here are some example command lines that extract just the necessary
+    command. Here are some example command lines that extract the necessary
     information: 
 -->
 #### 资源不足
diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-running-pod.md b/content/zh/docs/tasks/debug-application-cluster/debug-running-pod.md
index 8029504a80..3889cdf701 100644
--- a/content/zh/docs/tasks/debug-application-cluster/debug-running-pod.md
+++ b/content/zh/docs/tasks/debug-application-cluster/debug-running-pod.md
@@ -143,7 +143,7 @@ kubectl run ephemeral-demo --image=k8s.gcr.io/pause:3.1 --restart=Never
 ```
 
 This section use the `pause` container image in examples because it does not
-contain userland debugging utilities, but this method works with all container
+contain debugging utilities, but this method works with all container
 images.
 -->
 ## 使用临时容器来调试的例子 {#ephemeral-container-example}
@@ -162,7 +162,7 @@ kubectl run ephemeral-demo --image=k8s.gcr.io/pause:3.1 --restart=Never
 ```
 
 {{< note >}}
-本节示例中使用 `pause` 容器镜像，因为它不包含任何用户级调试程序，但是这个方法适用于所有容器镜像。
+本节示例中使用 `pause` 容器镜像，因为它不包含调试程序，但是这个方法适用于所有容器镜像。
 {{< /note >}}
 
 <!--
diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-service.md b/content/zh/docs/tasks/debug-application-cluster/debug-service.md
index 9c2ef902e7..469e004a5c 100644
--- a/content/zh/docs/tasks/debug-application-cluster/debug-service.md
+++ b/content/zh/docs/tasks/debug-application-cluster/debug-service.md
@@ -29,15 +29,15 @@ Deployment（或其他工作负载控制器）运行了 Pod，并创建 Service
 ## Running commands in a Pod
 
 For many steps here you will want to see what a Pod running in the cluster
-sees.  The simplest way to do this is to run an interactive alpine Pod:
+sees.  The simplest way to do this is to run an interactive busybox Pod:
 -->
 ## 在 Pod 中运行命令
 
 对于这里的许多步骤，你可能希望知道运行在集群中的 Pod 看起来是什么样的。
-最简单的方法是运行一个交互式的 alpine Pod：
+最简单的方法是运行一个交互式的 busybox Pod：
 
 ```none
-$ kubectl run -it --rm --restart=Never alpine --image=alpine sh
+kubectl run -it --rm --restart=Never busybox --image=gcr.io/google-containers/busybox sh
 ```
 
 <!--
@@ -161,13 +161,13 @@ kubectl get pods -l app=hostnames \
 ```
 
 <!--
-The example container used for this walk-through simply serves its own hostname
+The example container used for this walk-through serves its own hostname
 via HTTP on port 9376, but if you are debugging your own app, you'll want to
 use whatever port number your Pods are listening on.
 
 From within a pod:
 -->
-用于本教程的示例容器仅通过 HTTP 在端口 9376 上提供其自己的主机名，
+用于本教程的示例容器通过 HTTP 在端口 9376 上提供其自己的主机名，
 但是如果要调试自己的应用程序，则需要使用你的 Pod 正在侦听的端口号。
 
 在 Pod 内运行：
@@ -260,9 +260,9 @@ service/hostnames exposed
 ```
 
 <!--
-And read it back, just to be sure:
+And read it back:
 -->
-重新运行查询命令，确认没有问题：
+重新运行查询命令：
 
 ```shell
 kubectl get svc hostnames
@@ -608,14 +608,13 @@ Earlier you saw that the Pods were running.  You can re-check that:
 kubectl get pods -l app=hostnames
 ```
 ```none
-NAME              READY     STATUS    RESTARTS   AGE
+NAME                        READY     STATUS    RESTARTS   AGE
 hostnames-632524106-bbpiw   1/1       Running   0          1h
 hostnames-632524106-ly40y   1/1       Running   0          1h
 hostnames-632524106-tlaok   1/1       Running   0          1h
 ```
 <!--
-The `-l app=hostnames` argument is a label selector - just like our Service
-has.
+The `-l app=hostnames` argument is a label selector configured on the Service.
 
 The "AGE" column says that these Pods are about an hour old, which implies that
 they are running fine and not crashing.
@@ -627,7 +626,7 @@ If the restart count is high, read more about how to [debug pods](/docs/tasks/de
 Inside the Kubernetes system is a control loop which evaluates the selector of
 every Service and saves the results into a corresponding Endpoints object.
 -->
-`-l app=hostnames` 参数是一个标签选择算符 - 和我们 Service 中定义的一样。
+`-l app=hostnames` 参数是在 Service 上配置的标签选择器。
 
 "AGE" 列表明这些 Pod 已经启动一个小时了，这意味着它们运行良好，而未崩溃。
 
@@ -899,7 +898,7 @@ iptables-save | grep hostnames
 ```
 
 <!--
-There should be 2 rules for each port of your Service (just one in this
+There should be 2 rules for each port of your Service (only one in this
 example) - a "KUBE-PORTALS-CONTAINER" and a "KUBE-PORTALS-HOST".
 
 Almost nobody should be using the "userspace" mode any more, so you won't spend
diff --git a/content/zh/docs/tasks/debug-application-cluster/logging-stackdriver.md b/content/zh/docs/tasks/debug-application-cluster/logging-stackdriver.md
index fbc87d25f1..aacac3e5f0 100644
--- a/content/zh/docs/tasks/debug-application-cluster/logging-stackdriver.md
+++ b/content/zh/docs/tasks/debug-application-cluster/logging-stackdriver.md
@@ -493,13 +493,13 @@ a running cluster in the [Deploying section](#deploying).
 ### 更改 `DaemonSet` 参数    {#changing-daemonset-parameters}
 
 <!--
-When you have the Stackdriver Logging `DaemonSet` in your cluster, you can just modify the
-`template` field in its spec, daemonset controller will update the pods for you. For example,
-let's assume you've just installed the Stackdriver Logging as described above. Now you want to
+When you have the Stackdriver Logging `DaemonSet` in your cluster, you can modify the
+`template` field in its spec. The DaemonSet controller manages the pods for you.
+For example, assume you've 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。
+`template` 字段，DaemonSet 控制器将为你管理 Pod。
 例如，假设你按照上面的描述已经安装了 Stackdriver 日志机制。
 现在，你想更改内存限制，来给 fluentd 提供的更多内存，从而安全地处理更多日志。