企业官网建设流程全解析

我会从底层原理→每个参数的精确含义→常见坑点→生产级配置四个维度，把健康探测讲得明明白白。这是K8s实现零故障滚动更新和自动故障恢复的核心，90%的生产环境可用性问题都和健康探测配置不当有关。

一、先彻底搞懂：为什么默认健康检查完全不够用？

1. K8s默认的健康检查机制

K8s天生自带一个最基础的健康检查：

监控容器的主进程PID。如果主进程退出且退出码≠0，就认为容器故障，然后根据restartPolicy决定是否重启容器。

这个机制的致命缺陷：它只能检测"进程是否活着"，完全无法检测"服务是否可用"。

2. 生产环境中90%的故障场景，默认机制都检测不到

我给你举3个最常见的真实故障：

故障1：应用死锁/内存泄漏

• 现象：Java应用进程还在，CPU占用100%，但所有请求都超时
• 默认机制的表现：认为容器正常，不会重启
• 后果：服务完全不可用，直到人工介入

故障2：应用初始化未完成

• 现象：SpringBoot应用启动需要30秒（加载配置、连接数据库、初始化缓存），但Pod启动1秒后就被标记为Ready
• 默认机制的表现：立即把流量转发给这个Pod
• 后果：滚动更新时出现大量503错误，用户体验极差

故障3：数据库连接池耗尽

• 现象：应用进程正常，但所有数据库操作都超时，返回500错误
• 默认机制的表现：认为容器正常，不会重启也不会从负载中移除
• 后果：所有请求都失败，服务雪崩

这就是为什么我们必须配置自定义健康探测的原因！健康探测让K8s能够从应用的视角判断服务是否正常，而不仅仅是从进程的视角。

二、三种健康探测的底层原理与核心区别

K8s提供了三种互补的健康探测，它们各司其职，共同保证服务的可用性。

1. 启动探测（startupProbe）：专门解决慢启动问题

核心作用

一次性探测，只在容器启动阶段执行。它的唯一目的是：确认应用已经完成初始化，可以开始接收流量和其他探测。

工作原理

1. 容器启动后，startupProbe首先开始执行
2. 在startupProbe成功之前，所有其他探测（liveness和readiness）都会被完全禁用
3. 如果startupProbe在failureThreshold × periodSeconds时间内成功，则认为应用启动完成，然后启动liveness和readiness探测
4. 如果超过这个时间仍然失败，则kubelet会杀死容器，并根据restartPolicy重启容器

解决的核心问题

慢启动应用被livenessProbe误杀。

举个例子：

• 你的SpringBoot应用需要60秒才能启动完成
• 你配置了livenessProbe，initialDelaySeconds=30，periodSeconds=10，failureThreshold=3
• 那么livenessProbe会在容器启动30秒后开始执行，最多再等30秒（3×10），也就是总共60秒
• 但如果应用启动需要65秒，那么在第60秒时，livenessProbe会认为应用故障，杀死容器
• 然后容器重启，进入无限循环，永远无法启动成功

有了startupProbe之后：

• 你可以给startupProbe设置足够长的超时时间，比如failureThreshold=30，periodSeconds=5，总共150秒
• 只要应用在150秒内启动完成，livenessProbe就会正常开始工作
• 如果应用真的启动失败，150秒后也会被重启

必须配置startupProbe的场景

• Java应用（SpringBoot、SpringCloud）
• .NET应用
• 任何需要加载大量数据或初始化复杂依赖的应用

2. 存活性探测（livenessProbe）：检测应用是否"活着"

核心作用

持续探测，在容器的整个生命周期内执行。它的目的是：检测应用是否陷入了无法自愈的故障状态。

工作原理

1. 容器启动且startupProbe成功后，livenessProbe开始按照periodSeconds的间隔定期执行
2. 如果连续failureThreshold次探测失败，则认为容器故障
3. kubelet会杀死容器，并根据restartPolicy决定是否重启容器

什么情况应该让livenessProbe失败？

只有当应用无法自愈，必须重启才能恢复时，才应该让livenessProbe失败。比如：

• 应用死锁
• 内存泄漏导致OOM（虽然OOM会直接杀死进程，但有些情况下应用会卡住而不退出）
• 应用内部错误导致所有请求都失败

绝对不要让livenessProbe依赖外部服务（如数据库、Redis）。如果数据库挂了，你的应用不应该被重启，因为重启也解决不了问题，只会导致所有Pod都被重启，加剧故障。

3. 就绪性探测（readinessProbe）：检测应用是否"能干活"

核心作用

持续探测，在容器的整个生命周期内执行。它的目的是：检测应用是否已经准备好接收外部流量。

工作原理

1. 容器启动且startupProbe成功后，readinessProbe开始按照periodSeconds的间隔定期执行
2. 如果连续failureThreshold次探测失败，则认为应用暂时无法提供服务
3. kubelet会将这个Pod的IP从所有对应Service的Endpoint列表中移除，不再转发流量给它
4. 如果后续探测成功，则会将Pod重新加入Endpoint列表，恢复流量转发

什么情况应该让readinessProbe失败？

