boxmoe_header_banner_img

Hello! 欢迎来到悠悠畅享网!

文章导读

Golang服务健康检查怎么做 实现 readiness/liveness探针


avatar
站长 2025年8月18日 5

在Kubernetes中,Golang服务通过readiness和liveness探针实现健康检查。1. readiness探针检查服务是否就绪接收流量,如依赖数据库、Redis等是否可用,失败则从Service中移除;2. liveness探针判断服务是否存活,失败将触发重启,应避免检查外部依赖以防级联故障;3. 推荐使用独立HTTP服务在专用端口(如8081)暴露/ready和/healthz接口;4. Kubernetes配置中需合理设置initialDelaySeconds以匹配启动时间。通过HTTP探针配合代码逻辑可实现稳定健康检查。

Golang服务健康检查怎么做 实现 readiness/liveness探针

在 Kubernetes 环境中,Golang 服务的健康检查主要通过实现 readiness(就绪)和 liveness(存活)探针来完成。这两个探针通过 HTTP 接口暴露,由 kubelet 定期调用,判断容器状态。

readiness 探针:服务是否准备好接收流量

readiness 探针用于判断应用是否已经启动完成,可以正常处理请求。如果检查失败,Pod 会从 Service 的 Endpoint 列表中移除,暂时不接收新流量。

常见实现方式:

  • 检查依赖服务(如数据库、Redis、消息队列)是否连通
  • 检查内部状态是否就绪(如配置加载完成、缓存初始化)
  • 返回 200 表示就绪,非 200(如 500)表示未就绪

示例代码:

立即学习go语言免费学习笔记(深入)”;

func readinessHandler(w http.ResponseWriter, r *http.Request) { // 检查数据库连接等关键依赖 if err := db.Ping(); err != nil { http.Error(w, “DB not ready”, 500) return } // 其他检查… w.WriteHeader(200) w.Write([]byte(“ready”)) }

liveness 探针:服务是否还存活

liveness 探针用于判断应用是否处于运行状态。如果检查失败,kubelet 会重启容器。

注意:liveness 检查应尽量轻量,避免因依赖服务故障导致误重启。

  • 只检查自身进程是否卡死或陷入异常状态
  • 不建议检查外部依赖,否则可能导致级联重启
  • 返回 200 表示存活,否则视为异常

示例代码:

立即学习go语言免费学习笔记(深入)”;

func livenessHandler(w http.ResponseWriter, r *http.Request) { // 仅做最基础的健康判断,比如进程能响应 w.WriteHeader(200) w.Write([]byte(“alive”)) }

启动 HTTP 服务暴露探针接口

在 Golang 服务中,通常使用独立的 HTTP server 或复用主服务来暴露健康检查端点。

推荐做法:使用单独的端口(如 8081)运行健康检查服务,避免与主业务端口耦合。

示例:

func main() { // 主业务逻辑 go func() { http.ListenAndServe(“:8080”, nil) }()

// 健康检查服务 healthMux := http.NewServeMux() healthMux.HandleFunc(“/healthz”, livenessHandler) healthMux.HandleFunc(“/ready”, readinessHandler)

http.ListenAndServe(“:8081”, healthMux) }

Kubernetes 配置探针

在 Pod 的 yaml 中配置探针:

ports: – containerPort: 8080 – containerPort: 8081 # 健康检查端口

livenessProbe: httpGet: path: /healthz port: 8081 initialDelaySeconds: 10 periodSeconds: 10

readinessProbe: httpGet: path: /ready port: 8081 initialDelaySeconds: 5 periodSeconds: 5

关键是根据服务启动时间合理设置

initialDelaySeconds

,避免过早探查导致启动失败。

基本上就这些。只要暴露两个 HTTP 接口,配合合理的检查逻辑和 K8s 配置,就能实现可靠的健康检查机制。



评论(已关闭)

评论已关闭