Kubernetes存活与就绪探针差异及配置疑问（含/ping端点场景）

一、核心差异 #

• 存活探针（Liveness Probe）：聚焦容器本身的"存活状态"——判断进程是否还能正常执行核心逻辑。一旦探测失败，Kubernetes会直接重启容器，用于解决进程死锁、卡死等"活着但不能干活"的问题。
• 就绪探针（Readiness Probe）：聚焦服务的"可用状态"——判断容器是否已经准备好接收并处理用户流量。一旦探测失败，Kubernetes会把该容器从关联Service的端点列表中移除，不再转发流量给它，直到探测恢复正常。

二、是否可复用/ping端点？ #

完全可以复用你的/ping端点。因为/ping返回pong既证明了进程存活（能处理请求），也证明了服务就绪（可以响应请求）。但要注意：两者的配置参数必须根据各自的职责分开调整，不能直接用一套参数。

三、配置逻辑详解（你的方案是否合理？） #

你提到的就绪探针设更长初始延迟、存活探针设更低失败阈值是非常合理的配置，原因如下：

• 就绪探针长初始延迟：应用启动阶段通常需要完成初始化操作（比如加载配置、建立数据库连接、预热缓存），这段时间即使进程活着，/ping可能也无法正常响应。给就绪探针设置较长的initialDelaySeconds（比如30秒），能避免K8s误判应用未就绪，提前把容器加入服务端点导致流量报错。
• 存活探针低失败阈值：存活探针的作用是快速发现容器异常。如果设置较低的failureThreshold（比如2次），一旦/ping探测失败，K8s会立即重启容器，最大程度减少服务不可用的时间。相比之下，就绪探针的失败阈值可以稍高（比如3-5次），避免因临时网络波动或短时间资源耗尽导致容器被误移出服务端点。

举个配置示例（复用/ping端点）：

livenessProbe:
  httpGet:
    path: /ping
    port: 8080
  initialDelaySeconds: 10  # 启动后10秒开始探测，比就绪探针短
  periodSeconds: 5         # 每5秒探测一次
  failureThreshold: 2      # 失败2次就重启容器

readinessProbe:
  httpGet:
    path: /ping
    port: 8080
  initialDelaySeconds: 30  # 等待应用完成初始化再探测
  periodSeconds: 5
  failureThreshold: 4      # 允许短暂探测失败，避免误操作

四、是否可省略存活探针，依赖PID1崩溃自动重启？ #

如果完全排除死锁、进程卡死这类"进程存活但无法工作"的场景，确实可以依赖Kubernetes的默认行为——监控容器内的PID1进程，一旦进程退出就自动重启容器。但实际生产环境中，这类场景并不少见：比如内存泄漏导致应用卡死、线程池耗尽无法处理请求、依赖的外部服务挂掉导致应用阻塞等，这些情况PID1进程还活着，但/ping已经无法正常响应。此时存活探针能及时发现问题并重启容器，恢复服务可用性。

所以除非你的应用绝对不会出现"活着但不能干活"的情况，否则建议还是配置存活探针，提升服务的可靠性。

内容的提问来源于stack exchange，提问作者mafra