k8smeetup-shirdrn-pr-2017-8-15 (#5376)

* Chinese translation: 7.24-9.3, by shirdrn. * Translate and review again, and fix any translation problems for these 14 docs. * Delete network-policies.md temporarily, and then re-submit it for this PR.
2017-09-28 23:50:35 +08:00
parent d4e8e8fb9e
commit 88d3ed821d
15 changed files with 3222 additions and 0 deletions
@@ -0,0 +1,213 @@
+---
+assignees:
+- erictune
+- soltysh
+- janetkuo
+title: Cron Job
+redirect_from:
+- "/docs/concepts/jobs/cron-jobs/"
+- "/docs/concepts/jobs/cron-jobs.html"
+- "/docs/user-guide/cron-jobs/"
+- "/docs/user-guide/cron-jobs.html"
+---
+
+* TOC
+{:toc}
+
+
+
+## Cron Job 是什么？
+
+_Cron Job_ 管理基于时间的 [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/)，即：
+
+* 在给定时间点只运行一次
+* 在给定时间点周期性地运行
+
+一个 CronJob 对象类似于 _crontab_ （cron table）文件中的一行。它根据指定的预定计划周期性地运行一个 Job，格式可以参考 [Cron](https://en.wikipedia.org/wiki/Cron) 。
+
+
+
+**注意：** 在预定计划中，问号（`?`）和星号（`*`）的意义是相同的，表示给定字段的取值是任意可用值。
+
+**注意：** 在 Kubernetes 1.4 版本引入了 ScheduledJob 资源，但从 1.5 版本开始改成了 CronJob。
+
+典型的用法如下所示：
+
+
+
+* 在给定的时间点调度 Job 运行
+* 创建周期性运行的 Job，例如：数据库备份、发送邮件。
+
+### 前提条件
+
+
+
+当使用的 Kubernetes 集群，版本 >= 1.4（对 ScheduledJob），>= 1.5（对 CronJob），当启动 API Server（参考 [为集群开启或关闭 API 版本](/docs/admin/cluster-management/#turn-on-or-off-an-api-version-for-your-cluster) 获取更多信息）时，通过传递选项 `--runtime-config=batch/v2alpha1=true`  可以开启 batch/v2alpha1 API。
+
+## 创建 Cron Job
+
+下面是一个 Cron Job 的例子。它会每分钟运行一个 Job，打印出当前时间并输出问候语 hello。
+
+% include code.html language="yaml" file="cronjob.yaml" ghlink="/docs/concepts/workloads/controllers/cronjob.yaml" %}
+
+下载并运行该示例 Cron Job，然后执行如下命令：
+
+```shell
+$ kubectl create -f ./cronjob.yaml
+cronjob "hello" created
+```
+
+
+
+可选地，使用 `kubectl run` 创建一个 Cron Job，不需要写完整的配置：
+
+```shell
+$ kubectl run hello --schedule="*/1 * * * *" --restart=OnFailure --image=busybox -- /bin/sh -c "date; echo Hello from the Kubernetes cluster"
+cronjob "hello" created
+```
+
+
+
+创建该 Cron Job 之后，通过如下命令获取它的状态信息：
+
+```shell
+$ kubectl get cronjob hello
+NAME      SCHEDULE      SUSPEND   ACTIVE    LAST-SCHEDULE
+hello     */1 * * * *   False     0         <none>
+```
+
+
+
+如上所示，既没有 active 的 Job，也没有被调度的 Job。
+
+等待并观察创建的 Job，大约一分钟时间：
+
+```shell
+$ kubectl get jobs --watch
+NAME               DESIRED   SUCCESSFUL   AGE
+hello-4111706356   1         1         2s
+```
+
+
+
+现在能看到一个名称为 hello 的 Job 在运行。我们可以停止观察，并再次获取该 Job 的状态信息：
+
+```shell
+$ kubectl get cronjob hello
+NAME      SCHEDULE      SUSPEND   ACTIVE    LAST-SCHEDULE
+hello     */1 * * * *   False     0         Mon, 29 Aug 2016 14:34:00 -0700
+```
+
+
+应该能够看到名称为 “hello” 的 Job 在 `LAST-SCHEDULE` 指定的时间点被调度了。当前存在 0 个活跃（Active）的 Job，说明该 Job 已经被调度运行完成或失败。
+
+现在，找到最近一次被调度的 Job 创建的 Pod，能够看到其中一个 Pod 的标准输出。注意，Job 名称和 Pod 名称是不一样的。
+
+```shell
+# Replace "hello-4111706356" with the job name in your system
+$ pods=$(kubectl get pods --selector=job-name=hello-4111706356 --output=jsonpath={.items..metadata.name})
+
+$ echo $pods
+hello-4111706356-o9qcm
+
+$ kubectl logs $pods
+Mon Aug 29 21:34:09 UTC 2016
+Hello from the Kubernetes cluster
+```
+
+
+## 删除 Cron Job
+
+一旦不再需要 Cron Job，简单地可以使用 `kubectl` 命令删除它：
+
+```shell
+$ kubectl delete cronjob hello
+cronjob "hello" deleted
+```
+
+
+
+这将会终止正在创建的 Job。然而，运行中的 Job 将不会被终止，不会删除 Job 或 它们的 Pod。为了清理那些 Job 和 Pod，需要列出该 Cron Job 创建的全部 Job，然后删除它们：
+
+```shell
+$ kubectl get jobs
+NAME               DESIRED   SUCCESSFUL   AGE
+hello-1201907962   1         1            11m
+hello-1202039034   1         1            8m
+...
+
+$ kubectl delete jobs hello-1201907962 hello-1202039034 ...
+job "hello-1201907962" deleted
+job "hello-1202039034" deleted
+...
+```
+
+
+
+一旦 Job 被删除，由 Job 创建的 Pod 也会被删除。注意，所有由名称为 “hello” 的 Cron Job 创建的 Job 会以前缀字符串 “hello-” 进行命名。如果想要删除当前 Namespace 中的所有 Job，可以通过命令 `kubectl delete jobs --all` 立刻删除它们。
+
+
+
+## Cron Job 限制
+
+Cron Job 在每次调度运行时间内 _大概_ 会创建一个 Job 对象。我们之所以说 _大概_ ，是因为在特定的环境下可能会创建两个 Job，或者一个 Job 都没创建。我们尝试少发生这种情况，但却不能完全避免。因此，创建 Job 操作应该是 _幂等的_。
+
+Job 根据它所创建的 Pod 的并行度，负责重试创建 Pod，并就决定这一组 Pod 的成功或失败。Cron Job 根本不会去检查 Pod。
+
+
+
+## 编写 Cron Job 规约
+
+和其它 Kubernetes 配置一样，Cron Job 需要 `apiVersion`、 `kind`、和 `metadata` 这三个字段。
+关于如何实现一个配置文件的更新信息，参考文档 [部署应用](/docs/user-guide/deploying-applications)、
+[配置容器](/docs/user-guide/configuring-containers) 和 
+[使用 kubectl 管理资源](/docs/user-guide/working-with-resources)。
+
+Cron Job 也需要 [`.spec` 段](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status)。
+
+**注意：** 对一个 Cron Job 的所有修改，尤其是对其 `.spec` 的修改，仅会在下一次运行的时候生效。
+
+
+### 调度
+
+ `.spec.schedule` 是 `.spec` 中必需的字段，它的值是 [Cron](https://en.wikipedia.org/wiki/Cron) 格式字的符串，例如：`0 * * * *`，或者 `@hourly`，根据指定的调度时间 Job 会被创建和执行。
+
+
+
+### Job 模板
+
+`.spec.jobTemplate` 是另一个 `.spec` 中必需的字段。它是 Job 的模板。
+除了它可以是嵌套的，并且不具有 `apiVersion` 或 `kind` 字段之外，它和 [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/) 一样具有完全相同的模式（schema）。
+参考 [编写 Job 规格](/docs/concepts/jobs/run-to-completion-finite-workloads/#writing-a-job-spec)。
+
+
+
+### 启动 Job 的期限（秒级别）
+
+`.spec.startingDeadlineSeconds` 字段是可选的。它表示启动 Job 的期限（秒级别），如果因为任何原因而错过了被调度的时间，那么错过执行时间的 Job 将被认为是失败的。如果没有指定，则没有期限。
+
+
+
+### 并发策略
+
+`.spec.concurrencyPolicy` 字段也是可选的。它指定了如何处理被 Cron Job 创建的 Job 的并发执行。只允许指定下面策略中的一种：
+
+* `Allow`（默认）：允许并发运行 Job
+* `Forbid`：禁止并发运行，如果前一个还没有完成，则直接跳过下一个
+* `Replace`：取消当前正在运行的 Job，用一个新的来替换
+
+注意，当前策略只能应用于同一个 Cron Job 创建的 Job。如果存在多个 Cron Job，它们创建的 Job 之间总是允许并发运行。
+
+
+
+### 挂起
+
+`.spec.suspend` 字段也是可选的。如果设置为 `true`，后续所有执行都将被挂起。它对已经开始执行的 Job 不起作用。默认值为 `false`。
+
+
+
+### Job 历史限制
+
+`.spec.successfulJobsHistoryLimit` 和 `.spec.failedJobsHistoryLimit` 这两个字段是可选的。它们指定了可以保留完成和失败 Job 数量的限制。
+
+默认没有限制，所有成功和失败的 Job 都会被保留。然而，当运行一个 Cron Job 时，很快就会堆积很多 Job，推荐设置这两个字段的值。设置限制值为 `0`，相关类型的 Job 完成后将不会被保留。
@@ -0,0 +1,164 @@
+---
+assignees:
+- erictune
+title: DaemonSet
+redirect_from:
+- "/docs/admin/daemons/"
+- "/docs/admin/daemons.html"
+---
+
+* TOC
+{:toc}
+
+
+
+## 什么是 DaemonSet？
+
+ _DaemonSet_ 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时，也会为他们新增一个 Pod 。
+ 当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。
+
+ 
+
+使用 DaemonSet 的一些典型用法：
+
+- 运行集群存储 daemon，例如在每个节点上运行 `glusterd`、`ceph`。
+- 在每个节点上运行日志收集 daemon，例如`fluentd`、`logstash`。
+- 在每个节点上运行监控 daemon，例如 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter)、`collectd`、Datadog 代理、New Relic 代理，或 Ganglia `gmond`。
+
+一个简单的用法是在所有的节点上都启动一个 DaemonSet，将被作为每种类型的 daemon 使用。
+一个稍微复杂的用法是单独对每种 daemon 类型使用多个 DaemonSet，但具有不同的标志，和/或对不同硬件类型具有不同的内存、CPU要求。
+
+
+
+## 编写 DaemonSet 规约
+
+### 必需字段
+
+
+
+和其它所有 Kubernetes 配置一样，DaemonSet 需要 `apiVersion`、`kind` 和 `metadata` 字段。
+有关配置文件的基本信息，详见文档 [deploying applications](/docs/user-guide/deploying-applications/)、[配置容器](/docs/user-guide/configuring-containers/) 和 [资源管理](/docs/concepts/tools/kubectl/object-management-overview/) 。
+
+DaemonSet 也需要一个 [`.spec`](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) 配置段。
+
+
+
+### Pod 模板
+
+`.spec` 唯一必需的字段是 `.spec.template`。
+
+
+
+`.spec.template` 是一个 [Pod 模板](/docs/user-guide/replication-controller/#pod-template)。
+它与 [Pod](/docs/user-guide/pods) 具有相同的 schema，除了它是嵌套的，而且不具有 `apiVersion` 或 `kind` 字段。
+
+除了 Pod 必需字段外，在 DaemonSet 中的 Pod 模板必须指定合理的标签（查看 [Pod Selector](#pod-selector)）。
+
+在 DaemonSet 中的 Pod 模板必须具有一个值为 `Always` 的 [`RestartPolicy`](/docs/user-guide/pod-states)，或者未指定它的值，默认是 `Always`。
+
+
+
+### Pod Selector
+
+`.spec.selector` 字段表示 Pod Selector，它与 [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/) 或其它资源的 `.spec.selector` 的作用是相同的。
+
+`spec.selector` 表示一个对象，它由如下两个字段组成：
+
+* `matchLabels` - 与 [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/) 的 `.spec.selector` 的作用相同。
+* `matchExpressions` - 允许构建更加复杂的 Selector，可以通过指定 key、value 列表，以及与 key 和 value 列表相关的操作符。
+
+
+
+当上述两个字段都指定时，结果表示的是 AND 关系。
+
+如果指定了 `.spec.selector`，必须与 `.spec.template.metadata.labels` 相匹配。如果没有指定，它们默认是等价的。如果与它们配置的不匹配，则会被 API 拒绝。
+
+如果 Pod 的 label 与 selector 匹配，或者直接基于其它的 DaemonSet、或者 Controller（例如 ReplicationController），也不可以创建任何 Pod。
+否则 DaemonSet Controller 将认为那些 Pod 是它创建的。Kubernetes 不会阻止这样做。一个场景是，可能希望在一个具有不同值的、用来测试用的节点上手动创建 Pod。
+
+
+
+### 仅在某些节点上运行 Pod
+
+如果指定了 `.spec.template.spec.nodeSelector`，DaemonSet Controller 将在能够与 [Node Selector](/docs/concepts/configuration/assign-pod-node/) 匹配的节点上创建 Pod。
+类似这种情况，可以指定 `.spec.template.spec.affinity`，然后 DaemonSet Controller 将在能够与 [Node Affinity](/docs/concepts/configuration/assign-pod-node/) 匹配的节点上创建 Pod。
+如果根本就没有指定，则 DaemonSet Controller 将在所有节点上创建 Pod。
+
+
+
+## 如何调度 Daemon Pod
+
+正常情况下，Pod 运行在哪个机器上是由 Kubernetes 调度器来选择的。然而，由 Daemon Controller 创建的 Pod 已经确定了在哪个机器上（Pod 创建时指定了 `.spec.nodeName`），因此：
+
+- DaemonSet Controller 并不关心一个节点的 [`unschedulable`](/docs/admin/node/#manual-node-administration) 字段。
+- DaemonSet Controller 可以创建 Pod，即使调度器还没有启动，这对集群启动是非常有帮助的。
+
+
+
+Daemon Pod 关心 [Taint 和 Toleration](/docs/concepts/configuration/assign-pod-node/#taints-and-tolerations-beta-feature)，它们会为没有指定 `tolerationSeconds` 的 `node.alpha.kubernetes.io/notReady` 和 `node.alpha.kubernetes.io/unreachable` 的 Taint，创建具有 `NoExecute` 的 Toleration。这确保了当 alpha 特性的 `TaintBasedEvictions` 被启用时，发生节点故障，比如网络分区，这时它们将不会被清除掉（当 `TaintBasedEvictions` 特性没有启用，在这些场景下也不会被清除，但会因为 NodeController 的硬编码行为而被清除，而不会因为 Toleration 导致被清除）。
+
+
+
+## 与 Daemon Pod 通信
+
+与 DaemonSet 中的 Pod 进行通信，几种可能的模式如下：
+
+- **Push**：配置 DaemonSet 中的 Pod 向其它 Service 发送更新，例如统计数据库。它们没有客户端。
+- **NodeIP 和已知端口**：DaemonSet 中的 Pod 可以使用 `hostPort`，从而可以通过节点 IP 访问到 Pod。客户端能通过某种方法知道节点 IP 列表，并且基于此也可以知道端口。
+- **DNS**：创建具有相同 Pod Selector 的 [Headless Service](/docs/user-guide/services/#headless-services)，然后通过使用 `endpoints` 资源或从 DNS 检索到多个 A 记录来发现 DaemonSet。
+- **Service**：创建具有相同 Pod Selector 的 Service，并使用该 Service 随机访问到某个节点上的 daemon（没有办法访问到特定节点）。
+
+
+
+## 更新 DaemonSet
+
+如果修改了节点标签（Label），DaemonSet 将立刻向新匹配上的节点添加 Pod，同时删除新近不能够匹配的节点上的 Pod。
+
+我们可以修改 DaemonSet 创建的 Pod。然而，不允许对 Pod 的所有字段进行更新。当下次节点（即使具有相同的名称）被创建时，DaemonSet Controller 还会使用最初的模板。
+
+
+
+可以删除一个 DaemonSet。如果使用 `kubectl` 并指定 `--cascade=false` 选项，则 Pod 将被保留在节点上。然后可以创建具有不同模板的新 DaemonSet。具有不同模板的新 DaemonSet 将能够通过标签匹配并识别所有已经存在的 Pod。它不会修改或删除它们，即使是错误匹配了 Pod 模板。通过删除 Pod 或者删除节点，可以强制创建新的 Pod。
+
+在 Kubernetes 1.6 或以后版本，可以在 DaemonSet 上 [执行滚动升级](/docs/tasks/manage-daemon/update-daemon-set/)。
+
+未来的 Kubernetes 版本将支持节点的可控更新。
+
+
+
+## DaemonSet 的可替代选择
+
+### init 脚本
+
+我们很可能希望直接在一个节点上启动 daemon 进程（例如，使用 `init`、`upstartd`、或 `systemd`）。这非常好，但基于 DaemonSet 来运行这些进程有如下一些好处：
+
+
+
+- 像对待应用程序一样，具备为 daemon 提供监控和管理日志的能力。
+- 为 daemon 和应用程序使用相同的配置语言和工具（如 Pod 模板、`kubectl`）。
+- Kubernetes 未来版本可能会支持对 DaemonSet 创建 Pod 与节点升级工作流进行集成。
+- 在资源受限的容器中运行 daemon，能够增加 daemon 和应用容器的隔离性。然而，这也实现了在容器中运行 daemon，但却不能在 Pod 中运行（例如，直接基于 Docker 启动）。
+
+
+
+### 裸 Pod
+
+可能要直接创建 Pod，同时指定其运行在特定的节点上。
+然而，DaemonSet 替换了由于任何原因被删除或终止的 Pod，例如节点失败、例行节点维护、内核升级。由于这个原因，我们应该使用 DaemonSet 而不是单独创建 Pod。
+
+
+
+### 静态 Pod
+
+可能需要通过在一个指定目录下编写文件来创建 Pod，该目录受 Kubelet 所监视。这些 Pod 被称为 [静态 Pod](/docs/concepts/cluster-administration/static-pod/)。
+不像 DaemonSet，静态 Pod 不受 kubectl 和其它 Kubernetes API 客户端管理。静态 Pod 不依赖于 apiserver，这使得它们在集群启动的情况下非常有用。
+而且，未来静态 Pod 可能会被废弃掉。
+
+
+
+### Replication Controller
+
+DaemonSet 与 [Replication Controller](/docs/user-guide/replication-controller) 非常类似，它们都能创建 Pod，这些 Pod 对应的进程都不希望被终止掉（例如，Web 服务器、存储服务器）。
+为无状态的 Service 使用 Replication Controller，比如前端（Frontend）服务，实现对副本的数量进行扩缩容、平滑升级，比之于精确控制 Pod 运行在某个主机上要重要得多。
+需要 Pod 副本总是运行在全部或特定主机上，并需要先于其他 Pod 启动，当这被认为非常重要时，应该使用 Daemon Controller。
+
@@ -0,0 +1,180 @@
+---
+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"
+
+---
+
+{% capture overview %}
+
+
+
+Kubernetes 垃圾收集器的角色是删除指定的对象，这些对象曾经有但以后不再拥有 Owner 了。
+
+**注意**：垃圾收集是 beta 特性，在 Kubernetes 1.4 及以上版本默认启用。
+
+{% endcapture %}
+
+
+{% capture body %}
+
+
+## Owner 和 Dependent
+
+某些 Kubernetes 对象是其它一些对象的 Owner。例如，一个 ReplicaSet 是一组 Pod 的 Owner。
+具有 Owner 的对象被称为是 Owner 的 *Dependent*。
+每个 Dependent 对象具有一个指向其所属对象的 `metadata.ownerReferences` 字段。
+
+有时，Kubernetes 会自动设置 `ownerReference` 的值。
+例如，当创建一个 ReplicaSet 时，Kubernetes 自动设置 ReplicaSet 中每个 Pod 的 `ownerReference` 字段值。
+在 1.6 版本，Kubernetes 会自动为某些对象设置 `ownerReference` 的值，这些对象是由 ReplicationController、ReplicaSet、StatefulSet、DaemonSet 和 Deployment 所创建或管理。
+
+
+
+也可以通过手动设置 `ownerReference` 的值，来指定 Owner 和 Dependent 之间的关系。
+
+这里有一个配置文件，表示一个具有 3 个 Pod 的 ReplicaSet：
+
+{% include code.html language="yaml" file="my-repset.yaml" ghlink="/docs/concepts/workloads/controllers/my-repset.yaml" %}
+
+
+
+如果创建该 ReplicaSet，然后查看 Pod 的 metadata 字段，能够看到 OwnerReferences 字段：
+
+```shell
+kubectl create -f https://k8s.io/docs/concepts/abstractions/controllers/my-repset.yaml
+kubectl get pods --output=yaml
+```
+
+
+
+输出显示了 Pod 的 Owner 是名为 my-repset 的 ReplicaSet：
+
+```shell
+apiVersion: v1
+kind: Pod
+metadata:
+  ...
+  ownerReferences:
+  - apiVersion: extensions/v1beta1
+    controller: true
+    blockOwnerDeletion: true
+    kind: ReplicaSet
+    name: my-repset
+    uid: d9607e19-f88f-11e6-a518-42010a800195
+  ...
+```
+
+
+## 控制垃圾收集器删除 Dependent
+
+当删除对象时，可以指定是否该对象的 Dependent 也自动删除掉。
+自动删除 Dependent 也称为 *级联删除*。
+Kubernetes 中有两种 *级联删除* 的模式：*background* 模式和 *foreground* 模式。
+
+如果删除对象时，不自动删除它的 Dependent，这些 Dependent 被称作是原对象的 *孤儿*。
+
+
+
+### Background 级联删除
+
+在 *background 级联删除* 模式下，Kubernetes 会立即删除 Owner 对象，然后垃圾收集器会在后台删除这些 Dependent。
+
+
+
+### Foreground 级联删除
+
+在 *foreground 级联删除* 模式下，根对象首先进入 “删除中” 状态。在 “删除中” 状态会有如下的情况：
+
+ * 对象仍然可以通过 REST API 可见。
+ * 会设置对象的 `deletionTimestamp` 字段。
+ * 对象的 `metadata.finalizers` 字段包含了值 "foregroundDeletion"。
+
+ 一旦对象被设置为 “删除中” 状态，垃圾收集器会删除对象的所有 Dependent。
+ 垃圾收集器在删除了所有 “Blocking” 状态的 Dependent（对象的 `ownerReference.blockOwnerDeletion=true`）之后，它会删除 Owner 对象。
+
+
+
+注意，在 “foreground 删除” 模式下，只有设置了 `ownerReference.blockOwnerDeletion` 值得 Dependent 才能阻止删除 Owner 对象。
+在 Kubernetes 1.7 版本中将增加许可控制器（Admission Controller），基于 Owner 对象上的删除权限来控制用户去设置 `blockOwnerDeletion` 的值为 true，所以未授权的 Dependent 不能够延迟 Owner 对象的删除。
+
+如果一个对象的 `ownerReferences` 字段被一个 Controller（例如 Deployment 或 ReplicaSet）设置，`blockOwnerDeletion` 会被自动设置，不需要手动修改这个字段。
+
+
+
+### 设置级联删除策略
+
+通过为 Owner 对象设置 `deleteOptions.propagationPolicy` 字段，可以控制级联删除策略。
+可能的取值包括：“orphan”、“Foreground” 或 “Background”。
+
+对很多 Controller 资源，包括 ReplicationController、ReplicaSet、StatefulSet、DaemonSet 和 Deployment，默认的垃圾收集策略是 `orphan`。
+因此，除非指定其它的垃圾收集策略，否则所有 Dependent 对象使用的都是 `orphan` 策略。
+
+下面是一个在后台删除 Dependent 对象的例子：
+
+```shell
+kubectl proxy --port=8080
+curl -X DELETE localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/my-repset \
+-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
+-H "Content-Type: application/json"
+```
+
+
+
+下面是一个在前台删除 Dependent 对象的例子：
+
+```shell
+kubectl proxy --port=8080
+curl -X DELETE localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/my-repset \
+-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
+-H "Content-Type: application/json"
+```
+
+
+下面是一个孤儿 Dependent 的例子：
+
+```shell
+kubectl proxy --port=8080
+curl -X DELETE localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/my-repset \
+-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
+-H "Content-Type: application/json"
+```
+
+
+
+kubectl 也支持级联删除。
+通过设置 `--cascade` 为 true，可以使用 kubectl 自动删除 Dependent 对象。
+设置 `--cascade` 为 false，会使 Dependent 对象成为孤儿 Dependent 对象。
+`--cascade` 的默认值是 true。
+
+下面是一个例子，使一个 ReplicaSet 的 Dependent 对象成为孤儿 Dependent：
+
+
+```shell
+kubectl delete replicaset my-repset --cascade=false
+```
+
+
+
+## 已知的问题
+* 1.7 版本，垃圾收集不支持 [自定义资源](/docs/concepts/api-extension/custom-resources/)，比如那些通过 CustomResourceDefinition 新增，或者通过 API server 聚集而成的资源对象。
+
+[其它已知的问题](https://github.com/kubernetes/kubernetes/issues/26120)
+
+{% endcapture %}
+
+
+{% capture whatsnext %}
+
+
+
+[设计文档 1](https://git.k8s.io/community/contributors/design-proposals/garbage-collection.md)
+[设计文档 2](https://git.k8s.io/community/contributors/design-proposals/synchronous-garbage-collection.md)
+
+{% endcapture %}
+
+
+{% include templates/concept.md %}
@@ -0,0 +1,330 @@
+---
+assignees:
+- erictune
+title: Init 容器
+redirect_from:
+- "/docs/concepts/abstractions/init-containers/"
+- "/docs/concepts/abstractions/init-containers.html"
+- "/docs/user-guide/pods/init-container/"
+- "/docs/user-guide/pods/init-container.html"
+---
+
+{% capture overview %}
+
+本页提供了 Init 容器的概览，它是一种专用的容器，在应用容器启动之前运行，并包括一些应用镜像中不存在的实用工具和安装脚本。
+{% endcapture %}
+
+{:toc}
+
+
+这个特性在 1.6 版本已经退出 beta 版本。Init 容器可以在 PodSpec 中同应用的 `containers` 数组一起来指定。
+beta 注解的值将仍然需要保留，并覆盖 PodSpec 字段值。
+
+{% capture body %}
+
+
+## 理解 Init 容器
+
+
+
+[Pod](/docs/concepts/abstractions/pod/) 能够具有多个容器，应用运行在容器里面，但是它也可能有一个或多个先于应用容器启动的 Init 容器。
+
+Init 容器与普通的容器非常像，除了如下两点：
+
+
+
+* 它们总是运行到完成。
+* 每个都必须在下一个启动之前成功完成。
+
+
+
+如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。然而，如果 Pod 对应的 `restartPolicy` 值为 Never，它不会重新启动。
+
+指定容器为 Init 容器，需要在 PodSpec 中添加 `initContainers` 字段，以 [v1.Container](/docs/api-reference/v1.6/#container-v1-core) 类型对象的 JSON 数组的形式，还有 app 的 `containers` 数组。
+Init 容器的状态在 `status.initContainerStatuses` 字段中以容器状态数组的格式返回（类似 `status.containerStatuses` 字段）。
+
+
+
+### 与普通容器的不同之处
+
+Init 容器支持应用容器的全部字段和特性，包括资源限制、数据卷和安全设置。
+然而，Init 容器对资源请求和限制的处理稍有不同，在下面 [资源](#resources) 处有说明。
+而且 Init 容器不支持 Readiness Probe，因为它们必须在 Pod 就绪之前运行完成。
+
+如果为一个 Pod 指定了多个 Init 容器，那些容器会按顺序一次运行一个。
+每个 Init 容器必须运行成功，下一个才能够运行。
+当所有的 Init 容器运行完成时，Kubernetes 初始化 Pod 并像平常一样运行应用容器。
+
+
+
+## Init 容器能做什么？
+
+因为 Init 容器具有与应用容器分离的单独镜像，它们的启动相关代码具有如下优势：
+
+* 它们可以包含并运行实用工具，处于安全考虑，是不建议在应用容器镜像中包含这些实用工具的。
+* 它们可以包含使用工具和定制化代码来安装，但是不能出现在应用镜像中。例如，创建镜像没必要 `FROM` 另一个镜像，只需要在安装过程中使用类似 `sed`、 `awk`、 `python` 或 `dig` 这样的工具。
+* 应用镜像可以分离出创建和部署的角色，而没有必要联合它们构建一个单独的镜像。
+* 它们使用 Linux Namespace，所以对应用容器具有不同的文件系统视图。因此，它们能够具有访问 Secret 的权限，而应用容器不能够访问。
+* 它们在应用容器启动之前运行完成，然而应用容器并行运行，所以 Init 容器提供了一种简单的方式来阻塞或延迟应用容器的启动，直到满足了一组先决条件。
+
+
+
+### 示例
+
+下面是一些如何使用 Init 容器的想法：
+
+* 等待一个 Service 完成创建，通过类似如下 shell 命令：
+
+        for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; exit 1
+
+* 注册这个 Pod 到远程服务器，通过在命令中调用 API，类似如下：
+
+        curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'
+
+* 在启动应用容器之前等一段时间，使用类似 `sleep 60` 的命令。
+* 克隆 Git 仓库到数据卷。
+* 将配置值放到配置文件中，运行模板工具为主应用容器动态地生成配置文件。例如，在配置文件中存放 POD_IP 值，并使用 Jinja 生成主应用配置文件。
+
+更多详细用法示例，可以在 [StatefulSet 文档](/docs/concepts/abstractions/controllers/statefulsets/) 和 [生产环境 Pod 指南](/docs/user-guide/production-pods.md#handling-initialization)  中找到。
+
+
+
+### 使用 Init 容器
+
+下面是 Kubernetes 1.5 版本 yaml 文件，展示了一个具有 2 个 Init 容器的简单 Pod。
+第一个等待  `myservice` 启动，第二个等待 `mydb` 启动。
+一旦这两个 Service 都启动完成，Pod 将开始启动。
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: myapp-pod
+  labels:
+    app: myapp
+  annotations:
+    pod.beta.kubernetes.io/init-containers: '[
+        {
+            "name": "init-myservice",
+            "image": "busybox",
+            "command": ["sh", "-c", "until nslookup myservice; do echo waiting for myservice; sleep 2; done;"]
+        },
+        {
+            "name": "init-mydb",
+            "image": "busybox",
+            "command": ["sh", "-c", "until nslookup mydb; do echo waiting for mydb; sleep 2; done;"]
+        }
+    ]'
+spec:
+  containers:
+  - name: myapp-container
+    image: busybox
+    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
+```
+
+
+
+这是 Kubernetes 1.6 版本的新语法，尽管老的 annotation 语法仍然可以使用。我们已经把 Init 容器的声明移到 `spec` 中：
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: myapp-pod
+  labels:
+    app: myapp
+spec:
+  containers:
+  - name: myapp-container
+    image: busybox
+    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
+  initContainers:
+  - name: init-myservice
+    image: busybox
+    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
+  - name: init-mydb
+    image: busybox
+    command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
+```
+
+
+
+1.5 版本的语法在 1.6 版本仍然可以使用，但是我们推荐使用 1.6 版本的新语法。
+在 Kubernetes 1.6 版本中，Init 容器在 API 中新建了一个字段。
+虽然期望使用 beta 版本的 annotation，但在未来发行版将会被废弃掉。
+
+下面的 yaml 文件展示了 `mydb` 和 `myservice` 两个 Service：
+
+```
+kind: Service
+apiVersion: v1
+metadata:
+  name: myservice
+spec:
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 9376
+---
+kind: Service
+apiVersion: v1
+metadata:
+  name: mydb
+spec:
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 9377
+```
+
+
+
+这个 Pod 可以使用下面的命令进行启动和调试：
+
+```
+$ kubectl create -f myapp.yaml
+pod "myapp-pod" created
+$ kubectl get -f myapp.yaml
+NAME        READY     STATUS     RESTARTS   AGE
+myapp-pod   0/1       Init:0/2   0          6m
+$ kubectl describe -f myapp.yaml 
+Name:          myapp-pod
+Namespace:     default
+[...]
+Labels:        app=myapp
+Status:        Pending
+[...]
+Init Containers:
+  init-myservice:
+[...]
+    State:         Running
+[...]
+  init-mydb:
+[...]
+    State:         Waiting
+      Reason:      PodInitializing
+    Ready:         False
+[...]
+Containers:
+  myapp-container:
+[...]
+    State:         Waiting
+      Reason:      PodInitializing
+    Ready:         False
+[...]
+Events:
+  FirstSeen    LastSeen    Count    From                      SubObjectPath                           Type          Reason        Message
+  ---------    --------    -----    ----                      -------------                           --------      ------        -------
+  16s          16s         1        {default-scheduler }                                              Normal        Scheduled     Successfully assigned myapp-pod to 172.17.4.201
+  16s          16s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Pulling       pulling image "busybox"
+  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Pulled        Successfully pulled image "busybox"
+  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Created       Created container with docker id 5ced34a04634; Security:[seccomp=unconfined]
+  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Started       Started container with docker id 5ced34a04634
+$ kubectl logs myapp-pod -c init-myservice # Inspect the first init container
+$ kubectl logs myapp-pod -c init-mydb      # Inspect the second init container
+```
+
+
+
+一旦我们启动了 `mydb` 和 `myservice` 这两个 Service，我们能够看到 Init 容器完成，并且 `myapp-pod` 被创建：
+
+```
+$ kubectl create -f services.yaml
+service "myservice" created
+service "mydb" created
+$ kubectl get -f myapp.yaml
+NAME        READY     STATUS    RESTARTS   AGE
+myapp-pod   1/1       Running   0          9m
+```
+
+
+
+这个例子非常简单，但是应该能够为创建自己的 Init 容器提供一些启发。
+
+
+
+## 具体行为
+
+在 Pod 启动过程中，Init 容器会按顺序在网络和数据卷初始化之后启动。
+每个容器必须在下一个容器启动之前成功退出。
+如果由于运行时或失败退出，导致容器启动失败，它会根据 Pod 的 `restartPolicy` 指定的策略进行重试。
+然而，如果 Pod 的 `restartPolicy` 设置为 Always，Init 容器失败时会使用 `RestartPolicy` 策略。
+
+
+
+在所有的 Init 容器没有成功之前，Pod 将不会变成 `Ready` 状态。
+Init 容器的端口将不会在 Service 中进行聚集。
+正在初始化中的 Pod 处于 `Pending` 状态，但应该会将条件 `Initializing` 设置为 true。
+
+如果 Pod [重启](#pod-restart-reasons)，所有 Init 容器必须重新执行。
+
+对 Init 容器 spec 的修改，被限制在容器 image 字段中。
+更改 Init 容器的 image 字段，等价于重启该 Pod。
+
+
+
+因为 Init 容器可能会被重启、重试或者重新执行，所以 Init 容器的代码应该是幂等的。
+特别地，被写到 `EmptyDirs` 中文件的代码，应该对输出文件可能已经存在做好准备。
+
+Init 容器具有应用容器的所有字段。
+然而 Kubernetes 禁止使用 `readinessProbe`，因为 Init 容器不能够定义不同于完成（completion）的就绪（readiness）。 
+这会在验证过程中强制执行。
+
+
+
+在 Pod 上使用 `activeDeadlineSeconds`，在容器上使用 `livenessProbe`，这样能够避免 Init 容器一直失败。
+这就为 Init 容器活跃设置了一个期限。
+
+在 Pod 中的每个 app 和 Init 容器的名称必须唯一；与任何其它容器共享同一个名称，会在验证时抛出错误。
+
+
+
+### 资源
+
+为 Init 容器指定顺序和执行逻辑，下面对资源使用的规则将被应用：
+
+
+
+* 在所有 Init 容器上定义的，任何特殊资源请求或限制的最大值，是 *有效初始请求/限制*
+* Pod 对资源的 *有效请求/限制* 要高于：
+  * 所有应用容器对某个资源的请求/限制之和
+  * 对某个资源的有效初始请求/限制
+* 基于有效请求/限制完成调度，这意味着 Init 容器能够为初始化预留资源，这些资源在 Pod 生命周期过程中并没有被使用。
+* Pod 的 *有效 QoS 层*，是 Init 容器和应用容器相同的 QoS 层。
+
+
+
+基于有效 Pod 请求和限制来应用配额和限制。
+Pod 级别的 cgroups 是基于有效 Pod 请求和限制，和调度器相同。
+
+
+
+### Pod 重启的原因
+
+Pod 能够重启，会导致 Init 容器重新执行，主要有如下几个原因：
+
+* 用户更新 PodSpec 导致 Init 容器镜像发生改变。应用容器镜像的变更只会重启应用容器。
+* Pod 基础设施容器被重启。这不多见，但某些具有 root 权限可访问 Node 的人可能会这样做。
+* 当 `restartPolicy` 设置为 Always，Pod 中所有容器会终止，强制重启，由于垃圾收集导致 Init 容器完成的记录丢失。
+
+
+
+## 支持与兼容性
+
+Apiserver 版本为 1.6 或更高版本的集群，通过使用 `spec.initContainers` 字段来支持 Init 容器。
+之前的版本可以使用 alpha 和 beta 注解支持 Init 容器。
+`spec.initContainers` 字段也被加入到 alpha 和 beta 注解中，所以 Kubernetes 1.3.0 版本或更高版本可以执行 Init 容器，并且 1.6 版本的 apiserver 能够安全的回退到 1.5.x 版本，而不会使存在的已创建 Pod 失去 Init 容器的功能。
+
+{% endcapture %}
+
+
+{% capture whatsnext %}
+
+
+
+* [创建具有 Init 容器的 Pod](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)
+
+{% endcapture %}
+
+
+{% include templates/concept.md %}