pod存活探针及重要参数

借助了chatgpt的回答

1、概念

Pod的就绪探针（readinessProbe）和存活探针（livenessProbe）是用于监测和管理Pod健康状态的两种不同类型的探测器。

就绪探针（readinessProbe）用于确定Pod是否已经准备好接收流量。它检查Pod内部的某个服务或端口是否可用，如果就绪探针失败，Pod将被从Service的负载均衡中剔除，不再接收流量。就绪探针的目的是确保Pod已经完成启动和初始化过程，可以正常处理请求。

存活探针（livenessProbe）用于确定Pod是否仍然运行正常。它检查Pod内部的某个服务或端口是否可用，如果存活探针失败，Kubernetes将尝试重新启动Pod，以恢复Pod的正常运行状态。存活探针的目的是检测并处理Pod内部的故障或异常情况，以确保Pod的持续可用性。

总结来说，就绪探针用于判断Pod是否已经准备好接收流量，而存活探针用于判断Pod是否仍然运行正常。它们的作用和目的不同，但都是为了确保Pod的健康状态和可用性。在Pod的配置中，可以同时配置就绪探针和存活探针，以实现全面的健康检查和管理。

2、常见配置

Pod探针中的各个参数及其含义如下：

readinessProbe（就绪探针）参数：

initialDelaySeconds：指定探测器在容器启动后延迟多少秒开始执行第一次探测。
periodSeconds：指定探测器执行探测的间隔时间，单位为秒。
timeoutSeconds：指定探测器等待探测结果的超时时间，单位为秒。
successThreshold：指定连续多少次成功的探测结果后，将Pod标记为就绪状态。
failureThreshold：指定连续多少次失败的探测结果后，将Pod标记为不就绪状态。

livenessProbe（存活探针）参数：

initialDelaySeconds：指定探测器在容器启动后延迟多少秒开始执行第一次探测。
periodSeconds：指定探测器执行探测的间隔时间，单位为秒。
timeoutSeconds：指定探测器等待探测结果的超时时间，单位为秒。
successThreshold：指定连续多少次成功的探测结果后，将Pod标记为存活状态。
failureThreshold：指定连续多少次失败的探测结果后，将Pod标记为不存活状态。
这些参数可以根据具体的需求进行配置，以确保Pod的健康状态。通过设置合适的探测间隔、超时时间和阈值，可以及时发现和处理容器的异常情况，确保应用程序的可用性和稳定性。

3、常见报错

3.1 Readiness probe failed: Get “http://10.170.xxx.xxx:8108/”: dial tcp 10.170.xxx.xxx:8108: connect: connection refused

根据错误信息来看，”connection refused” 表示连接被拒绝，这通常是由于网络故障或目标服务未正确启动导致的。

在这种情况下，就绪探针（readinessProbe）尝试通过发送HTTP GET请求到指定的地址（”http://10.170.xxx.xxx:8108/"）来检查Pod的就绪状态。然而，由于连接被拒绝，无法建立与目标服务的连接，因此就绪探针失败。

可能的原因包括：

目标服务未正确启动或未监听指定的端口（8108）。
Pod所在的网络出现故障，导致无法与目标服务进行通信。
您可以检查目标服务是否已正确启动，并确保它正在监听指定的端口。另外，您还可以检查网络配置和连接是否正常，以确保Pod能够与目标服务进行通信。

3.2 Liveness probe failed: Get “http://10.170.xxx.xxx:8108/”: dial tcp 10.170.xxx.xxx:8108: connect: connection refused
这个错误信息表明存活探针（livenessProbe）无法成功连接到指定的地址和端口。具体原因可能是以下几种情况之一：

目标地址和端口不可达：存活探针尝试连接的地址和端口无法被访问。可能是因为目标服务未启动、网络配置问题或防火墙规则等原因导致无法建立连接。

容器内部服务未正确启动：存活探针可能尝试连接的是容器内部的服务，而该服务在容器启动后未正确启动或未监听指定的端口。

网络延迟或故障：存活探针在连接目标地址和端口时遇到了网络延迟或故障，导致连接失败。

解决这个问题的方法取决于具体的情况。你可以尝试以下步骤来解决问题：

确保目标服务已正确启动并监听指定的端口。可以在容器内部执行命令或使用其他工具来验证服务的可用性。

检查网络配置和防火墙规则，确保目标地址和端口可以被访问。

如果是网络延迟或故障导致的问题，可以尝试调整存活探针的参数，如timeoutSeconds和periodSeconds，以适应网络环境。

如果问题仍然存在，可能需要进一步检查容器和网络配置，或者查看相关日志以获取更多的错误信息来定位问题。