c 网站开发实例教程,福州关键词快速排名,wordpress kratos主题,免费做封面的网站在 Kubernetes 中#xff0c;livenessProbe 和 readinessProbe 是确保应用高可用性的关键机制#xff0c;但配置不当可能导致应用频繁重启或流量中断。以下是配置这两个探针的最佳实践#xff1a;
1. 核心区别与作用
探针类型目的失败后果livenessProbe检测应用是否 存活livenessProbe 和 readinessProbe 是确保应用高可用性的关键机制但配置不当可能导致应用频繁重启或流量中断。以下是配置这两个探针的最佳实践
1. 核心区别与作用
探针类型目的失败后果livenessProbe检测应用是否 存活如死锁、内存泄漏。重启容器kubectl restartreadinessProbe检测应用是否 准备好接收流量如依赖服务未就绪、缓存未加载。从 Service 的 Endpoints 移除 Pod
2. 最佳实践指南
(1) 明确区分两个探针的用途
livenessProbe 保守检查仅检测应用是否处于不可恢复的故障状态如主线程崩溃。一般服务没挂掉就认为是正常的。避免敏感条件例如不要用业务逻辑失败如数据库连接超时触发重启除非明确需要。 readinessProbe 严格检查确保所有依赖如数据库、通过 feign 调用的外部组件、中间件就绪后才接收流量。动态调整在运行时若依赖服务不可用如 Redis 宕机应通过 readinessProbe 主动拒绝流量。
(2) 设置合理的检查端点 为 livenessProbe 和 readinessProbe 使用不同的 HTTP 路径 livenessProbe:httpGet:path: /health/liveness # 轻量级存活检查仅进程存活port: 8080
readinessProbe:httpGet:path: /health/readiness # 包含依赖检查如数据库连接port: 8080(3) 配置合理的参数
livenessProbe:httpGet:path: /actuator/health/livenessport: 8080initialDelaySeconds: 10 # 应用启动后等待 10 秒再开始探测periodSeconds: 5 # 每 5 秒检查一次timeoutSeconds: 3 # 超时时间设为 3 秒failureThreshold: 3 # 连续失败 3 次后判定为故障readinessProbe:httpGet:path: /actuator/health/readinessport: 8080initialDelaySeconds: 5 # 比 livenessProbe 更早开始检查periodSeconds: 5timeoutSeconds: 3failureThreshold: 1 # 1 次失败即标记为未就绪关键参数说明
initialDelaySeconds必须设置避免应用未完成初始化就被判定为失败如 JVM 启动慢。failureThreshold livenessProbe 可设置较高如 3避免偶发故障触发重启。readinessProbe 可设置较低如 1快速从负载均衡中剔除异常 Pod。 periodSeconds 和 timeoutSeconds根据应用响应时间调整避免超时误判。
(4) 结合 startupProbe 处理慢启动应用
对于启动时间较长的应用如 Java 服务使用 startupProbe 延迟 livenessProbe 和 readinessProbe 的启动
startupProbe:httpGet:path: /actuator/health/startupport: 8080failureThreshold: 30 # 允许最多 30 次检查失败periodSeconds: 5 # 每 5 秒检查一次# 总等待时间 failureThreshold * periodSeconds 150 秒如果想了解 k8s 为什么要专门提出 startupProb 来解决慢服务启动的问题而不是直接把 livenessPro 中初始化的时间设置的长一点。可以参考下面的文章《为什么需要启动探针StartupProb》。 (5) 选择适当的探测类型 HTTP GET适合 Web 服务通过状态码2xx/3xx 表示成功判断。 Exec执行命令返回 0 表示成功适合非 HTTP 服务 readinessProbe:exec:command:- /app/check-dependency.sh # 自定义脚本检查依赖TCP Socket仅检查端口是否开放适用非 HTTP 协议。
(6) 避免依赖下游服务
readinessProbe 不要深度检查外部依赖如数据库、API 若外部服务宕机所有 Pod 都会被标记为未就绪导致全面故障。改为在应用内部实现熔断机制如 Hystrix部分功能降级。
(7) 日志与监控
记录探针检查结果在 /health 端点返回详细信息如版本、依赖状态。监控探针失败通过 Prometheus 监控 kubelet_probe_errors_total及时报警。
3. 示例配置
Spring Boot 应用
apiVersion: apps/v1
kind: Deployment
spec:template:spec:containers:- name: applivenessProbe:httpGet:path: /actuator/health/livenessport: 8080initialDelaySeconds: 30periodSeconds: 10failureThreshold: 3readinessProbe:httpGet:path: /actuator/health/readinessport: 8080initialDelaySeconds: 5periodSeconds: 5failureThreshold: 1startupProbe:httpGet:path: /actuator/health/startupport: 8080failureThreshold: 30periodSeconds: 5
