Skip to content

Commit 08ad36d

Browse files
authored
Merge pull request #31752 from shawnhanx/pod
[zh] resync pod-lifecycle page
2 parents a35cecc + 253b02c commit 08ad36d

File tree

1 file changed

+119
-68
lines changed

1 file changed

+119
-68
lines changed

content/zh/docs/concepts/workloads/pods/pod-lifecycle.md

Lines changed: 119 additions & 68 deletions
Original file line numberDiff line numberDiff line change
@@ -107,7 +107,7 @@ created anew.
107107
如果 Pod 因为任何原因被删除,甚至某完全相同的替代 Pod 被创建时,
108108
这个相关的对象(例如这里的卷)也会被删除并重建。
109109

110-
{{< figure src="/images/docs/pod.svg" title="Pod 结构图例" width="50%" >}}
110+
{{< figure src="/images/docs/pod.svg" title="Pod 结构图例" class="diagram-medium" >}}
111111

112112
*一个包含多个容器的 Pod 中包含一个用来拉取文件的程序和一个 Web 服务器,
113113
均使用持久卷作为容器间共享的存储。*
@@ -153,7 +153,7 @@ Value | Description
153153
-->
154154
取值 | 描述
155155
:-----|:-----------
156-
`Pending`(悬决)| Pod 已被 Kubernetes 系统接受,但有一个或者多个容器尚未创建亦未运行。此阶段包括等待 Pod 被调度的时间和通过网络下载镜像的时间
156+
`Pending`(悬决)| Pod 已被 Kubernetes 系统接受,但有一个或者多个容器尚未创建亦未运行。此阶段包括等待 Pod 被调度的时间和通过网络下载镜像的时间
157157
`Running`(运行中) | Pod 已经绑定到了某个节点,Pod 中所有的容器都已被创建。至少有一个容器仍在运行,或者正处于启动或重启状态。
158158
`Succeeded`(成功) | Pod 中的所有容器都已成功终止,并且不会再重启。
159159
`Failed`(失败) | Pod 中的所有容器都已终止,并且至少有一个容器是因为失败终止。也就是说,容器以非 0 状态退出或者被系统终止。
@@ -300,14 +300,14 @@ Pod 有一个 PodStatus 对象,其中包含一个
300300
* `PodScheduled`: the Pod has been scheduled to a node.
301301
* `ContainersReady`: all containers in the Pod are ready.
302302
* `Initialized`: all [init containers](/docs/concepts/workloads/pods/init-containers/)
303-
have started successfully.
303+
have completed successfully.
304304
* `Ready`: the Pod is able to serve requests and should be added to the load
305305
balancing pools of all matching Services.
306306
-->
307307
* `PodScheduled`:Pod 已经被调度到某节点;
308308
* `ContainersReady`:Pod 中所有容器都已就绪;
309309
* `Initialized`:所有的 [Init 容器](/zh/docs/concepts/workloads/pods/init-containers/)
310-
都已成功启动
310+
都已成功完成
311311
* `Ready`:Pod 可以为请求提供服务,并且应该被添加到对应服务的负载均衡池中。
312312

313313
<!--
@@ -425,93 +425,145 @@ When a Pod's containers are Ready but at least one custom condition is missing o
425425
<!--
426426
## Container probes
427427
428-
A [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) is a diagnostic
428+
A _probe_ is a diagnostic
429429
performed periodically by the
430430
[kubelet](/docs/reference/command-line-tools-reference/kubelet/)
431-
on a Container. To perform a diagnostic,
432-
the kubelet calls a
433-
[Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core) implemented by
434-
the container. There are three types of handlers:
431+
on a container. To perform a diagnostic,
432+
the kubelet either executes code within the container, or makes
433+
a network request.
435434
-->
436435
## 容器探针 {#container-probes}
437436

438-
[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)
439-
是由 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 对容器执行的定期诊断。
440-
要执行诊断,kubelet 调用由容器实现的
441-
[Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)
442-
(处理程序)。有三种类型的处理程序:
437+
probe 是由 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 对容器执行的定期诊断。
438+
要执行诊断,kubelet 既可以在容器内执行代码,也可以发出一个网络请求。
443439

