Kubernetes集群中如何避免就绪探针检测死锁，实现多副本正常启动

死锁根因 #

Deployment默认滚动更新策略限制：默认maxUnavailable为0、maxSurge为25%，3副本场景下会先启动1个Pod，等待其就绪探针通过后才会启动剩余副本，和应用层多节点启动依赖形成冲突。

解决方案 #

方案1：调整Deployment部署策略，允许同时启动所有副本

直接修改Deployment的spec.strategy配置，让部署阶段一次性启动全部3个Pod，不受单个Pod就绪状态影响：

spec:
  replicas: 3
  strategy:
    rollingUpdate:
      maxSurge: 3 # 允许一次性创建全部3个新副本
      maxUnavailable: 0
    type: RollingUpdate

调整后部署时会同时创建所有3个Pod，不需要等待前一个就绪探针通过，即可解决死锁问题。

方案2：改用StatefulSet + 并行部署模式（更适合有状态集群类服务）

如果你的服务是需要节点互相发现的有状态服务，更推荐使用StatefulSet，并将Pod管理策略设为并行：

spec:
  podManagementPolicy: Parallel # 不需要等待前一个Pod就绪，一次性启动所有副本
  serviceName: your-headless-service-name # 配套Headless Service实现稳定的集群内DNS发现
  replicas: 3

这种方式天然支持多副本同时启动，不需要依赖就绪探针结果，还能为每个Pod提供稳定的DNS域名，方便节点间互相寻址。

方案3：调整探针逻辑，拆分启动检测和就绪检测

K8s 1.16+版本支持startupProbe（启动探针），你可以拆分检测逻辑：

• 启动探针仅检测应用进程是否正常启动、端口是否监听，不验证业务逻辑是否可用，只要启动探针通过，就认为Pod已经完成初始化
• 原有就绪探针保留，负责检测业务是否真正对外可用

配置示例：

readinessProbe:
  exec:
    command: ["curl", "localhost:2004"]
  timeoutSeconds: 10
  periodSeconds: 10
  successThreshold: 1
  failureThreshold: 3
# 新增启动探针
startupProbe:
  exec:
    # 仅检测2004端口是否处于监听状态，不需要返回正常业务响应
    command: ["nc", "-z", "localhost", "2004"]
  initialDelaySeconds: 10
  timeoutSeconds: 5
  periodSeconds: 5
  failureThreshold: 24 # 最多等待24*5=120秒，和原有初始延迟时间对齐

启动探针通过后才会执行就绪探针，同时Deployment会在Pod启动、启动探针检测通过后就继续创建后续副本，不会等待就绪探针结果。

方案4：应用层逻辑优化

调整应用的启动逻辑，不要阻塞主进程等待其他节点就绪：

• 应用启动后先监听2004端口，正常响应就绪探针的基础检测
• 后台异步检测其他节点的注册状态，集齐3个节点后再正式对外处理业务请求
• 就绪探针新增判断逻辑：如果节点已经集齐，返回正常业务响应；如果还在等待节点，也返回成功状态，保证所有Pod可以顺利启动。

内容的提问来源于stack exchange，提问作者Aviral Srivastava