项目：One App — Three Probes — 真实故障

I’m ready to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (excluding the source line you already provided) here? Once I have it, I’ll translate it into Simplified Chinese while preserving all formatting, markdown, and code blocks.

视觉思维模型（先记住这个）

流量规则（关键）

• ❌ Startup probe FAIL → 容器 未 被活性/就绪探针检查。
• ❌ Readiness probe FAIL → pod 获得 无流量。
• ❌ Liveness probe FAIL → pod 被 RESTARTED。

您将演示的内容

您将运行 一个应用，它：

• 启动 缓慢（需要 startup 探针）
• 可能 暂时不可用（需要 readiness 探针）
• 可能 卡住（需要 liveness 探针）

这反映了 真实的生产行为。

步骤 0 — 前置条件

minikube start
kubectl get nodes

第一步 — 演示应用（有意不完美）

我们将使用一个小型 HTTP 应用，它：

• 启动需要 20 秒
• 暴露 /ready 和 /health 接口

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: probe-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: probe-demo
  template:
    metadata:
      labels:
        app: probe-demo
    spec:
      containers:
      - name: app
        image: ghcr.io/stefanprodan/podinfo:6.5.3
        ports:
        - containerPort: 9898

Apply the manifest:

kubectl apply -f deployment.yaml
kubectl get pods

此时：

• 应用启动缓慢。
• Kubernetes 并不知道 流量可能会过早地到达它。

第 2 步 — 暴露应用

service.yaml

apiVersion: v1
kind: Service
metadata:
  name: probe-demo-svc
spec:
  selector:
    app: probe-demo
  ports:
  - port: 80
    targetPort: 9898
  type: NodePort

创建服务并在浏览器中打开：

kubectl apply -f service.yaml
minikube service probe-demo-svc

现在 真正的学习 开始了。

启动探针

什么是启动探针

“在容器完全启动之前不要对其进行判断。”

为什么 DevOps 需要它

如果没有启动探针，存活探针可能会无限重启启动缓慢的应用（例如 JVM、Python、连接数据库的应用）。

添加启动探针

startupProbe:
  httpGet:
    path: /health
    port: 9898
  failureThreshold: 30   # try for 30 seconds
  periodSeconds: 1

含义：
Kubernetes 会等待最长 30 秒 才将容器标记为已启动。在此期间，存活和就绪探针会被禁用。

演示失败（移除探针）

kubectl delete pod -l app=probe-demo
kubectl describe pod 

你会看到：

• Pod 在启动完成之前就已重启 → 对于慢启动的应用会出现经典的 CrashLoopBackOff。

就绪探针

它是什么

“这个 pod 能够 立即 接收流量吗？”

为什么 DevOps 关心

• 防止在部署期间接收流量。
• 阻止损坏的 pod 为用户提供服务。
• 零停机滚动更新的必备条件。

添加就绪探针

readinessProbe:
  httpGet:
    path: /ready
    port: 9898
  initialDelaySeconds: 5
  periodSeconds: 3

观察

kubectl get pods
kubectl describe pod 
kubectl get endpoints probe-demo-svc

当就绪探针失败时：

• Pod 仍保持 Running（运行）状态。
• 它会被 从 Service 端点中移除 → 不会收到流量。

演示缺失时的问题

移除就绪探针并部署新版本 → 流量可能会落到尚未完全启动的 pod 上，导致用户收到 502 / 空响应。

活跃性探针

它是什么

“这个容器仍然健康还是卡住了？”

为什么 DevOps 需要它

• 应用可能会永久挂起（死锁、内存泄漏）。
• Kubernetes 必须自动重启它们。

添加活跃性探针

livenessProbe:
  httpGet:
    path: /health
    port: 9898
  initialDelaySeconds: 20
  periodSeconds: 5

演示自动重启

模拟故障：

kubectl exec -it <pod-name> -- kill 1

观察结果：

kubectl get pods

你会看到 pod 自动重启——无需手动干预。

最终合并（生产‑正确）

startupProbe:
  httpGet:
    path: /health
    port: 9898
  failureThreshold: 30
  periodSeconds: 1

readinessProbe:
  httpGet:
    path: /ready
    port: 9898
  periodSeconds: 3

livenessProbe:
  httpGet:
    path: /health
    port: 9898
  initialDelaySeconds: 20
  periodSeconds: 5

DevOps Engineer Checklist (Interview‑Level)

你 必须 知道：

• Startup → 保护启动缓慢的应用
• Readiness → 控制流量
• Liveness → 自动恢复

常见陷阱：

• Readiness ≠ Liveness（最常见的错误）
• 缺少 readiness → 停机
• 缺少 liveness → 静默故障
• 错误的 startup 配置 → 无限重启

如何用生产环境的术语解释

“Startup 保护初始化，readiness 保护用户，liveness 保护平台。”