本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 配置探测器和负载均衡器运行状况检查
<a name="probes-checks"></a>

除了负载均衡器运行状况检查外，Kubernetes 还提供了多种执行应用程序运行状况检查的方法。你可以将以下 Kubernetes 内置探测器与负载均衡器运行状况检查一起运行，作为容器上下文中的命令或者作为对 kubelet 或主机 IP 地址的 HTTP/TCP 探测器。

存活探测器和就绪探测器应该不同且独立（或者至少具有不同的超时值）。如果应用程序存在临时问题，则就绪探测器会将该 pod 标记为未就绪，直到问题得到解决。如果存活探测器设置不正确，则存活探测器可能会终止 pod。

## 启动探测
<a name="startup-probe"></a>

使用启动探测器来保护初始化周期较长的应用程序。在启动探测成功之前，其他探测器将处于禁用状态。

你可以定义 Kubernetes 等待应用程序启动的最长时间。如果在配置的最长时间之后，Pod 仍然无法通过启动探测，则应用程序将被终止，并创建一个新的 Pod。

当应用程序的启动时间不可预测时，请使用启动探针。如果您知道应用程序需要 10 秒钟才能启动，请`initialDelaySeconds`改用存活探测器或就绪探测器。

## 活性探测
<a name="liveness-probe"></a>

使用活动探测器来检测应用程序问题或进程是否正常运行。活跃探测器可以检测到死锁情况，即进程继续运行但应用程序无响应。使用活性探测器时，请执行以下操作：
+ `initialDelaySeconds`用于延迟第一次探测。
+ 不要为存活和就绪探测器设置相同的规格。
+ 不要将存活探测器配置为依赖于 pod 外部因素（例如数据库）。
+ 将活性探测器设置为特定`terminationGracePeriodSeconds`。有关更多信息，请参阅 [Kubernetes 文档](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)。

## 准备情况调查
<a name="readiness-probe"></a>

使用就绪探测器检测以下内容：
+ 应用程序是否准备好接受流量
+ 部分可用性，即应用程序可能暂时不可用，但预计在某个操作完成后会恢复正常

就绪探测器有助于确保应用程序配置和依赖关系在没有问题或错误的情况下运行，以便应用程序可以为流量提供服务。但是，配置不当的就绪探测器可能会导致中断，而不是阻止中断。依赖于外部因素（例如与数据库的连接）的就绪探测可能会导致所有 Pod 都无法通过探测。此类故障可能导致中断，并可能导致从后端服务到使用故障 pod 的其他服务发生级联故障。

## 入口资源和负载均衡器运行状况检查
<a name="health-checks"></a>

Application Load Balancer 和 Kubernetes `ingress` 提供运行状况检查功能。对于 Application Load Balancer 运行状况检查，请指定目标端口和路径。

**注意**  
对于 Kubernetes 来说`ingress`，注销会有延迟。Application Load Balancer 的默认值为 300 秒。考虑使用与准备探测相同的值来设置入口资源或负载均衡器运行状况检查。

NGINX 还提供运行状况检查。有关更多信息，请参阅 [NGINX 文档](https://nginx.org/en/docs/http/load_balancing.html#nginx_load_balancing_health_checks)。

Istio 的入口和出口网关没有与 NGINX 的 HTTP 运行状况检查相提并论的运行状况检查机制。但是，您可以使用 [Istio 断路器或`DestinationRule`异](https://istio.io/latest/docs/tasks/traffic-management/circuit-breaking/)常值检测来实现类似的功能。

有关更多信息，请参阅 *Amazon EKS 最佳实践指南*中的[可用性和 Pod 生命周期](https://docs.aws.amazon.com/eks/latest/best-practices/load-balancing.html#_availability_and_pod_lifecycle)。