Nginx健康检查必须与Kubernetes就绪探针协同设计，不能仅依赖/healthz；就绪探针应验证真实服务能力，如通过/readyz检查upstream可达性或exec执行nginx -t && curl验证，且initialDelaySeconds需设为15s以适配配置加载延迟。
Nginx 的健康检查在容器化编排中不能只靠自身 /healthz 接口“裸奔”，必须和 Kubernetes 的就绪探针（readinessProbe）协同设计，否则容易出现“容器已运行，但流量已涌入，Nginx 却还没加载完配置或后端未连通”的上线故障。
关键逻辑是：就绪探针不是验证 Nginx 进程是否存活，而是验证它是否真正具备服务请求的能力。
Nginx 自身的健康端点（如 /healthz）默认只返回 200，不感知 upstream 是否可用、配置是否热重载成功、SSL 证书是否加载完毕等真实就绪条件。这就需要把就绪判断前移到更可靠的层面。
就绪探针应检查 Nginx 的实际服务能力
-
使用
httpGet探针时，路径不应仅设为/healthz，而应指向一个能反映业务链路完整性的端点，例如：-
/readyz（需在 Nginx 配置中显式定义，返回 200 仅当upstream中至少一个 backend 可达） - 或代理到后端服务的
/health，让 Nginx 把健康检查透传并兜底（配合proxy_next_upstream和proxy_next_upstream_tries）
-
-
若使用
exec探针，可执行轻量脚本验证：nginx -t && curl -f http://127.0.0.1:8080/health || exit 1
其中
nginx -t确保配置语法正确，curl检查监听端口与最小业务响应。
配置参数要匹配真实启动耗时
Nginx 容器启动快，但若挂载了大量 conf.d/*.conf 或依赖 ConfigMap/Secret 动态注入，首次 reload 可能延迟数秒。此时 initialDelaySeconds 设置过小（如默认 10s）会导致探针过早触发、反复失败、Pod 卡在 NotReady。
推荐组合：
-
initialDelaySeconds: 15（留出配置加载 + 首次 reload 时间） periodSeconds: 10-
failureThreshold: 3（允许短暂抖动，避免误判）
示例（Helm values 片段）：
readinessProbe: httpGet: path: /readyz port: 10254 scheme: HTTP initialDelaySeconds: 15 periodSeconds: 10 timeoutSeconds: 2 failureThreshold: 3
避免就绪探针与 Nginx reload 冲突
Nginx 在收到 SIGHUP 重载配置时，旧 worker 进程会继续处理已有连接，新 worker 启动后才接管新请求——这个过程是优雅的。但若就绪探针在 reload 中间时刻发起请求，可能因新 worker 尚未完成 upstream 初始化而返回 502/503。
解决方法：
- 在
/readyz对应的 location 中添加proxy_cache off; proxy_buffering off;，绕过缓存和缓冲干扰； - 或用
exec探针调用nginx -s status（需提前安装 nginx-module-status）或检查ss -tlnp | grep :80+curl -I http://localhost/health组合判断。
结合 PostStart 钩子预热关键依赖
就绪探针负责“守门”，PostStart 钩子负责“铺路”。例如：
- 用 PostStart 下载远程配置、校验证书完整性、预热 Lua 模块、或向 Consul 注册服务前先 ping 后端 API；
- 钩子执行成功后，再由就绪探针确认最终状态，形成“准备 → 自检 → 上线”闭环。
这样，Nginx 容器上线不再是“启动即就绪”的假象，而是真实可服务的状态同步。
