Go服务在Kubernetes中无法自主恢复Pod，真正的自愈依赖原生控制器；应用需暴露健康信号、容忍重启、解耦状态，并正确配置Probe与优雅终止。
Go 服务在 Kubernetes 中无法靠自身“自动恢复 Pod”——Pod 生命周期由 kubelet 和 controller manager 管理，Go 程序只能配合机制，不能越权重启 Pod。真正的自愈依赖 Kubernetes 原生控制器，Go 应用要做的，是暴露健康信号、容忍重启、避免状态残留。
为什么 os.Exit(1) 或 panic 后 Pod 并不“自动恢复”？
Kubernetes 不会因为容器进程退出就“修复”它；它只按 restartPolicy（默认 Always）拉起新容器。但若退出太快（如秒级崩溃），可能触发 CrashLoopBackOff，此时 Pod 处于反复启停状态，不是“恢复”，而是失控。
- 必须设置合理的
livenessProbe：避免误杀尚在启动中的进程 - 避免在
initContainer中执行不可重入操作（如写固定路径的锁文件） - Go 主程序不应捕获
os.Interrupt后静默 hang 住——kubelet 会超时判定为未响应
livenessProbe 和 readinessProbe 怎么写才不拖慢部署？
Probe 是 Go 应用参与自愈的唯一主动接口。关键不是“加 Probe”，而是让 Probe 快、准、可诊断。
-
livenessProbe应只检查进程是否存活 + 核心依赖（如本地 gRPC server 是否可 bind），不要查数据库连通性——那属于 readiness 范畴 -
readinessProbe可查 DB 连接池、下游 HTTP 健康端点，但超时时间建议 ≤ 2s，失败阈值设为failureThreshold: 3 - Go 里推荐用
http.ServeMux暴露/healthz（liveness）和/readyz（readiness），不用额外框架
func main() {
http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
w.WriteHeader(http.StatusOK)
w.Write([]byte("ok"))
})
http.HandleFunc("/readyz", func(w http.ResponseWriter, r *http.Request) {
if !dbPing() {
w.WriteHeader(http.StatusServiceUnavailable)
return
}
w.WriteHeader(http.StatusOK)
})
log.Fatal(http.ListenAndServe(":8080", nil))
}
如何让 Go 服务在 Pod 重建时“无感续命”？
自愈的本质是快速重建 + 状态解耦。Go 代码本身不保存状态，但容易踩坑的是日志、临时文件、内存缓存这些隐式状态。
立即学习“go语言免费学习笔记（深入）”；
- 日志必须输出到
stdout/stderr，禁用文件写入（os.OpenFile("app.log", ...)会导致新 Pod 丢失上下文） - 避免使用
sync.Map存业务状态——Pod 删除后数据即消失；需持久化状态一律走 Redis / ETCD / CRD - 使用
context.WithTimeout包裹所有外部调用，防止一个卡死请求拖垮整个健康检查 - 在
SIGTERM信号处理中做 graceful shutdown，但别等超过 30s（kubelet 默认 terminationGracePeriodSeconds=30）
StatefulSet 场景下，如何避免“自愈”变成“数据覆盖”？
对有状态服务（如 etcd sidecar、metrics collector），直接用 Deployment + 自动重建会丢失 PVC 绑定关系或破坏主从拓扑。
- 必须用
StatefulSet，并确保volumeClaimTemplates名称稳定、podManagementPolicy: OrderedReady - Go 程序启动时检查
HOSTNAME环境变量和 PVC 挂载路径内容，若发现已有数据且版本不兼容，应 panic 并打印明确错误，而不是强行覆盖 - 禁止在 Go 中硬编码节点路径（如
/data/node-1），全部通过VolumeMount注入
最常被忽略的一点：Probe 的 initialDelaySeconds 必须大于 Go 程序冷启动耗时（特别是加载证书、初始化连接池），否则 kubelet 会在服务真正 ready 前反复 kill 容器——这不是故障，是配置失配。
