1. 探针分类
针对运行中的容器，kubelet 可以选择是否执行以下三种探针，以及如何针对探测结果作出反应：
livenessProbe：指示容器是否正在运行。
如果存活态探测失败，则 kubelet 会杀死容器， 并且容器将根据其重启策略决定未来。
如果容器不提供存活探针， 则默认状态为 Success。
readinessProbe：指示容器是否准备好为请求提供服务。
如果就绪态探测失败， 端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。也就是 svc 负载均衡会将这个 Pod 删掉，不提供服务
初始延迟之前的就绪态的状态值默认为 Failure。
如果容器不提供就绪态探针，则默认状态为 Success。
startupProbe: 指示容器中的应用是否已经启动。
如果提供了启动探针，则所有其他探针都会被 禁用，直到此探针成功为止。
如果启动探测失败，kubelet 将杀死容器，而容器依其 重启策略进行重启。
如果容器没有提供启动探测，则默认状态为 Success。
2. 每个探针都有三种处理程序
探针 是由 kubelet 对容器执行的定期诊断, 要执行诊断, 有三种类型的处理程序：
ExecAction： 在容器内执行指定命令。
如果命令退出时返回码为 0 则认为诊断成功。
TCPSocketAction： 对容器的 IP 地址上的指定端口执行 TCP 检查。
如果端口打开，则诊断被认为是成功的。
三次握手是否建立成功
HTTPGetAction： 对容器的 IP 地址上指定端口和路径执行 HTTP Get 请求。
3.
所有探针类型的通用配置属性：
initialDelaySeconds ：容器启动后第一次执行探测时需要等待多少秒。
：执行探测的频率。默认是10秒，最小1秒。
timeoutSeconds ：探测超时时间。默认1秒，最小1秒。
successThreshold ：探测失败后，最少连续探测成功多少次才被认定为成功。默认是1。对于liveness必须是1。最小值是1
failureThreshold ：探测成功后，最少连续探测失败多少次才被认定为失败。默认是3。最小值是1
4. 探针的探测结果
每次探测都将获得以下三种结果之一：
Success（成功）：容器通过了诊断。
Failure（失败）：容器未通过诊断。
Unknown（未知）：诊断失败，因此不会采取任何行动。
5. 探针 yaml 模板
5.1
使用场景：对于所包含的容器需要较长时间才能启动就绪的 Pod 而言，启动探针是有用的。
作用：不再需要配置间隔时间来每隔多长时间探测一次，利用启动探针：startupProbe， 对启动期间的容器执行探测，从而允许使用远远超出存活态时间间隔所允许的时长。
也就是说，livenessProbe 和 readnessProbe 探针 都是一开始就开始探测，有些 pod 需要额外的时间来启动，再启动后，在进行探测，
模板：
说明：
应用程序将有最大的 5 分钟（30×10＝300秒）完成它的启动。
每隔 10 秒探测一次，探测从失败到成功需要 30 次，因此，有 30*10=300秒
一旦启动探测成功一次，liveness 探测就会接管
5.2
livenessProbe 探针 探测失败后，根据 Pod 重启策略来进行处理。
readinessProbe 探针 探测失败后，会将 Pod 从 svc 的负载均衡列表中删除。
说明：
容器启动需要后会创建 /tmp/healthy 文件，30 秒后删除该文件
命令探测成功与否，是根据运行该 linux 命令的返回值，0表示成功，其他表示失败
而 livenessProbe 探针 ，容器第一次探测的时间是 5 秒，每隔五秒探测一次
livenessProbe 探针的探测命令时，查看 /tmp/healthy ，前 30 秒时成功的，而 30 秒后，删除文件后，探测失败，在探测 3 次，也就是花费 15s
注意：这里会在大概 70s 探测失败重启，因为 terminationGracePeriodSeconds 默认是 30 秒，也就是终止 pod 时会给 pod 30s 的处理时间。然后终止 Pod 。
2. livenessProbe 探针发送 http 的模板
3. livenessProbe 探针发送 tcp 的模板
评论