Skip to content

Commit

Permalink
[zh] Resync concepts section (9)
Browse files Browse the repository at this point in the history
  • Loading branch information
@tengqm
tengqm committed Apr 28, 2021
1 parent c8ce980 commit 65a5f83
Show file tree
Hide file tree
Showing 4 changed files with 175 additions and 61 deletions.
72 changes: 38 additions & 34 deletions content/zh/docs/concepts/workloads/controllers/cron-jobs.md
View file
Expand Up @@ -12,15 +12,15 @@ weight: 80

<!-- overview -->

{{< feature-state for_k8s_version="v1.8" state="beta" >}}
{{< feature-state for_k8s_version="v1.21" state="stable" >}}

<!--
A _Cron Job_ creates [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) on a time-based schedule.
A _CronJob_ creates {{< glossary_tooltip term_id="job" text="Jobs" >}} on a repeating schedule.
One CronJob object is like one line of a _crontab_ (cron table) file. It runs a job periodically
on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format.
-->
_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) 格式进行编写，
Expand Down Expand Up @@ -102,24 +102,22 @@ This example CronJob manifest prints the current time and a hello message every
# * * * * *
```


<!--
| 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 * * * * |

| 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 * * * * |

<!--
For example, the line below states that the task must be started every Friday at midnight, as well as on the 13th of each month at midnight:
Expand Down Expand Up @@ -192,8 +190,10 @@ For example, suppose a CronJob is set to schedule a new Job every one minute beg
`startingDeadlineSeconds` field is not set. If the CronJob controller happens to
be down from `08:29:00` to `10:21:00`, the job will not start as the number of missed jobs which missed their schedule is greater than 100.
-->
例如，假设一个 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。

<!--
To illustrate this concept further, suppose a CronJob is set to schedule a new Job every one minute beginning at `08:30:00`, and its
Expand All @@ -214,22 +214,25 @@ the Job in turn is responsible for the management of the Pods it represents.
CronJob 仅负责创建与其调度时间相匹配的 Job，而 Job 又负责管理其代表的 Pod。

<!--
## New controller
There's an alternative implementation of the CronJob controller, available as an alpha feature since Kubernetes 1.20. To select version 2 of the CronJob controller, pass the following [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) flag to the {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}.
## Controller version {#new-controller}
```
--feature-gates="CronJobControllerV2=true"
```
Starting with Kubernetes v1.21 the second version of the CronJob controller
is the default implementation. To disable the default CronJob controller
and use the original CronJob controller instead, one pass the `CronJobControllerV2`
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
flag to the {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}},
and set this flag to `false`. For example:
-->
## 新控制器
## 控制器版本 {#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" %}}
Expand All @@ -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/)。

98 changes: 97 additions & 1 deletion content/zh/docs/concepts/workloads/controllers/replicaset.md
View file
Expand Up @@ -472,7 +472,7 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
<!--
### Deleting just a ReplicaSet
You can delete a ReplicaSet without affecting any of its Pods using [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) with the `--cascade=orphan` option.
You can delete a ReplicaSet without affecting any of its Pods using [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) with the `-cascade=orphan` option.
When using the REST API or the `client-go` library, you must set `propagationPolicy` to `Orphan`.
For example:
-->
Expand Down Expand Up @@ -531,6 +531,102 @@ ensures that a desired number of pods with a matching label selector are availab
通过更新 `.spec.replicas` 字段，ReplicaSet 可以被轻松的进行缩放。ReplicaSet
控制器能确保匹配标签选择器的数量的 Pod 是可用的和可操作的。

<!--
When scaling down, the ReplicaSet controller chooses which pods to delete by sorting the available pods to
prioritize scaling down pods based on the following general algorithm:
-->
在降低集合规模时，ReplicaSet 控制器通过对可用的 Pods 进行排序来优先选择
要被删除的 Pods。其一般性算法如下：

<!--
1. Pending (and unschedulable) pods are scaled down first
2. If controller.kubernetes.io/pod-deletion-cost annotation is set, then
the pod with the lower value will come first.
3. Pods on nodes with more replicas come before pods on nodes with fewer replicas.
4. If the pods' creation times differ, the pod that was created more recently
comes before the older pod (the creation times are bucketed on an integer log scale
when the `LogarithmicScaleDown` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled)
-->
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 deletion cost
-->
### Pod 删除开销 {#pod-deletion-cost}

{{< feature-state for_k8s_version="v1.21" state="alpha" >}}

<!--
Using the [`controller.kubernetes.io/pod-deletion-cost`](/docs/reference/labels-annotations-taints/#pod-deletion-cost)
annotation, users can set a preference regarding which pods to remove first when downscaling a ReplicaSet.
-->
通过使用 [`controller.kubernetes.io/pod-deletion-cost`](/zh/docs/reference/labels-annotations-taints/#pod-deletion-cost)
注解，用户可以对 ReplicaSet 缩容时要先删除哪些 Pods 设置偏好。

<!--
The annotation should be set on the pod, the range is [-2147483647, 2147483647]. It represents the cost of
deleting a pod compared to other pods belonging to the same ReplicaSet. Pods with lower deletion
cost are preferred to be deleted before pods with higher deletion cost.
-->
此注解要设置到 Pod 上，取值范围为 [-2147483647, 2147483647]。
所代表的的是删除同一 ReplicaSet 中其他 Pod 相比较而言的开销。
删除开销较小的 Pods 比删除开销较高的 Pods 更容易被删除。

<!--
The implicit value for this annotation for pods that don't set it is 0; negative values are permitted.
Invalid values will be rejected by the API server.
-->
Pods 如果未设置此注解，则隐含的设置值为 0。负值也是可接受的。
如果注解值非法，API 服务器会拒绝对应的 Pod。

<!--
This feature is alpha and disabled by default. You can enable it by setting the
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
`PodDeletionCost` in both kube-apiserver and kube-controller-manager.
-->
此功能特性处于 Alpha 阶段，默认被禁用。你可以通过为 kube-apiserver 和
kube-controller-manager 设置
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
`PodDeletionCost` 来启用此功能。

{{< note >}}
<!--
- This is honored on a best-effort basis, so it does not offer any guarantees on pod deletion order.
- Users should avoid updating the annotation frequently, such as updating it based on a metric value,
because doing so will generate a significant number of pod updates on the apiserver.
-->
- 此机制实施时仅是尽力而为，并不能对 Pod 的删除顺序作出任何保证；
- 用户应避免频繁更新注解值，例如根据某观测度量值来更新此注解值是应该避免的。
这样做会在 API 服务器上产生大量的 Pod 更新操作。
{{< /note >}}

<!--
#### Example Use Case
The different pods of an application could have different utilization levels. On scale down, the application
may prefer to remove the pods with lower utilization. To avoid frequently updating the pods, the application
should update `controller.kubernetes.io/pod-deletion-cost` once before issuing a scale down (setting the
annotation to a value proportional to pod utilization level). This works if the application itself controls
the down scaling; for example, the driver pod of a Spark deployment.
-->
#### 使用场景示例

同一应用的不同 Pods 可能其利用率是不同的。在对应用执行缩容操作时，可能
希望移除利用率较低的 Pods。为了避免频繁更新 Pods，应用应该在执行缩容
操作之前更新一次 `controller.kubernetes.io/pod-deletion-cost` 注解值
（将注解值设置为一个与其 Pod 利用率对应的值）。
如果应用自身控制器缩容操作时（例如 Spark 部署的驱动 Pod），这种机制
是可以起作用的。

<!--
### ReplicaSet as an Horizontal Pod Autoscaler Target
Expand Down

0 comments on commit 65a5f83

Please sign in to comment.