K8S readinessGates详解

在 Kubernetes (K8s) 中，readinessGates 是一个允许外部控制器（External Controller） 参与 Pod 就绪状态判断的机制。

简单来说，标准的 Readiness Probe 是由 Kubelet 在节点内部检查容器健康状态的，而 readinessGates 允许集群中的其他组件（如 Operator、Service Mesh 控制器等）告诉 K8s："这个 Pod 还没准备好，别给它流量"。

以下是关于 readinessGates 的详细解析，包括原理、与 Probe 的区别、配置示例及使用场景。

1. 核心原理

Kubernetes 判断一个 Pod 是否"就绪"（Ready），从而决定是否将流量转发给它（更新 Service 的 Endpoint），主要依据是 Pod 状态中的 PodReady Condition。

传统机制 ：PodReady 状态仅依赖于 Readiness Probe 的结果（由 Kubelet 管理）。
readinessGates 机制 ：PodReady 状态不仅依赖 Probe，还依赖 readinessGates 列表中定义的自定义 Condition 。
- 只有当 所有 Readiness Probe 通过 且 所有 readinessGates 定义的 Condition 状态为 True 时，PodReady 才会变为 True。
- 这些自定义 Condition 的状态不是由 Kubelet 更新的 ，而是由外部控制器 通过 API Server 更新 Pod 的 status.conditions 字段。

2. readinessGates vs. Readiness Probe

这是最容易混淆的地方，两者的区别如下：

特性	Readiness Probe	readinessGates
执行者	Kubelet (节点上的代理)	外部控制器 (Operator, Istio 等)
检查范围	容器内部 (HTTP, TCP, Exec)	外部依赖、集群状态、Sidecar 状态等
配置位置	`spec.containers.readinessProbe`	`spec.readinessGates`
状态更新	Kubelet 自动更新	外部控制器调用 API 更新 `status.conditions`
典型场景	应用进程是否存活，端口是否监听	配置是否下发，数据库是否迁移，Sidecar 是否注入
关系	必须同时满足	必须同时满足

结论：readinessGates 是对 Readiness Probe 的补充，而不是替代。

3. 工作流程

① Pod 创建流程：

用户在 Pod spec 中定义 readinessGates 列表（如 ["www.example.com/feature-1"]）

② Pod 启动阶段：

Kubelet 启动容器并执行标准 Readiness Probe 检查

③ 外部监控流程：

集群中的外部控制器（如自定义 Operator）监听到新 Pod 创建事件
控制器执行自定义检查逻辑（如验证数据库连接、等待配置中心下发配置等）

④ 状态更新机制：

检查通过时：控制器通过 API Server 将对应 condition 状态更新为 True
检查未通过时：状态更新为 False

⑤ 就绪判定标准：

Kubernetes 控制管理器同时验证：
- Readiness Probe 是否通过
- readinessGates 中所有 Condition 状态是否为 True
满足条件时，将 PodReady 状态设为 True，Service 开始路由流量

4. 配置示例

Pod YAML 定义

bash 复制代码

apiVersion: v1
kind: Pod
metadata:
  name: readiness-gate-example
spec:
  # 1. 定义 readinessGates 列表
  # 这里声明了该 Pod 就绪需要满足一个额外的条件类型
  readinessGates:
    - conditionType: "www.example.com/feature-1"
  
  containers:
    - name: myapp
      image: nginx
      # 标准的 Readiness Probe 依然需要
      readinessProbe:
        httpGet:
          path: /healthz
          port: 80
        initialDelaySeconds: 5
        periodSeconds: 5

外部控制器更新状态 (模拟)

外部控制器需要更新 Pod 的 status 子资源。以下是一个模拟的 kubectl patch 命令，展示如何将条件设为 True：

bash 复制代码

kubectl patch pod readiness-gate-example --subresource='status' --type='merge' -p '{
  "status": {
    "conditions": [
      {
        "type": "www.example.com/feature-1",
        "status": "True",
        "reason": "Checked",
        "message": "External dependency is ready"
      }
    ]
  }
}'

注意：只有当 www.example.com/feature-1 和 httpGet 探针都通过时，Pod 才会真正变为 Ready。

5. 典型使用场景

readinessGates 主要解决 Kubelet 无法感知的外部依赖 问题。

Service Mesh (如 Istio)：

问题：Pod 容器启动了，但 Sidecar 代理（Envoy）还没准备好接收流量。
解决：Istio 控制器通过 readinessGates 标记 Pod，直到 Sidecar 配置下发完成才将 Pod 标记为 Ready。

数据库迁移/初始化：

问题：应用启动后需要等待数据库表结构迁移完成才能提供服务。
解决：一个 Job 或 Operator 执行迁移，完成后更新 Pod 的 readinessGate 状态。

配置中心同步：

问题：应用需要从外部配置中心拉取配置，拉取完成前不能处理请求。
解决：配置控制器确认配置已下发后，更新 Gate 状态。

网络策略生效：

问题：等待网络策略（NetworkPolicy）生效后再开放流量。
解决：网络控制器确认策略应用后更新状态。

6. 注意事项与限制

权限要求：

外部控制器必须有权限更新 Pod 的 status 子资源（pods/status）。这通常需要特定的 RBAC 配置。

Condition 类型命名：

建议使用域名前缀（如 example.com/condition），避免与 K8s 原生 Condition 冲突。

版本支持：

readinessGates 在 Kubernetes v1.14 引入 Beta，v1.16 正式 GA。确保集群版本足够新。

性能影响：

如果外部控制器更新状态延迟过高，会导致 Pod 长时间无法接收流量，影响发布速度。

Pod 删除：

当 Pod 被删除时，相关的 Condition 也会随之消失，无需手动清理。

总结

是什么：一种让外部组件控制 Pod 就绪状态的机制。
为什么：弥补 Kubelet 探针只能检查容器内部，无法检查外部依赖的不足。
怎么做 ：在 Pod Spec 中声明 readinessGates，由外部控制器更新 status.conditions。
关键点 ：Probe + Gates 全部通过，Pod 才算真正 Ready。