Liveness/Readiness样本

2）设计原则

1.共享语义。

准备就绪：外部满足查询的能力（考虑关键依赖性）。
活着："无法治愈"的过程状态的细节。
2.失败快速，但不是"false-fast"。自定义"failureThreshold"计时器/阈值,使短暂的爆发不会导致额外的重启。
3.样品中没有重型手术。检查必须快速（≤100-200毫秒），并且没有副作用。
4.优美的降解。如果依赖项部分不可访问,则Readiness=OK（如果存在安全后备程序（缓存/收缩））。
5.Deterministic I/O.状态仅取决于当前状态，而不取决于"随机"外部测试。

3）健康末端的语义

3.1个HTTP方法（推荐）

"GET/healthz/liveness" → 200如果过程"活着"（事件循环旋转，GC没有卡住，看门狗"心脏"跳动）。
"GET/healthz/readiness" → 200如果实例已准备好用于关键类的流量。检查：连接池、本地缓存、业务逻辑核心可用性。
初始化后"GET/healthz/startup" → 200（缓存迁移/加热/模型加载）。

• 你不能活着去外部DB/API-这将导致成瘾事件期间的"自杀"。
• 在准备就绪中，可以测试关键依赖性，但是随着时间的流逝和退化：如果有一个有效的后卫-不要倒下。

3.2 gRPC Health Checking

使用'grpc标准。health.v1.具有Service scoped状态的健康/检查（"SERVING"，"NOT_SERVING"）。对于Kubernetes，是grpc样本（或http代理）。

3.3内部触发器

看门狗"软"停止：在SIGTERM中，显示Readiness=FAIL →等待"terminationGracePeriodSeconds" →通过排队完成。

4）计时和急流（tuning）

• `initialDelaySeconds`, `periodSeconds`, `timeoutSeconds`, `successThreshold`, `failureThreshold`.

• readiness: `period=5s, timeout=0.2–0.5s, failure=2`
• liveness: `period=10s, timeout=0.2–0.5s, failure=3`

• startup： 'period=5s, failure=60'（最多~ 5分钟）
• 在启动成功后激活就绪/生活
• Batch/consumer:

准备就绪反映了处理准备（连接到经纪人，是否存在DLQ降解），

liveness-内部心跳循环。

故障后坐力：在应用程序中,使用指数后坐力重新连接到依赖项,否则就绪将"剥离"。

5）配置（片段）

5.1 Kubernetes, HTTP样本

yaml livenessProbe:
httpGet: { path: /healthz/liveness, port: 8080 }
periodSeconds: 10 timeoutSeconds: 1 failureThreshold: 3

readinessProbe:
httpGet: { path: /healthz/readiness, port: 8080 }
periodSeconds: 5 timeoutSeconds: 1 failureThreshold: 2

startupProbe:
httpGet: { path: /healthz/startup, port: 8080 }
periodSeconds: 5 failureThreshold: 60

5.2 Kubernetes, gRPC样本

yaml readinessProbe:
grpc:
port: 9090 service: my. app. Service periodSeconds: 5 timeoutSeconds: 1

5.3 Graceful shutdown

yaml terminationGracePeriodSeconds: 30 lifecycle:
preStop:
exec:
command: ["/bin/sh","-c","curl -s localhost:8080/healthz/drain && sleep 5"]

服务内部的'/healthz/drain'翻译Readiness=FAIL（停止接受）,给时间完成活动请求。

6）成瘾和退化

关键（没有它们就无法维护）："/登录"的授权数据库，"/pay"的支付网关。可以使用"timeoutSeconds"样本的≤80％定时进行准备性检查。
非临界：分析、电子邮件、缓存层（如果有挂载）。不要将它们包括在准备工作中；使用后卫。
Feature-flags：当部分降解时,通过保留Readiness=OK来禁用从属字体。

7）队列和背景处理程序

Consumers/Workers:

如果已为经纪人建立订阅/连接,并且有处理资源,则Readiness=确定。
当DLQ/Lag溢出时，Readiness →可以保持OK（如果我们接受和折叠），但是SLI "新鲜/LA"亮起-根据数据。
Liveness： 控制poll 循环/heartbeat, dedlock检测器。

等效性：加快从重启生活中的恢复。

8) Sidecar/mesh/ingress

