kubectl port-forward是验证Kubernetes探针行为最贴近真实场景的方式：执行kubectl port-forward pod/myapp-xxxxx 8080:8080 -n myns后，用curl -v http://localhost:8080/health检查状态码、响应头和耗时，确保服务监听0.0.0.0而非127.0.0.1，并排除probe配置与handler不匹配、超时设置过短、路径注册错误等常见问题。
直接用 kubectl exec 进容器 curl 是错的——Kubernetes 探针走的是 Pod IP + 端口，不经过 Service 或 Ingress，本地测试必须模拟这个路径。
用 kubectl port-forward 测 /health 路径是否返回 200
这是最贴近真实探针行为的验证方式：
- 先确认服务监听在
0.0.0.0:8080（不是127.0.0.1:8080），否则port-forward无法连通 - 运行
kubectl port-forward pod/myapp-xxxxx 8080:8080 -n myns，然后curl -v http://localhost:8080/health - 重点看三件事：HTTP 状态码是不是
200、响应头有没有Content-Type: application/json、响应体是否能在 2 秒内返回 - 如果返回
503或超时，别急着改代码——先查kubectl describe pod里 readiness probe 的lastProbeTime和失败原因
检查 readinessProbe 配置是否匹配 handler 实现
Kubernetes 不解析 JSON，只认状态码和耗时。常见错配：
-
timeoutSeconds: 1但你的/health里调了db.PingContext(ctx, 2*time.Second)→ 必然超时失败 -
httpGet.path: "/health"但代码里注册的是http.HandleFunc("/readyz", ...)→ 探针 404，反复失败 - 没设
initialDelaySeconds，容器刚启动就探测，DB 连接池还没 warmup → 连续失败触发重启 - 用了
failureThreshold: 1，一次网络抖动就摘除实例，实际应设为3
用 curl -v 直连 Pod IP 验证 TCP 层是否通、TLS 是否干扰
绕过 kube-proxy，测最底层链路：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 先
kubectl get pod -o wide拿到 Pod IP（比如10.244.1.5） - 执行
curl -v http://10.244.1.5:8080/health；如果通但port-forward不通，说明是节点防火墙或 CNI 插件问题 - 如果服务启了 HTTPS，探针默认走 HTTP，会卡在 TLS 握手 → 必须用
httpGet.scheme: HTTPS并确保证书可信，或干脆用tcpSocket探活 - 注意：某些 Ingress（如 Traefik）会强制重定向 HTTP 到 HTTPS，导致探针收到 301 → 被判失败
日志里搜不到 probe 请求？那可能是路由没注册对
健康端点被中间件拦截或挂错 mux 是高频盲区：
- 别用
gin.Default()注册/health—— 它自带 Logger 和 Recovery 中间件，可能 panic 后静默丢请求 - 推荐用独立
http.ServeMux：mux := http.NewServeMux(); mux.HandleFunc("/health", healthHandler)，再传给http.Server{Handler: mux} - 如果用了 chi 或 gorilla/mux，确认没在全局加 Auth 中间件，否则
/health会被 401 拦截 - 写个临时 handler 打印
r.URL.Path和r.Header，确认探针真发到了你预期的路径
真正难的不是让接口返回 200，而是让 /readyz 在 DB 慢查询、Redis 网络抖动、gRPC 对端升级时仍能稳定返回带错误详情的 200，同时不拖垮主服务 goroutine 池——这需要缓存快照、并发控制、依赖分级，而不是每次 probe 都重连一遍。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
