@@ -107,7 +107,7 @@ created anew.
107
107
如果 Pod 因为任何原因被删除,甚至某完全相同的替代 Pod 被创建时,
108
108
这个相关的对象(例如这里的卷)也会被删除并重建。
109
109
110
- {{< figure src="/images/docs/pod.svg" title="Pod 结构图例" width="50% " >}}
110
+ {{< figure src="/images/docs/pod.svg" title="Pod 结构图例" class="diagram-medium " >}}
111
111
112
112
* 一个包含多个容器的 Pod 中包含一个用来拉取文件的程序和一个 Web 服务器,
113
113
均使用持久卷作为容器间共享的存储。*
@@ -153,7 +153,7 @@ Value | Description
153
153
-->
154
154
取值 | 描述
155
155
:-----|:-----------
156
- ` Pending ` (悬决)| Pod 已被 Kubernetes 系统接受,但有一个或者多个容器尚未创建亦未运行。此阶段包括等待 Pod 被调度的时间和通过网络下载镜像的时间,
156
+ ` Pending ` (悬决)| Pod 已被 Kubernetes 系统接受,但有一个或者多个容器尚未创建亦未运行。此阶段包括等待 Pod 被调度的时间和通过网络下载镜像的时间。
157
157
` Running ` (运行中) | Pod 已经绑定到了某个节点,Pod 中所有的容器都已被创建。至少有一个容器仍在运行,或者正处于启动或重启状态。
158
158
` Succeeded ` (成功) | Pod 中的所有容器都已成功终止,并且不会再重启。
159
159
` Failed ` (失败) | Pod 中的所有容器都已终止,并且至少有一个容器是因为失败终止。也就是说,容器以非 0 状态退出或者被系统终止。
@@ -300,14 +300,14 @@ Pod 有一个 PodStatus 对象,其中包含一个
300
300
* `PodScheduled`: the Pod has been scheduled to a node.
301
301
* `ContainersReady`: all containers in the Pod are ready.
302
302
* `Initialized`: all [init containers](/docs/concepts/workloads/pods/init-containers/)
303
- have started successfully.
303
+ have completed successfully.
304
304
* `Ready`: the Pod is able to serve requests and should be added to the load
305
305
balancing pools of all matching Services.
306
306
-->
307
307
* ` PodScheduled ` :Pod 已经被调度到某节点;
308
308
* ` ContainersReady ` :Pod 中所有容器都已就绪;
309
309
* ` Initialized ` :所有的 [ Init 容器] ( /zh/docs/concepts/workloads/pods/init-containers/ )
310
- 都已成功启动 ;
310
+ 都已成功完成 ;
311
311
* ` Ready ` :Pod 可以为请求提供服务,并且应该被添加到对应服务的负载均衡池中。
312
312
313
313
<!--
@@ -425,93 +425,145 @@ When a Pod's containers are Ready but at least one custom condition is missing o
425
425
<!--
426
426
## Container probes
427
427
428
- A [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) is a diagnostic
428
+ A _probe_ is a diagnostic
429
429
performed periodically by the
430
430
[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.
435
434
-->
436
435
## 容器探针 {#container-probes}
437
436
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 既可以在容器内执行代码,也可以发出一个网络请求。
443
439
444
440
<!--
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}
452
442
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:
460
445
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.
463
449
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
466
491
且小于 400,则诊断被认为是成功的。
467
492
493
+ ` tcpSocket `
494
+ : 对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开,则诊断被认为是成功的。
495
+ 如果远程系统(容器)在打开连接后立即将其关闭,这算作是健康的。
496
+
468
497
<!--
498
+ ### Probe outcome
469
499
Each probe has one of three results:
470
500
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
+
474
511
-->
512
+ ### 探测结果 {#probe-outcome}
475
513
每次探测都将获得以下三种结果之一:
476
514
477
- - ` Success ` (成功):容器通过了诊断。
478
- - ` Failure ` (失败):容器未通过诊断。
479
- - ` Unknown ` (未知):诊断失败,因此不会采取任何行动。
515
+ ` Success ` (成功)
516
+ : 容器通过了诊断。
517
+
518
+ ` Failure ` (失败)
519
+ : 容器未通过诊断。
520
+
521
+ ` Unknown ` (未知)
522
+ : 诊断失败,因此不会采取任何行动。
480
523
481
524
<!--
525
+ ### Types of probe
482
526
The kubelet can optionally perform and react to three kinds of probes on running
483
527
containers:
484
528
-->
529
+ ### 探测类型 {#types-of-probe}
485
530
针对运行中的容器,` kubelet ` 可以选择是否执行以下三种探针,以及如何针对探测结果作出反应:
486
531
487
532
<!--
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`.
492
538
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`.
498
545
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`.
504
552
-->
505
- - ` livenessProbe ` :指示容器是否正在运行。如果存活态探测失败,则 kubelet 会杀死容器,
553
+
554
+ ` livenessProbe `
555
+ : 指示容器是否正在运行。如果存活态探测失败,则 kubelet 会杀死容器,
506
556
并且容器将根据其[ 重启策略] ( #restart-policy ) 决定未来。如果容器不提供存活探针,
507
557
则默认状态为 ` Success ` 。
508
558
509
- - ` readinessProbe ` :指示容器是否准备好为请求提供服务。如果就绪态探测失败,
559
+ ` readinessProbe `
560
+ : 指示容器是否准备好为请求提供服务。如果就绪态探测失败,
510
561
端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。
511
562
初始延迟之前的就绪态的状态值默认为 ` Failure ` 。
512
563
如果容器不提供就绪态探针,则默认状态为 ` Success ` 。
513
564
514
- - ` startupProbe ` : 指示容器中的应用是否已经启动。如果提供了启动探针,则所有其他探针都会被
565
+ ` startupProbe `
566
+ : 指示容器中的应用是否已经启动。如果提供了启动探针,则所有其他探针都会被
515
567
禁用,直到此探针成功为止。如果启动探测失败,` kubelet ` 将杀死容器,而容器依其
516
568
[ 重启策略] ( #restart-policy ) 进行重启。
517
569
如果容器没有提供启动探测,则默认状态为 ` Success ` 。
@@ -524,9 +576,9 @@ see [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod
524
576
[ 配置存活态、就绪态和启动探针] ( /zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ ) 。
525
577
526
578
<!--
527
- ### When should you use a liveness probe?
579
+ #### When should you use a liveness probe?
528
580
-->
529
- ### 何时该使用存活态探针? {#when-should-you-use-a-liveness-probe}
581
+ #### 何时该使用存活态探针? {#when-should-you-use-a-liveness-probe}
530
582
531
583
{{< feature-state for_k8s_version="v1.0" state="stable" >}}
532
584
@@ -546,9 +598,9 @@ specify a liveness probe, and specify a `restartPolicy` of Always or OnFailure.
546
598
并指定` restartPolicy ` 为 "` Always ` " 或 "` OnFailure ` "。
547
599
548
600
<!--
549
- ### When should you use a readiness probe?
601
+ #### When should you use a readiness probe?
550
602
-->
551
- ### 何时该使用就绪态探针? {#when-should-you-use-a-readiness-probe}
603
+ #### 何时该使用就绪态探针? {#when-should-you-use-a-readiness-probe}
552
604
553
605
{{< feature-state for_k8s_version="v1.0" state="stable" >}}
554
606
@@ -606,9 +658,9 @@ to stop.
606
658
{{< /note >}}
607
659
608
660
<!--
609
- ### When should you use a startup probe?
661
+ #### When should you use a startup probe?
610
662
-->
611
- ### 何时该使用启动探针? {#when-should-you-use-a-startup-probe}
663
+ #### 何时该使用启动探针? {#when-should-you-use-a-startup-probe}
612
664
613
665
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
614
666
@@ -852,21 +904,20 @@ This avoids a resource leak as Pods are created and terminated over time.
852
904
853
905
<!--
854
906
* 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/).
856
908
857
909
* Get hands-on experience
858
910
[configuring Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
859
911
860
912
* Learn more about [container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/).
861
913
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 .
865
917
-->
866
918
* 动手实践[ 为容器生命周期时间关联处理程序] ( /zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/ ) 。
867
919
* 动手实践[ 配置存活态、就绪态和启动探针] ( /zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ ) 。
868
920
* 进一步了解[ 容器生命周期回调] ( /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 ) 字段。
872
923
0 commit comments