14.Kubernetes 就绪性探针（Readiness Probe）详解

Liao wen xiu

已于 2025-04-13 20:58:24 修改

阅读量1k

点赞数 13

分类专栏： Kubernetes 文章标签： kubernetes 容器云原生

于 2025-04-13 20:51:31 首次发布

本文链接：https://blog.csdn.net/weixin_39749311/article/details/147197055

版权

Kubernetes 专栏收录该内容

48 篇文章

订阅专栏

Kubernetes 就绪性探针（Readiness Probe）详解

一、核心定义与作用

就绪性探针（Readiness Probe）用于检测容器是否已准备好接收外部流量。其核心机制包括：
流量控制：探针成功时，Pod IP 被加入 Service 的 Endpoints 列表，允许流量转发；失败时则从列表中移除，暂停流量分发至该 Pod。
业务就绪保障：确保 Pod 完成初始化（如加载配置、预热程序）后才开放服务请求，避免未就绪实例处理请求导致失败。

二、工作原理与组件协作

探测流程
kubelet 周期性执行 Readiness Probe（支持 HTTP GET、TCP Socket、Exec 三种类型），根据响应结果判断 Pod 状态。
若连续失败次数超过 failureThreshold，Endpoints Controller 将该 Pod IP 从关联 Service 的 Endpoints 列表中剔除。
kube-proxy 监听 Endpoints 变化，动态更新 iptables/IPVS 规则，停止向异常 Pod 转发流量。

与存活探针（Liveness Probe）的差异
探针类型触发动作优先级
Readiness Probe 仅影响流量路由（不重启容器）与存活探针并行执行
Liveness Probe 触发容器重启或 Pod 重建启动探针成功后生效

三、配置参数与示例

关键配置项

readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 5   # 容器启动后延迟首次探测时间（秒）
  periodSeconds: 10        # 探测间隔（默认10秒）
  successThreshold: 1      # 连续成功次数判定为就绪
  failureThreshold: 3      # 连续失败次数判定为未就绪

initialDelaySeconds：避免过早检测未初始化完成的容器。
failureThreshold：容忍短暂波动，防止因临时故障误剔除 Pod。

探测类型选择
HTTP GET：适用于 Web 服务，通过状态码（2xx/3xx）判断就绪性。
TCP Socket：检测端口是否监听，适用于非 HTTP 协议服务。
Exec：执行自定义命令，通过退出码（0 为成功）判断就绪性。

四、典型应用场景

滚动更新
新版本 Pod 需通过 Readiness Probe 检测后才会加入 Endpoints 列表，逐步替换旧实例，实现零停机升级。

故障隔离
当 Pod 因资源不足、依赖服务异常等问题无法处理请求时，探针失败触发流量切换，保障服务可用性。

慢启动服务
配合 initialDelaySeconds 和 periodSeconds，为初始化耗时较长的服务预留准备时间。

五、注意事项

避免过度敏感：合理设置 failureThreshold 和 periodSeconds，防止因短暂抖动（如高负载响应延迟）误判未就绪。
与存活探针协同：若需同时保障服务可用性和容器自愈，建议同时配置 Readiness Probe 和 Liveness Probe。
监控与告警：结合集群监控工具（如 Prometheus）追踪探针失败事件，及时排查根因。

总结
Kubernetes 就绪性探针通过动态控制流量路由，成为保障服务稳定性的核心机制。其与 Endpoints、kube-proxy 的深度集成，实现了故障实例秒级隔离、
滚动更新平滑过渡等关键能力

Kubernetes 就绪性探针（Readiness Probe）核心作用

一、流量路由控制

就绪性探针通过动态调整 Service 的 Endpoints 列表，决定 Pod 是否参与流量分发：

检测通过：Pod IP 被加入 Service 的负载均衡列表，允许接收外部请求。
检测失败：Pod IP 被移除，流量暂停转发至该实例，避免请求分发至未就绪容器。

二、关键作用场景

滚动更新与零停机部署
新版本 Pod 需通过就绪性探针检测后才会被加入流量池，逐步替换旧实例，确保服务无中断。

示例：更新时旧 Pod 持续处理请求，新 Pod 就绪后接管流量，旧 Pod 最终被销毁。
初始化阶段流量屏蔽
当容器需执行耗时初始化操作（如加载配置文件、预热缓存）时，探针在完成前屏蔽流量，防止请求处理失败。

故障实例自动隔离
若 Pod 因资源不足、依赖服务异常等原因无法处理请求，探针失败触发流量切换，保障服务整体可用性。