当应用暂时无法提供服务，但不需要重启时，应该让readinessProbe失败。比如：

• 应用正在加载缓存
• 数据库连接池耗尽
• 依赖的下游服务暂时不可用
• 应用正在处理大量请求，负载过高

readinessProbe是实现优雅滚动更新和流量熔断的核心。

4. 三种探针的执行顺序与关系（90%的人都搞错了）

这是最容易混淆的知识点，我用一张表给你讲清楚：

官方文档明确说明：

Liveness probes do not wait for readiness probes to succeed. If you want to wait before executing a liveness probe you should use initialDelaySeconds or a startupProbe.

翻译：存活性探针不会等待就绪性探针成功。如果你想在执行存活性探针之前等待，应该使用initialDelaySeconds或者startupProbe。

三、三种探测实现方式的细节与坑点

所有探针都支持三种实现方式，每种方式都有自己的适用场景和隐藏的坑。

1. exec：在容器内执行命令

原理

kubelet会在容器内执行你指定的命令。如果命令的退出码为0，则探测成功；否则探测失败。

适用场景

• 没有HTTP接口的应用（如数据库、消息队列）
• 需要自定义复杂健康检查逻辑的场景

示例

livenessProbe:exec:command:-/bin/sh--c-"ps aux | grep tomcat | grep -v grep"initialDelaySeconds:20periodSeconds:10timeoutSeconds:5failureThreshold:3

超级大坑！90%的人都踩过

不要用ps aux | grep xxx来做健康检查！

原因：

• grep命令本身会出现在进程列表中
• 所以即使你的应用已经死了，ps aux | grep tomcat也会因为匹配到grep自己而返回退出码0
• 导致探测永远成功，无法检测到应用故障

正确的写法：

# 方法1：用pgrep（推荐）command:["pgrep","tomcat"]# 方法2：给grep加个过滤command:-/bin/sh--c-"ps aux | grep tomcat | grep -v grep | wc -l | grep -q ^1$"

其他注意事项

• 命令执行的超时时间由timeoutSeconds控制，默认1秒
• 命令会在容器的默认工作目录下执行
• 命令的输出会被丢弃，不会出现在Pod日志中

2. TCPSocket：尝试建立TCP连接

原理

kubelet会尝试与容器的指定端口建立TCP连接。如果连接成功建立，则探测成功；否则探测失败。

适用场景

• 数据库（MySQL、PostgreSQL）
• 缓存（Redis、Memcached）
• 任何基于TCP的服务

示例

livenessProbe:tcpSocket:port:3306initialDelaySeconds:30periodSeconds:10timeoutSeconds:5failureThreshold:3

坑点

TCPSocket只能检测端口是否开放，无法检测服务是否正常工作。

比如：

• MySQL进程在，端口也通，但因为权限问题拒绝所有连接
• Redis进程在，端口也通，但已经进入只读模式

这些情况TCPSocket都会认为探测成功，但实际上服务已经不可用。

解决方法：
对于数据库这类服务，最好使用exec方式，执行一个简单的查询命令来检测服务是否正常：

livenessProbe:exec:command:-mysql--h-localhost--u-root--p123456--e-"SELECT 1"initialDelaySeconds:30periodSeconds:10timeoutSeconds:5failureThreshold:3

3. HTTPGet：发送HTTP GET请求

原理

kubelet会向容器的指定端口和路径发送一个HTTP GET请求。如果响应的状态码在[200, 399]范围内，则探测成功；否则探测失败。

适用场景

• Web应用
• RESTful API服务
• 任何提供HTTP接口的服务

完整的参数说明

livenessProbe:httpGet:path:/actuator/health# 请求路径port:8081# 请求端口，可以是端口号或端口名称scheme:HTTP# 协议，HTTP或HTTPS，默认HTTPhost:localhost# 请求的主机名，默认是Pod的IPhttpHeaders:# 自定义请求头-name:Authorizationvalue:Bearer token123initialDelaySeconds:20periodSeconds:5timeoutSeconds:10failureThreshold:3

非常重要的细节

• 状态码范围是200-399，包括301、302、304等重定向状态码。也就是说，如果你的健康检查接口返回302重定向，也会被认为是成功的。
• 如果请求超时（超过timeoutSeconds），则认为探测失败。
• kubelet会从节点上发起请求，而不是从Pod内部。

最佳实践

对于SpringBoot应用，强烈推荐使用Actuator的/actuator/health接口作为健康检查地址。它会自动检查应用的所有依赖（数据库、Redis、消息队列等）的健康状态。

四、所有探针参数的精确含义与调优方法

每个探针都有5个通用参数，理解每个参数的精确含义，是配置出健壮的健康探测的关键。

怎么计算应用需要的启动时间？

一个简单的方法：

1. 手动启动应用，记录从启动到可以正常接收请求的时间
2. 给startupProbe设置failureThreshold × periodSeconds = 实际启动时间 × 1.5

比如，你的应用实际启动时间是60秒，那么可以设置：

• periodSeconds: 5
• failureThreshold: 18
• 总共等待时间：18×5=90秒，给应用留30秒的余量

