Argo CD Argo CD

推送与拉取:Argo CD 如何向 Kubernetes 交付

为什么基于拉取、由 Git 驱动的交付会改变你部署、保障安全和恢复集群的方式。

8 min 初级

大多数团队开始向 Kubernetes 部署的方式都一样:CI 系统构建镜像,然后对集群运行 kubectl apply 或 helm upgrade。这在一开始行得通,直到应用和集群的数量增长。本指南解释当集群内部的代理(例如 Argo CD)改为从 Git 拉取期望状态时,会发生什么变化,以及随之而来的权衡。

推送模型及其吃力之处

在推送式流水线中,CI 任务是唯一接触集群的组件:

  1. 一次提交触发测试和镜像构建。
  2. 任务用新的镜像标签更新清单。
  3. 任务对集群运行 kubectl apply(或 helm upgrade)。

随着规模扩大,会出现三个问题:

  • 凭据位于集群之外。 每条流水线都需要 kubeconfig 或云凭据,并且随着应用和集群的增多而成倍增加。
  • 工具位于 runner 上。 kubectl、helm 及其版本必须安装在每个执行部署的地方,并保持同步。
  • 反馈止于”已应用”。 任务只知道 API 服务器接受了清单,却不知道 Pod 是否真的变为健康。

反转方向:拉取

在拉取模型中,一个运行在集群内部的代理监视 Git 仓库,将其中声明的内容与实际运行的内容进行比较,并应用差异。

Developer ─▶ App repo ─▶ CI (test, build) ─▶ Image registry
                            │
                            └─ commits new image tag ─▶ Config repo
                                                            ▲
                                        Argo CD (in cluster) ┘ pulls, compares, applies
                                                │
                                                ▼
                                            Kubernetes

集群凭据永远不会离开集群,因为唯一应用变更的是运行在集群内部的代理。工程师和 CI 系统只需要 Git 的写权限。Argo CD 可以读取纯 YAML、Helm chart 和 Kustomize overlay,并在应用之前把它们渲染成 Kubernetes 清单。

将应用代码与配置放在不同的仓库中

通常的建议是使用两个仓库:一个放应用源代码,一个放 Kubernetes 配置(Deployment、Service、ConfigMap、Ingress 等)。

原因在于配置有它自己的变更节奏。编辑一个 Service 或 ConfigMap,不应该为未改动的代码触发完整的构建与测试流水线,你也不希望流水线里有检查提交内容以决定跳过什么的逻辑。CI 流水线的最后一步变成”把新的镜像标签提交到配置仓库”,之后由 Argo CD 接手。这也清晰地划分了职责:开发者负责 CI,平台或运维团队负责交付。

让 Git 成为唯一入口:漂移检测与自愈

Argo CD 既监视仓库,也监视实时集群。当两者不一致时,应用会被报告为 OutOfSync。根据你的配置,Argo CD 随后要么只是通知你,要么将集群恢复为与 Git 一致(参见本系列中的同步策略指南)。

这会带来一些实际影响:

  • 每一次变更都有提交、作者,通常还有经过审查的拉取请求,这为你提供了审计轨迹。
  • 权限转移到了 Git。初级工程师可以提交拉取请求,只有少数人可以合并。你无需为此给每个人配置集群角色。
  • 在生产环境里临时用 kubectl edit 改一下,不再是不可见的。

回滚与恢复变成 Git 操作

因为期望状态有版本记录,回到已知的良好状态只需 git revert,Argo CD 会让集群收敛到该状态。恢复同理:如果集群丢失,你只需创建新集群、安装 Argo CD、注册同一个仓库,工作负载就会从中重新创建。不在 Git 中的内容,例如持久化数据或你在别处管理的 Secret,仍然需要各自的备份方案。

一个 Argo CD 实例还可以管理多个集群,因此一个仓库就能驱动整个集群队列。

Argo CD 不能替代什么

Argo CD 是交付工具,而不是构建工具。你仍然需要 CI 来测试代码、构建镜像并推送到镜像仓库。它专用于 Kubernetes,因此其他部署目标需要其他工具。而且它并非唯一的 GitOps 控制器:Flux 以不同的设计实现了同样的原则。本系列的其余部分以 Argo CD 为前提,并从安装它开始。完整参考请见 Argo CD 官方文档。

热门指南