三、与存活探针（Liveness Probe）的差异

特性就绪性探针（Readiness Probe）存活探针（Liveness Probe）
触发动作仅控制流量路由触发容器重启或重建
检测周期容器生命周期内持续执行启动探针成功后生效
优先级与存活探针并行运行依赖启动探针完成初始化

四、配置建议与参数说明

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 15   # 容器启动后延迟检测时间（覆盖初始化耗时）
  periodSeconds: 10         # 检测间隔（默认10秒）
  successThreshold: 1       # 连续成功1次判定为就绪
  failureThreshold: 3       # 连续失败3次判定为未就绪
参数优化原则：

initialDelaySeconds 需大于容器初始化最大耗时，避免误判未就绪。
failureThreshold 根据业务容忍度调整，防止短暂抖动导致流量频繁切换。
总结
就绪性探针通过动态管理流量分发，成为保障 Kubernetes 服务稳定性的核心机制，其核心价值体现在：

✅ 服务可用性：屏蔽未初始化或异常实例，避免无效请求；
✅ 平滑升级：支持滚动更新零停机切换；
✅ 资源优化：仅将请求路由至健康实例，提升资源利用率

Kubernetes 就绪性探针（Readiness Probe）配置指南

一、基础配置方法

在 Pod 的 YAML 文件中，通过 readinessProbe 字段定义就绪性探针，支持 HTTP GET、TCP Socket、Exec 命令三种探测方式：

HTTP GET 探测
适用于 Web 服务，通过 HTTP 状态码（2xx/3xx）判断容器是否就绪：

readinessProbe:
  httpGet:
    path: /healthz    # 健康检查接口路径
    port: 8080        # 容器监听的端口
    httpHeaders:      # 可选自定义请求头
    - name: X-Custom-Header
      value: ProbeCheck
  initialDelaySeconds: 10   # 容器启动后延迟10秒开始探测
  periodSeconds: 5          # 每5秒探测一次
  failureThreshold: 3       # 连续失败3次判定为未就绪
  successThreshold: 1       # 连续成功1次判定为就绪

适用场景：REST API、Web 服务等基于 HTTP 的应用程序。
TCP Socket 探测
通过检测指定端口是否开放判断服务可用性：

readinessProbe:
  tcpSocket:
    port: 3306        # 检测的容器端口
  initialDelaySeconds: 15
  periodSeconds: 10

适用场景：数据库（如 MySQL、Redis）、消息队列等非 HTTP 协议服务。
Exec 命令探测
执行自定义命令，以退出码 0 表示成功（就绪）：

readinessProbe:
  exec:
    command:
    - sh
    - -c
    - "curl -s localhost:8080/ready | grep OK"  # 自定义检测逻辑
  initialDelaySeconds: 20
  periodSeconds: 15

适用场景：需要复杂逻辑判断就绪状态的场景（如依赖外部文件或脚本）。

二、关键参数说明

参数作用推荐值

initialDelaySeconds 容器启动后首次探测的延迟时间（避免过早检测未初始化完成的服务） ≥ 容器最大启动时间
periodSeconds 探测间隔时间 5~15 秒（根据业务负载调整）
failureThreshold 连续失败次数阈值，超过后标记 Pod 为未就绪 3~5 次（容忍短暂抖动）
successThreshold 连续成功次数阈值，达到后标记 Pod 为就绪 1 次（默认值）

三、最佳实践与注意事项

避免与存活探针（Liveness Probe）冲突
就绪探针失败不会重启容器，仅控制流量路由。
存活探针失败会触发容器重启，两者需独立配置且存活探针检测条件应更严格。

健康检查接口设计
使用专用端点（如 /healthz）进行检测，避免与业务接口耦合。
检测逻辑需轻量，避免因探针执行耗时过长导致误判。

滚动更新优化
结合 maxSurge 和 maxUnavailable 参数，确保新 Pod 通过就绪检测后再逐步替换旧实例。

监控与告警
通过 Prometheus 或集群事件监控就绪探针失败事件，及时排查依赖服务异常或资源不足问题。

配置示例（Web 服务场景）

apiVersion: v1
kind: Pod
metadata:
  name: web-app
spec:
  containers:
  - name: web
    image: nginx:latest
    ports:
    - containerPort: 80
    readinessProbe:
      httpGet:
        path: /healthz
        port: 80
      initialDelaySeconds: 15   # 预留 Nginx 启动时间
      periodSeconds: 5
      failureThreshold: 3