Skip to content

[zh-cn]sync cron-jobs pods/_index daemonset #56130

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
my-git9 wants to merge 1 commit into
base: main
Choose a base branch
from
+44 −57
Open

[zh-cn]sync cron-jobs pods/_index daemonset #56130

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 21 additions & 15 deletions content/zh-cn/docs/concepts/workloads/controllers/cron-jobs.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -54,17 +54,18 @@ CronJob 有所限制，也比较特殊。

<!--
When the control plane creates new Jobs and (indirectly) Pods for a CronJob, the `.metadata.name`
of the CronJob is part of the basis for naming those Pods. The name of a CronJob must be a valid
of the CronJob is part of the basis for naming those Pods. The name of a CronJob must be a valid
[DNS subdomain](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)
value, but this can produce unexpected results for the Pod hostnames. For best compatibility,
value, but this can produce unexpected results for the Pod hostnames. For best compatibility,
the name should follow the more restrictive rules for a
[DNS label](/docs/concepts/overview/working-with-objects/names#dns-label-names).
Even when the name is a DNS subdomain, the name must be no longer than 52
characters. This is because the CronJob controller will automatically append
characters. This is because the CronJob controller will automatically append
11 characters to the name you provide and there is a constraint that the
length of a Job name is no more than 63 characters.
-->
当控制平面为 CronJob 创建新的 Job 和（间接）Pod 时，CronJob 的 `.metadata.name` 是命名这些 Pod 的部分基础。
当控制平面为 CronJob 创建新的 Job 和（间接）Pod 时，CronJob
的 `.metadata.name` 是命名这些 Pod 的部分基础。
CronJob 的名称必须是一个合法的
[DNS 子域](/zh-cn/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)值，
但这会对 Pod 的主机名产生意外的结果。为获得最佳兼容性，名称应遵循更严格的
Expand Down Expand Up @@ -121,7 +122,7 @@ The `.spec.schedule` field is required. The value of that field follows the [Cro
# │ │ ┌───────────── 月的某天 (1 - 31)
# │ │ │ ┌───────────── 月份 (1 - 12)
# │ │ │ │ ┌───────────── 周的某天 (0 - 6)（周日到周六）
# │ │ │ │ │ 或者是 sun，mon，tue，web，thu，fri，sat
# │ │ │ │ │ 或者是 sun、mon、tue、web、thu、fri、sat
# │ │ │ │ │
# │ │ │ │ │
# * * * * *
Expand Down Expand Up @@ -185,7 +186,8 @@ Other than the standard syntax, some macros like `@monthly` can also be used:
<!--
To generate CronJob schedule expressions, you can also use web tools like [crontab.guru](https://crontab.guru/).
-->
为了生成 CronJob 时间表的表达式，你还可以使用 [crontab.guru](https://crontab.guru/) 这类 Web 工具。
为了生成 CronJob 时间表的表达式，你还可以使用 [crontab.guru](https://crontab.guru/)
这类 Web 工具。

<!--
### Job template
Expand Down Expand Up @@ -259,7 +261,7 @@ The spec may specify only one of the following concurrency policies:
### 并发性规则 {#concurrency-policy}

`.spec.concurrencyPolicy` 字段也是可选的。它声明了 CronJob 创建的 Job 执行时发生重叠如何处理。
spec 仅能声明下列规则中的一种：
`spec` 仅能声明下列规则中的一种：

<!--
* `Allow` (default): The CronJob allows concurrently running Jobs
Expand All @@ -279,7 +281,8 @@ spec 仅能声明下列规则中的一种：
Note that concurrency policy only applies to the Jobs created by the same CronJob.
If there are multiple CronJobs, their respective Jobs are always allowed to run concurrently.
-->
请注意，并发性规则仅适用于相同 CronJob 创建的 Job。如果有多个 CronJob，它们相应的 Job 总是允许并发执行的。
请注意，并发性规则仅适用于相同 CronJob 创建的 Job。
如果有多个 CronJob，它们相应的 Job 总是允许并发执行的。

<!--
### Schedule suspension
Expand All @@ -301,15 +304,17 @@ scheduled, but the CronJob controller does not start the Jobs to run the tasks)
you unsuspend the CronJob.
-->
如果你将此字段设置为 `true`，后续发生的执行都会被挂起
（这些任务仍然在调度中，但 CronJob 控制器不会启动这些 Job 来运行任务），直到你取消挂起 CronJob 为止。
（这些任务仍然在调度中，但 CronJob 控制器不会启动这些 Job 来运行任务），
直到你取消挂起 CronJob 为止。

{{< caution >}}
<!--
Executions that are suspended during their scheduled time count as missed Jobs.
When `.spec.suspend` changes from `true` to `false` on an existing CronJob without a
[starting deadline](#starting-deadline), the missed Jobs are scheduled immediately.
-->
在调度时间内挂起的执行都会被统计为错过的 Job。当现有的 CronJob 将 `.spec.suspend` 从 `true` 改为 `false` 时，
在调度时间内挂起的执行都会被统计为错过的 Job。
当现有的 CronJob 将 `.spec.suspend` 从 `true` 改为 `false` 时，
且没有[开始的最后期限](#starting-deadline)，错过的 Job 会被立即调度。
{{< /caution >}}

Expand Down Expand Up @@ -408,7 +413,7 @@ That is, the CronJob does _not_ update existing Jobs, even if those remain runni
按照设计，CronJob 包含一个用于**新** Job 的模板。
如果你修改现有的 CronJob，你所做的更改将应用于修改完成后开始运行的新任务。
已经开始的任务（及其 Pod）将继续运行而不会发生任何变化。
也就是说，CronJob **不** 会更新现有任务，即使这些任务仍在运行。
也就是说，CronJob **不**会更新现有任务，即使这些任务仍在运行。

<!--
### Job creation
Expand All @@ -423,7 +428,7 @@ the Jobs that you define should be _idempotent_.

CronJob 根据其计划编排，在每次该执行任务的时候大约会创建一个 Job。
我们之所以说 "大约"，是因为在某些情况下，可能会创建两个 Job，或者不会创建任何 Job。
我们试图使这些情况尽量少发生，但不能完全杜绝。因此，Job 应该是 **幂等的**。
我们试图使这些情况尽量少发生，但不能完全杜绝。因此，Job 应该是**幂等的**。

<!--
Starting with Kubernetes v1.32, CronJobs apply an annotation
Expand Down Expand Up @@ -525,13 +530,14 @@ CronJob 仅负责创建与其调度时间相匹配的 Job，而 Job 又负责管
of a CronJob manifest,
see [Running automated tasks with CronJobs](/docs/tasks/job/automated-tasks-with-cron-jobs/).
* `CronJob` is part of the Kubernetes REST API.
Read the {{< api-reference page="workload-resources/cron-job-v1" >}}
Read the {{< api-reference page="batch/cron-job-v1" >}}
API reference for more details.
-->
* 了解 CronJob 所依赖的 [Pod](/zh-cn/docs/concepts/workloads/pods/) 与
[Job](/zh-cn/docs/concepts/workloads/controllers/job/) 的概念。
* 阅读 CronJob `.spec.schedule` 字段的详细[格式](https://pkg.go.dev/github.com/robfig/cron/v3#hdr-CRON_Expression_Format)。
* 阅读 CronJob `.spec.schedule`
字段的详细[格式](https://pkg.go.dev/github.com/robfig/cron/v3#hdr-CRON_Expression_Format)。
* 有关创建和使用 CronJob 的说明及 CronJob 清单的示例，
请参见[使用 CronJob 运行自动化任务](/zh-cn/docs/tasks/job/automated-tasks-with-cron-jobs/)。
* `CronJob` 是 Kubernetes REST API 的一部分，
阅读 {{< api-reference page="workload-resources/cron-job-v1" >}} API 参考了解更多细节。
阅读 {{< api-reference page="batch/cron-job-v1" >}} API 参考了解更多细节。
6 changes: 3 additions & 3 deletions content/zh-cn/docs/concepts/workloads/controllers/daemonset.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -443,7 +443,7 @@ running such processes via a DaemonSet:
- Ability to monitor and manage logs for daemons in the same way as applications.
- Same config language and tools (e.g. Pod templates, `kubectl`) for daemons and applications.
- Running daemons in containers with resource limits increases isolation between daemons from app
containers. However, this can also be accomplished by running the daemons in a container but not in a Pod.
containers. However, this can also be accomplished by running the daemons in a container but not in a Pod.
-->
直接在节点上启动守护进程（例如使用 `init`、`upstartd` 或 `systemd`）的做法当然是可行的。
不过，基于 DaemonSet 来运行这些进程有如下一些好处：
Expand Down Expand Up @@ -530,7 +530,7 @@ DaemonSet 运行的组件。这个 DaemonSet 组件确保它所在的节点的
* Learn about [device plugins](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) and
[add ons](/docs/concepts/cluster-administration/addons/), which often run as DaemonSets.
* `DaemonSet` is a top-level resource in the Kubernetes REST API.
Read the {{< api-reference page="workload-resources/daemon-set-v1" >}}
Read the {{< api-reference page="apps/daemon-set-v1" >}}
object definition to understand the API for daemon sets.
-->
* 了解 [Pod](/zh-cn/docs/concepts/workloads/pods):
Expand All @@ -542,5 +542,5 @@ DaemonSet 运行的组件。这个 DaemonSet 组件确保它所在的节点的
* 理解 [Kubernetes 如何将 Pod 分配给节点](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/)。
* 了解[设备插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)和
[扩展（Addons）](/zh-cn/docs/concepts/cluster-administration/addons/)，它们常以 DaemonSet 运行。
* `DaemonSet` 是 Kubernetes REST API 中的顶级资源。阅读 {{< api-reference page="workload-resources/daemon-set-v1" >}}
* `DaemonSet` 是 Kubernetes REST API 中的顶级资源。阅读 {{< api-reference page="apps/daemon-set-v1" >}}
对象定义理解关于该资源的 API。
59 changes: 20 additions & 39 deletions content/zh-cn/docs/concepts/workloads/pods/_index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -108,7 +108,7 @@ Kubernetes 集群中的 Pod 主要有两种用法：
Grouping multiple co-located and co-managed containers in a single Pod is a
relatively advanced use case. You should use this pattern only in specific
instances in which your containers are tightly coupled.

You don't need to run multiple containers to provide replication (for resilience
or capacity); if you need multiple replicas, see
[Workload management](/docs/concepts/workloads/controllers/).
Expand Down Expand Up @@ -143,21 +143,21 @@ kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml
Pods are generally not created directly and are created using workload resources.
See [Working with Pods](#working-with-pods) for more information on how Pods are used
with workload resources.

### Workload resources for managing pods
-->
Pod 通常不是直接创建的，而是使用工作负载资源创建的。
有关如何将 Pod 用于工作负载资源的更多信息，请参阅[使用 Pod](#working-with-pods)。

### 用于管理 Pod 的工作负载资源 {#workload-resources-for-managing-pods}

<!--
### Workload resources for managing pods

Usually you don't need to create Pods directly, even singleton Pods. Instead,
create them using workload resources such as {{< glossary_tooltip text="Deployment"
term_id="deployment" >}} or {{< glossary_tooltip text="Job" term_id="job" >}}.
If your Pods need to track state, consider the
{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} resource.
-->
### 用于管理 Pod 的工作负载资源 {#workload-resources-for-managing-pods}

通常你不需要直接创建 Pod，甚至单实例 Pod。相反，你会使用诸如
{{< glossary_tooltip text="Deployment" term_id="deployment" >}} 或
{{< glossary_tooltip text="Job" term_id="job" >}} 这类工作负载资源来创建 Pod。
Expand Down Expand Up @@ -205,8 +205,8 @@ the Pod is *evicted* for lack of resources, or the node fails.

你很少在 Kubernetes 中直接创建一个个的 Pod，甚至是单实例（Singleton）的 Pod。
这是因为 Pod 被设计成了相对临时性的、用后即抛的一次性实体。
当 Pod 由你或者间接地由{{< glossary_tooltip text="控制器" term_id="controller" >}}
创建时，它被调度在集群中的{{< glossary_tooltip text="节点" term_id="node" >}}上运行。
当 Pod 由你或者间接地由{{< glossary_tooltip text="控制器" term_id="controller" >}}创建时，
它被调度在集群中的{{< glossary_tooltip text="节点" term_id="node" >}}上运行。
Pod 会保持在该节点上运行，直到 Pod 结束执行、Pod 对象被删除、Pod 因资源不足而被**驱逐**或者节点失效为止。

{{< note >}}
Expand All @@ -223,7 +223,7 @@ Pod 不是进程，而是容器运行的环境。
<!--
The name of a Pod must be a valid
[DNS subdomain](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)
value, but this can produce unexpected results for the Pod hostname. For best compatibility,
value, but this can produce unexpected results for the Pod hostname. For best compatibility,
the name should follow the more restrictive rules for a
[DNS label](/docs/concepts/overview/working-with-objects/names#dns-label-names).
-->
Expand All @@ -244,7 +244,8 @@ You should set the `.spec.os.name` field to either `windows` or `linux` to indic
which you want the pod to run. These two are the only operating systems supported for now by
Kubernetes. In the future, this list may be expanded.
-->
你应该将 `.spec.os.name` 字段设置为 `windows` 或 `linux` 以表示你希望 Pod 运行在哪个操作系统之上。
你应该将 `.spec.os.name` 字段设置为 `windows` 或 `linux`
以表示你希望 Pod 运行在哪个操作系统之上。
这两个是 Kubernetes 目前支持的操作系统。将来，这个列表可能会被扩充。

<!--
Expand Down Expand Up @@ -608,7 +609,8 @@ This behavior applies to:
- **容器镜像**：`ContainerStatus.ImageID` 反映的是上一代的镜像，直到新的镜像被拉取并且容器被更新。
- **实际资源**：在扩缩进行中，实际使用的资源仍然属于上一代请求的资源。
- **容器状态**：在扩缩进行中，需要重启策略反映的是上一代的请求。
- **activeDeadlineSeconds** & **terminationGracePeriodSeconds** & **deletionTimestamp**：这些字段对 Pod 状态的影响是之前观察到的规约的结果。
- **activeDeadlineSeconds** & **terminationGracePeriodSeconds** & **deletionTimestamp**：这些字段对
Pod 状态的影响是之前观察到的规约的结果。

<!--
## Resource sharing and communication
Expand Down Expand Up @@ -660,7 +662,7 @@ Pod 中的每个容器共享网络名字空间，包括 IP 地址和网络端口
Within a Pod, containers share an IP address and port space, and
can find each other via `localhost`. The containers in a Pod can also communicate
with each other using standard inter-process communications like SystemV semaphores
or POSIX shared memory. Containers in different Pods have distinct IP addresses
or POSIX shared memory. Containers in different Pods have distinct IP addresses
and can not communicate by OS-level IPC without special configuration.
Containers that want to interact with a container running in a different Pod can
use IP networking to communicate.
Expand Down Expand Up @@ -766,7 +768,6 @@ CPU 限制通过 CPU 节流机制来强制执行。
内核会通过内存不足（OOM）机制终止进程。

{{< note >}}

<!--
Setting CPU limits involves a trade-off. CPU limits help prevent noisy neighbor
problems where a single workload starves others on the same node. This is
Expand All @@ -781,7 +782,6 @@ CPU 限制有助于防止“嘈杂邻居”问题，即同一节点上的单个
然而，即使节点有剩余的 CPU 资源，CPU 限制也可能导致性能下降，
从而降低对延迟敏感的工作负载的性能。
是否设置 CPU 限制取决于你的环境、工作负载特性和隔离要求。

{{< /note >}}

<!--
Expand Down Expand Up @@ -818,29 +818,9 @@ using the kubelet to supervise the individual [control plane components](/docs/c
来管理各个独立的[控制面组件](/zh-cn/docs/concepts/architecture/#control-plane-components)。

<!--
The kubelet automatically tries to create a {{< glossary_tooltip text="mirror Pod" term_id="mirror-pod" >}}
on the Kubernetes API server for each static Pod.
This means that the Pods running on a node are visible on the API server,
but cannot be controlled from there. See the guide [Create static Pods](/docs/tasks/configure-pod-container/static-pod)
for more information.
-->
`kubelet` 自动尝试为每个静态 Pod 在 Kubernetes API
服务器上创建一个{{< glossary_tooltip text="镜像 Pod" term_id="mirror-pod" >}}。
这意味着在节点上运行的 Pod 在 API 服务器上是可见的，但不可以通过 API 服务器来控制。
有关更多信息，请参阅[创建静态 Pod](/zh-cn/docs/tasks/configure-pod-container/static-pod) 的指南。

{{< note >}}
<!--
The `spec` of a static Pod cannot refer to other API objects
(e.g., {{< glossary_tooltip text="ServiceAccount" term_id="service-account" >}},
{{< glossary_tooltip text="ConfigMap" term_id="configmap" >}},
{{< glossary_tooltip text="Secret" term_id="secret" >}}, etc).
For details, see [Static Pods](/docs/concepts/workloads/pods/static-pods/).
-->
静态 Pod 的 `spec` 不能引用其他的 API 对象（例如：
{{< glossary_tooltip text="ServiceAccount" term_id="service-account" >}}、
{{< glossary_tooltip text="ConfigMap" term_id="configmap" >}}、
{{< glossary_tooltip text="Secret" term_id="secret" >}} 等）。
{{< /note >}}
详情见[静态 Pod](/zh-cn/docs/concepts/workloads/pods/static-pods/)。

<!--
## Pods with multiple containers {#how-pods-manage-multiple-containers}
Expand Down Expand Up @@ -926,7 +906,8 @@ Containers that you explicitly define as sidecar containers
start up before the main application Pod and remain running until the Pod is
shut down.
-->
启用 `SidecarContainers` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)（默认启用）允许你为
启用 `SidecarContainers`
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)（默认启用）允许你为
Init 容器指定 `restartPolicy: Always`。
设置重启策略为 `Always` 会确保设置的容器被视为**边车**，
并在 Pod 的整个生命周期内保持运行。
Expand All @@ -948,7 +929,7 @@ in the Pod Lifecycle documentation.
## 容器探针 {#container-probes}

**Probe** 是由 kubelet 对容器执行的定期诊断。要执行诊断，kubelet 可以执行三种动作：

- `ExecAction`（借助容器运行时执行）
- `TCPSocketAction`（由 kubelet 直接检测）
- `HTTPGetAction`（由 kubelet 直接检测）
Expand All @@ -962,7 +943,7 @@ in the Pod Lifecycle documentation.
* Read about [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/)
and how you can use it to manage application availability during disruptions.
* Pod is a top-level resource in the Kubernetes REST API.
The {{< api-reference page="workload-resources/pod-v1" >}}
The {{< api-reference page="core/pod-v1" >}}
object definition describes the object in detail.
* [The Distributed System Toolkit: Patterns for Composite Containers](/blog/2015/06/the-distributed-system-toolkit-patterns/) explains common layouts for Pods with more than one container.
* Read about [Pod topology spread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/)
Expand All @@ -976,7 +957,7 @@ in the Pod Lifecycle documentation.
* 了解 [PodDisruptionBudget](/zh-cn/docs/concepts/workloads/pods/disruptions/)，
以及你可以如何利用它在出现干扰因素时管理应用的可用性。
* Pod 在 Kubernetes REST API 中是一个顶层资源。
{{< api-reference page="workload-resources/pod-v1" >}}
{{< api-reference page="core/pod-v1" >}}
对象的定义中包含了更多的细节信息。
* 博客[分布式系统工具箱：复合容器模式](/blog/2015/06/the-distributed-system-toolkit-patterns/)中解释了在同一
Pod 中包含多个容器时的几种常见布局。
Expand Down