五、生产环境常见的致命错误配置

我见过太多因为健康探测配置不当导致的生产事故，这里给你列出最常见的7个错误，一定要避免！

错误1：没有配置startupProbe

后果：慢启动应用被livenessProbe频繁误杀，进入无限重启循环。

错误2：livenessProbe依赖外部服务

错误示例：

# 绝对不要这么写！livenessProbe:httpGet:path:/healthport:8080

如果/health接口会检查数据库连接，那么当数据库挂了的时候，所有Pod的livenessProbe都会失败，导致所有Pod被重启，整个服务雪崩。

正确做法：

• livenessProbe只检查应用自身的健康状态，不依赖任何外部服务
• readinessProbe可以检查外部依赖的健康状态

错误3：livenessProbe和readinessProbe完全相同

后果：当依赖的外部服务故障时，应用会被不断重启，而不是暂时从负载中移除。

错误4：initialDelaySeconds设得太长

后果：应用已经启动完成，但还要等很久才开始探测，导致服务不可用时间延长。

错误5：timeoutSeconds使用默认值1秒

后果：网络稍微有点波动，就会导致探测失败，误杀容器或误移除Pod。

错误6：没有配置readinessProbe

后果：滚动更新时，新Pod还没启动完成就开始接收流量，导致大量503错误。

错误7：过度探测

后果：过于频繁的探测会消耗大量的CPU和内存资源，影响应用的性能。

六、生产级健康探测完整示例（SpringBoot应用）

这是我在生产环境中使用的标准配置，你可以直接套用：

apiVersion:v1kind:Podmetadata:name:springboot-productionlabels:app:springbootspec:containers:-name:springbootimage:mydlqclub/springboot-helloworld:0.0.1ports:-name:servercontainerPort:8080# 业务端口-name:managementcontainerPort:8081# 管理端口，专门用于健康检查resources:requests:cpu:"500m"memory:"512Mi"limits:cpu:"2"memory:"2Gi"# 启动探测：专门处理慢启动startupProbe:httpGet:path:/actuator/health/liveness# 只检查应用自身是否启动port:8081periodSeconds:5# 每5秒探测一次timeoutSeconds:10# 超时时间10秒failureThreshold:30# 最多重试30次，总共等待150秒successThreshold:1# 存活性探测：检测应用是否活着livenessProbe:httpGet:path:/actuator/health/liveness# 只检查应用自身的健康状态port:8081periodSeconds:10# 每10秒探测一次timeoutSeconds:5# 超时时间5秒failureThreshold:3# 连续3次失败则重启successThreshold:1# 就绪性探测：检测应用是否可以接收流量readinessProbe:httpGet:path:/actuator/health/readiness# 检查所有依赖（数据库、Redis等）port:8081periodSeconds:5# 每5秒探测一次timeoutSeconds:5# 超时时间5秒failureThreshold:2# 连续2次失败则移除流量successThreshold:1restartPolicy:Always

配置说明：

1. 使用了SpringBoot Actuator的独立的健康检查端点：
   • /actuator/health/liveness：只检查应用自身是否存活，不依赖外部服务
   • /actuator/health/readiness：检查所有外部依赖是否正常
2. startupProbe给了足够长的启动时间（150秒），适合大多数Java应用
3. livenessProbe和readinessProbe分开配置，职责明确
4. 所有超时时间都设置得比较合理，避免误判

七、怎么调试健康探测？

当你的健康探测不工作时，可以按照以下步骤排查：

步骤1：查看Pod的事件

kubectl describe pods<pod-name>

在Events部分，你会看到探测失败的详细信息，比如：

Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning Unhealthy 10s kubelet Liveness probe failed: Get "http://10.244.121.45:8081/actuator/health": dial tcp 10.244.121.45:8081: connect: connection refused

步骤2：手动执行探测命令

对于exec探测：

kubectlexec-it<pod-name>--<你的探测命令>

比如：

kubectlexec-itspringboot-production --curlhttp://localhost:8081/actuator/health

步骤3：从节点上测试HTTP/TCP探测

kubelet是从节点上发起探测的，所以你需要登录到Pod所在的节点上，然后测试：

# 登录到节点sshroot@xianchaonode1# 测试HTTP探测curlhttp://<pod-ip>:8081/actuator/health# 测试TCP探测telnet<pod-ip>3306

八、终极总结

1. 默认健康检查完全不够用，生产环境必须配置自定义健康探测
2. 三种探针各司其职：
   • startupProbe：解决慢启动问题
   • livenessProbe：检测应用是否需要重启
   • readinessProbe：检测应用是否可以接收流量
3. 三种探测方式各有优劣：
   • HTTPGet：最准确，优先使用
   • exec：最灵活，适合自定义逻辑
   • TCPSocket：最简单，但准确性最低
4. 合理设置参数：根据应用的实际情况调整探测间隔、超时时间和重试次数
5. 避免常见坑点：不要让livenessProbe依赖外部服务，不要使用默认的1秒超时时间

健康探测是K8s服务高可用的基石，花时间把它配置好，能帮你避免90%的生产环境可用性问题。