就绪探针（readiness probe）不重启容器，仅控制service是否将pod加入endpoints；探测失败则立即摘流，成功才允许流量进入。支持http get、tcp socket、exec三种方式，需按应用特性选型，并合理配置initialdelayseconds、periodseconds、timeoutseconds、failurethreshold和successthreshold参数。
在Kubernetes中，Pod状态显示Running不代表应用已能处理请求，数据库连接未建立、模型加载未完成、配置热更新卡住等情况都会导致服务“假就绪”，此时若流量直接打入，必然引发大量5xx错误或超时。
明确就绪探针的核心职责
Readiness Probe不重启容器，只控制Service是否将该Pod加入Endpoints。只有探测成功，Pod才被标记为Ready，流量才会路由进来；失败则立即从Endpoint列表中剔除，且【不会触发重启】。
这与Liveness Probe有本质区别——后者失败会杀容器，前者失败只是“静音”该实例。
选择合适的探测方式
就绪探针支持三种探测机制，需按应用特性选型：
方法一：HTTP GET（推荐用于Web类服务）
在应用内暴露轻量级健康端点，如/health/ready或/actuator/health/readiness，返回HTTP 200且响应体不含错误标识。务必确保该端点【检查所有关键依赖】，例如数据库连接池可用、Redis连通性、必要配置文件已加载完毕。
方法二：TCP Socket（适用于无HTTP协议的长连接服务）
仅验证端口可连通，不校验业务逻辑。适合gRPC Server、MQTT Broker等。但注意：端口通 ≠ 服务就绪，比如gRPC服务可能已监听但尚未完成服务注册。
方法三：Exec（适用于无法暴露网络端点的离线任务型容器）
在容器内执行命令，如curl -f http://localhost:8080/health/ready || exit 1。缺点是每次探测都启动新进程，开销略高。
配置关键参数避免误判
第一步：设置initialDelaySeconds
给应用留足初始化时间。Spring Boot应用建议设为30～60秒，大模型加载服务建议设为120秒以上。过小会导致探针在应用真正启动前就失败，Pod反复进出Ready状态。
第二步：控制periodSeconds和timeoutSeconds
就绪探针应比存活探针更频繁、更宽容。典型值：periodSeconds: 5、timeoutSeconds: 3。若设为10秒以上，可能让故障Pod多承接几十秒无效流量。
第三步：谨慎配置failureThreshold
设为1表示单次失败即摘流，适合强一致性场景；设为3可容忍短暂抖动。但绝不应设为0或省略——省略时默认值为3，看似安全，实则掩盖了首次探测失败的真实原因。
第四步：确认successThreshold保持默认值1
就绪探针只要一次成功就可加回流量，无需连续多次成功。修改此值会导致Pod就绪延迟，违背就绪探针“快速入流”的设计初衷。
实战：为Django应用添加就绪探针
在Deployment的container字段下插入以下配置：
readinessProbe: httpGet: path: /health/ready port: 8000 initialDelaySeconds: 45 periodSeconds: 5 timeoutSeconds: 3 failureThreshold: 1
同时确保Django项目已实现/health/ready视图，该视图必须同步检查数据库连接（django.db.connection.ensure_connection()）、缓存连通性（cache.ping()）及必要静态资源路径是否存在。
验证探针是否生效
执行kubectl get pods，观察READY列是否为1/1而非0/1；再运行kubectl describe pod <pod-name></pod-name>，在Events区域查找Readiness probe failed或Readiness probe succeeded记录。若长时间无日志输出，说明探针未被触发，检查initialDelaySeconds是否过大或路径拼写错误。
