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

Update configure-liveness-readiness-startup-probes.md

This commit is contained in:
yanrongshi 2022-08-24 22:05:20 +08:00
parent ec18dbfc4f
commit 331857a28a
1 changed files with 99 additions and 87 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -1,5 +1,5 @@
--- ---
title: 配置存活、就绪和启动探测器 title: 配置存活、就绪和启动探针
content_type: task content_type: task
weight: 110 weight: 110
--- ---
@ -14,11 +14,11 @@ 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,15 +33,15 @@ 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 的负载均衡器中剔除。
kubelet 使用启动探测器来了解应用容器何时启动。 kubelet 使用启动探针来了解应用容器何时启动。
如果配置了这类探测器，你就可以控制容器在启动成功后再进行存活性和就绪态检查， 如果配置了这类探针，你就可以控制容器在启动成功后再进行存活性和就绪态检查，
确保这些存活、就绪探测器不会影响应用的启动。 确保这些存活、就绪探针不会影响应用的启动。
启动探测器可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被杀掉。 启动探针可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被杀掉。
## {{% heading "prerequisites" %}} ## {{% heading "prerequisites" %}}
@ -57,14 +57,14 @@ broken states, and cannot recover except by being restarted. Kubernetes provides
liveness probes to detect and remedy such situations. liveness probes to detect and remedy such situations.
In this exercise, you create a Pod that runs a container based on the In this exercise, you create a Pod that runs a container based on the
`k8s.gcr.io/busybox` image. Here is the configuration file for the Pod: `registry.k8s.io/busybox` image. Here is the configuration file for the Pod:
--> -->
## 定义存活命令 {#define-a-liveness-command} ## 定义存活命令 {#define-a-liveness-command}
许多长时间运行的应用最终会进入损坏状态，除非重新启动，否则无法被恢复。 许多长时间运行的应用最终会进入损坏状态，除非重新启动，否则无法被恢复。
Kubernetes 提供了存活探测器来发现并处理这种情况。 Kubernetes 提供了存活探针来发现并处理这种情况。
在本练习中，你会创建一个 Pod，其中运行一个基于 `k8s.gcr.io/busybox` 镜像的容器。 在本练习中，你会创建一个 Pod，其中运行一个基于 `registry.k8s.io/busybox` 镜像的容器。
下面是这个 Pod 的配置文件。 下面是这个 Pod 的配置文件。
{{< codenew file="pods/probe/exec-liveness.yaml" >}} {{< codenew file="pods/probe/exec-liveness.yaml" >}}
@ -123,16 +123,16 @@ kubectl describe pod liveness-exec
<!-- <!--
The output indicates that no liveness probes have failed yet: The output indicates that no liveness probes have failed yet:
--> -->
输出结果表明还没有存活探测器失败： 输出结果表明还没有存活探针失败：
``` ```
FirstSeen LastSeen Count From SubobjectPath Type Reason Message Type Reason Age From Message
--------- -------- ----- ---- ------------- -------- ------ ------- ---- ------ ---- ---- -------
24s 24s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0 Normal Scheduled 11s default-scheduler Successfully assigned default/liveness-exec to node01
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox" Normal Pulling 9s kubelet, node01 Pulling image "registry.k8s.io/busybox"
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox" Normal Pulled 7s kubelet, node01 Successfully pulled image "registry.k8s.io/busybox"
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined] Normal Created 7s kubelet, node01 Created container liveness
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e Normal Started 7s kubelet, node01 Started container liveness
``` ```
<!-- <!--
@ -148,17 +148,18 @@ kubectl describe pod liveness-exec
At the bottom of the output, there are messages indicating that the liveness At the bottom of the output, there are messages indicating that the liveness
probes have failed, and the failed containers have been killed and recreated. probes have failed, and the failed containers have been killed and recreated.
--> -->
在输出结果的最下面，有信息显示存活探测器失败了，这个失败的容器被杀死并且被重建了。 在输出结果的最下面，有信息显示存活探针失败了，这个失败的容器被杀死并且被重建了。
``` ```
FirstSeen LastSeen Count From SubobjectPath Type Reason Message Type Reason Age From Message
--------- -------- ----- ---- ------------- -------- ------ ------- ---- ------ ---- ---- -------
37s 37s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0 Normal Scheduled 57s default-scheduler Successfully assigned default/liveness-exec to node01
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox" Normal Pulling 55s kubelet, node01 Pulling image "registry.k8s.io/busybox"
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox" Normal Pulled 53s kubelet, node01 Successfully pulled image "registry.k8s.io/busybox"
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined] Normal Created 53s kubelet, node01 Created container liveness
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e Normal Started 53s kubelet, node01 Started container liveness
2s 2s 1 {kubelet worker0} spec.containers{liveness} Warning Unhealthy Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory Warning Unhealthy 10s (x3 over 20s) kubelet, node01 Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
Normal Killing 10s kubelet, node01 Container liveness failed liveness probe, will be restarted
``` ```
<!-- <!--
@ -184,13 +185,13 @@ liveness-exec 1/1 Running 1 1m
## Define a liveness HTTP request ## Define a liveness HTTP request
Another kind of liveness probe uses an HTTP GET request. Here is the configuration Another kind of liveness probe uses an HTTP GET request. Here is the configuration
file for a Pod that runs a container based on the `k8s.gcr.io/liveness` file for a Pod that runs a container based on the `registry.k8s.io/liveness`
image. image.
--> -->
## 定义一个存活态 HTTP 请求接口 {#define-a-liveness-HTTP-request} ## 定义一个存活态 HTTP 请求接口 {#define-a-liveness-HTTP-request}
另外一种类型的存活探测方式是使用 HTTP GET 请求。 另外一种类型的存活探测方式是使用 HTTP GET 请求。
下面是一个 Pod 的配置文件，其中运行一个基于 `k8s.gcr.io/liveness` 镜像的容器。 下面是一个 Pod 的配置文件，其中运行一个基于 `registry.k8s.io/liveness` 镜像的容器。
{{< codenew file="pods/probe/http-liveness.yaml" >}} {{< codenew file="pods/probe/http-liveness.yaml" >}}
@ -262,7 +263,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
@ -312,13 +313,13 @@ will be restarted.
To try the TCP liveness check, create a Pod: To try the TCP liveness check, create a Pod:
--> -->
如你所见，TCP 检测的配置和 HTTP 检测非常相似。 如你所见，TCP 检测的配置和 HTTP 检测非常相似。
下面这个例子同时使用就绪和存活探测器。kubelet 会在容器启动 5 秒后发送第一个就绪探测。 下面这个例子同时使用就绪和存活探针。kubelet 会在容器启动 5 秒后发送第一个就绪探针。
探测器会尝试连接 `goproxy` 容器的 8080 端口。 探针会尝试连接 `goproxy` 容器的 8080 端口。
如果探测成功，这个 Pod 会被标记为就绪状态，kubelet 将继续每隔 10 秒运行一次检测。 如果探测成功，这个 Pod 会被标记为就绪状态，kubelet 将继续每隔 10 秒运行一次探测。
除了就绪探测，这个配置包括了一个存活探测。 除了就绪探针，这个配置包括了一个存活探针。
kubelet 会在容器启动 15 秒后进行第一次存活探测。 kubelet 会在容器启动 15 秒后进行第一次存活探测。
与就绪探测类似，活跃探测器会尝试连接 `goproxy` 容器的 8080 端口。 与就绪探针类似，活跃探针会尝试连接 `goproxy` 容器的 8080 端口。
如果存活探测失败，容器会被重新启动。 如果存活探测失败，容器会被重新启动。
```shell ```shell
@ -328,7 +329,7 @@ kubectl apply -f https://k8s.io/examples/pods/probe/tcp-liveness-readiness.yaml
<!-- <!--
After 15 seconds, view Pod events to verify that liveness probes: After 15 seconds, view Pod events to verify that liveness probes:
--> -->
15 秒之后，通过看 Pod 事件来检测存活探测器： 15 秒之后，通过看 Pod 事件来检测存活探针：
```shell ```shell
kubectl describe pod goproxy kubectl describe pod goproxy
@ -337,7 +338,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" >}}
@ -365,14 +366,14 @@ kubelet 可以配置为使用该协议来执行应用活跃性检查。
To use a gRPC probe, `port` must be configured. If the health endpoint is configured To use a gRPC probe, `port` must be configured. If the health endpoint is configured
on a non-default service, you must also specify the `service`. on a non-default service, you must also specify the `service`.
--> -->
要使用 gRPC 探测器，必须配置 `port` 属性。如果健康状态端点配置在非默认服务之上， 要使用 gRPC 探针，必须配置 `port` 属性。如果健康状态端点配置在非默认服务之上，
你还必须设置 `service` 属性。 你还必须设置 `service` 属性。
{{< note >}} {{< note >}}
<!-- <!--
Unlike HTTP and TCP probes, named ports cannot be used and custom host cannot be configured. Unlike HTTP and TCP probes, named ports cannot be used and custom host cannot be configured.
--> -->
与 HTTP 和 TCP 探测器不同，gRPC 探测不能使用命名端口或定制主机。 与 HTTP 和 TCP 探针不同，gRPC 探测不能使用命名端口或定制主机。
{{< /note >}} {{< /note >}}
<!-- <!--
@ -383,7 +384,7 @@ To try the gRPC liveness check, create a Pod using the command below.
In the example below, the etcd pod is configured to use gRPC liveness probe. In the example below, the etcd pod is configured to use gRPC liveness probe.
--> -->
配置问题（例如：错误的 `port` 和 `service`、未实现健康检查协议） 配置问题（例如：错误的 `port` 和 `service`、未实现健康检查协议）
都被认作是探测失败，这一点与 HTTP 和 TCP 探测器类似。 都被认作是探测失败，这一点与 HTTP 和 TCP 探针类似。
```shell ```shell
kubectl apply -f https://k8s.io/examples/pods/probe/grpc-liveness.yaml kubectl apply -f https://k8s.io/examples/pods/probe/grpc-liveness.yaml
@ -407,8 +408,8 @@ When migrating from grpc-health-probe to built-in probes, remember the following
在 Kubernetes 1.23 之前，gRPC 健康探测通常使用 在 Kubernetes 1.23 之前，gRPC 健康探测通常使用
[grpc-health-probe](https://github.com/grpc-ecosystem/grpc-health-probe/) [grpc-health-probe](https://github.com/grpc-ecosystem/grpc-health-probe/)
来实现，如博客 [Health checking gRPC servers on Kubernetes（对 Kubernetes 上的 gRPC 服务器执行健康检查）](/blog/2018/10/01/health-checking-grpc-servers-on-kubernetes/)所描述。 来实现，如博客 [Health checking gRPC servers on Kubernetes（对 Kubernetes 上的 gRPC 服务器执行健康检查）](/blog/2018/10/01/health-checking-grpc-servers-on-kubernetes/)所描述。
内置的 gRPC 探测器行为与 `grpc-health-probe` 所实现的行为类似。 内置的 gRPC 探针行为与 `grpc-health-probe` 所实现的行为类似。
从 `grpc-health-probe` 迁移到内置探测器时，请注意以下差异： 从 `grpc-health-probe` 迁移到内置探针时，请注意以下差异：
<!-- <!--
- Built-in probes run against the pod IP address, unlike grpc-health-probe that often runs against `127.0.0.1`. - Built-in probes run against the pod IP address, unlike grpc-health-probe that often runs against `127.0.0.1`.
@ -418,26 +419,30 @@ When migrating from grpc-health-probe to built-in probes, remember the following
- If `ExecProbeTimeout` feature gate is set to `false`, grpc-health-probe does **not** respect the `timeoutSeconds` setting (which defaults to 1s), - If `ExecProbeTimeout` feature gate is set to `false`, grpc-health-probe does **not** respect the `timeoutSeconds` setting (which defaults to 1s),
while built-in probe would fail on timeout. while built-in probe would fail on timeout.
--> -->
- 内置探测器运行时针对的是 Pod 的 IP 地址，不像 `grpc-health-probe` - 内置探针运行时针对的是 Pod 的 IP 地址，不像 `grpc-health-probe`
那样通常针对 `127.0.0.1` 执行探测； 那样通常针对 `127.0.0.1` 执行探测；
请一定配置你的 gRPC 端点使之监听于 Pod 的 IP 地址之上。 请一定配置你的 gRPC 端点使之监听于 Pod 的 IP 地址之上。
- 内置探测器不支持任何身份认证参数（例如 `-tls`）。 - 内置探针不支持任何身份认证参数（例如 `-tls`）。
- 对于内置的探测器而言，不存在错误代码。所有错误都被视作探测失败。 - 对于内置的探针而言，不存在错误代码。所有错误都被视作探测失败。
- 如果 `ExecProbeTimeout` 特性门控被设置为 `false`，则 `grpc-health-probe` - 如果 `ExecProbeTimeout` 特性门控被设置为 `false`，则 `grpc-health-probe`
不会考虑 `timeoutSeconds` 设置状态（默认值为 1s）， 不会考虑 `timeoutSeconds` 设置状态（默认值为 1s），
而内置探测器则会在超时时返回失败。 而内置探针则会在超时时返回失败。
<!-- <!--
## Use a named port ## Use a named port
You can use a named You can use a named
[`port`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#ports) [`port`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#ports)
for HTTP or TCP liveness checks: for HTTP and TCP probes. (gRPC probes do not support named ports).
For example:
--> -->
## 使用命名端口 {#use-a-named-port} ## 使用命名端口 {#use-a-named-port}
对于 HTTP 或者 TCP 存活检测可以使用命名的 对于 HTTP 和 TCP 存活检测可以使用命名的
[`port`](/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#ports)。 [`port`](/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#ports)（gRPC 探针不支持使用命名端口）。
例如：
```yaml ```yaml
ports: ports:
@ -464,7 +469,7 @@ worse case startup time.
So, the previous example would become: So, the previous example would become:
--> -->
## 使用启动探测器保护慢启动容器 {#define-startup-probes} ## 使用启动探针保护慢启动容器 {#define-startup-probes}
有时候，会有一些现有的应用在启动时需要较长的初始化时间。 有时候，会有一些现有的应用在启动时需要较长的初始化时间。
要这种情况下，若要不影响对死锁作出快速响应的探测，设置存活探测参数是要技巧的。 要这种情况下，若要不影响对死锁作出快速响应的探测，设置存活探测参数是要技巧的。
@ -519,34 +524,34 @@ readiness probes to detect and mitigate these situations. A pod with containers
reporting that they are not ready does not receive traffic through Kubernetes reporting that they are not ready does not receive traffic through Kubernetes
Services. Services.
--> -->
## 定义就绪探测器 {#define-readiness-probes} ## 定义就绪探针 {#define-readiness-probes}
有时候，应用会暂时性地无法为请求提供服务。 有时候，应用会暂时性地无法为请求提供服务。
例如，应用在启动时可能需要加载大量的数据或配置文件，或是启动后要依赖等待外部服务。 例如，应用在启动时可能需要加载大量的数据或配置文件，或是启动后要依赖等待外部服务。
在这种情况下，既不想杀死应用，也不想给它发送请求。 在这种情况下，既不想杀死应用，也不想给它发送请求。
Kubernetes 提供了就绪探测器来发现并缓解这些情况。 Kubernetes 提供了就绪探针来发现并缓解这些情况。
容器所在 Pod 上报还未就绪的信息，并且不接受通过 Kubernetes Service 的流量。 容器所在 Pod 上报还未就绪的信息，并且不接受通过 Kubernetes Service 的流量。
{{< note >}} {{< note >}}
<!-- <!--
Readiness probes runs on the container during its whole lifecycle. Readiness probes runs on the container during its whole lifecycle.
--> -->
就绪探测器在容器的整个生命周期中保持运行状态。 就绪探针在容器的整个生命周期中保持运行状态。
{{< /note >}} {{< /note >}}
{{< caution >}} {{< caution >}}
<!-- <!--
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 >}}
<!-- <!--
Readiness probes are configured similarly to liveness probes. The only difference Readiness probes are configured similarly to liveness probes. The only difference
is that you use the `readinessProbe` field instead of the `livenessProbe` field. is that you use the `readinessProbe` field instead of the `livenessProbe` field.
--> -->
就绪探测器的配置和存活探测器的配置相似。 就绪探针的配置和存活探针的配置相似。
唯一区别就是要使用 `readinessProbe` 字段，而不是 `livenessProbe` 字段。 唯一区别就是要使用 `readinessProbe` 字段，而不是 `livenessProbe` 字段。
```yaml ```yaml
@ -567,7 +572,7 @@ Readiness and liveness probes can be used in parallel for the same container.
Using both can ensure that traffic does not reach a container that is not ready Using both can ensure that traffic does not reach a container that is not ready
for it, and that containers are restarted when they fail. for it, and that containers are restarted when they fail.
--> -->
HTTP 和 TCP 的就绪探测器配置也和存活探测器的配置完全相同。 HTTP 和 TCP 的就绪探针配置也和存活探针的配置完全相同。
就绪和存活探测可以在同一个容器上并行使用。 就绪和存活探测可以在同一个容器上并行使用。
两者共同使用，可以确保流量不会发给还未就绪的容器，当这些探测失败时容器会被重新启动。 两者共同使用，可以确保流量不会发给还未就绪的容器，当这些探测失败时容器会被重新启动。
@ -575,7 +580,7 @@ HTTP 和 TCP 的就绪探测器配置也和存活探测器的配置完全相同
<!-- <!--
## Configure Probes ## Configure Probes
--> -->
## 配置探测器 {#configure-probes} ## 配置探针 {#configure-probes}
<!-- <!--
Eventually, some of this section could be moved to a concept topic. Eventually, some of this section could be moved to a concept topic.
@ -606,11 +611,11 @@ 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。
* `successThreshold`：探测器在失败后，被视为成功的最小连续成功数。默认值是 1。 * `successThreshold`：探针在失败后，被视为成功的最小连续成功数。默认值是 1。
存活和启动探测的这个值必须是 1。最小值是 1。 存活和启动探测的这个值必须是 1。最小值是 1。
* `failureThreshold`：当探测失败时，Kubernetes 的重试次数。 * `failureThreshold`：当探测失败时，Kubernetes 的重试次数。
对存活探测而言，放弃就意味着重新启动容器。 对存活探测而言，放弃就意味着重新启动容器。
@ -768,9 +773,9 @@ to resolve it.
<!-- <!--
### Probe-level `terminationGracePeriodSeconds` ### Probe-level `terminationGracePeriodSeconds`
--> -->
### 探测器层面的 `terminationGracePeriodSeconds` ### 探针层面的 `terminationGracePeriodSeconds`
{{< feature-state for_k8s_version="v1.22" state="beta" >}} {{< feature-state for_k8s_version="v1.25" state="beta" >}}
<!-- <!--
Prior to release 1.21, the pod-level `terminationGracePeriodSeconds` was used Prior to release 1.21, the pod-level `terminationGracePeriodSeconds` was used
@ -785,43 +790,50 @@ was set.
时容器要花非常长的时间才能重新启动。 时容器要花非常长的时间才能重新启动。
<!-- <!--
In 1.21 and beyond, when the feature gate `ProbeTerminationGracePeriod` is In 1.25 and beyond, users can specify a probe-level `terminationGracePeriodSeconds`
enabled, users can specify a probe-level `terminationGracePeriodSeconds` as as part of the probe specification. When both a pod- and probe-level
part of the probe specification. When the feature gate is enabled, and both a `terminationGracePeriodSeconds` are set, the kubelet will use the probe-level value.
pod- and probe-level `terminationGracePeriodSeconds` are set, the kubelet will
use the probe-level value.
--> -->
在 1.21 及更高版本中，当特性门控 `ProbeTerminationGracePeriod` 被启用时， 在 1.21 及更高版本中，用户可以指定一个探针层面的 `terminationGracePeriodSeconds`
用户可以指定一个探测器层面的 `terminationGracePeriodSeconds` 作为探测器规约的一部分。 作为探针规约的一部分。
当该特性门控被启用，并且 Pod 层面和探测器层面的 `terminationGracePeriodSeconds` 当 Pod 层面和探针层面的 `terminationGracePeriodSeconds`
都已设置，kubelet 将使用探测器层面设置的值。 都已设置，kubelet 将使用探针层面设置的值。
<!-- <!--
As of Kubernetes 1.22, the `ProbeTerminationGracePeriod` feature gate is only Beginning in Kubernetes 1.25, the `ProbeTerminationGracePeriod` feature is enabled
available on the API Server. The kubelet always honors the probe-level by default. For users choosing to disable this feature, please note the following:
`terminationGracePeriodSeconds` field if it is present on a Pod.
* The `ProbeTerminationGracePeriod` feature gate is only available on the API Server.
The kubelet always honors the probe-level `terminationGracePeriodSeconds` field if
it is present on a Pod.
--> -->
在 Kubernetes 1.22 中，`ProbeTerminationGracePeriod` 特性门控只能用在 API 服务器上。 {{< note >}}
kubelet 始终遵守探针级别 `terminationGracePeriodSeconds` 字段 从 Kubernetes 1.25 开始，默认启用 `ProbeTerminationGracePeriod` 特性。
（如果它存在于 Pod 上）。 选择禁用此特性的用户，请注意以下事项:
* `ProbeTerminationGracePeriod` 特性门控只能用在 API 服务器上。
kubelet 始终优先选用探针级别 `terminationGracePeriodSeconds` 字段
（如果它存在于 Pod 上）。
<!-- <!--
If you have existing Pods where the `terminationGracePeriodSeconds` field is set and * If you have existing Pods where the `terminationGracePeriodSeconds` field is set and
you no longer wish to use per-probe termination grace periods, you must delete you no longer wish to use per-probe termination grace periods, you must delete
those existing Pods. those existing Pods.
--> -->
如果你已经为现有 Pod 设置了 `terminationGracePeriodSeconds` * 如果你已经为现有 Pod 设置了 `terminationGracePeriodSeconds`
字段并且不再希望使用针对每个探针的终止宽限期，则必须删除现有的这类 Pod。 字段并且不再希望使用针对每个探针的终止宽限期，则必须删除现有的这类 Pod。
<!-- <!--
When you (or the control plane, or some other component) create replacement * When you (or the control plane, or some other component) create replacement
Pods, and the feature gate `ProbeTerminationGracePeriod` is disabled, then the Pods, and the feature gate `ProbeTerminationGracePeriod` is disabled, then the
API server ignores the Probe-level `terminationGracePeriodSeconds` field, even if API server ignores the Probe-level `terminationGracePeriodSeconds` field, even if
a Pod or pod template specifies it. a Pod or pod template specifies it.
--> -->
当你（或控制平面或某些其他组件）创建替换 Pod，并且特性门控 `ProbeTerminationGracePeriod` * 当你（或控制平面或某些其他组件）创建替换 Pod，并且特性门控 `ProbeTerminationGracePeriod`
被禁用时，API 服务器会忽略探针级别的 `terminationGracePeriodSeconds` 字段设置， 被禁用时，即使 Pod 或 Pod 模板指定了 `terminationGracePeriodSeconds` 字段，
即使 Pod 或 Pod 模板指定了它。 API 服务器也会忽略探针级别的 `terminationGracePeriodSeconds` 字段设置。
{{< /note >}}
例如: 例如:
@ -851,7 +863,7 @@ spec:
Probe-level `terminationGracePeriodSeconds` cannot be set for readiness probes. Probe-level `terminationGracePeriodSeconds` cannot be set for readiness probes.
It will be rejected by the API server. It will be rejected by the API server.
--> -->
探测器层面的 `terminationGracePeriodSeconds` 不能用于就绪态探针。 探针层面的 `terminationGracePeriodSeconds` 不能用于就绪态探针。
这一设置将被 API 服务器拒绝。 这一设置将被 API 服务器拒绝。
## {{% heading "whatsnext" %}} ## {{% heading "whatsnext" %}}