diff --git a/content/zh/docs/concepts/workloads/controllers/garbage-collection.md b/content/zh/docs/concepts/workloads/controllers/garbage-collection.md
index e023a786be6bb..64daa61ff4c8b 100644
--- a/content/zh/docs/concepts/workloads/controllers/garbage-collection.md
+++ b/content/zh/docs/concepts/workloads/controllers/garbage-collection.md
@@ -1,11 +1,7 @@
 ---
 title: 垃圾收集
-redirect_from:
-- "/docs/concepts/abstractions/controllers/garbage-collection/"
-- "/docs/concepts/abstractions/controllers/garbage-collection.html"
-- "/docs/user-guide/garbage-collection/"
-- "/docs/user-guide/garbage-collection.html"
 content_template: templates/concept
+weight: 60
 ---
 
 <!--
@@ -59,7 +55,7 @@ Here's a configuration file for a ReplicaSet that has three Pods:
 
 有时，Kubernetes 会自动设置 `ownerReference` 的值。
 例如，当创建一个 ReplicaSet 时，Kubernetes 自动设置 ReplicaSet 中每个 Pod 的 `ownerReference` 字段值。
-在 1.6 版本，Kubernetes 会自动为某些对象设置 `ownerReference` 的值，这些对象是由 ReplicationController、ReplicaSet、StatefulSet、DaemonSet 和 Deployment 所创建或管理。
+在 Kubernetes 1.8 版本，Kubernetes 会自动为某些对象设置 `ownerReference` 的值，这些对象是由 ReplicationController、ReplicaSet、StatefulSet、DaemonSet、Deployment、Job 和 CronJob 所创建或管理。
 也可以通过手动设置 `ownerReference` 的值，来指定所有者和附属之间的关系。
 
 这里有一个配置文件，表示一个具有 3 个 Pod 的 ReplicaSet：
@@ -84,7 +80,7 @@ The output shows that the Pod owner is a ReplicaSet named `my-repset`:
 
 输出显示了 Pod 的所有者是名为 my-repset 的 ReplicaSet：
 
-```shell
+```yaml
 apiVersion: v1
 kind: Pod
 metadata:
@@ -99,8 +95,6 @@ metadata:
   ...
 ```
 
-{{< note >}}
-
 <!--
 Cross-namespace owner references are disallowed by design. This means:
 1) Namespace-scoped dependents can only specify owners in the same namespace,
@@ -108,13 +102,10 @@ and owners that are cluster-scoped.
 2) Cluster-scoped dependents can only specify cluster-scoped owners, but not
 namespace-scoped owners.
 -->
-
+{{< note >}}
 根据设计，kubernetes 不允许跨命名空间指定所有者。这意味着：
-
 1）命名空间范围的附属只能在相同的命名空间中指定所有者，并且只能指定集群范围的所有者。
-
 2）集群范围的附属只能指定集群范围的所有者，不能指定命名空间范围的。
-
 {{< /note >}}
 
 <!--
@@ -130,16 +121,19 @@ automatically, the dependents are said to be *orphaned*.
 -->
 ## 控制垃圾收集器删除附属者
 
-当删除对象时，可以指定是否该对象的附属者也自动删除掉。
+当删除对象时，可以指定该对象的附属者是否也自动删除掉。
 自动删除 Dependent 也称为 *级联删除* 。
 Kubernetes 中有两种 *级联删除* 的模式：*background* 模式和 *foreground* 模式。
 
-如果删除对象时，不自动删除它的附属者，这些附属者被称作是原对象的*孤儿* 。
+如果删除对象时，不自动删除它的附属者，这些附属者被称作是原对象的 *orphaned* 。
 
 
 <!--
 ### Foreground cascading deletion
+-->
+### 显式级联删除
 
+<!--
 In *foreground cascading deletion*, the root object first
 enters a "deletion in progress" state. In the "deletion in progress" state,
 the following things are true:
@@ -147,12 +141,23 @@ the following things are true:
  * The object is still visible via the REST API
  * The object's `deletionTimestamp` is set
  * The object's `metadata.finalizers` contains the value "foregroundDeletion".
+-->
+在*显式级联删除*模式下，根对象首先进入 `deletion in progress` 状态。在 `deletion in progress` 状态会有如下的情况：
 
+ * 对象仍然可以通过 REST API 可见。
+ * 会设置对象的 `deletionTimestamp` 字段。
+ * 对象的 `metadata.finalizers` 字段包含了值 `foregroundDeletion`。
+
+<!--
 Once the "deletion in progress" state is set, the garbage
 collector deletes the object's dependents. Once the garbage collector has deleted all
 "blocking" dependents (objects with `ownerReference.blockOwnerDeletion=true`), it deletes
 the owner object.
+-->
+一旦对象被设置为 `deletion in progress` 状态，垃圾收集器会删除对象的所有附属。
+垃圾收集器在删除了所有 `Blocking` 状态的附属（对象的 `ownerReference.blockOwnerDeletion=true`）之后，它会删除拥有者对象。
 
+<!--
 Note that in the "foregroundDeletion", only dependents with
 `ownerReference.blockOwnerDeletion=true` block the deletion of the owner object.
 Kubernetes version 1.7 added an [admission controller](/docs/reference/access-authn-authz/admission-controllers/#ownerreferencespermissionenforcement) that controls user access to set
@@ -162,22 +167,8 @@ unauthorized dependents cannot delay deletion of an owner object.
 If an object's `ownerReferences` field is set by a controller (such as Deployment or ReplicaSet),
 blockOwnerDeletion is set automatically and you do not need to manually modify this field.
 -->
-
-### 显式级联删除
-
-在*显式级联删除*模式下，根对象首先进入 `deletion in progress` 状态。在 `deletion in progress` 状态会有如下的情况：
-
- * 对象仍然可以通过 REST API 可见。
- * 会设置对象的 `deletionTimestamp` 字段。
- * 对象的 `metadata.finalizers` 字段包含了值 `foregroundDeletion`。
-
-一旦对象被设置为 `deletion in progress` 状态，垃圾收集器会删除对象的所有附属。
- 垃圾收集器在删除了所有 `Blocking` 状态的附属（对象的 `ownerReference.blockOwnerDeletion=true`）之后，它会删除拥有者对象。
-
-
-
 注意，在 `foregroundDeletion` 模式下，只有设置了 `ownerReference.blockOwnerDeletion` 值的附属者才能阻止删除拥有者对象。
-在 Kubernetes 1.7 版本中将增加准入控制器（Admission Controller），基于拥有者对象上的删除权限来控制用户去设置 `blockOwnerDeletion` 的值为 true，所以未授权的附属者不能够延迟拥有者对象的删除。
+在 Kubernetes 1.7 版本中将增加[准入控制器](/docs/reference/access-authn-authz/admission-controllers/#ownerreferencespermissionenforcement)，基于拥有者对象上的删除权限来控制用户去设置 `blockOwnerDeletion` 的值为 true，所以未授权的附属者不能够延迟拥有者对象的删除。
 
 如果一个对象的 `ownerReferences` 字段被一个 Controller（例如 Deployment 或 ReplicaSet）设置，`blockOwnerDeletion` 会被自动设置，不需要手动修改这个字段。
 
@@ -191,7 +182,7 @@ the background.
 -->
 ### 隐式级联删除
 
-在 *隐式级联删除除* 模式下，Kubernetes 会立即删除拥有者对象，然后垃圾收集器会在后台删除这些附属。
+在 *隐式级联删除* 模式下，Kubernetes 会立即删除拥有者对象，然后垃圾收集器会在后台删除这些附属值。
 
 <!--
 ### Setting the cascading deletion policy
@@ -206,18 +197,20 @@ Deployment. For kinds in the `extensions/v1beta1`, `apps/v1beta1`, and `apps/v1b
 specify otherwise, dependent objects are orphaned by default. In Kubernetes 1.9, for all kinds in the `apps/v1` 
 group version, dependent objects are deleted by default.
 
