Go服务无自愈能力，依赖Kubernetes机制；需配合信号处理、健康检查与优雅退出：避免os.Exit(1)致误判正常退出，应优先panic让Kubelet识别为崩溃，健康探针须轻量无副作用。

Go 服务本身没有内置的“自愈”能力，云原生的自愈（如自动重启、故障转移、滚动更新）完全依赖 Kubernetes 等编排平台的机制；Go 应用要做的，是配合这些机制——不阻塞信号、快速响应健康检查、避免启动卡死、正确处理退出。

为什么 os.Exit(1) 在 Kubernetes 中会导致自愈失效

Kubernetes 的容器生命周期管理依赖进程退出码和信号。若 Go 程序在异常时直接调用 os.Exit(1)，会跳过 defer 和 runtime.SetFinalizer，但更关键的是：它让容器“静默死亡”，Kubelet 无法区分这是主动退出还是崩溃。而崩溃（如 panic 未捕获、SIGSEGV）会触发 RestartPolicy: Always 下的重启；但主动 os.Exit 可能被误判为“正常退出”，尤其当 readiness/liveness 探针配置不当的时候。

实操建议：

• 避免在业务逻辑中使用 os.Exit，改用 log.Fatal（它内部调用 os.Exit，但至少统一了日志上下文）或更可控的退出流程
• 在 main 函数末尾用 os.Exit(0) 显式退出，确保主 goroutine 结束后整个进程终止
• 若需异常终止，优先抛出 panic 并用 recover 记录后让主 goroutine 自然结束（Kubelet 更倾向将 panic 视为 crash）

livenessProbe 和 readinessProbe 的 Go 实现要点

Kubernetes 通过 HTTP 或 TCP 探针判断容器状态，Go 应用必须提供轻量、无副作用、低延迟的健康端点。常见错误是把数据库连接检查塞进 /healthz，导致探针超时、反复重启。

实操建议：

• livenessProbe 应只检查进程是否存活（如能否响应 HTTP）、goroutine 是否卡死（可读取 runtime.NumGoroutine() 阈值）
• readinessProbe 才适合检查依赖（DB、Redis、下游 gRPC），但它失败只影响流量路由，不触发重启
• 避免在 probe handler 中做同步 I/O；用预热连接池 + context.WithTimeout，超时立即返回 503
• 示例 HTTP 健康 handler：

func healthz(w http.ResponseWriter, r *http.Request) {
    ctx, cancel := context.WithTimeout(r.Context(), 100*time.Millisecond)
    defer cancel()

    // 检查本地状态（非依赖）
    if runtime.NumGoroutine() > 5000 {
        http.Error(w, "too many goroutines", http.StatusServiceUnavailable)
        return
    }

    select {
    case <-ctx.Done():
        http.Error(w, "timeout", http.StatusServiceUnavailable)
    default:
        w.WriteHeader(http.StatusOK)
        w.Write([]byte("ok"))
    }
}

如何让 Go 程序优雅响应 SIGTERM 并配合 Kubernetes 生命周期

Kubernetes 在删除 Pod 前发送 SIGTERM，默认等待 30 秒（terminationGracePeriodSeconds），之后发 SIGKILL 强杀。Go 若不监听该信号，会立刻中断所有 goroutine，导致连接未关闭、事务未提交、指标未刷盘。

实操建议：

• 用 signal.Notify 监听 os.Interrupt 和 syscall.SIGTERM
• 收到信号后，先关闭 HTTP server（srv.Shutdown()），再等待所有 worker goroutine 完成（可用 sync.WaitGroup 或 context.WithCancel）
• 设置合理的 shutdownTimeout（如 10s），超时则强制退出，避免拖慢滚动更新
• 不要在 Shutdown 期间接受新请求：确保反向代理（如 nginx、istio）已将该 Pod 从 endpoints 中摘除（靠 readinessProbe 失败实现）

为什么 initContainer 和 startupProbe 对 Go 服务很关键

Go 编译产物启动快，但若依赖初始化耗时（如加载大模型、预热缓存、等待 ConfigMap 挂载），可能在 readiness/liveness 探针生效前就失败。Kubernetes 1.16+ 的 startupProbe 就是为此设计：它只在容器启动初期运行，成功后才启用其他探针。

实操建议：

• 对冷启动敏感的 Go 服务（如带嵌入式 SQLite、本地向量库），务必配 startupProbe，初始延迟设为 5–10s，失败阈值设高些（如 30 次）
• 用 initContainer 预检必要条件：比如确认 Consul 服务可连、下载证书、校验配置文件语法（jsonschema 工具）
• 避免在 main container 的 command 中做耗时初始化；拆到 initContainer 或 startupProbe handler 中

真正决定自愈效果的，不是 Go 写得多漂亮，而是它有没有把“我挂了”“我还活着”“我准备好接流量了”这三件事，用 Kubernetes 能听懂的方式说清楚。信号、探针、退出码、启动时序——这些地方错一个，自愈就变成“反复拉起又杀死”。