四个绿色状态回答四个不同问题

一句话总结

与 Git 一致、Kubernetes 已经就绪、用户请求成功，是彼此不同的主张。

为什么需要了解这一点

值班频道收到一条“无法付款”的消息。部署画面显示 Synced 和 Healthy，Pod 也是 Ready。 此时如果回答“基础设施正常，请用户重试”，结论就超出了已经确认的范围。 也不必断言画面上的绿色标记是错误的，因为该标记回答的问题可能与用户提出的问题不同。 本练习不会连接支付系统，而是用一个让 nginx 业务路径故意返回 500 的小型模型来复现这种差异。 它使用个人 VM 中的 Argo CD 与 HTTP server，而不是为了模拟真实故障处置而制作的虚假状态文件。

工作原理

调查时，请按顺序分开以下四个问题。

问题	确认依据	仅凭这一点无法知道什么
试图部署哪项变更	远程 main 与 Git commit 中的文件	controller 是否看到了该 commit
该目标是否已反映到 cluster	Application 的 sync revision 与 Synced	运行中的进程是否读取了新设置
资源是否满足就绪条件	health、observedGeneration、updatedReplicas、Pod Ready	业务路径是否返回正确正文
我们调查的请求是否成功	请求路径、响应码、正文、观测时间	全体外部用户的成功率与长期可用性

Argo CD 默认的 health 评估使用各资源类型的 Kubernetes 状态。例如，确认 Deployment 的当前 generation 是否已被观测以及 updated replica 很重要，但它无法自动理解电商订单的业务含义。 Synced 也不是评估应用含义的功能。如果把错误配置保存到 Git，忠实部署该配置的结果仍可能是 Synced。 因此，GitOps 的声明式管理与良好的应用验证不能互相替代。 官方 resource health 文档。

readiness 是判断是否准备好向该 Pod 发送流量的信号。但实际检查什么，取决于我们编写的 probe 和应用实现。 练习中的 /healthz 只返回表示进程能够响应的 200，业务路径 / 则返回 500。这种设计故意不完整， 不是推荐用于生产的 probe。另一方面，当外部支付 API 暂时变慢时，让所有 Pod 的 liveness 都失败也不能解决问题。 readiness 的流量控制与 liveness 的重启判断有不同目的。如果未确认外部依赖故障能否通过重启修复， 就把两个信号关联起来，可能不会带来恢复，反而会产生重启负载。 官方 probe 概念。

实际工作中的表现

第一个陷阱是不检查 commit，只看绿色画面。看到的可能不是刚推送变更的 Healthy， 而是上一个 commit 的 Healthy。应同时比较本地 HEAD、server 的远程 main 和 Application 的 status.sync.revision。 branch 名称 main 是会移动的名称，而 commit SHA 是那个时刻的具体 source。push 命令结束并不能证明部署完成。 练习中会通过 refresh 请求相应 Application 重新比较，但这也不是成功声明，因此还要等待实际 revision 与状态收敛。 不会更改整个 controller 的设置或其他 Application。

第二个陷阱是只记录响应码。即使是 200，也可能是旧正文或其他版本的响应。 同时记录 service address、路径、正文与时间，再与已部署 Pod 的 UID 关联，主张会更加明确。 反过来，500 是 server 已经发送 HTTP 响应这一观测结果。不要把 DNS 失败或连接失败笼统归为同一事件。 本练习的 500 通过 nginx 配置复现，因此如果把外部 API 或 DNS 故障写成原因，就与观测不符。

练习从 VM 调用 ClusterIP。仅凭这条路径成功，无法断言外部 DNS、ingress、TLS 和认证均正常。 最终报告中要写明仍需确认外部路径。即使短时间内成功三次，也不要把结果解释为一个月的可用性或真实支付成功率， 这同样是工程师验证能力的一部分。

下个练习将做什么

在首次观测中保留 Git revision 与资源身份，分别读取 readiness 和业务响应。依据公开的 nginx 设置与实际响应缩小原因范围。之后在 Git 中修复设置，但还要通过另一项观测确认：只修改设置是否已经改变现有进程。 不要编造数字或 UID，应从辅助工具留下的实际观测中调查。