文章目录Nginx 配置 Readiness Probe就绪探针第一步为 Nginx 添加 HTTP 就绪探针第二步检查探针和滚动更新第三步 给 Nginx 添加 Liveness Probe下一步先练习 Liveness Probe存活探针和 Readiness Probe就绪探针暂时不急着部署 Ingress。Liveness Probe判断容器是否需要重启。Readiness Probe判断容器是否已经可以接收流量。Startup Probe给启动较慢的应用预留初始化时间避免过早触发其他探针。这三个概念在 DevOps 面试中非常常见也能帮助你解释为什么容器处于 Running 状态却不一定能正常对外提供服务。我们下一步可以给现有 Nginx Deployment 配置 HTTP 就绪探针验证 Pod 的 Ready 状态如何影响 Service 的后端流量。操作前先保存当前 Deployment 配置便于随时恢复sudok3s kubectl get deployment nginx-nnginx-lab-oyaml\~/nginx-deployment-before-probes.yamlcat nginx-deployment-before-probes.yamlapiVersion:apps/v1kind:Deploymentmetadata:annotations:deployment.kubernetes.io/revision:2creationTimestamp:2026-10-14T06:37:23Zgeneration:2labels:app:nginxname:nginxnamespace:nginx-labresourceVersion:10134uid:194c1d63-613d-4ba4-9abd-8c452a4cc597spec:progressDeadlineSeconds:600replicas:2revisionHistoryLimit:10selector:matchLabels:app:nginxstrategy:rollingUpdate:maxSurge:25%maxUnavailable:25%type:RollingUpdatetemplate:metadata:labels:app:nginxspec:containers:-image:m.daocloud.io/docker.io/library/nginx:stableimagePullPolicy:IfNotPresentname:nginxresources:{}terminationMessagePath:/dev/termination-logterminationMessagePolicy:FilednsPolicy:ClusterFirstrestartPolicy:AlwaysschedulerName:default-schedulersecurityContext:{}terminationGracePeriodSeconds:30status:availableReplicas:2conditions:-lastTransitionTime:2026-10-14T06:47:50ZlastUpdateTime:2026-10-14T06:56:22Zmessage:ReplicaSet nginx-68bfbd8bb7 has successfully progressed.reason:NewReplicaSetAvailablestatus:Truetype:Progressing-lastTransitionTime:2026-10-14T08:18:41ZlastUpdateTime:2026-10-14T08:18:41Zmessage:Deployment has minimum availability.reason:MinimumReplicasAvailablestatus:Truetype:AvailableobservedGeneration:2readyReplicas:2replicas:2terminatingReplicas:0updatedReplicas:2Nginx 配置 Readiness Probe就绪探针第一步为 Nginx 添加 HTTP 就绪探针sudok3s kubectl patch deployment nginx-nnginx-lab\--typestrategic\-p{ spec: { template: { spec: { containers: [{ name: nginx, readinessProbe: { httpGet: { path: /, port: 80 }, initialDelaySeconds: 5, periodSeconds: 5, timeoutSeconds: 2, failureThreshold: 3 } }] } } } }这条命令会修改 Deployment 的 Pod 模板因此 Kubernetes 会触发一次滚动更新逐步替换原来的两个 Pod。它不会修改宿主机端口也不会改动你的博客和 Jenkins。参数含义path: /请求 Nginx 首页port: 80检查容器的 80 端口initialDelaySeconds: 5容器启动约 5 秒后开始检查periodSeconds: 5每隔 5 秒检查一次timeoutSeconds: 2单次检查最多等待 2 秒failureThreshold: 3连续失败 3 次后判定为未就绪第二步检查探针和滚动更新# 等待 Deployment 更新完成sudok3s kubectl rollout status deployment/nginx\-nnginx-lab--timeout120s# 查看 Pod 就绪状态sudok3s kubectl get pods-nnginx-lab# 查看探针配置sudok3s kubectl describe deployment nginx-nnginx-lab第三步 给 Nginx 添加 Liveness Probe先给现有 Deployment 增加存活探针。它和已有的 Readiness Probe 可以同时工作不会因为配置 Liveness 就立即重启容器。sudok3s kubectl patch deployment nginx-nnginx-lab\--typestrategic\-p{ spec: { template: { spec: { containers: [{ name: nginx, livenessProbe: { httpGet: { path: /, port: 80 }, initialDelaySeconds: 10, periodSeconds: 5, timeoutSeconds: 2, failureThreshold: 3 } }] } } } }参数含义参数含义httpGet.path: /通过 HTTP 请求 Nginx 首页initialDelaySeconds: 10容器启动后先等待 10 秒periodSeconds: 5每 5 秒检查一次timeoutSeconds: 2单次检查最多等待 2 秒failureThreshold: 3连续失败 3 次后触发重启deployment.apps/nginx patched说明Liveness Probe 的配置修改已被 Kubernetes 接受。接下来确认滚动更新成功并检查两个探针是否都生效。执行下面三条命令# 1. 等待滚动更新完成sudok3s kubectl rollout status deployment/nginx\-nnginx-lab--timeout120s# 2. 查看 Pod 状态和重启次数sudok3s kubectl get pods-nnginx-lab# 3. 检查两个探针的配置sudok3s kubectl describe deployment nginx-nnginx-lab第一步生成实验 Pod 配置cat~/nginx-liveness-lab.yamlEOF apiVersion: v1 kind: Pod metadata: name: nginx-liveness-lab namespace: nginx-lab spec: restartPolicy: Always containers: - name: nginx image: m.daocloud.io/docker.io/library/nginx:stable command: - nginx - -g - daemon off; ports: - containerPort: 80 livenessProbe: httpGet: path: /healthz-missing port: 80 initialDelaySeconds: 5 periodSeconds: 5 timeoutSeconds: 2 failureThreshold: 3 EOF这份配置的关键点restartPolicy: Always容器退出后Kubernetes 会尝试重新启动它。livenessProbe访问一个不存在的 URL预期返回 HTTP 404。failureThreshold: 3连续三次检查失败后触发容器重启。第二步检查 YAML 是否正确执行sudok3s kubectl apply\--dry-runclient\-f~/nginx-liveness-lab.yaml面试中可以这样总结我在 K3s 中创建了一个独立的 Nginx 实验 Pod并配置 Liveness Probe 检查一个不存在的 HTTP 路径。通过 kubectl get pod 观察到重启次数持续增加最终进入 CrashLoopBackOff。查看容器日志后发现Kubernetes 探针连续请求 /healthz-missing 并收到 404随后 Nginx 收到 SIGQUIT 开始退出。结合 Pod Events 可以确认探针失败触发了容器重启。这个实验说明容器进程最初能够正常启动并不代表健康检查一定能通过Liveness Probe 配置错误本身也可能导致持续重启。因此在生产环境中探针路径必须与应用真实的健康检查接口匹配并合理设置延迟、间隔和失败阈值。这就是一段完整的 Kubernetes 故障排查案例发现异常 → 查状态 → 看日志 → 查事件 → 定位原因 → 修复或清理。