[zh] Sync configure-liveness-readiness-startup-probes.md
This commit is contained in:
Michael
parent
24540ba388
commit
4ffe7a9b48
|
|
@ -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
|
||||
despite bugs.
|
||||
-->
|
||||
这篇文章介绍如何给容器配置活跃（Liveness）、就绪（Readiness）和启动（Startup）探针。
|
||||
这篇文章介绍如何给容器配置存活（Liveness）、就绪（Readiness）和启动（Startup）探针。
|
||||
|
||||
[kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/)
|
||||
使用存活探针来确定什么时候要重启容器。
|
||||
|
|
@ -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:
|
||||
-->
|
||||
输出结果显示 `RESTARTS` 的值增加了 1。请注意，一旦失败的容器恢复为运行状态，`RESTARTS` 计数器就会增加 1：
|
||||
输出结果显示 `RESTARTS` 的值增加了 1。
|
||||
请注意，一旦失败的容器恢复为运行状态，`RESTARTS` 计数器就会增加 1：
|
||||
|
||||
```
|
||||
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
|
||||
the container has been restarted:
|
||||
-->
|
||||
10 秒之后，通过查看 Pod 事件来确认活跃探针已经失败，并且容器被重新启动了。
|
||||
10 秒之后，通过查看 Pod 事件来确认存活探针已经失败，并且容器被重新启动了。
|
||||
|
||||
```shell
|
||||
kubectl describe pod liveness-http
|
||||
|
|
@ -319,7 +320,7 @@ To try the TCP liveness check, create a Pod:
|
|||
|
||||
除了就绪探针，这个配置包括了一个存活探针。
|
||||
kubelet 会在容器启动 15 秒后进行第一次存活探测。
|
||||
与就绪探针类似，活跃探针会尝试连接 `goproxy` 容器的 8080 端口。
|
||||
与就绪探针类似，存活探针会尝试连接 `goproxy` 容器的 8080 端口。
|
||||
如果存活探测失败，容器会被重新启动。
|
||||
|
||||
```shell
|
||||
|
|
@ -338,7 +339,7 @@ kubectl describe pod goproxy
|
|||
<!--
|
||||
## Define a gRPC liveness probe
|
||||
-->
|
||||
## 定义 gRPC 活跃探针
|
||||
## 定义 gRPC 存活探针
|
||||
|
||||
{{< 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)，
|
||||
kubelet 可以配置为使用该协议来执行应用活跃性检查。
|
||||
kubelet 可以配置为使用该协议来执行应用存活性检查。
|
||||
你必须启用 `GRPCContainerProbe`
|
||||
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
才能配置依赖于 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:
|
||||
-->
|
||||
15 秒钟之后，查看 Pod 事件确认活跃性检查并未失败：
|
||||
15 秒钟之后，查看 Pod 事件确认存活性检查并未失败：
|
||||
|
||||
```shell
|
||||
kubectl describe pod etcd-with-grpc
|
||||
|
|
@ -509,8 +510,8 @@ subject to the pod's `restartPolicy`.
|
|||
-->
|
||||
幸亏有启动探测，应用程序将会有最多 5 分钟（30 * 10 = 300s）的时间来完成其启动过程。
|
||||
一旦启动探测成功一次，存活探测任务就会接管对容器的探测，对容器死锁作出快速响应。
|
||||
如果启动探测一直没有成功，容器会在 300 秒后被杀死，并且根据 `restartPolicy` 来
|
||||
执行进一步处置。
|
||||
如果启动探测一直没有成功，容器会在 300 秒后被杀死，并且根据 `restartPolicy`
|
||||
来执行进一步处置。
|
||||
|
||||
<!--
|
||||
## 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.
|
||||
-->
|
||||
活跃探针 **不等待** 就绪性探针成功。
|
||||
如果要在执行活跃探针之前等待，应该使用 `initialDelaySeconds` 或 `startupProbe`。
|
||||
存活探针 **不等待** 就绪性探针成功。
|
||||
如果要在执行存活探针之前等待，应该使用 `initialDelaySeconds` 或 `startupProbe`。
|
||||
{{< /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
|
||||
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:
|
||||
-->
|
||||
[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)
|
||||
有很多配置字段，可以使用这些字段精确地控制活跃和就绪检测的行为：
|
||||
有很多配置字段，可以使用这些字段精确地控制启动、存活和就绪检测的行为：
|
||||
|
||||
<!--
|
||||
* `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
|
||||
seconds. Minimum value is 1.
|
||||
* `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.
|
||||
Defaults to 3. Minimum value is 1.
|
||||
-->
|
||||
* `initialDelaySeconds`：容器启动后要等待多少秒后才启动存活和就绪探针，
|
||||
* `initialDelaySeconds`：容器启动后要等待多少秒后才启动启动、存活和就绪探针，
|
||||
默认是 0 秒，最小值是 0。
|
||||
* `periodSeconds`：执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1。
|
||||
* `timeoutSeconds`：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。
|
||||
|
|
@ -706,7 +707,7 @@ case, you should not use `host`, but rather set the `Host` header in `httpHeader
|
|||
对于 HTTP 探测，kubelet 发送一个 HTTP 请求到指定的路径和端口来执行检测。
|
||||
除非 `httpGet` 中的 `host` 字段设置了，否则 kubelet 默认是给 Pod 的 IP 地址发送探测。
|
||||
如果 `scheme` 字段设置为了 `HTTPS`，kubelet 会跳过证书验证发送 HTTPS 请求。
|
||||
大多数情况下，不需要设置`host` 字段。
|
||||
大多数情况下，不需要设置 `host` 字段。
|
||||
这里有个需要设置 `host` 字段的场景，假设容器监听 127.0.0.1，并且 Pod 的 `hostNetwork`
|
||||
字段设置为了 `true`。那么 `httpGet` 中的 `host` 字段应该设置为 127.0.0.1。
|
||||
可能更常见的情况是如果 Pod 依赖虚拟主机，你不应该设置 `host` 字段，而是应该在
|
||||
|
|
@ -785,7 +786,7 @@ unusually long time to restart when a pod-level `terminationGracePeriodSeconds`
|
|||
was set.
|
||||
-->
|
||||
在 1.21 发行版之前，Pod 层面的 `terminationGracePeriodSeconds`
|
||||
被用来终止活跃探测或启动探测失败的容器。
|
||||
被用来终止存活探测或启动探测失败的容器。
|
||||
这一行为上的关联不是我们想要的，可能导致 Pod 层面设置了 `terminationGracePeriodSeconds`
|
||||
时容器要花非常长的时间才能重新启动。
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue