kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

[zh] Sync configure-liveness-readiness-startup-probes.md

This commit is contained in:
Michael 2022-09-30 21:25:17 +08:00
parent 24540ba388
commit 4ffe7a9b48
1 changed files with 21 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
content/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
View File

@ -14,7 +14,7 @@ where an application is running, but unable to make progress. Restarting a
container in such a state can help to make the application more available container in such a state can help to make the application more available
despite bugs. despite bugs.
--> -->
这篇文章介绍如何给容器配置活跃（Liveness）、就绪（Readiness）和启动（Startup）探针。 这篇文章介绍如何给容器配置存活（Liveness）、就绪（Readiness）和启动（Startup）探针。
[kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) [kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/)
使用存活探针来确定什么时候要重启容器。 使用存活探针来确定什么时候要重启容器。
@ -33,7 +33,7 @@ it succeeds, making sure those probes don't interfere with the application start
This can be used to adopt liveness checks on slow starting containers, avoiding them This can be used to adopt liveness checks on slow starting containers, avoiding them
getting killed by the kubelet before they are up and running. getting killed by the kubelet before they are up and running.
--> -->
kubelet 使用就绪探针可以知道容器何时准备好接受请求流量，当一个 Pod kubelet 使用就绪探针可以知道容器何时准备好接受请求流量，当一个 Pod
内的所有容器都就绪时，才能认为该 Pod 就绪。 内的所有容器都就绪时，才能认为该 Pod 就绪。
这种信号的一个用途就是控制哪个 Pod 作为 Service 的后端。 这种信号的一个用途就是控制哪个 Pod 作为 Service 的后端。
若 Pod 尚未就绪，会被从 Service 的负载均衡器中剔除。 若 Pod 尚未就绪，会被从 Service 的负载均衡器中剔除。
@ -174,7 +174,8 @@ kubectl get pod liveness-exec
<!-- <!--
The output shows that `RESTARTS` has been incremented. Note that the `RESTARTS` counter increments as soon as a failed container comes back to the running state: The output shows that `RESTARTS` has been incremented. Note that the `RESTARTS` counter increments as soon as a failed container comes back to the running state:
--> -->
输出结果显示 `RESTARTS` 的值增加了 1。请注意，一旦失败的容器恢复为运行状态，`RESTARTS` 计数器就会增加 1： 输出结果显示 `RESTARTS` 的值增加了 1。
请注意，一旦失败的容器恢复为运行状态，`RESTARTS` 计数器就会增加 1：
``` ```
NAME READY STATUS RESTARTS AGE NAME READY STATUS RESTARTS AGE
@ -263,7 +264,7 @@ kubectl apply -f https://k8s.io/examples/pods/probe/http-liveness.yaml
After 10 seconds, view Pod events to verify that liveness probes have failed and After 10 seconds, view Pod events to verify that liveness probes have failed and
the container has been restarted: the container has been restarted:
--> -->
10 秒之后，通过查看 Pod 事件来确认活跃探针已经失败，并且容器被重新启动了。 10 秒之后，通过查看 Pod 事件来确认存活探针已经失败，并且容器被重新启动了。
```shell ```shell
kubectl describe pod liveness-http kubectl describe pod liveness-http
@ -319,7 +320,7 @@ To try the TCP liveness check, create a Pod:
除了就绪探针，这个配置包括了一个存活探针。 除了就绪探针，这个配置包括了一个存活探针。
kubelet 会在容器启动 15 秒后进行第一次存活探测。 kubelet 会在容器启动 15 秒后进行第一次存活探测。
与就绪探针类似，活跃探针会尝试连接 `goproxy` 容器的 8080 端口。 与就绪探针类似，存活探针会尝试连接 `goproxy` 容器的 8080 端口。
如果存活探测失败，容器会被重新启动。 如果存活探测失败，容器会被重新启动。
```shell ```shell
@ -338,7 +339,7 @@ kubectl describe pod goproxy
<!-- <!--
## Define a gRPC liveness probe ## Define a gRPC liveness probe
--> -->
## 定义 gRPC 活跃探针 ## 定义 gRPC 存活探针
{{< feature-state for_k8s_version="v1.24" state="beta" >}} {{< feature-state for_k8s_version="v1.24" state="beta" >}}
@ -353,7 +354,7 @@ Here is an example manifest:
--> -->
如果你的应用实现了 如果你的应用实现了
[gRPC 健康检查协议](https://github.com/grpc/grpc/blob/master/doc/health-checking.md)， [gRPC 健康检查协议](https://github.com/grpc/grpc/blob/master/doc/health-checking.md)，
kubelet 可以配置为使用该协议来执行应用活跃性检查。 kubelet 可以配置为使用该协议来执行应用存活性检查。
你必须启用 `GRPCContainerProbe` 你必须启用 `GRPCContainerProbe`
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
才能配置依赖于 gRPC 的检查机制。 才能配置依赖于 gRPC 的检查机制。
@ -393,7 +394,7 @@ kubectl apply -f https://k8s.io/examples/pods/probe/grpc-liveness.yaml
<!-- <!--
After 15 seconds, view Pod events to verify that the liveness check has not failed: After 15 seconds, view Pod events to verify that the liveness check has not failed:
--> -->
15 秒钟之后，查看 Pod 事件确认活跃性检查并未失败： 15 秒钟之后，查看 Pod 事件确认存活性检查并未失败：
```shell ```shell
kubectl describe pod etcd-with-grpc kubectl describe pod etcd-with-grpc
@ -509,8 +510,8 @@ subject to the pod's `restartPolicy`.
--> -->
幸亏有启动探测，应用程序将会有最多 5 分钟（30 * 10 = 300s）的时间来完成其启动过程。 幸亏有启动探测，应用程序将会有最多 5 分钟（30 * 10 = 300s）的时间来完成其启动过程。
一旦启动探测成功一次，存活探测任务就会接管对容器的探测，对容器死锁作出快速响应。 一旦启动探测成功一次，存活探测任务就会接管对容器的探测，对容器死锁作出快速响应。
如果启动探测一直没有成功，容器会在 300 秒后被杀死，并且根据 `restartPolicy` 来 如果启动探测一直没有成功，容器会在 300 秒后被杀死，并且根据 `restartPolicy`
执行进一步处置。 来执行进一步处置。
<!-- <!--
## Define readiness probes ## Define readiness probes
@ -543,8 +544,8 @@ Readiness probes runs on the container during its whole lifecycle.
<!-- <!--
Liveness probes *do not* wait for readiness probes to succeed. If you want to wait before executing a liveness probe you should use initialDelaySeconds or a startupProbe. Liveness probes *do not* wait for readiness probes to succeed. If you want to wait before executing a liveness probe you should use initialDelaySeconds or a startupProbe.
--> -->
活跃探针 **不等待** 就绪性探针成功。 存活探针 **不等待** 就绪性探针成功。
如果要在执行活跃探针之前等待，应该使用 `initialDelaySeconds` 或 `startupProbe`。 如果要在执行存活探针之前等待，应该使用 `initialDelaySeconds` 或 `startupProbe`。
{{< /caution >}} {{< /caution >}}
<!-- <!--
@ -591,15 +592,15 @@ Eventually, some of this section could be moved to a concept topic.
<!-- <!--
[Probes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) have a number of fields that [Probes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) have a number of fields that
you can use to more precisely control the behavior of liveness and readiness you can use to more precisely control the behavior of startup, liveness and readiness
checks: checks:
--> -->
[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)
有很多配置字段，可以使用这些字段精确地控制活跃和就绪检测的行为： 有很多配置字段，可以使用这些字段精确地控制启动、存活和就绪检测的行为：
<!-- <!--
* `initialDelaySeconds`: Number of seconds after the container has started * `initialDelaySeconds`: Number of seconds after the container has started
before liveness or readiness probes are initiated. Defaults to 0 seconds. Minimum value is 0. before startup, liveness or readiness probes are initiated. Defaults to 0 seconds. Minimum value is 0.
* `periodSeconds`: How often (in seconds) to perform the probe. Default to 10 * `periodSeconds`: How often (in seconds) to perform the probe. Default to 10
seconds. Minimum value is 1. seconds. Minimum value is 1.
* `timeoutSeconds`: Number of seconds after which the probe times out. Defaults * `timeoutSeconds`: Number of seconds after which the probe times out. Defaults
@ -611,7 +612,7 @@ and startup Probes. Minimum value is 1.
try `failureThreshold` times before giving up. Giving up in case of liveness probe means restarting the container. In case of readiness probe the Pod will be marked Unready. try `failureThreshold` times before giving up. Giving up in case of liveness probe means restarting the container. In case of readiness probe the Pod will be marked Unready.
Defaults to 3. Minimum value is 1. Defaults to 3. Minimum value is 1.
--> -->
* `initialDelaySeconds`：容器启动后要等待多少秒后才启动存活和就绪探针， * `initialDelaySeconds`：容器启动后要等待多少秒后才启动启动、存活和就绪探针，
默认是 0 秒，最小值是 0。 默认是 0 秒，最小值是 0。
* `periodSeconds`：执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1。 * `periodSeconds`：执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1。
* `timeoutSeconds`：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。 * `timeoutSeconds`：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。
@ -629,7 +630,7 @@ until a result was returned.
--> -->
在 Kubernetes 1.20 版本之前，`exec` 探针会忽略 `timeoutSeconds`： 在 Kubernetes 1.20 版本之前，`exec` 探针会忽略 `timeoutSeconds`：
探针会无限期地持续运行，甚至可能超过所配置的限期，直到返回结果为止。 探针会无限期地持续运行，甚至可能超过所配置的限期，直到返回结果为止。
<!-- <!--
This defect was corrected in Kubernetes v1.20. You may have been relying on the previous behavior, This defect was corrected in Kubernetes v1.20. You may have been relying on the previous behavior,
even without realizing it, as the default timeout is 1 second. even without realizing it, as the default timeout is 1 second.
@ -706,8 +707,8 @@ case, you should not use `host`, but rather set the `Host` header in `httpHeader
对于 HTTP 探测，kubelet 发送一个 HTTP 请求到指定的路径和端口来执行检测。 对于 HTTP 探测，kubelet 发送一个 HTTP 请求到指定的路径和端口来执行检测。
除非 `httpGet` 中的 `host` 字段设置了，否则 kubelet 默认是给 Pod 的 IP 地址发送探测。 除非 `httpGet` 中的 `host` 字段设置了，否则 kubelet 默认是给 Pod 的 IP 地址发送探测。
如果 `scheme` 字段设置为了 `HTTPS`，kubelet 会跳过证书验证发送 HTTPS 请求。 如果 `scheme` 字段设置为了 `HTTPS`，kubelet 会跳过证书验证发送 HTTPS 请求。
大多数情况下，不需要设置`host` 字段。 大多数情况下，不需要设置 `host` 字段。
这里有个需要设置 `host` 字段的场景，假设容器监听 127.0.0.1，并且 Pod 的 `hostNetwork` 这里有个需要设置 `host` 字段的场景，假设容器监听 127.0.0.1，并且 Pod 的 `hostNetwork`
字段设置为了 `true`。那么 `httpGet` 中的 `host` 字段应该设置为 127.0.0.1。 字段设置为了 `true`。那么 `httpGet` 中的 `host` 字段应该设置为 127.0.0.1。
可能更常见的情况是如果 Pod 依赖虚拟主机，你不应该设置 `host` 字段，而是应该在 可能更常见的情况是如果 Pod 依赖虚拟主机，你不应该设置 `host` 字段，而是应该在
`httpHeaders` 中设置 `Host`。 `httpHeaders` 中设置 `Host`。
@ -785,7 +786,7 @@ unusually long time to restart when a pod-level `terminationGracePeriodSeconds`
was set. was set.
--> -->
在 1.21 发行版之前，Pod 层面的 `terminationGracePeriodSeconds` 在 1.21 发行版之前，Pod 层面的 `terminationGracePeriodSeconds`
被用来终止活跃探测或启动探测失败的容器。 被用来终止存活探测或启动探测失败的容器。
这一行为上的关联不是我们想要的，可能导致 Pod 层面设置了 `terminationGracePeriodSeconds` 这一行为上的关联不是我们想要的，可能导致 Pod 层面设置了 `terminationGracePeriodSeconds`
时容器要花非常长的时间才能重新启动。 时容器要花非常长的时间才能重新启动。