就绪探针（readinessprobe）用于判断容器是否准备好接收流量，不重启容器，仅控制service是否转发请求；必须配置initialdelayseconds、periodseconds、timeoutseconds、failurethreshold等参数，并支持httpget、tcpsocket、exec三种检查方式。
容器创建时定义就绪状态，核心是通过 readinessProbe 明确告诉 Kubernetes：“这个容器什么时候才算准备好收流量”。它不重启容器，只控制 Service 是否把请求转发过来。
就绪探针必须配置的关键参数
每个 readinessProbe 至少要指定检查方式和基础调度节奏：
- initialDelaySeconds：容器启动后等多久才开始第一次检查（比如设为 10，避免应用还没加载完就误判）
- periodSeconds：每隔几秒检查一次（默认 10，生产环境建议 15–30，太频繁会增加负载）
- timeoutSeconds：单次检查最多等几秒响应（HTTP 或 TCP 连接超时，一般设 2–5）
- failureThreshold：连续失败几次才标记为“未就绪”（设 3 比较稳妥，防偶发抖动）
- successThreshold：恢复后连续成功几次才重新接纳流量（默认是 1，通常不用改）
三种常用检查方式怎么选
根据应用特性选一种最贴合的实现方式，不需要都配：
-
HTTP GET：适合 Web 服务。配置 path（如
/readyz）和 port（如 8080），返回 200–399 算通过。Golang 示例中常对应http.HandleFunc("/readyz", ...) - TCP Socket：适合不暴露 HTTP、但监听端口的服务（如 Redis、gRPC server）。只需确认端口能连通，不校验内容
- Exec 命令：适合需要自定义逻辑的场景（如检查本地文件是否存在、执行健康脚本）。命令退出码为 0 才算就绪
在 Deployment 中直接写 YAML 示例
这是最常见也最可控的方式，在容器 spec 下添加 readinessProbe 块：
readinessProbe:
httpGet:
path: /readyz
port: 8080
initialDelaySeconds: 15
periodSeconds: 20
timeoutSeconds: 3
failureThreshold: 3
注意：不要和 livenessProbe 共用同一个健康端点（如都用 /healthz），否则容器可能因初始化慢被误杀。就绪端点应专注“是否可服务”，存活端点专注“是否还活着”。
配合 startupProbe 避免启动期误判
如果应用冷启动耗时较长（比如 >30 秒），建议加 startupProbe：
- 它优先级最高，先于 readinessProbe 和 livenessProbe 生效
- 等 startupProbe 成功后，其他两个探针才开始工作
- 例如设置
startupProbe: { httpGet: { path: "/livez" }, failureThreshold: 30, periodSeconds: 10 }，给足 5 分钟启动时间
