From dd340133968d50decc7d6a3729168d018208c64c Mon Sep 17 00:00:00 2001 From: Sean Wei Date: Sun, 29 May 2022 17:47:00 +0800 Subject: [PATCH] [zh] Sync workloads --- .../concepts/workloads/controllers/job.md | 93 +++++++---- .../workloads/controllers/replicaset.md | 151 +++++++++--------- 2 files changed, 137 insertions(+), 107 deletions(-) diff --git a/content/zh/docs/concepts/workloads/controllers/job.md b/content/zh/docs/concepts/workloads/controllers/job.md index 0a1c6b484d..0c90de9c31 100644 --- a/content/zh/docs/concepts/workloads/controllers/job.md +++ b/content/zh/docs/concepts/workloads/controllers/job.md @@ -33,6 +33,9 @@ The Job object will start a new Pod if the first Pod fails or is deleted (for ex due to a node hardware failure or a node reboot). You can also use a Job to run multiple Pods in parallel. + +If you want to run a Job (either a single task, or several in parallel) on a schedule, +see [CronJob](/docs/concepts/workloads/controllers/cron-jobs/). --> Job 会创建一个或者多个 Pods，并将继续重试 Pods 的执行，直到指定数量的 Pods 成功终止。 随着 Pods 成功结束，Job 跟踪记录成功完成的 Pods 个数。 @@ -46,7 +49,11 @@ Job 会创建一个或者多个 Pods，并将继续重试 Pods 的执行，直 你也可以使用 Job 以并行的方式运行多个 Pod。 +如果你想按某种排期表（Schedule）运行 Job（单个任务或多个并行任务），请参阅 +[CronJob](/docs/concepts/workloads/controllers/cron-jobs/)。 + + + 你可以使用下面的命令来运行此示例： ```shell kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml ``` - + + 输出类似于： ``` job.batch/pi created ``` - + 使用 `kubectl` 来检查 Job 的状态： ```shell kubectl describe jobs/pi ``` - + + 输出类似于： ``` @@ -131,7 +148,10 @@ To list all the Pods that belong to a Job in a machine readable form, you can us pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}') echo $pods ``` - + + 输出类似于： ``` @@ -139,7 +159,7 @@ pi-5rwd7 ``` + 输出类似于： ``` 3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901 ``` + -## 编写 Job 规约 +## 编写 Job 规约 {#writing-a-job-spec} 与 Kubernetes 中其他资源的配置类似，Job 也需要 `apiVersion`、`kind` 和 `metadata` 字段。 Job 的名字必须是合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 -Job 配置还需要一个[`.spec` 节](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。 +Job 配置还需要一个 [`.spec` 节](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。 -### Pod 模版 +### Pod 模版 {#pod-template} Job 的 `.spec` 中只有 `.spec.template` 是必需的字段。 @@ -195,7 +218,7 @@ Job 的 `.spec` 中只有 `.spec.template` 是必需的字段。 完全相同，只是其中不再需要 `apiVersion` 或 `kind` 字段。 除了作为 Pod 所必需的字段之外，Job 中的 Pod 模版必需设置合适的标签 -（参见[Pod 选择算符](#pod-selector)）和合适的重启策略。 +（参见 [Pod 选择算符](#pod-selector)）和合适的重启策略。 Job 中 Pod 的 [`RestartPolicy`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 只能设置为 `Never` 或 `OnFailure` 之一。 @@ -219,6 +242,7 @@ There are three main types of task suitable to run as a Job: ### Job 的并行执行 {#parallel-jobs} 适合以 Job 形式来运行的任务主要有三种： + -## 处理 Pod 和容器失效 +## 处理 Pod 和容器失效 {#handling-pod-and-container-failures} Pod 中的容器可能因为多种不同原因失效，例如因为其中的进程退出时返回值非零， 或者容器因为超出内存约束而被杀死等等。 @@ -430,7 +454,7 @@ exponential back-off delay (10s, 20s, 40s ...) capped at six minutes. The back-off count is reset when a Job's Pod is deleted or successful without any other Pods for the Job failing around that time. --> -### Pod 回退失效策略 +### Pod 回退失效策略 {#pod-backoff-failure-policy} 在有些情形下，你可能希望 Job 在经历若干次重试之后直接进入失败状态，因为这很 可能意味着遇到了配置错误。 @@ -463,7 +487,7 @@ allows you to still view the logs of completed pods to check for errors, warning The job object also remains after it is completed so that you can view its status. It is up to the user to delete old jobs after noting their status. Delete the job with `kubectl` (e.g. `kubectl delete jobs/pi` or `kubectl delete -f ./job.yaml`). When you delete the job using `kubectl`, all the pods it created are deleted too. --> -## Job 终止与清理 +## Job 终止与清理 {#clean-up-finished-jobs-automatically} Job 完成时不会再创建新的 Pod，不过已有的 Pod [通常](#pod-backoff-failure-policy)也不会被删除。 保留这些 Pod 使得你可以查看已完成的 Pod 的日志输出，以便检查错误、警告 @@ -732,7 +756,7 @@ Job 被创建时，Job 控制器会马上开始执行 Pod 创建操作以满足 不过你可能想要暂时挂起 Job 执行，或启动处于挂起状态的job， 并拥有一个自定义控制器以后再决定什么时候开始。 - + + 输出类似于： ```yaml @@ -999,7 +1026,7 @@ the selector that the system normally generates for you automatically. 它们也会被名为 `new` 的 Job 所控制。 你需要在新 Job 中设置 `manualSelector: true`，因为你并未使用系统通常自动为你 -生成的选择算符。 +生成的选择算符。 ```yaml kind: Job @@ -1025,29 +1052,31 @@ mismatch. ### 使用 Finalizer 追踪 Job {#job-tracking-with-finalizers} {{< feature-state for_k8s_version="v1.23" state="beta" >}} {{< note >}} + 要使用该行为，你必须为 [API 服务器](/zh/docs/reference/command-line-tools-reference/kube-apiserver/) 和[控制器管理器](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) 启用 `JobTrackingWithFinalizers` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 默认是启用的。 + 启用后，控制面基于下述行为追踪新的 Job。在启用该特性之前创建的 Job 不受影响。 作为用户，你会看到的唯一区别是控制面对 Job 完成情况的跟踪更加准确。 {{< /note >}} @@ -1117,7 +1146,7 @@ Job 会重新创建新的 Pod 来替代已终止的 Pod。 -### 单个 Job 启动控制器 Pod +### 单个 Job 启动控制器 Pod {#single-job-starts-controller-pod} 另一种模式是用唯一的 Job 来创建 Pod，而该 Pod 负责启动其他 Pod，因此扮演了一种 后启动 Pod 的控制器的角色。 diff --git a/content/zh/docs/concepts/workloads/controllers/replicaset.md b/content/zh/docs/concepts/workloads/controllers/replicaset.md index ca92f8378e..0d64bce6c4 100644 --- a/content/zh/docs/concepts/workloads/controllers/replicaset.md +++ b/content/zh/docs/concepts/workloads/controllers/replicaset.md @@ -56,10 +56,11 @@ ReplicaSet 所获得的 Pod 都在其 ownerReferences 字段中包含了属主 R ReplicaSet 使用其选择算符来辨识要获得的 Pod 集合。如果某个 Pod 没有 -OwnerReference 或者其 OwnerReference 不是一个 +OwnerReference 或者其 OwnerReference 不是一个 {{< glossary_tooltip text="控制器" term_id="controller" >}}，且其匹配到 某 ReplicaSet 的选择算符，则该 Pod 立即被此 ReplicaSet 获得。 @@ -68,14 +69,14 @@ OwnerReference 或者其 OwnerReference 不是一个 A ReplicaSet ensures that a specified number of pod replicas are running at any given time. However, a Deployment is a higher-level concept that manages ReplicaSets and -provides declarative updates to pods along with a lot of other useful features. +provides declarative updates to Pods along with a lot of other useful features. Therefore, we recommend using Deployments instead of directly using ReplicaSets, unless you require custom update orchestration or don't require updates at all. This actually means that you may never need to manipulate ReplicaSet objects: use a Deployment instead, and define your application in the spec section. --> -## 何时使用 ReplicaSet +## 何时使用 ReplicaSet {#when-to-use-a-replicaset} ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行。 然而，Deployment 是一个更高级的概念，它管理 ReplicaSet，并向 Pod @@ -89,16 +90,16 @@ Deployment，并在 spec 部分定义你的应用。 -## 示例 +## 示例 {#example} {{< codenew file="controllers/frontend.yaml" >}} 将此清单保存到 `frontend.yaml` 中，并将其提交到 Kubernetes 集群， -应该就能创建 yaml 文件所定义的 ReplicaSet 及其管理的 Pod。 +就能创建 yaml 文件所定义的 ReplicaSet 及其管理的 Pod。 ```shell @@ -139,25 +140,25 @@ And you will see output similar to: 你会看到类似如下的输出： ``` -Name: frontend -Namespace: default -Selector: tier=frontend -Labels: app=guestbook - tier=frontend +Name: frontend +Namespace: default +Selector: tier=frontend +Labels: app=guestbook + tier=frontend Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"apps/v1","kind":"ReplicaSet","metadata":{"annotations":{},"labels":{"app":"guestbook","tier":"frontend"},"name":"frontend",... -Replicas: 3 current / 3 desired -Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed +Replicas: 3 current / 3 desired +Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed Pod Template: - Labels: tier=frontend + Labels: tier=frontend Containers: php-redis: - Image: gcr.io/google_samples/gb-frontend:v3 + Image: gcr.io/google_samples/gb-frontend:v3 Port: Host Port: Environment: - Mounts: - Volumes: + Mounts: + Volumes: Events: Type Reason Age From Message ---- ------ ---- ---- ------- @@ -226,22 +227,15 @@ metadata: -## 非模板 Pod 的获得 +## 非模板 Pod 的获得 {#non-template-pod-acquisitions} 尽管你完全可以直接创建裸的 Pods，强烈建议你确保这些裸的 Pods 并不包含可能与你 的某个 ReplicaSet 的选择算符相匹配的标签。原因在于 ReplicaSet 并不仅限于拥有 @@ -288,7 +282,7 @@ The output shows that the new Pods are either already terminated, or in the proc --> 输出显示新的 Pods 或者已经被终止，或者处于终止过程中： -```shell +``` NAME READY STATUS RESTARTS AGE frontend-b2zdv 1/1 Running 0 10m frontend-vcmts 1/1 Running 0 10m @@ -339,10 +333,13 @@ pod1 1/1 Running 0 36s pod2 1/1 Running 0 36s ``` + 采用这种方式，一个 ReplicaSet 中可以包含异质的 Pods 集合。 -## 编写 ReplicaSet 的 spec +## 编写 ReplicaSet 的清单 {#writing-a-replicaset-manifest} 与所有其他 Kubernetes API 对象一样，ReplicaSet 也需要 `apiVersion`、`kind`、和 `metadata` 字段。 对于 ReplicaSets 而言，其 `kind` 始终是 ReplicaSet。 @@ -360,7 +357,8 @@ A ReplicaSet also needs a [`.spec` section](https://git.k8s.io/community/contrib ReplicaSet 对象的名称必须是合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 -ReplicaSet 也需要 [`.spec`](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) +ReplicaSet 也需要 +[`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 部分。 -### Pod 模版 +### Pod 模版 {#pod-template} -`.spec.template` 是一个[Pod 模版](/zh/docs/concepts/workloads/pods/#pod-templates)， +`.spec.template` 是一个 [Pod 模版](/zh/docs/concepts/workloads/pods/#pod-templates)， 要求设置标签。在 `frontend.yaml` 示例中，我们指定了标签 `tier: frontend`。 注意不要将标签与其他控制器的选择算符重叠，否则那些控制器会尝试收养此 Pod。 @@ -415,7 +413,7 @@ matchLabels: -对于设置了相同的 `.spec.selector`，但 +对于设置了相同的 `.spec.selector`，但 `.spec.template.metadata.labels` 和 `.spec.template.spec` 字段不同的 两个 ReplicaSet 而言，每个 ReplicaSet 都会忽略被另一个 ReplicaSet 所 创建的 Pods。 @@ -434,7 +432,7 @@ If you do not specify `.spec.replicas`, then it defaults to 1. 你可以通过设置 `.spec.replicas` 来指定要同时运行的 Pod 个数。 ReplicaSet 创建、删除 Pods 以与此值匹配。 -如果你没有指定 `.spec.replicas`, 那么默认值为 1。 +如果你没有指定 `.spec.replicas`，那么默认值为 1。 -## 使用 ReplicaSets +## 使用 ReplicaSets {#working-with-replicasets} -### 删除 ReplicaSet 和它的 Pod +### 删除 ReplicaSet 和它的 Pod {#deleting-a-replicaset-and-its-pods} 要删除 ReplicaSet 和它的所有 Pod，使用 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 命令。 默认情况下，[垃圾收集器](/zh/docs/concepts/workloads/controllers/garbage-collection/) 自动删除所有依赖的 Pod。 -当使用 REST API 或 `client-go` 库时，你必须在删除选项中将 `propagationPolicy` +当使用 REST API 或 `client-go` 库时，你必须在 `-d` 选项中将 `propagationPolicy` 设置为 `Background` 或 `Foreground`。例如： ```shell kubectl proxy --port=8080 curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \ - -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \ - -H "Content-Type: application/json" + -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \ + -H "Content-Type: application/json" ``` -### 只删除 ReplicaSet +### 只删除 ReplicaSet {#deleting-just-a-replicaset} 你可以只删除 ReplicaSet 而不影响它的 Pods，方法是使用 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) @@ -489,8 +489,8 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron @@ -502,16 +502,15 @@ To update Pods to a new spec in a controlled way, use a 资源，因为 ReplicaSet 并不直接支持滚动更新。 -### 将 Pod 从 ReplicaSet 中隔离 +### 将 Pod 从 ReplicaSet 中隔离 {#isolating-pods-from-a-replicaset} -可以通过改变标签来从 ReplicaSet 的目标集中移除 Pod。 +可以通过改变标签来从 ReplicaSet 中移除 Pod。 这种技术可以用来从服务中去除 Pod，以便进行排错、数据恢复等。 以这种方式移除的 Pod 将被自动替换（假设副本的数量没有改变）。 @@ -519,9 +518,9 @@ from service for debugging, data recovery, etc. Pods that are removed in this wa ### Scaling a ReplicaSet A ReplicaSet can be easily scaled up or down by simply updating the `.spec.replicas` field. The ReplicaSet controller -ensures that a desired number of pods with a matching label selector are available and operational. +ensures that a desired number of Pods with a matching label selector are available and operational. --> -### 缩放 RepliaSet +### 缩放 RepliaSet {#scaling-a-replicaset} 通过更新 `.spec.replicas` 字段，ReplicaSet 可以被轻松的进行缩放。ReplicaSet 控制器能确保匹配标签选择器的数量的 Pod 是可用的和可操作的。 @@ -551,7 +550,7 @@ prioritize scaling down pods based on the following general algorithm: [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) 被启用时，创建时间是按整数幂级来分组的）。 -如果以上比较结果都相同，则随机选择。 +如果以上比较结果都相同，则随机选择。 - 此机制实施时仅是尽力而为，并不能对 Pod 的删除顺序作出任何保证； - 用户应避免频繁更新注解值，例如根据某观测度量值来更新此注解值是应该避免的。 - 这样做会在 API 服务器上产生大量的 Pod 更新操作。 + 这样做会在 API 服务器上产生大量的 Pod 更新操作。 {{< /note >}} -#### 使用场景示例 +#### 使用场景示例 {#example-use-case} 同一应用的不同 Pods 可能其利用率是不同的。在对应用执行缩容操作时，可能 希望移除利用率较低的 Pods。为了避免频繁更新 Pods，应用应该在执行缩容 @@ -623,14 +622,14 @@ the down scaling; for example, the driver pod of a Spark deployment. 是可以起作用的。 -### ReplicaSet 作为水平的 Pod 自动缩放器目标 +### ReplicaSet 作为水平的 Pod 自动缩放器目标 {#replicaset-as-a-horizontal-pod-autoscaler-target} ReplicaSet 也可以作为 [水平的 Pod 缩放器 (HPA)](/zh/docs/tasks/run-application/horizontal-pod-autoscale/) @@ -642,7 +641,7 @@ ReplicaSet 也可以作为 将这个列表保存到 `hpa-rs.yaml` 并提交到 Kubernetes 集群，就能创建它所定义的 HPA，进而就能根据复制的 Pod 的 CPU 利用率对目标 ReplicaSet进行自动缩放。 @@ -655,7 +654,7 @@ kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml Alternatively, you can use the `kubectl autoscale` command to accomplish the same (and it's easier!) --> -或者，可以使用 `kubectl autoscale` 命令完成相同的操作。 (而且它更简单！) +或者，可以使用 `kubectl autoscale` 命令完成相同的操作。（而且它更简单！） ```shell kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50 @@ -664,7 +663,7 @@ kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50 -## ReplicaSet 的替代方案 +## ReplicaSet 的替代方案 {#alternatives-to-replicaset} -### Deployment （推荐） +### Deployment（推荐） {#deployment-recommended} [`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/) 是一个 可以拥有 ReplicaSet 并使用声明式方式在服务器端完成对 Pods 滚动更新的对象。 @@ -689,7 +688,7 @@ As such, it is recommended to use Deployments when you want ReplicaSets. Unlike the case where a user directly created Pods, a ReplicaSet replaces Pods that are deleted or terminated for any reason, such as in the case of node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, we recommend that you use a ReplicaSet even if your application requires only a single Pod. Think of it similarly to a process supervisor, only it supervises multiple Pods across multiple nodes instead of individual processes on a single node. A ReplicaSet delegates local container restarts to some agent on the node (for example, Kubelet or Docker). --> -### 裸 Pod +### 裸 Pod {#bare-pods} 与用户直接创建 Pod 的情况不同，ReplicaSet 会替换那些由于某些原因被删除或被终止的 Pod，例如在节点故障或破坏性的节点维护（如内核升级）的情况下。 @@ -713,9 +712,9 @@ Use a [`Job`](/docs/concepts/workloads/controllers/job/) instead of a ReplicaSet ### DaemonSet @@ -756,6 +755,8 @@ ReplicaSet 是 [ReplicationController](/zh/docs/concepts/workloads/controllers/r * 了解 [Pods](/zh/docs/concepts/workloads/pods)。 * 了解 [Deployments](/zh/docs/concepts/workloads/controllers/deployment/)。 * [使用 Deployment 运行一个无状态应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)，它依赖于 ReplicaSet。 -* `ReplicaSet` 是 Kubernetes REST API 中的顶级资源。阅读 {{< api-reference page="workload-resources/replica-set-v1" >}} - 对象定义理解关于该资源的 API。 -* 阅读[Pod 干扰预算（Disruption Budget）](/zh/docs/concepts/workloads/pods/disruptions/)，了解如何在干扰下运行高度可用的应用。 +* `ReplicaSet` 是 Kubernetes REST API 中的顶级资源。阅读 + {{< api-reference page="workload-resources/replica-set-v1" >}} + 对象定义理解关于该资源的 API。 +* 阅读 [Pod 干扰预算（Disruption Budget）](/zh/docs/concepts/workloads/pods/disruptions/)， + 了解如何在干扰下运行高度可用的应用。