diff --git a/content/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 9e3044c47f..155c9a0eac 100644 --- a/content/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -1,5 +1,5 @@ --- -title: 配置存活、就绪和启动探测器 +title: 配置存活、就绪和启动探针 content_type: task 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 despite bugs. --> -这篇文章介绍如何给容器配置活跃（Liveness）、就绪（Readiness）和启动（Startup）探测器。 +这篇文章介绍如何给容器配置活跃（Liveness）、就绪（Readiness）和启动（Startup）探针。 [kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) -使用存活探测器来确定什么时候要重启容器。 -例如，存活探测器可以探测到应用死锁（应用程序在运行，但是无法继续执行后面的步骤）情况。 +使用存活探针来确定什么时候要重启容器。 +例如，存活探针可以探测到应用死锁（应用程序在运行，但是无法继续执行后面的步骤）情况。 重启这种状态下的容器有助于提高应用的可用性，即使其中存在缺陷。 -kubelet 使用就绪探测器可以知道容器何时准备好接受请求流量，当一个 Pod +kubelet 使用就绪探针可以知道容器何时准备好接受请求流量，当一个 Pod 内的所有容器都就绪时，才能认为该 Pod 就绪。 这种信号的一个用途就是控制哪个 Pod 作为 Service 的后端。 若 Pod 尚未就绪，会被从 Service 的负载均衡器中剔除。 -kubelet 使用启动探测器来了解应用容器何时启动。 -如果配置了这类探测器，你就可以控制容器在启动成功后再进行存活性和就绪态检查， -确保这些存活、就绪探测器不会影响应用的启动。 -启动探测器可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被杀掉。 +kubelet 使用启动探针来了解应用容器何时启动。 +如果配置了这类探针，你就可以控制容器在启动成功后再进行存活性和就绪态检查， +确保这些存活、就绪探针不会影响应用的启动。 +启动探针可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被杀掉。 ## {{% 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. 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} 许多长时间运行的应用最终会进入损坏状态，除非重新启动，否则无法被恢复。 -Kubernetes 提供了存活探测器来发现并处理这种情况。 +Kubernetes 提供了存活探针来发现并处理这种情况。 -在本练习中，你会创建一个 Pod，其中运行一个基于 `k8s.gcr.io/busybox` 镜像的容器。 +在本练习中，你会创建一个 Pod，其中运行一个基于 `registry.k8s.io/busybox` 镜像的容器。 下面是这个 Pod 的配置文件。 {{< codenew file="pods/probe/exec-liveness.yaml" >}} @@ -123,16 +123,16 @@ kubectl describe pod liveness-exec -输出结果表明还没有存活探测器失败： +输出结果表明还没有存活探针失败： ``` -FirstSeen LastSeen Count From SubobjectPath Type Reason Message ---------- -------- ----- ---- ------------- -------- ------ ------- -24s 24s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0 -23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox" -23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox" -23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined] -23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e +Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal Scheduled 11s default-scheduler Successfully assigned default/liveness-exec to node01 + Normal Pulling 9s kubelet, node01 Pulling image "registry.k8s.io/busybox" + Normal Pulled 7s kubelet, node01 Successfully pulled image "registry.k8s.io/busybox" + Normal Created 7s kubelet, node01 Created container liveness + Normal Started 7s kubelet, node01 Started container liveness ``` -在输出结果的最下面，有信息显示存活探测器失败了，这个失败的容器被杀死并且被重建了。 +在输出结果的最下面，有信息显示存活探针失败了，这个失败的容器被杀死并且被重建了。 ``` -FirstSeen LastSeen Count From SubobjectPath Type Reason Message ---------- -------- ----- ---- ------------- -------- ------ ------- -37s 37s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0 -36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox" -36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox" -36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined] -36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e -2s 2s 1 {kubelet worker0} spec.containers{liveness} Warning Unhealthy Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal Scheduled 57s default-scheduler Successfully assigned default/liveness-exec to node01 + Normal Pulling 55s kubelet, node01 Pulling image "registry.k8s.io/busybox" + Normal Pulled 53s kubelet, node01 Successfully pulled image "registry.k8s.io/busybox" + Normal Created 53s kubelet, node01 Created container liveness + Normal Started 53s kubelet, node01 Started container liveness + 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 ``` ## 定义一个存活态 HTTP 请求接口 {#define-a-liveness-HTTP-request} 另外一种类型的存活探测方式是使用 HTTP GET 请求。 -下面是一个 Pod 的配置文件，其中运行一个基于 `k8s.gcr.io/liveness` 镜像的容器。 +下面是一个 Pod 的配置文件，其中运行一个基于 `registry.k8s.io/liveness` 镜像的容器。 {{< 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 the container has been restarted: --> -10 秒之后，通过查看 Pod 事件来确认活跃探测器已经失败，并且容器被重新启动了。 +10 秒之后，通过查看 Pod 事件来确认活跃探针已经失败，并且容器被重新启动了。 ```shell kubectl describe pod liveness-http @@ -312,13 +313,13 @@ will be restarted. To try the TCP liveness check, create a Pod: --> 如你所见，TCP 检测的配置和 HTTP 检测非常相似。 -下面这个例子同时使用就绪和存活探测器。kubelet 会在容器启动 5 秒后发送第一个就绪探测。 -探测器会尝试连接 `goproxy` 容器的 8080 端口。 -如果探测成功，这个 Pod 会被标记为就绪状态，kubelet 将继续每隔 10 秒运行一次检测。 +下面这个例子同时使用就绪和存活探针。kubelet 会在容器启动 5 秒后发送第一个就绪探针。 +探针会尝试连接 `goproxy` 容器的 8080 端口。 +如果探测成功，这个 Pod 会被标记为就绪状态，kubelet 将继续每隔 10 秒运行一次探测。 -除了就绪探测，这个配置包括了一个存活探测。 +除了就绪探针，这个配置包括了一个存活探针。 kubelet 会在容器启动 15 秒后进行第一次存活探测。 -与就绪探测类似，活跃探测器会尝试连接 `goproxy` 容器的 8080 端口。 +与就绪探针类似，活跃探针会尝试连接 `goproxy` 容器的 8080 端口。 如果存活探测失败，容器会被重新启动。 ```shell @@ -328,7 +329,7 @@ kubectl apply -f https://k8s.io/examples/pods/probe/tcp-liveness-readiness.yaml -15 秒之后，通过看 Pod 事件来检测存活探测器： +15 秒之后，通过看 Pod 事件来检测存活探针： ```shell kubectl describe pod goproxy @@ -337,7 +338,7 @@ kubectl describe pod goproxy -## 定义 gRPC 活跃探测器 +## 定义 gRPC 活跃探针 {{< 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 on a non-default service, you must also specify the `service`. --> -要使用 gRPC 探测器，必须配置 `port` 属性。如果健康状态端点配置在非默认服务之上， +要使用 gRPC 探针，必须配置 `port` 属性。如果健康状态端点配置在非默认服务之上， 你还必须设置 `service` 属性。 {{< note >}} -与 HTTP 和 TCP 探测器不同，gRPC 探测不能使用命名端口或定制主机。 +与 HTTP 和 TCP 探针不同，gRPC 探测不能使用命名端口或定制主机。 {{< /note >}} 配置问题（例如：错误的 `port` 和 `service`、未实现健康检查协议） -都被认作是探测失败，这一点与 HTTP 和 TCP 探测器类似。 +都被认作是探测失败，这一点与 HTTP 和 TCP 探针类似。 ```shell 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 健康探测通常使用 [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/)所描述。 -内置的 gRPC 探测器行为与 `grpc-health-probe` 所实现的行为类似。 -从 `grpc-health-probe` 迁移到内置探测器时，请注意以下差异： +内置的 gRPC 探针行为与 `grpc-health-probe` 所实现的行为类似。 +从 `grpc-health-probe` 迁移到内置探针时，请注意以下差异： -- 内置探测器运行时针对的是 Pod 的 IP 地址，不像 `grpc-health-probe` +- 内置探针运行时针对的是 Pod 的 IP 地址，不像 `grpc-health-probe` 那样通常针对 `127.0.0.1` 执行探测； 请一定配置你的 gRPC 端点使之监听于 Pod 的 IP 地址之上。 -- 内置探测器不支持任何身份认证参数（例如 `-tls`）。 -- 对于内置的探测器而言，不存在错误代码。所有错误都被视作探测失败。 +- 内置探针不支持任何身份认证参数（例如 `-tls`）。 +- 对于内置的探针而言，不存在错误代码。所有错误都被视作探测失败。 - 如果 `ExecProbeTimeout` 特性门控被设置为 `false`，则 `grpc-health-probe` 不会考虑 `timeoutSeconds` 设置状态（默认值为 1s）， - 而内置探测器则会在超时时返回失败。 + 而内置探针则会在超时时返回失败。 ## 使用命名端口 {#use-a-named-port} -对于 HTTP 或者 TCP 存活检测可以使用命名的 -[`port`](/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#ports)。 +对于 HTTP 和 TCP 存活检测可以使用命名的 +[`port`](/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#ports)（gRPC 探针不支持使用命名端口）。 + +例如： ```yaml ports: @@ -464,7 +469,7 @@ worse case startup time. 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 Services. --> -## 定义就绪探测器 {#define-readiness-probes} +## 定义就绪探针 {#define-readiness-probes} 有时候，应用会暂时性地无法为请求提供服务。 例如，应用在启动时可能需要加载大量的数据或配置文件，或是启动后要依赖等待外部服务。 在这种情况下，既不想杀死应用，也不想给它发送请求。 -Kubernetes 提供了就绪探测器来发现并缓解这些情况。 +Kubernetes 提供了就绪探针来发现并缓解这些情况。 容器所在 Pod 上报还未就绪的信息，并且不接受通过 Kubernetes Service 的流量。 {{< note >}} -就绪探测器在容器的整个生命周期中保持运行状态。 +就绪探针在容器的整个生命周期中保持运行状态。 {{< /note >}} {{< caution >}} -活跃探测器 **不等待** 就绪性探测器成功。 -如果要在执行活跃探测器之前等待，应该使用 `initialDelaySeconds` 或 `startupProbe`。 +活跃探针 **不等待** 就绪性探针成功。 +如果要在执行活跃探针之前等待，应该使用 `initialDelaySeconds` 或 `startupProbe`。 {{< /caution >}} -就绪探测器的配置和存活探测器的配置相似。 +就绪探针的配置和存活探针的配置相似。 唯一区别就是要使用 `readinessProbe` 字段，而不是 `livenessProbe` 字段。 ```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 for it, and that containers are restarted when they fail. --> -HTTP 和 TCP 的就绪探测器配置也和存活探测器的配置完全相同。 +HTTP 和 TCP 的就绪探针配置也和存活探针的配置完全相同。 就绪和存活探测可以在同一个容器上并行使用。 两者共同使用，可以确保流量不会发给还未就绪的容器，当这些探测失败时容器会被重新启动。 @@ -575,7 +580,7 @@ HTTP 和 TCP 的就绪探测器配置也和存活探测器的配置完全相同 -## 配置探测器 {#configure-probes} +## 配置探针 {#configure-probes} -* `initialDelaySeconds`：容器启动后要等待多少秒后才启动存活和就绪探测器， +* `initialDelaySeconds`：容器启动后要等待多少秒后才启动存活和就绪探针， 默认是 0 秒，最小值是 0。 * `periodSeconds`：执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1。 * `timeoutSeconds`：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。 -* `successThreshold`：探测器在失败后，被视为成功的最小连续成功数。默认值是 1。 +* `successThreshold`：探针在失败后，被视为成功的最小连续成功数。默认值是 1。 存活和启动探测的这个值必须是 1。最小值是 1。 * `failureThreshold`：当探测失败时，Kubernetes 的重试次数。 对存活探测而言，放弃就意味着重新启动容器。 @@ -768,9 +773,9 @@ to resolve it. -### 探测器层面的 `terminationGracePeriodSeconds` +### 探针层面的 `terminationGracePeriodSeconds` -{{< feature-state for_k8s_version="v1.22" state="beta" >}} +{{< feature-state for_k8s_version="v1.25" state="beta" >}} -在 1.21 及更高版本中，当特性门控 `ProbeTerminationGracePeriod` 被启用时， -用户可以指定一个探测器层面的 `terminationGracePeriodSeconds` 作为探测器规约的一部分。 -当该特性门控被启用，并且 Pod 层面和探测器层面的 `terminationGracePeriodSeconds` -都已设置，kubelet 将使用探测器层面设置的值。 +在 1.21 及更高版本中，用户可以指定一个探针层面的 `terminationGracePeriodSeconds` +作为探针规约的一部分。 +当 Pod 层面和探针层面的 `terminationGracePeriodSeconds` +都已设置，kubelet 将使用探针层面设置的值。 -在 Kubernetes 1.22 中，`ProbeTerminationGracePeriod` 特性门控只能用在 API 服务器上。 -kubelet 始终遵守探针级别 `terminationGracePeriodSeconds` 字段 -（如果它存在于 Pod 上）。 +{{< note >}} +从 Kubernetes 1.25 开始，默认启用 `ProbeTerminationGracePeriod` 特性。 +选择禁用此特性的用户，请注意以下事项: + +* `ProbeTerminationGracePeriod` 特性门控只能用在 API 服务器上。 + kubelet 始终优先选用探针级别 `terminationGracePeriodSeconds` 字段 + （如果它存在于 Pod 上）。 -如果你已经为现有 Pod 设置了 `terminationGracePeriodSeconds` -字段并且不再希望使用针对每个探针的终止宽限期，则必须删除现有的这类 Pod。 +* 如果你已经为现有 Pod 设置了 `terminationGracePeriodSeconds` + 字段并且不再希望使用针对每个探针的终止宽限期，则必须删除现有的这类 Pod。 -当你（或控制平面或某些其他组件）创建替换 Pod，并且特性门控 `ProbeTerminationGracePeriod` -被禁用时，API 服务器会忽略探针级别的 `terminationGracePeriodSeconds` 字段设置， -即使 Pod 或 Pod 模板指定了它。 +* 当你（或控制平面或某些其他组件）创建替换 Pod，并且特性门控 `ProbeTerminationGracePeriod` + 被禁用时，即使 Pod 或 Pod 模板指定了 `terminationGracePeriodSeconds` 字段， + API 服务器也会忽略探针级别的 `terminationGracePeriodSeconds` 字段设置。 +{{< /note >}} 例如: @@ -851,7 +863,7 @@ spec: Probe-level `terminationGracePeriodSeconds` cannot be set for readiness probes. It will be rejected by the API server. --> -探测器层面的 `terminationGracePeriodSeconds` 不能用于就绪态探针。 +探针层面的 `terminationGracePeriodSeconds` 不能用于就绪态探针。 这一设置将被 API 服务器拒绝。 ## {{% heading "whatsnext" %}}