444440
<!--
445-
* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core):
446-
Executes a specified command inside the container. The diagnostic
447-
is considered successful if the command exits with a status code of 0.
448-
449-
* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core):
450-
Performs a TCP check against the Pod's IP address on
451-
a specified port. The diagnostic is considered successful if the port is open.
441+
### Check mechanisms {#probe-check-methods}
452442
453-
* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core):
454-
Performs an HTTP `GET` request against the Pod's IP
455-
address on a specified port and path. The diagnostic is considered successful
456-
if the response has a status code greater than or equal to 200 and less than 400.
457-
-->
458-
- [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core):
459-
在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
443+
There are four different ways to check a container using a probe.
444+
Each probe must define exactly one of these four mechanisms:
460445
461-
- [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core):
462-
对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开,则诊断被认为是成功的。
446+
`exec`
447+
: Executes a specified command inside the container. The diagnostic
448+
is considered successful if the command exits with a status code of 0.
463449
464-
- [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core):
465-
对容器的 IP 地址上指定端口和路径执行 HTTP Get 请求。如果响应的状态码大于等于 200
450+
`grpc`
451+
: Performs a remote procedure call using [gRPC](https://grpc.io/).
452+
The target should implement
453+
[gRPC health checks](https://grpc.io/grpc/core/md_doc_health-checking.html).
454+
The diagnostic is considered successful if the `status`
455+
of the response is `SERVING`.
456+
gRPC probes are an alpha feature and are only available if you
457+
enable the `GRPCContainerProbe`
458+
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
459+
460+
`httpGet`
461+
: Performs an HTTP `GET` request against the Pod's IP
462+
address on a specified port and path. The diagnostic is
463+
considered successful if the response has a status code
464+
greater than or equal to 200 and less than 400.
465+
466+
`tcpSocket`
467+
: Performs a TCP check against the Pod's IP address on
468+
a specified port. The diagnostic is considered successful if
469+
the port is open. If the remote system (the container) closes
470+
the connection immediately after it opens, this counts as healthy.
471+
472+
-->
473+
### 检查机制 {#probe-check-methods}
474+
475+
使用探针来检查容器有四种不同的方法。
476+
每个探针都必须准确定义为这四种机制中的一种:
477+
478+
`exec`
479+
: 在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
480+
481+
`grpc`
482+
: 使用 [gRPC](https://grpc.io/) 执行一个远程过程调用。
483+
目标应该实现
484+
[gRPC健康检查](https://grpc.io/grpc/core/md_doc_health-checking.html)
485+
如果响应的状态是 "SERVING",则认为诊断成功。
486+
gRPC 探针是一个 alpha 特性,只有在你启用了
487+
"GRPCContainerProbe" [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gate/)时才能使用。
488+
489+
`httpGet`
490+
: 对容器的 IP 地址上指定端口和路径执行 HTTP `GET` 请求。如果响应的状态码大于等于 200
466491
且小于 400,则诊断被认为是成功的。
467492

493+
`tcpSocket`
494+
: 对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开,则诊断被认为是成功的。
495+
如果远程系统(容器)在打开连接后立即将其关闭,这算作是健康的。
496+
468497
<!--
498+
### Probe outcome
469499
Each probe has one of three results:
470500
471-
* `Success`: The container passed the diagnostic.
472-
* `Failure`: The container failed the diagnostic.
473-
* `Unknown`: The diagnostic failed, so no action should be taken.
501+
`Success`
502+
: The container passed the diagnostic.
503+
504+
`Failure`
505+
: The container failed the diagnostic.
506+
507+
`Unknown`
508+
: The diagnostic failed (no action should be taken, and the kubelet
509+
will make further checks).
510+
474511
-->
512+
### 探测结果 {#probe-outcome}
475513
每次探测都将获得以下三种结果之一:
476514

477-
- `Success`(成功):容器通过了诊断。
478-
- `Failure`(失败):容器未通过诊断。
479-
- `Unknown`(未知):诊断失败,因此不会采取任何行动。
515+
`Success`(成功)
516+
: 容器通过了诊断。
517+
518+
`Failure`(失败)
519+
: 容器未通过诊断。
520+
521+
`Unknown`(未知)
522+
: 诊断失败,因此不会采取任何行动。
480523

481524
<!--
525+
### Types of probe
482526
The kubelet can optionally perform and react to three kinds of probes on running
483527
containers:
484528
-->
529+
### 探测类型 {#types-of-probe}
485530
针对运行中的容器,`kubelet` 可以选择是否执行以下三种探针,以及如何针对探测结果作出反应:
486531

487532
<!--
488-
* `livenessProbe`: Indicates whether the container is running. If
489-
the liveness probe fails, the kubelet kills the container, and the container
490-
is subjected to its [restart policy](#restart-policy). If a Container does not
491-
provide a liveness probe, the default state is `Success`.
533+
`livenessProbe`
534+
: Indicates whether the container is running. If
535+
the liveness probe fails, the kubelet kills the container, and the container
536+
is subjected to its [restart policy](#restart-policy). If a container does not
537+
provide a liveness probe, the default state is `Success`.
492538
493-
* `readinessProbe`: Indicates whether the container is ready to respond to requests.
494-
If the readiness probe fails, the endpoints controller removes the Pod's IP
495-
address from the endpoints of all Services that match the Pod. The default
496-
state of readiness before the initial delay is `Failure`. If a Container does
497-
not provide a readiness probe, the default state is `Success`.
539+
`readinessProbe`
540+
: Indicates whether the container is ready to respond to requests.
541+
If the readiness probe fails, the endpoints controller removes the Pod's IP
542+
address from the endpoints of all Services that match the Pod. The default
543+
state of readiness before the initial delay is `Failure`. If a container does
544+
not provide a readiness probe, the default state is `Success`.
498545
499-
* `startupProbe`: Indicates whether the application within the container is started.
500-
All other probes are disabled if a startup probe is provided, until it succeeds.
501-
If the startup probe fails, the kubelet kills the container, and the container
502-
is subjected to its [restart policy](#restart-policy). If a Container does not
503-
provide a startup probe, the default state is `Success`.
546+
`startupProbe`
547+
: Indicates whether the application within the container is started.
548+
All other probes are disabled if a startup probe is provided, until it succeeds.
549+
If the startup probe fails, the kubelet kills the container, and the container
550+
is subjected to its [restart policy](#restart-policy). If a container does not
551+
provide a startup probe, the default state is `Success`.
504552
-->
505-
- `livenessProbe`:指示容器是否正在运行。如果存活态探测失败,则 kubelet 会杀死容器,
553+
554+
`livenessProbe`
555+
: 指示容器是否正在运行。如果存活态探测失败,则 kubelet 会杀死容器,
506556
并且容器将根据其[重启策略](#restart-policy)决定未来。如果容器不提供存活探针,
507557
则默认状态为 `Success`
508558

509-
- `readinessProbe`:指示容器是否准备好为请求提供服务。如果就绪态探测失败,
559+
`readinessProbe`
560+
: 指示容器是否准备好为请求提供服务。如果就绪态探测失败,
510561
端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。
511562
初始延迟之前的就绪态的状态值默认为 `Failure`
512563
如果容器不提供就绪态探针,则默认状态为 `Success`
513564

514-
- `startupProbe`: 指示容器中的应用是否已经启动。如果提供了启动探针,则所有其他探针都会被
565+
`startupProbe`
566+
: 指示容器中的应用是否已经启动。如果提供了启动探针,则所有其他探针都会被
515567
禁用,直到此探针成功为止。如果启动探测失败,`kubelet` 将杀死容器,而容器依其
516568
[重启策略](#restart-policy)进行重启。
517569
如果容器没有提供启动探测,则默认状态为 `Success`
@@ -524,9 +576,9 @@ see [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod
524576
[配置存活态、就绪态和启动探针](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)
525577

526578
<!--
527-
### When should you use a liveness probe?
579+
#### When should you use a liveness probe?
528580
-->
529-
### 何时该使用存活态探针? {#when-should-you-use-a-liveness-probe}
581+
#### 何时该使用存活态探针? {#when-should-you-use-a-liveness-probe}
530582

531583
{{< feature-state for_k8s_version="v1.0" state="stable" >}}
532584

@@ -546,9 +598,9 @@ specify a liveness probe, and specify a `restartPolicy` of Always or OnFailure.
546598
并指定`restartPolicy` 为 "`Always`" 或 "`OnFailure`"。
547599

548600
<!--
549-
### When should you use a readiness probe?
601+
#### When should you use a readiness probe?
550602
-->
551-
### 何时该使用就绪态探针? {#when-should-you-use-a-readiness-probe}
603+
#### 何时该使用就绪态探针? {#when-should-you-use-a-readiness-probe}
552604

553605
{{< feature-state for_k8s_version="v1.0" state="stable" >}}
554606

@@ -606,9 +658,9 @@ to stop.
606658
{{< /note >}}
607659

608660
<!--
609-
### When should you use a startup probe?
661+
#### When should you use a startup probe?
610662
-->
611-
### 何时该使用启动探针? {#when-should-you-use-a-startup-probe}
663+
#### 何时该使用启动探针? {#when-should-you-use-a-startup-probe}
612664

613665
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
614666

@@ -852,21 +904,20 @@ This avoids a resource leak as Pods are created and terminated over time.
852904

853905
<!--
854906
* Get hands-on experience
855-
[attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
907+
[attaching handlers to container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
856908
857909
* Get hands-on experience
858910
[configuring Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
859911
860912
* Learn more about [container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/).
861913
862-
* For detailed information about Pod / Container status in the API, see [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)
863-
and
864-
[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core).
914+
* For detailed information about Pod and container status in the API, see
915+
the API reference documentation covering
916+
[`.status`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodStatus) for Pod.
865917
-->
866918
* 动手实践[为容器生命周期时间关联处理程序](/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)
867919
* 动手实践[配置存活态、就绪态和启动探针](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)
868920
* 进一步了解[容器生命周期回调](/zh/docs/concepts/containers/container-lifecycle-hooks/)
869-
* 关于 API 中定义的有关 Pod/容器的详细规范信息,
870-
可参阅 [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)
871-
[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)。
921+
* 关于 API 中定义的有关 Pod 和容器状态的详细规范信息,
922+
可参阅 API 参考文档中 Pod 的 [`.status`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodStatus) 字段。
872923

0 commit comments

Comments
 (0)