-Here's an example that deletes dependents in background:
 -->
 
 ### 设置级联删除策略
 
 通过为拥有者对象设置 `deleteOptions.propagationPolicy` 字段，可以控制级联删除策略。
-可能的取值包括：`orphan`、`Foreground`或`Background`。
+可能的取值包括：`orphan`、`Foreground` 或者 `Background`。
 
 对很多 Controller 资源，包括 ReplicationController、ReplicaSet、StatefulSet、DaemonSet 和 Deployment，默认的垃圾收集策略是 `orphan`。
-因此，除非指定其它的垃圾收集策略，否则所有附属对象使用的都是 `orphan` 策略。
+因此，对于使用 `extensions/v1beta1`、`apps/v1beta1` 和 `apps/v1beta2` 组版本中的 `Kind`,除非指定其它的垃圾收集策略，否则所有附属对象默认使用的都是 `orphan` 策略。
 
-下面是一个在后台删除 Dependent 对象的例子：
+<!--
+Here's an example that deletes dependents in background:
+-->
+下面是一个在 `Background` 中删除 Dependent 对象的示例：
 
 ```shell
 kubectl proxy --port=8080
@@ -230,7 +223,7 @@ curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-rep
 Here's an example that deletes dependents in foreground:
 -->
 
-下面是一个在前台删除附属对象的例子：
+下面是一个在 `Foreground` 中删除附属对象的示例：
 
 ```shell
 kubectl proxy --port=8080
@@ -243,7 +236,7 @@ curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-rep
 Here's an example that orphans dependents:
 -->
 
-这里是一个孤儿附属的例子：
+这里是一个 `Orphan` 附属的示例：
 
 ```shell
 kubectl proxy --port=8080
@@ -281,7 +274,7 @@ See [kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment
 
 ### Deployment 的其他说明
 
-在 1.7 之前的版本中，当在 Deployment 中使用级联删除时，您必须*使用* `propagationPolicy:Foreground`。这样不仅删除所创建的 ReplicaSet，还删除其 Pod。如果不使用这种类型的 `propagationPolicy`，则将只删除 ReplicaSet，而 Pod 被孤立。
+在 1.7 之前的版本中，当在 Deployment 中使用级联删除时，您必须*使用* `propagationPolicy:Foreground` 模式。这样不仅删除所创建的 ReplicaSet，还删除其 Pod。如果不使用这种类型的 `propagationPolicy`，则将只删除 ReplicaSet，而 Pod 被孤立。
 
 更多信息，请参考 [kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment-284766613)。
 
@@ -301,7 +294,11 @@ Tracked at [#26120](https://github.com/kubernetes/kubernetes/issues/26120)
 {{% capture whatsnext %}}
 
 
-## 控制垃圾收集器删除附属者
+<!--
+[Design Doc 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md)
+
+[Design Doc 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md)
+-->
 [设计文档 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md)
 
 [设计文档 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md)