Go微服务在Kubernetes中健康探针失败的根本原因是kubelet探测行为与HTTP服务器响应不匹配：/health接口本地可通但探针超时或返回503，常因中间件干扰、阻塞操作、监听地址错误或探针配置不当所致。
Go 微服务在 Kubernetes 里显示 Running 却收不到请求、健康端点 /health 一直超时或返回 503，大概率不是网络或 Service 配置问题，而是探针和 Go 程序的协作断开了——Kubernetes 在“问”，你的程序没“答”，或者答得不对、答得太慢、答得不一致。
为什么 /health 接口 curl 得通但 kubelet 总是失败？
常见现象：本地 curl http://localhost:8080/health 返回 200，但 Pod 日志里反复出现 Readiness probe failed: HTTP probe failed with statuscode: 503 或直接超时。根本原因不是接口不存在，而是 kubelet 的探测行为和你程序的 HTTP server 行为不匹配。
-
readinessProbe和livenessProbe默认使用httpGet，它不带User-Agent、不走中间件、不复用连接，且对响应头和 body 长度极其敏感 - 如果你用了 Gin 或 Echo 之类框架，并在全局注册了
Recovery、Logger中间件，某些中间件会拦截并修改响应（比如加 header、重定向、延迟写入），导致 probe 超时或状态码异常 - Go 的
http.Server默认启用Keep-Alive，但 kubelet 的 probe 是单次短连接；若 handler 里有阻塞操作（如未设 timeout 的db.Ping()），就会卡住整个 probe 请求 - 检查是否监听了
0.0.0.0:8080而非127.0.0.1:8080——后者在容器里会导致 kubelet 从宿主机 netns 发起请求时连不上
readinessProbe 和 livenessProbe 能共用一个 /health handler 吗？
能，但强烈不建议。两个探针语义不同，混用极易引发雪崩或卡死。
-
livenessProbe应只确认进程存活：比如检查atomic.LoadInt32(&healthy)，不碰任何外部依赖，响应必须在timeoutSeconds内完成（建议 ≤1s） -
readinessProbe才该查 DB、Redis、下游 gRPC 连接等——但它必须容忍短暂抖动，否则一次数据库慢查询就触发重启 - 典型错误配置：
failureThreshold: 1+periodSeconds: 5+ 全链路依赖检查 → DB 偶发 600ms 延迟就连续失败，kubelet 直接杀 Pod - 推荐分离端点：
/livez（轻量）、/readyz（带依赖），并在 Deployment 中分别指向：
livenessProbe:
httpGet:
path: /livez
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 2
failureThreshold: 3
readinessProbe:
httpGet:
path: /readyz
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
timeoutSeconds: 3
failureThreshold: 2
Go 程序启动慢，initialDelaySeconds 设多少才安全？
不能拍脑袋填 10 或 30。真实值取决于你的初始化耗时，而这个时间往往随环境变化——开发环境秒级加载配置，生产环境可能要拉取远程密钥、预热缓存、建立 10+ 个 gRPC 连接。
- 在 main 启动逻辑末尾加一行日志：
log.Println("server started, ready to serve")，然后用kubectl logs观察这条日志实际出现时间--since=10s -
initialDelaySeconds至少要比这个时间多 3–5 秒，留出 kubelet 首次探测的缓冲 - 如果初始化不可预测（比如依赖外部 API 响应），不要硬编码 delay，改用
startupProbe替代：failureThreshold: 30+periodSeconds: 10，给足 5 分钟启动窗口，避免因启动慢被误杀 - 注意：
startupProbe成功后，livenessProbe和readinessProbe才开始计时；它不替代后两者，只是“启动守门员”
probe 失败后 Pod 不重启，或流量没摘掉？
这说明探针没生效，或生效了但没触发预期动作。最常忽略的是 readiness 和 liveness 的“作用域隔离”没做好。
-
readinessProbe失败只会让 Endpoint Controller 把该 Pod 从 Service 的Endpoints列表中移除，但 Pod 本身仍是Running状态——你得手动kubectl get endpoints确认它是否真的消失了 -
livenessProbe失败后，kubelet 会发docker kill或ctr t kill，但若容器内主进程是 PID 1 且未处理SIGTERM，它可能僵住不动，表现为Terminating卡住；务必在 Go 中注册signal.Notify捕获SIGTERM并优雅退出 - 检查是否误配了
restartPolicy: OnFailure（仅适用于 Job），Deployment 的 Pod 默认是Always，但若容器启动即 crash，会先进入CrashLoopBackOff，此时 readiness/liveness 不会运行——先解决启动失败，再谈健康检查
真正难调的从来不是参数数字，而是探针行为和业务状态的耦合深度：DB 连不上时，/readyz 返回 503 是对的；但 /livez 如果也跟着挂掉，整个自愈链就断了。轻量与真实之间那条线，得靠日志、监控和一次真实的故障注入来反复校准。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