• 启用"readinessGate" （K8s）以考虑附带状态,
• 确保样品不会进入mTLS屏障（或添加例外情况）。
• Ingress/Envoy/Nginx：在本地滚动'/healthz/'，不向外"输出"内部细节。

9）安全和隐私

Health Endpoints不应披露Configs，库版本，错误行-仅"OK/FAIL"+最小原因代码。
限制外部访问（NetworkPolicy/ACL）。对于公众来说-让我们只是在没有细节的情况下直播。
健康检查的日志位于DEBUG级别，带有trottling。

10）可观察性和SLO

导出指标：'health_readiness {status}、'health_liveness {status}、样品处理时间'。
将Readiness-flaps与可用性SLO（从Endpoint → 5xx/connection reset）关联。

• "频繁的liveness重新开始>N/hour"是衰落/泄漏的症状。
• "Flap Readiness> X/15 min"是依赖/网络问题的症状。
• 与dploy（'service。version`).

11）测试

单位/合同：当关闭每个依赖项时,endpoints '/healthz/'返回正确的状态。
混乱：DB/缓存/经纪人断开：准备就绪应严格按照模型下降或打开后卫。Liveness-如果过程"活着"不会触发。
Load/Soak：在负载下，健康端点必须保持快速（不要打孔）。
金丝雀：在流量增加之前检查准备就绪的稳定性。

12）频繁的错误以及如何避免错误

Liveness检查DB/外部 API。结果是事件无休止的重启。解决方桉：将生活限制在"过程生活"。
样品中的重检查。导致虚假拒绝。解决方桉：轻松检查+单独的背景健康监视器。
没有Startup Probe。缓慢的开始被liveness"杀死"。解决方桉：添加带有宽窗口的启动。
缺少graceful shutdown。稀有的5xx变质。解决方桉：preStop+退出平衡。
Flap风暴。太激进的阈值。解决方桉：举起"failureThreshold"，增加"timeoutSeconds"，添加backoff。
一切都一样。语义混合。解决方桉：单独的"liveness/readiness/startup"。

13）实现迷你模式

python
@app. get("/healthz/liveness")
def liveness():
return 200

@app. get("/healthz/readiness")
def readiness():
ok_core = core_is_ready () # local pools/caches/initialization ok_db = db. ping (timeout = 50 _ ms) # only if the DB is critical return 200 if (ok_core and ok_db) else 503

@app. get("/healthz/startup")
def startup():
return 200 if INIT_DONE else 503

@app. post("/healthz/drain")
def drain():
set_readiness(False); return 200

go
// use google. golang. org/grpc/health/grpc_health_v1 healthServer. SetServingStatus("my. app. Service", SERVING) // or NOT_SERVING

yaml spec:
readinessGates:
- conditionType: "proxy. istio. io/ready"

14）支票单

出售前

• 分开liveness/readiness/startup后端，描述其语义。
• Liveness不触及外部依赖性；Readiness仅检查关键的taymouth和fallback。
• 将'initialDelay/period/timeout/failureThreshold'配置为服务配置文件。
• 启用了graceful shutdown： 'preStop'+从平衡中移除。
• 健康指标/逻辑连接；Alertes on restarts/flap。
• 已通过依赖性故障和慢启动测试。

运营

• 每周重新开始和准备工作报告。
• 事件发生后的阈值调节；与发行版的关系。
• 定期chaos关闭依赖性测试。
• 当依赖关系的关键性发生变化时语义的相关性。

15) FAQ

问：是否可以通过一个样本来关闭所有内容？
答：不希望。分享"启动"、"准备就绪"、"生活"-减少误报并加速RCA。

问： 是否在准备就绪中检查缓存?

答：如果没有缓存，则有正确的（尽管速度最慢）模式-不要放弃准备，只需启用降级即可。

问：经常重启生活怎么办？
答：首先排除减速/泄漏；然后放宽阈值并在应用程序中添加看门狗。

问：如何考虑多重性？
答：准备就绪应反映为任何租赁流量提供服务的能力。对于特定租户的私人问题-不要改变准备工作，而是用单独的SLI/Alert发出信号。

• "可观察性：逻辑，度量，跟踪"
• "分布式跟踪"
• "SLO/SLA和指标"
• "网络手册交付保证"
• "In Transit加密"
• "秘密管理"