From 1341984890fdb0b4ad39c95ea7161d3f42d9b629 Mon Sep 17 00:00:00 2001 From: "xin.li" Date: Tue, 16 Jun 2026 16:03:15 +0800 Subject: [PATCH] [zh-cn]sync cron-jobs pods/_index Signed-off-by: xin.li --- .../workloads/controllers/cron-jobs.md | 36 ++++++----- .../workloads/controllers/daemonset.md | 6 +- .../docs/concepts/workloads/pods/_index.md | 59 +++++++------------ 3 files changed, 44 insertions(+), 57 deletions(-) diff --git a/content/zh-cn/docs/concepts/workloads/controllers/cron-jobs.md b/content/zh-cn/docs/concepts/workloads/controllers/cron-jobs.md index 2dca71f6af9a5..0cd09d1860d1b 100644 --- a/content/zh-cn/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/zh-cn/docs/concepts/workloads/controllers/cron-jobs.md @@ -54,17 +54,18 @@ CronJob 有所限制，也比较特殊。 -当控制平面为 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 的主机名产生意外的结果。为获得最佳兼容性，名称应遵循更严格的 @@ -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 # │ │ │ │ │ # │ │ │ │ │ # * * * * * @@ -185,7 +186,8 @@ Other than the standard syntax, some macros like `@monthly` can also be used: -为了生成 CronJob 时间表的表达式，你还可以使用 [crontab.guru](https://crontab.guru/) 这类 Web 工具。 +为了生成 CronJob 时间表的表达式，你还可以使用 [crontab.guru](https://crontab.guru/) +这类 Web 工具。 -请注意，并发性规则仅适用于相同 CronJob 创建的 Job。如果有多个 CronJob，它们相应的 Job 总是允许并发执行的。 +请注意，并发性规则仅适用于相同 CronJob 创建的 Job。 +如果有多个 CronJob，它们相应的 Job 总是允许并发执行的。 如果你将此字段设置为 `true`，后续发生的执行都会被挂起 -（这些任务仍然在调度中，但 CronJob 控制器不会启动这些 Job 来运行任务），直到你取消挂起 CronJob 为止。 +（这些任务仍然在调度中，但 CronJob 控制器不会启动这些 Job 来运行任务）， +直到你取消挂起 CronJob 为止。 {{< caution >}} -在调度时间内挂起的执行都会被统计为错过的 Job。当现有的 CronJob 将 `.spec.suspend` 从 `true` 改为 `false` 时， +在调度时间内挂起的执行都会被统计为错过的 Job。 +当现有的 CronJob 将 `.spec.suspend` 从 `true` 改为 `false` 时， 且没有[开始的最后期限](#starting-deadline)，错过的 Job 会被立即调度。 {{< /caution >}} @@ -408,7 +413,7 @@ That is, the CronJob does _not_ update existing Jobs, even if those remain runni 按照设计，CronJob 包含一个用于**新** Job 的模板。 如果你修改现有的 CronJob，你所做的更改将应用于修改完成后开始运行的新任务。 已经开始的任务（及其 Pod）将继续运行而不会发生任何变化。 -也就是说，CronJob **不** 会更新现有任务，即使这些任务仍在运行。 +也就是说，CronJob **不**会更新现有任务，即使这些任务仍在运行。 * 了解 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 参考了解更多细节。 diff --git a/content/zh-cn/docs/concepts/workloads/controllers/daemonset.md b/content/zh-cn/docs/concepts/workloads/controllers/daemonset.md index ae4bf8454e047..1ffa07349c631 100644 --- a/content/zh-cn/docs/concepts/workloads/controllers/daemonset.md +++ b/content/zh-cn/docs/concepts/workloads/controllers/daemonset.md @@ -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 来运行这些进程有如下一些好处： @@ -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): @@ -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。 diff --git a/content/zh-cn/docs/concepts/workloads/pods/_index.md b/content/zh-cn/docs/concepts/workloads/pods/_index.md index 82c7c42c433ae..78610e2dcd6df 100644 --- a/content/zh-cn/docs/concepts/workloads/pods/_index.md +++ b/content/zh-cn/docs/concepts/workloads/pods/_index.md @@ -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/). @@ -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} - +### 用于管理 Pod 的工作负载资源 {#workload-resources-for-managing-pods} + 通常你不需要直接创建 Pod，甚至单实例 Pod。相反，你会使用诸如 {{< glossary_tooltip text="Deployment" term_id="deployment" >}} 或 {{< glossary_tooltip text="Job" term_id="job" >}} 这类工作负载资源来创建 Pod。 @@ -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 >}} @@ -223,7 +223,7 @@ Pod 不是进程，而是容器运行的环境。 @@ -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 目前支持的操作系统。将来，这个列表可能会被扩充。 -`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 >}} - -静态 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/)。 -启用 `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 的整个生命周期内保持运行。 @@ -948,7 +929,7 @@ in the Pod Lifecycle documentation. ## 容器探针 {#container-probes} **Probe** 是由 kubelet 对容器执行的定期诊断。要执行诊断，kubelet 可以执行三种动作： - + - `ExecAction`（借助容器运行时执行） - `TCPSocketAction`（由 kubelet 直接检测） - `HTTPGetAction`（由 kubelet 直接检测） @@ -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/) @@ -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 中包含多个容器时的几种常见布局。