本文介绍了Kubernetes探针的工作原理，通过交互式演示展示如何利用探针提升应用弹性、避免重启循环和请求丢失等问题，并提及了基于TypeScript的模拟集群工具webernetes。

好的，这是根据您的要求，对原文进行的中文重述，保留了核心细节，并删减了与主题无关的内容（如作者的个人介绍、webernetes项目的具体细节、以及文末的ngrok产品推广）。

Kubernetes 探针（Probes）工作原理详解

本文通过交互式演示，深入浅出地讲解了 Kubernetes 探针如何提升应用的弹性，并帮助避免常见的错误，例如重启循环和滚动更新期间的请求丢失。

1. 无探针的 Pod 问题

一个没有配置探针的 Pod，在容器启动后会被 Kubernetes 立即标记为“就绪”（Ready），即使它还在进行初始化工作，并未真正开始监听端口。这会导致一个问题：当客户端（如另一个 Pod）向该 Pod 发送请求时，如果容器正在启动或重启，请求就会失败。

2. 三种探针

Kubernetes 提供了三种探针来解决上述问题：

• 启动探针（Startup Probe）：判断容器内的应用是否已成功启动。
• 就绪探针（Readiness Probe）：判断应用是否已准备好接收流量。
• 存活探针（Liveness Probe）：判断应用是否需要被重启。

3. 启动探针

启动探针最适合解决容器启动期间的请求失败问题。它通过定期检查（如 HTTP GET 请求）来判断应用是否启动完成。在启动探针成功之前，Pod 会保持“未就绪”（NotReady）状态。

关键点： * 配置：可以设置检查频率（periodSeconds）和允许的失败次数（failureThreshold）。例如，periodSeconds: 1 和 failureThreshold: 5 意味着给容器大约 5 秒的启动时间。 * 作用：启动探针成功前，Pod 不会被标记为 Ready，从而避免在未就绪时接收流量。 * 误配置风险：如果 failureThreshold 设置过小，导致探针在容器启动完成前就判定失败，Kubernetes 会不断重启容器，造成崩溃循环（CrashLoopBackOff）。

4. 就绪探针

在启动探针成功后，就绪探针接管工作，持续监控容器的运行状态。一旦就绪探针失败，Pod 会被标记为 NotReady，并从所有关联的服务（Service）的负载均衡中移除，不再接收新请求。

关键点： * 作用：确保只有健康、能处理请求的 Pod 才会接收流量。 * 阈值：可以设置 failureThreshold 和 successThreshold 来避免因瞬时故障导致 Pod 被频繁移除。默认值（失败3次，成功1次）通常是合理的。 * 与启动探针的区别：启动探针专注于启动阶段，可以更频繁地检查；就绪探针则用于稳态运行。启动探针失败会重启容器，而就绪探针失败不会。

5. 存活探针

存活探针的工作方式与就绪探针类似，但失败后的后果更严重：它会直接杀死容器，然后由 Kubernetes 根据 Pod 的重启策略（默认为“总是”）进行重启。

关键点： * 作用：用于处理容器自身无法恢复的严重问题，如死锁、关键线程崩溃等。 * 误配置风险：切勿让存活探针依赖共享的外部依赖（如数据库）的健康状态。如果数据库短暂故障，所有 Pod 的存活探针都会失败，导致所有容器同时崩溃重启，形成“雪崩式故障”。即使数据库恢复，重启后的容器也会因瞬间涌入的流量洪峰（“惊群效应”）而再次崩溃，陷入无法恢复的恶性循环。

6. 探针与部署（Deployments）

在滚动更新（RollingUpdate）中，探针直接影响更新速度。部署策略中的 maxUnavailable 和 maxSurge 参数控制着新旧 Pod 的替换节奏。

• 有探针时：新 Pod 必须通过启动探针和就绪探针后，才会被标记为 Ready，然后才能替换旧 Pod。探针的检查周期越长，滚动更新完成所需的时间就越长。
• 无探针时：新 Pod 一启动就被视为 Ready，更新速度极快，但会导致请求失败，因为新容器尚未完成初始化。

7. 设计探针端点的建议

• 启动探针：
  • 用于启动缓慢或不确定的场景。
  • 可设置较短的检查周期和较高的失败阈值，以快速检测启动完成。
  • 最好使用独立的 /startup 端点进行针对性检查。
• 就绪探针：
  • 保持轻量和保守。仅在移除 Pod 能改善整体服务健康时才让其失败。
  • 避免依赖共享依赖（如数据库）或高 CPU/内存使用率。
• 存活探针：
  • 仅在容器确实卡死且重启能解决问题时让其失败。
  • 切勿依赖共享依赖或高资源使用率。
• 通用建议：
  • 保持探针轻量，避免消耗过多集群资源。
  • 默认的 failureThreshold 为 3，仅在必要时才降低。

总结

正确配置探针是保障 Kubernetes 应用稳定性的关键。通过理解其工作原理和潜在陷阱，可以做出更明智的决策，避免因配置不当导致的严重故障。

根据评论内容，主要观点及论据总结如下：

观点一：文章解释清晰，但无新意
- 评论1（sidcool）认为文章虽未提出新内容，但解释比Kubernetes官方文档更易懂。
- 关键引用：
- "This does not state anything new, but explains it so much well than the kubernetes documentation."

观点二：反对“不因上游依赖失败而触发健康检查”
- 评论2（stackskeleton，SRE）强烈反对文章建议，认为应在上游依赖失败时触发就绪/存活检查，理由包括：
- 重启可清除DNS缓存（如Java不尊重TTL）。
- 重启可修复TCP连接异常状态。
- 避免因错误环境变量导致数据库连接失败，从而阻止滚动更新引发故障。
- 关键引用：
- "Strong disagree with do not fail readiness and liveness checks on upstream dependencies failing."
- "if you are not ready to do work including critical upstream dependencies, don't lie to system and say you are."

观点三：对文章动画制作方法感兴趣
- 评论3（stroebs）关注如何制作类似动画用于内部文档，未涉及文章核心观点。
- 关键引用：
- "I need to know how to animate things like this for internal documentation."

总结：评论主要围绕文章对Kubernetes健康检查策略的争议展开，一方认可其解释清晰性，另一方（SRE）强烈反对其“不因上游依赖失败而触发检查”的建议，并列举实际运维场景支持重启策略。另有评论关注动画制作技术。