From 65a5f83483b6d902e3e62c8f5722f63f6c61ac3a Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Wed, 28 Apr 2021 13:40:50 +0800 Subject: [PATCH] [zh] Resync concepts section (9) --- .../workloads/controllers/cron-jobs.md | 72 +++++++------- .../workloads/controllers/replicaset.md | 98 ++++++++++++++++++- .../controllers/replicationcontroller.md | 52 ++++++---- .../workloads/controllers/ttlafterfinished.md | 14 +-- 4 files changed, 175 insertions(+), 61 deletions(-) diff --git a/content/zh/docs/concepts/workloads/controllers/cron-jobs.md b/content/zh/docs/concepts/workloads/controllers/cron-jobs.md index 21eb03385c980..44be9b9a68bdb 100644 --- a/content/zh/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/zh/docs/concepts/workloads/controllers/cron-jobs.md @@ -12,15 +12,15 @@ weight: 80 -{{< feature-state for_k8s_version="v1.8" state="beta" >}} +{{< feature-state for_k8s_version="v1.21" state="stable" >}} -_Cron Job_ 创建基于时间调度的 [Jobs](/zh/docs/concepts/workloads/controllers/job/)。 +_CronJob_ 创建基于时隔重复调度的 {{< glossary_tooltip term_id="job" text="Jobs" >}}。 一个 CronJob 对象就像 _crontab_ (cron table) 文件中的一行。 它用 [Cron](https://en.wikipedia.org/wiki/Cron) 格式进行编写， @@ -102,24 +102,22 @@ This example CronJob manifest prints the current time and a hello message every # * * * * * ``` - -| 输入 | 描述 | 相当于 | -| ------------- | ------------- |------------- | -| @yearly (or @annually) | 每年 1 月 1 日的午夜运行一次 | 0 0 1 1 * | -| @monthly | 每月第一天的午夜运行一次 | 0 0 1 * * | -| @weekly | 每周的周日午夜运行一次 | 0 0 * * 0 | -| @daily (or @midnight) | 每天午夜运行一次 | 0 0 * * * | -| @hourly | 每小时的开始一次 | 0 * * * * | - +| Entry | Description | Equivalent to | +| ------------- | ------------- |------------- | +| @yearly (or @annually) | Run once a year at midnight of 1 January | 0 0 1 1 * | +| @monthly | Run once a month at midnight of the first day of the month | 0 0 1 * * | +| @weekly | Run once a week at midnight on Sunday morning | 0 0 * * 0 | +| @daily (or @midnight) | Run once a day at midnight | 0 0 * * * | +| @hourly | Run once an hour at the beginning of the hour | 0 * * * * | +--> +| 输入 | 描述 | 相当于 | +| ------------- | ------------- |------------- | +| @yearly (or @annually) | 每年 1 月 1 日的午夜运行一次 | 0 0 1 1 * | +| @monthly | 每月第一天的午夜运行一次 | 0 0 1 * * | +| @weekly | 每周的周日午夜运行一次 | 0 0 * * 0 | +| @daily (or @midnight) | 每天午夜运行一次 | 0 0 * * * | +| @hourly | 每小时的开始一次 | 0 * * * * | -例如，假设一个 CronJob 被设置为从 `08:30:00` 开始每隔一分钟创建一个新的 Job，并且它的 `startingDeadlineSeconds` 字段 -未被设置。如果 CronJob 控制器从 `08:29:00` 到 `10:21:00` 终止运行，则该 Job 将不会启动，因为其错过的调度次数超过了100。 +例如，假设一个 CronJob 被设置为从 `08:30:00` 开始每隔一分钟创建一个新的 Job， +并且它的 `startingDeadlineSeconds` 字段未被设置。如果 CronJob 控制器从 +`08:29:00` 到 `10:21:00` 终止运行，则该 Job 将不会启动，因为其错过的调度 +次数超过了 100。 -## 新控制器 +## 控制器版本 {#new-controller} -CronJob 控制器有一个替代的实现，自 Kubernetes 1.20 开始以 alpha 特性引入。 -如果选择 CronJob 控制器的 v2 版本，请在 {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} -中设置以下[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) 标志。 +从 Kubernetes v1.21 版本开始，CronJob 控制器的第二个版本被用作默认实现。 +要禁用此默认 CronJob 控制器而使用原来的 CronJob 控制器，请在 +{{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} +中设置[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +`CronJobControllerV2`，将此标志设置为 `false`。例如： ``` ---feature-gates="CronJobControllerV2=true" +--feature-gates="CronJobControllerV2=false" ``` ## {{% heading "whatsnext" %}} @@ -240,7 +243,8 @@ documents the format of CronJob `schedule` fields. For instructions on creating and working with cron jobs, and for an example of a spec file for a cron job, see [Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs). --> -* 进一步了解 [Cron 表达式的格式](https://en.wikipedia.org/wiki/Cron)，学习设置 CronJob `schedule` 字段 +* 进一步了解 [Cron 表达式的格式](https://en.wikipedia.org/wiki/Cron)，学习设置 + CronJob `schedule` 字段 * 有关创建和使用 CronJob 的说明及示例规约文件，请参见 [使用 CronJob 运行自动化任务](/zh/docs/tasks/job/automated-tasks-with-cron-jobs/)。 diff --git a/content/zh/docs/concepts/workloads/controllers/replicaset.md b/content/zh/docs/concepts/workloads/controllers/replicaset.md index 7ad68c9e53a16..14c86eb956ec3 100644 --- a/content/zh/docs/concepts/workloads/controllers/replicaset.md +++ b/content/zh/docs/concepts/workloads/controllers/replicaset.md @@ -472,7 +472,7 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron @@ -531,6 +531,102 @@ ensures that a desired number of pods with a matching label selector are availab 通过更新 `.spec.replicas` 字段，ReplicaSet 可以被轻松的进行缩放。ReplicaSet 控制器能确保匹配标签选择器的数量的 Pod 是可用的和可操作的。 + +在降低集合规模时，ReplicaSet 控制器通过对可用的 Pods 进行排序来优先选择 +要被删除的 Pods。其一般性算法如下： + + +1. 首先选择剔除悬决（Pending，且不可调度）的 Pods +2. 如果设置了 `controller.kubernetes.io/pod-deletion-cost` 注解，则注解值 + 较小的优先被裁减掉 +3. 所处节点上副本个数较多的 Pod 优先于所处节点上副本较少者 +4. 如果 Pod 的创建时间不同，最近创建的 Pod 优先于早前创建的 Pod 被裁减。 + （当 `LogarithmicScaleDown` 这一 + [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) + 被启用时，创建时间是按整数幂级来分组的）。 + +如果以上比较结果都相同，则随机选择。 + + +### Pod 删除开销 {#pod-deletion-cost} + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + + +通过使用 [`controller.kubernetes.io/pod-deletion-cost`](/zh/docs/reference/labels-annotations-taints/#pod-deletion-cost) +注解，用户可以对 ReplicaSet 缩容时要先删除哪些 Pods 设置偏好。 + + +此注解要设置到 Pod 上，取值范围为 [-2147483647, 2147483647]。 +所代表的的是删除同一 ReplicaSet 中其他 Pod 相比较而言的开销。 +删除开销较小的 Pods 比删除开销较高的 Pods 更容易被删除。 + + +Pods 如果未设置此注解，则隐含的设置值为 0。负值也是可接受的。 +如果注解值非法，API 服务器会拒绝对应的 Pod。 + + +此功能特性处于 Alpha 阶段，默认被禁用。你可以通过为 kube-apiserver 和 +kube-controller-manager 设置 +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +`PodDeletionCost` 来启用此功能。 + +{{< note >}} + +- 此机制实施时仅是尽力而为，并不能对 Pod 的删除顺序作出任何保证； +- 用户应避免频繁更新注解值，例如根据某观测度量值来更新此注解值是应该避免的。 + 这样做会在 API 服务器上产生大量的 Pod 更新操作。 +{{< /note >}} + + +#### 使用场景示例 + +同一应用的不同 Pods 可能其利用率是不同的。在对应用执行缩容操作时，可能 +希望移除利用率较低的 Pods。为了避免频繁更新 Pods，应用应该在执行缩容 +操作之前更新一次 `controller.kubernetes.io/pod-deletion-cost` 注解值 +（将注解值设置为一个与其 Pod 利用率对应的值）。 +如果应用自身控制器缩容操作时（例如 Spark 部署的驱动 Pod），这种机制 +是可以起作用的。 + 输出类似于： + ``` replicationcontroller/nginx created ``` @@ -113,10 +114,12 @@ Check on the status of the ReplicationController using this command: ```shell kubectl describe replicationcontrollers/nginx ``` + 输出类似于： + ``` Name: nginx Namespace: default @@ -167,6 +170,7 @@ echo $pods The output is similar to this: --> 输出类似于： + ``` nginx-3ntk0 nginx-4ok8v nginx-qrm3m ``` @@ -183,14 +187,16 @@ specifies an expression with the name from each pod in the returned list. ## Writing a ReplicationController Spec As with all other Kubernetes config, a ReplicationController needs `apiVersion`, `kind`, and `metadata` fields. -For general information about working with config files, see [object management ](/docs/concepts/overview/working-with-objects/object-management/). +For general information about working with configuration files, see [object management](/docs/concepts/overview/working-with-objects/object-management/). A ReplicationController also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). --> -## 编写一个 ReplicationController Spec +## 编写一个 ReplicationController 规约 -与所有其它 Kubernetes 配置一样，ReplicationController 需要 `apiVersion`、`kind` 和 `metadata` 字段。 -有关使用配置文件的常规信息，参考[对象管理](/zh/docs/concepts/overview/working-with-objects/object-management/)。 +与所有其它 Kubernetes 配置一样，ReplicationController 需要 `apiVersion`、 +`kind` 和 `metadata` 字段。 +有关使用配置文件的常规信息，参考 +[对象管理](/zh/docs/concepts/overview/working-with-objects/object-management/)。 ReplicationController 也需要一个 [`.spec` 部分](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。 @@ -230,7 +236,7 @@ for example the [Kubelet](/docs/admin/kubelet/) or Docker. The ReplicationController can itself have labels (`.metadata.labels`). Typically, you would set these the same as the `.spec.template.metadata.labels`; if `.metadata.labels` is not specified -then it defaults to `.spec.template.metadata.labels`. However, they are allowed to be +then it defaults to `.spec.template.metadata.labels`. However, they are allowed to be different, and the `.metadata.labels` do not affect the behavior of the ReplicationController. --> ### ReplicationController 上的标签 @@ -351,12 +357,13 @@ To update pods to a new spec in a controlled way, use a [rolling update](#rollin ### 从 ReplicationController 中隔离 Pod 通过更改 Pod 的标签，可以从 ReplicationController 的目标中删除 Pod。 -此技术可用于从服务中删除 Pod 以进行调试、数据恢复等。以这种方式删除的 Pod 将自动替换（假设复制副本的数量也没有更改）。 +此技术可用于从服务中删除 Pod 以进行调试、数据恢复等。以这种方式删除的 Pod +将被自动替换（假设复制副本的数量也没有更改）。 ### 扩缩容 {#scaling} -通过设置 `replicas` 字段，ReplicationController 可以方便地横向扩容或缩容副本的数量。 +通过设置 `replicas` 字段，ReplicationController 可以允许扩容或缩容副本的数量。 你可以手动或通过自动缩放控制代理来控制 ReplicationController 执行此操作。 ### 多个版本跟踪 -除了在滚动更新过程中运行应用程序的多个版本之外，通常还会使用多个版本跟踪来长时间，甚至持续运行多个版本。这些跟踪将根据标签加以区分。 +除了在滚动更新过程中运行应用程序的多个版本之外，通常还会使用多个版本跟踪来长时间， +甚至持续运行多个版本。这些跟踪将根据标签加以区分。 例如，一个服务可能把具有 `tier in (frontend), environment in (prod)` 的所有 Pod 作为目标。 现在假设你有 10 个副本的 Pod 组成了这个层。但是你希望能够 `canary` （`金丝雀`）发布这个组件的新版本。 @@ -429,7 +436,8 @@ For instance, a service might target all pods with `tier in (frontend), environm 标签为 `tier=frontend, environment=prod, track=stable` 而为 `canary` 设置另一个 ReplicationController，其中 `replicas` 设置为 1， 标签为 `tier=frontend, environment=prod, track=canary`。 -现在这个服务覆盖了 `canary` 和非 `canary` Pod。但你可以单独处理 ReplicationController，以测试、监控结果等。 +现在这个服务覆盖了 `canary` 和非 `canary` Pod。但你可以单独处理 +ReplicationController，以测试、监控结果等。 ### 和服务一起使用 ReplicationController -多个 ReplicationController 可以位于一个服务的后面，例如，一部分流量流向旧版本，一部分流量流向新版本。 +多个 ReplicationController 可以位于一个服务的后面，例如，一部分流量流向旧版本， +一部分流量流向新版本。 一个 ReplicationController 永远不会自行终止，但它不会像服务那样长时间存活。 服务可以由多个 ReplicationController 控制的 Pod 组成，并且在服务的生命周期内 @@ -455,8 +464,10 @@ Pods created by a ReplicationController are intended to be fungible and semantic --> ## 编写多副本的应用 -由 ReplicationController 创建的 Pod 是可替换的，语义上是相同的，尽管随着时间的推移，它们的配置可能会变得异构。 -这显然适合于多副本的无状态服务器，但是 ReplicationController 也可以用于维护主选、分片和工作池应用程序的可用性。 +由 ReplicationController 创建的 Pod 是可替换的，语义上是相同的， +尽管随着时间的推移，它们的配置可能会变得异构。 +这显然适合于多副本的无状态服务器，但是 ReplicationController 也可以用于维护主选、 +分片和工作池应用程序的可用性。 这样的应用程序应该使用动态的工作分配机制，例如 [RabbitMQ 工作队列](https://www.rabbitmq.com/tutorials/tutorial-two-python.html)， 而不是静态的或者一次性定制每个 Pod 的配置，这被认为是一种反模式。 @@ -481,8 +492,10 @@ The ReplicationController is forever constrained to this narrow responsibility. --> ReplicationController 永远被限制在这个狭隘的职责范围内。 它本身既不执行就绪态探测，也不执行活跃性探测。 -它不负责执行自动缩放，而是由外部自动缩放器控制（如 [#492](https://issue.k8s.io/492) 中所述），后者负责更改其 `replicas` 字段值。 -我们不会向 ReplicationController 添加调度策略(例如，[spreading](https://issue.k8s.io/367#issuecomment-48428019))。 +它不负责执行自动缩放，而是由外部自动缩放器控制（如 +[#492](https://issue.k8s.io/492) 中所述），后者负责更改其 `replicas` 字段值。 +我们不会向 ReplicationController 添加调度策略(例如， +[spreading](https://issue.k8s.io/367#issuecomment-48428019))。 它也不应该验证所控制的 Pod 是否与当前指定的模板匹配，因为这会阻碍自动调整大小和其他自动化过程。 类似地，完成期限、整理依赖关系、配置扩展和其他特性也属于其他地方。 我们甚至计划考虑批量创建 Pod 的机制（查阅 [#170](https://issue.k8s.io/170)）。 @@ -549,7 +562,8 @@ Unlike in the case where a user directly created pods, a ReplicationController r --> ### 裸 Pod -与用户直接创建 Pod 的情况不同，ReplicationController 能够替换因某些原因被删除或被终止的 Pod ，例如在节点故障或中断节点维护的情况下，例如内核升级。 +与用户直接创建 Pod 的情况不同，ReplicationController 能够替换因某些原因 +被删除或被终止的 Pod ，例如在节点故障或中断节点维护的情况下，例如内核升级。 因此，我们建议你使用 ReplicationController，即使你的应用程序只需要一个 Pod。 可以将其看作类似于进程管理器，它只管理跨多个节点的多个 Pod ，而不是单个节点上的单个进程。 ReplicationController 将本地容器重启委托给节点上的某个代理(例如，Kubelet 或 Docker)。 diff --git a/content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md index 91483c5513a9e..291b88e0d7b72 100644 --- a/content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -1,17 +1,17 @@ --- title: 已完成资源的 TTL 控制器 content_type: concept -weight: 65 +weight: 70 --- -{{< feature-state for_k8s_version="v1.12" state="alpha" >}} +{{< feature-state for_k8s_version="v1.21" state="beta" >}} -Alpha 免责声明：此功能目前是 alpha 版，并且可以通过 `kube-apiserver` 和 +此功能目前是 Beta 版而自动启用，并且可以通过 `kube-apiserver` 和 `kube-controller-manager` 上的 [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) -`TTLAfterFinished` 启用。 +`TTLAfterFinished` 禁用。