考试用的那些词 — 以及 CI 与 CD 的边界挪到哪去了
一句话总结
CGOA 没有实操考试，取而代之的是检查术语使用是否准确。desired state、actual（live）state、drift、reconciliation、convergence 不能互换使用，它们分别占据同一个 loop 中五个不同位置。
为什么需要它
实际工作中，即使用“已经执行 sync”“状态不一致”这样的表达也能沟通。但考试会问“以下哪项最准确地描述 drift？”，四个选项中往往有三个看起来都合理，还会加入 Deviation、Delta、Divergence 等干扰词。只掌握模糊定义，一定会选错。
工作原理
按顺序走完一个 loop，如下所示。
- Desired state（期望状态）——在 Git 中声明、系统应达到的目标，包含渲染结果。Helm chart 或 kustomize overlay 是“生成期望状态的材料”，期望状态本身则是由它们渲染得到的最终 manifest。
- Actual state / Live state（实际状态）——cluster API server 当前持有的 object。
- Drift（漂移）——二者之间的差异。有人执行
kubectl edit、controller 修改字段，或先前 sync 在中途失败时都会产生 drift。 - Reconciliation（协调）——发现差异，并把 actual state 推向 desired state 的动作。
- Convergence（收敛）——最终二者相同的状态。它可能无法一次完成；经过多个 loop 最终达到一致，称为 eventual consistency。
此外还有两个术语。State store 是保存 desired state 的 version control system（通常是 Git）；Software agent 是集群内执行 reconciliation 的 process（Argo CD、Flux）。OpenGitOps 文档使用这两个词而非具体工具名称，是为了说明 GitOps 并不绑定某个产品。
CI 与 CD 的边界去了哪里
传统 CI/CD 以“测试结束的位置”为边界。GitOps 则把边界移动到两个 repository 之间。
[앱 저장소] 코드 커밋 → 빌드 → 테스트 → 이미지 푸시 → (설정 저장소에 태그 커밋)
|
| ← 여기가 CI 의 끝
|
[설정 저장소] PR 리뷰 → 머지 → (에이전트가 당겨감) → 클러스터
↑ 여기부터가 CD
CI 的 artifact 不再是“部署”，而是commit。CD 不是由人触发的 task，而是始终运行的 loop。因此，在 GitOps 中，“部署失败”与“同步失败”是两类不同事件；rollback 也不是重新执行 pipeline，而是使用 git revert。revert 不会删除历史，而是添加新 commit，因此也符合不可变原则。
一个经常出现的陷阱：webhook 不是必需的。即使没有 webhook，agent 仍会按 polling interval 检查 Git，最终完成 convergence。webhook 只是缩短延迟的优化，声称“没有 webhook 就不是 GitOps”是错误的。
现场会遇到的情况
作者的家庭实验室曾遇到这样一幕：部署 KubeVirt 后，所有 component 状态都是 AllComponentsReady，VM 却无法启动。检查 virt-launcher Pod spec 后，发现缺少 init container 所需 binary 的 volume mount。记录显示，这已经是同一集群第三次出现此类事件。
这与术语的关系在于：Sync status 与 Health status 是两条不同轴线。Argo CD 也会分别显示 Synced（desired state 与 actual object 相同）和 Healthy（object 确实正常工作）。应用处于 Synced 但 Degraded 很常见，因为它完全按 Git 指示创建了 object，只是 manifest 本身有错。如果考试问“OutOfSync 时能否同时 Healthy？”，答案是可以。两条轴彼此独立。
下一项测验要确认什么
下一模块将设计 repository structure。desired state “以什么形态放在哪个 directory”本身就是 repository strategy，而 environment promotion 会被整理成一个 PR：只在该结构上移动一行 image tag。