如何配置Kubernetes：避免Pod在容器未全部就绪时标记为Running

首先要明确一个关键概念：Kubernetes中Pod的Running状态是内置的核心状态，它的判定逻辑是至少一个主容器（非Init容器）处于运行状态，且没有容器处于崩溃终止状态，这个逻辑无法修改。你遇到的核心问题其实是“未完全就绪的Pod被Service转发流量”，而非要修改Pod的Running标记——因为Running仅表示Pod的基本生命周期状态，而是否具备服务能力、能否接收流量，由Pod的Ready状态（就绪条件）决定。

要实现“所有容器都就绪后才让Pod接收流量”，可以通过以下配置实现：

1. 为每个业务容器配置就绪探针（Readiness Probe） #

就绪探针的作用是检测容器是否真正准备好处理请求，只有当Pod内所有配置了就绪探针的容器都通过检测后，Pod的Ready状态才会变为True，Service才会将该Pod加入流量转发列表。

示例配置（HTTP探针） #

apiVersion: apps/v1
kind: Deployment
metadata:
  name: your-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: your-app
  template:
    metadata:
      labels:
        app: your-app
    spec:
      containers:
      - name: main-container
        image: your-image:v1
        ports:
        - containerPort: 80
        # 就绪探针：检查容器的/healthz接口是否返回200
        readinessProbe:
          httpGet:
            path: /healthz
            port: 80
          initialDelaySeconds: 5  # 容器启动后等待5秒再开始探测
          periodSeconds: 3        # 每3秒探测一次
          failureThreshold: 2     # 连续失败2次则标记为未就绪
      - name: sidecar-container
        image: your-sidecar:v1
        ports:
        - containerPort: 9090
        # 为Sidecar容器也配置就绪探针
        readinessProbe:
          tcpSocket:
            port: 9090
          initialDelaySeconds: 10
          periodSeconds: 5

其他探针类型 #

• TCP探针：检测指定端口是否能建立连接（适合非HTTP服务）
• 命令探针：在容器内执行指定命令，根据退出码判断是否就绪：

  readinessProbe:
    exec:
      command:
      - cat
      - /tmp/ready
    initialDelaySeconds: 5
    periodSeconds: 3
  

2. 配合minReadySeconds配置（可选） #

在Deployment中添加minReadySeconds，可以让Pod在就绪状态保持指定时长后，才被视为“完全可用”，避免刚就绪就接收流量可能出现的瞬时不稳定：

spec:
  minReadySeconds: 10  # Pod就绪后等待10秒，才会被纳入滚动更新的可用计数

验证效果 #

配置完成后，执行kubectl rollout start deployment your-deployment启动滚动更新，通过kubectl get pods -w观察Pod状态：只有当所有容器的就绪探针都通过，Pod的状态列才会显示Running, Ready（比如1/1或2/2，数字表示就绪容器数/总容器数），此时Service才会将流量转发给该Pod。

内容的提问来源于stack exchange，提问作者Shawn Cao