04-05-nodejs-探针与健康检查

为 nodejs-demo 配置 存活 / 就绪 / 启动 探针，使 kubelet 能在异常时重启容器，并在未就绪时从 Service Endpoints 摘除流量。

TL;DR

自动化验收：./scripts/verify.sh run 04-05
关键前置：按本文「前置条件」准备环境变量/Secret/入口 IP
成功判据：达到本文「预期」且 playbook 断言通过
排障：见本文「排障」

前置条件

已部署 nodejs-demo（04-01）；应用需暴露可探测的 HTTP 路径（示例用根路径 /）。

清单路径（唯一真源）

探针端口与累积清单一致，为 8080（自 04-02 起与监听端口对齐）。

场景说明（白话）

Kubernetes 会周期性访问你指定的地址，判断容器该不该重启、该不该接流量：

探针	人话
存活 liveness	「还活着吗？」一直失败就重启容器（认为卡死）。
就绪 readiness	「能接客了吗？」失败时不放进 Service 负载均衡（流量不打进来）。
启动 startup	「是不是还在慢启动？」启动阶段先由它把关，避免被 liveness 误杀。

相对 `04-04` 的变更（原文 → 新文）

位置	原文（`04-04`）	新文（`04-05`）
`livenessProbe` / `readinessProbe`	（无）	`httpGet` 路径 `/`，端口 8080，`initialDelaySeconds`/`periodSeconds` 见清单文件

生产建议为健康检查单独提供 /health 或 /ready 路径（与业务路由分离）。

部署与验证

kubectl apply -f ansible/files/04-01/04-05-nodejs-demo.yaml
kubectl describe pod -l app=nodejs-demo -n default | sed -n '/Liveness/,/Events/p'
kubectl get endpoints nodejs-demo -n default

故意让应用崩溃或阻塞时，观察 重启次数 与 Ready 条件变化。

TCP 探针（备选）

YAML 怎么接：与 HTTP 探针二选一；仍在 Deployment 容器里把 httpGet 换成 tcpSocket: { port: 3000 } 即可。适合「没有 HTTP、但端口能连上就算活着」的服务。

失败排查

CrashLoopBackOff：livenessProbe 过严或 initialDelaySeconds 过短；先放宽或加 startupProbe。
Service 无流量但 Pod Running：readiness 失败；kubectl get ep 为空地址。
06-01-k3s-networkpolicy-故障排查.md

排障

先看 playbook 输出：失败时先定位是 deploy/wait/http_check 哪一步。
集群侧总览：kubectl get nodes -o wide、kubectl -n kube-system get pods -o wide。
事件与日志：kubectl -n <ns> describe ...、kubectl -n <ns> logs ... --tail=200。

3.1 KiB Raw Blame History Unescape Escape