whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

sync zh-trans content/zh/docs/concepts/workloads/controllers/garbage-collection.md (#18865)

Browse Source
This commit is contained in:
chentanjun
2020-02-08 20:27:53 +08:00
committed by GitHub
parent 61a72d1f37
commit 9004bae90e
1 changed files with 36 additions and 39 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/concepts/workloads/controllers/garbage-collection.md
+36 -39
View File
@@ -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)