Kubernetes（k8s）中的探针是一种健康检查机制，用于监测Pod内容器的运行状况。主要包括以下三种类型的探针：
1、存活探针（Liveness Probe）
2、就绪探针（Readiness Probe）
3、启动探针（Startup Probe）（自1.16版本引入）
Kubernetes (k8s) 的启动探针（StartupProbe）主要用于检测容器内的应用是否已经成功启动并完成初始化任务。它的主要作用有以下几点：
延缓其他探针生效： 在容器启动初期，启动探针先于存活探针（LivenessProbe）和就绪探针（ReadinessProbe）生效。当启动探针配置存在时，kubelet不会执行存活和就绪探针，直到启动探针成功为止。这对于某些启动时间较长或者启动过程中有复杂初始化序列的应用程序来说非常重要，可以避免在应用还未完全启动时就被误判为不健康或就绪，进而被错误地重启或流量过早涌入。
防止频繁重启： 若应用启动期间，存活探针或就绪探针就开始工作，而此时应用可能还没有完全启动成功，这两个探针可能会因为应用未能及时响应而触发容器重启，造成不必要的服务中断和循环重启。启动探针的存在可以有效地防止此类情况的发生。
确保应用稳定： 启动探针使得Kubernetes能够在应用真正启动完毕后才将其视为健康的，并开始接受流量，从而保障了集群中应用服务的稳定性。
Kubernetes（k8s）中的就绪探针（Readiness Probe）主要作用是检测容器是否已经准备好对外提供服务。具体来说：
状态评估： 就绪探针会定期对容器进行检查，以确定容器内应用程序是否完成了必要的初始化工作，并且能够处理来自外部的请求或流量。
流量路由控制： 当就绪探针成功时，表示该容器内部的应用程序已处于可接受请求的状态，此时kubelet会将该容器标记为“就绪”状态，Service将会将其IP地址添加到后端服务列表中，允许Service开始将网络流量转发至这个Pod。
避免无效请求： 如果就绪探针失败，则意味着容器可能还在启动过程中、正在重启服务、或者由于某种原因暂时无法正常响应请求。在这种情况下，kubelet会将容器从Service的后端池中移除，确保不会向其发送任何用户请求，从而避免了因应用未准备完毕而引起的错误响应和用户体验下降。
平滑过渡： 通过就绪探针，Kubernetes可以实现滚动更新或部署过程中的平滑过渡，新版本的容器在通过就绪探针验证前，不会承担任何实际流量，直到它们完全启动并做好处理请求的准备。
总之，就绪探针是Kubernetes中用于保证服务质量的关键机制之一，它使得集群能够根据容器的实际运行状况动态调整流量分配，确保系统的整体稳定性和可用性。
Kubernetes（k8s）中的存活探针（Liveness Probe）主要作用是检测容器内主进程或服务是否仍然运行正常且响应健康检查。具体来说：
监控状态： 存活探针会定期对容器内的应用进行检查，以判断其是否处于“存活”状态，即应用程序没有崩溃、死锁或其他不可恢复的错误。
自动恢复： 当存活探针检测失败时，kubelet将认为该容器内的主进程已经不再健康或者已停止提供预期的服务。此时，kubelet会根据Pod的重启策略来决定是否应该重新启动这个容器。通过这种方式，存活探针可以帮助实现故障自愈，及时恢复服务的可用性。
避免僵死进程： 如果一个容器由于内部错误而进入不可用状态但并未退出，存活探针能够识别出这种情况，并触发容器重启，从而避免资源被僵死进程占用。
保持服务质量： 通过持续监控和及时重启不健康的容器，存活探针有助于确保整个集群的服务质量，减少因单个容器异常导致的整体服务失效的可能性。
总之，在Kubernetes中，存活探针是一种关键的健康管理机制，用于确保容器内应用程序始终维持在可接受的工作状态，当出现问题时能迅速采取行动修复问题。
在Kubernetes（k8s）中，探针包括存活探针（Liveness Probe）、就绪探针（Readiness Probe）和启动探针（Startup Probe），它们执行的时间点不同：
启动探针（Startup Probe）：
initialDelaySeconds开始探测。successThreshold次数时，kubelet会停止执行启动探针，并开始执行存活探针和就绪探针。存活探针（Liveness Probe）：
initialDelaySeconds开始执行。如果配置了启动探针（Startup Probe），在启动探针成功后等待initialDelaySeconds开始探测。就绪探针（Readiness Probe）：
initialDelaySeconds开始执行。如果配置了启动探针（Startup Probe），在启动探针成功后等待initialDelaySeconds开始探测。livenessProbe:
httpGet:
path: /health-check
port: 8080
httpHeaders: # 可选，用于设置自定义HTTP头部
- name: Custom-Header
value: Value
livenessProbe:
tcpSocket:
port: 8080
livenessProbe:
exec:
command:
- cat
- /tmp/health
Kubernetes（k8s）中的探针都支持一些通用的参数来定义它们的行为。以下是这些探针通常使用的配置参数：
livenessProbe:
# 类型选择器，可以选择 httpGet、tcpSocket 或 exec 中的一种
httpGet: # HTTP GET 请求方式
path: /health # 要请求的路径
port: 8080 # 要请求的端口
httpHeaders: # 可选，HTTP 请求头列表
- name: X-Custom-Header
value: Awesome
tcpSocket: # TCP Socket 检查方式
port: 8080 # 要连接的端口
exec: # 执行命令检查方式
command:
- cat
- /tmp/healthy
# 基本探测间隔参数：
initialDelaySeconds: 30 # 容器启动后延迟多少秒开始执行第一次探测，默认为0秒
periodSeconds: 10 # 探测的时间间隔，即每隔多少秒执行一次，默认为10秒（最小值1秒）
# 控制何时判断容器健康或不健康的阈值参数：
timeoutSeconds: 1 # 探测超时时间，默认为1秒（最小值1秒）
successThreshold: 1 # 在连续失败之后需要多少次连续成功才能认为容器是健康的，默认为1
failureThreshold: 3 # 连续失败多少次才触发相应动作（如重启容器对于存活探针）
readinessProbe: # 就绪探针配置类似
startupProbe: # 启动探针配置也相似，不过主要用于检测应用是否完成启动过程
启动探针在Kubernetes 1.16版本以后引入，其配置参数与存活探针和就绪探针基本相同，但主要作用是在容器启动阶段确定应用程序是否已经准备就绪，一旦启动探针确认应用程序启动成功，就会停止执行并切换到其他探针继续进行监控。
1、启动探针（Startup Probe）：推荐配置
不需要配置的情况：对于那些启动速度快、无需复杂初始化或依赖检查就能立即对外提供服务的应用程序来说，启动探针可能不是必需的。在这种情况下，可以仅依赖存活探针（Liveness Probe）和就绪探针（Readiness Probe）来确保容器运行状态和服务可用性。
建议配置的情况：然而，对于那些启动时间较长或者有复杂的初始化过程，需要一定时间才能准备好对外提供服务的应用程序来说，配置启动探针是很有帮助的。启动探针可以在应用启动过程中阻止kubelet进行不必要的健康检查（如存活探针和就绪探针），直到应用程序完成必要的启动步骤并真正准备就绪为止。
综上所述，虽然启动探针不是Kubernetes中每个Pod都必须设置的部分，但在特定应用场景下，为了更精确地管理Pod的生命周期和流量引入时机，合理配置启动探针是非常有益的。
2、存活探针（Liveness Probe）：强烈推荐配置
不需要配置的情况：对于一些简单、始终运行且没有潜在状态问题的应用程序来说，如果不设置存活探针可能也不会影响其正常运行。在这种情况下，如果容器一旦启动就会持续提供服务，并且在出现任何故障时都会自行退出或重启，那么可以不使用存活探针。
建议配置的情况：然而，对于大多数生产环境中的复杂应用，尤其是那些长时间运行后可能会遇到内部错误导致无法响应请求或者进入死锁状态的应用，配置存活探针是非常重要的。通过存活探针，Kubernetes 能够及时检测到这类问题并自动重启容器，从而保证服务的高可用性和稳定性。
总结起来，虽然不是每个 Pod 必须都要设置存活探针，但在实际部署中强烈推荐针对可能出现僵死状态的应用进行健康检查以确保容器始终处于可提供服务的状态。
3、就绪探针（Readiness Probe）：推荐配置
不需要配置的情况：对于那些启动后立即就能处理客户端请求且不涉及任何额外初始化或依赖检查的应用程序，可以不设置就绪探针。在这种情况下，应用一旦运行起来就可以被路由流量。
建议配置的情况：然而，对于许多生产级别的复杂应用来说，特别是在启动过程中需要加载数据、建立连接或者完成其他预热操作才能对外提供服务时，配置就绪探针是至关重要的。通过就绪探针，Kubernetes 可以确保只有准备完毕并能够正确响应请求的容器才会被添加到 Service 的负载均衡池中，从而避免将流量导向还未完全准备好的 Pod，提高服务质量和用户体验。
总之，虽然不是每个Pod都必须设置就绪探针，但在大多数实际部署场景下，为了更好地管理服务可用性状态和防止未就绪容器接受外部请求，推荐为具有明显初始化过程的应用程序设置就绪探针。
1、启动探针+存活探针
现象：启动探针在pod启动后等待initialDelaySeconds后开始探测，探测成功后就会退出，pod会立马进入就绪状态即endpoints中加入pod的地址即可接收流量。启动探针探测失败次数达到failureThreshold后才会重启pod。启动探针成功退出后存活探针等待initialDelaySeconds后启动。存活探针在pod运行期间如探测失败达到failureThreshold后则重启pod。
缺点：对于一些项目启动后还需要一些初始化的工作，如不配置就绪探针，启动探针探测成功后会立即接收流量，此时项目还未初始化完成会造成项目无法处理请求。
2、就绪探针+存活探针
现象：就绪探针和存活探针分别等待各自的initialDelaySeconds后开始探测，就绪探针探测成功pod进入就绪状态即endpoints中加入pod的地址即可接收流量，探测失败failureThreshold后将从endpoints中去掉pod的地址即停止接收流量。存活探针如探测失败达到failureThreshold后则重启pod。
缺点：对于一些启动时间比较长的项目，如不配置启动探针可能会造成存活探针探测失败而导致pod频繁重启。
3、启动探针+就绪探针+存活探针
现象：启动探针在pod启动后等待initialDelaySeconds后开始探测，探测成功后就会退出，此时pod不会进入就绪状态。就绪探针等待initialDelaySeconds后开始探测，探测成功后pod进入就绪状态即endpoints中加入pod的地址即可接收流量，探测失败则流量无法进入。同时存活探针等待initialDelaySeconds后也开始探测，如探测失败达到failureThreshold后则重启pod。
#由于启动探针探测成功后就会退出，所以为了保证项目成功且快速启动，可以将initialDelaySeconds、periodSeconds设置小，failureThreshold设置大
startupProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
failureThreshold: 20
timeoutSeconds: 5
successThreshold: 1
#就绪探针在启动探针探测成功后执行，可以预留30s等待其他初始化工作
readinessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 30
periodSeconds: 5
failureThreshold: 3
timeoutSeconds: 5
successThreshold: 1
#存活探针探测失败会导致pod重启，因此将failureThreshold设置比就绪探针大，这样如果项目有问题可以先切断流量
livenessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 30
periodSeconds: 5
failureThreshold: 10
timeoutSeconds: 5
successThreshold: 1