Kubernetes中Go应用部署失败或反复重启，主因是startupProbe配置不当或与readinessProbe冲突；startupProbe存在时kubelet会禁用livenessProbe和readinessProbe直至其首次成功，故应仅保留startupProbe和livenessProbe。
Go应用在Kubernetes中部署失败或反复重启，大概率是探针配置不当——尤其是startupProbe没设对，或者和readinessProbe冲突。
startupProbe必须单独存在，不能和readinessProbe共存
只要你在容器 spec 中定义了 startupProbe，kubelet 就会自动禁用 livenessProbe 和 readinessProbe，直到 startupProbe 首次成功。这是硬性规则，不是可选行为。
常见错误是把三个 probe 全写上，结果 startupProbe 还没成功，readinessProbe 已经开始报错，导致 Pod 卡在 ContainerCreating 或反复重启。
- 只保留
startupProbe和livenessProbe（推荐）：startupProbe 负责“启动完成”，livenessProbe 负责“运行中存活” - 不要同时配
startupProbe和readinessProbe：后者会被忽略，但 YAML 里留着容易误导人 - 如果应用启动快（initialDelaySeconds 更简单
startupProbe参数怎么设才不卡住Pod
startupProbe 的核心作用是给慢启动应用“宽限时间”，而不是替代健康检查。它只运行一次成功即退出管控，后续交由 livenessProbe 接管。
关键参数组合示例（适用于启动耗时 40–90s 的 Go 应用）：
startupProbe:
httpGet:
path: /health/startup
port: 8080
failureThreshold: 30
periodSeconds: 2
timeoutSeconds: 1
-
failureThreshold: 30×periodSeconds: 2= 最多容忍 60 秒失败，适合启动时间波动大的场景 -
timeoutSeconds: 1避免 HTTP 请求挂住（Go 默认超时短，但网络抖动时仍可能卡住） - 不要设
initialDelaySeconds：startupProbe 从容器启动后立刻开始探测，加 delay 反而延长不可用时间 - 路径
/health/startup必须在 Go 服务里真实实现，且仅在应用初始化完成（如 DB 连通、gRPC server ready、配置加载完毕）后才返回 200
Go服务里怎么实现 /health/startup 端点
这个端点不是随便返回 OK 就行，它必须反映真实就绪状态。比如数据库连接未建好，就不能认为“已启动”。
典型实现逻辑（使用 sync.Once + atomic.Bool 控制）：
var started atomic.Bool
func initServer() {
// 各种初始化：DB、cache、config...
db, err := connectDB()
if err != nil {
log.Fatal(err)
}
// ...其他阻塞操作
started.Store(true) // 所有初始化完成后才设为 true
}
func setupStartupHandler(mux *http.ServeMux) {
mux.HandleFunc("/health/startup", func(w http.ResponseWriter, r *http.Request) {
if started.Load() {
w.WriteHeader(http.StatusOK)
w.Write([]byte("OK"))
} else {
http.Error(w, "not started", http.StatusServiceUnavailable)
}
})
}
- 务必在
initServer()完成后再调用started.Store(true)，不能放错位置 - 不要在 handler 里做耗时操作（如重试连 DB），否则 probe 会超时失败
- 如果用的是 Gin/Echo 等框架，确保该路由注册在所有中间件之前，避免被鉴权拦截
Dockerfile和Deployment要配合startupProbe用
startupProbe 不是孤立配置，它依赖镜像构建方式和资源限制是否合理。
- 必须用静态编译：
CGO_ENABLED=0 GOOS=linux go build -a -o app .，否则 Alpine 镜像里缺 libc 会导致启动失败，probe 永远收不到响应 - 镜像基础环境推荐
alpine:latest或distroless/static，避免带 shell 增加攻击面，也防止误用 exec 探针 - resources.requests 设置过低（如 CPU cpu: "200m"
- Deployment 的
replicas不宜设为 1：单副本下 startupProbe 失败会直接 kill 容器，没有 fallback；设为 3 并配合滚动更新更稳妥
startupProbe 的本质是“启动确认开关”，不是万能兜底。它解决不了代码级死锁、配置硬编码错误、Secret 挂载失败这些底层问题——那些得靠日志、kubectl describe pod 和 kubectl logs --previous 来定位。真正容易被忽略的是：probe 路径返回 200 ≠ 服务可用，只是表示“进程已跨过初始化门槛”。
