Argo CD 是基于 Kubernetes 的声明式， GitOps 持续交付工具。
GitOps Agent
GitOps = IaC + Git + CI/CD，即基于 IaC 的版本化 CI/CD。它的核心是使用 Git 仓库来管理基础设施和应用的配置，并且以 Git 仓库作为基础设施和应用的单一事实来源。
Git 仓库中的声明式配置描述了目标环境当前所需基础设施的期望状态
GItOps的Agent 会根据期望状态来调整当前的状态，最终使实际状态符合期望状态。
GitOps 的设计哲学
声明式
版本控制/不可变
所有状态声明都存储在 Git 仓库中，所有的操作都是从 Git 仓库里驱动的，保留了完整的版本历史，方便回滚。
自动应用变更/自动修复
1.在目标环境中安装 agent
2.Git 仓库中声明的期望状态发生变更，agent可以立即将变更 应用到系统中
3.不需要额外工具（比如 kubectl），也不需要配置 Kubernetes 的认证授权
4.一旦实际状态与期望状态不匹配，agent 就会进行自动修复
Push vs Pull
Push 模式
大多数 CI/CD 工具都使用基于 Push 的部署模式，例如 Jenkins、CircleCI 等。这种模式一般都会在 CI 流水线运行完成后执行一个命令（比如 kubectl）将应用部署到目标环境中
push 模式的缺陷：
需要安装配置额外工具（比如 kubectl）；
需要 Kubernetes 对其进行授权；
需要云平台授权；
无法感知部署状态。也就无法感知期望状态与实际状态的偏差，需要借助额外的方案来保障一致性。
Pull 模式
Pull 模式会在目标环境中安装一个 Agent，Agent 会周期性地监控目标环境的实际状态，并与 Git 仓库中的期望状态进行比较，如果实际状态不符合期望状态，Agent 就会更新基础设施的实际状态以匹配期望状态。
GitOps 的优势
GitOps 工具大部分都是基于 Pull 的部署模式，这种模式有以下优势
更强大的安全保障
使用 GitOps 不需要任何 Kubernetes 或者云平台的凭证来执行部署，Kubernetes 集群内的 Argo CD 或者 Flux CD 只需要访问 Git 仓库，并通过 Pull 模式来更新即可。
Git 作为唯一真实来源
所有的应用包括基础设施的声明式配置都保存在 Git 中，并把 Git 作为应用系统的唯一事实来源，因此可以利用 Git 的强大功能操作所有东西，例如版本控制、历史记录、审计和回滚等等。
提高生产力
Git 是开发人员非常熟悉的工具，通过 Git 不断迭代，可以提高生产率，加快开发和部署速度
更容易合规的审计
使用 GitOps 的基础设施（cpu，内存，磁盘，带宽等）可以像任何软件项目一样使用 Git 来管理，可以通过创建 Pull Request的方式进行 Code Review ，更改才可以应用到系统中。
Argo CD Agent
Argo CD 的主要职责是 CD，CI主要是交给 Jenkins，Gitlab CI 等工具来完成，Argo CD 在 CI/CD 流程中的位置如下图所示:
Argo CD是基于Kubernetes对GitOps的实现
Argo CD在Kubernetes 集群中靠 Operator（下图中 Application Controller） 来充当GitOps的 Agent。实现的GitOps功能
Argo CD架构图
Argo CD架构图
Argo CD 有三大组件：API Server、Repository Server 和 Application Controller
从 GitOps 工作流的角度来看，总共分为 3 个阶段：检索、调谐和呈现。
检索 -- Repository Server
检索阶段会克隆应用声明式配置清单所在的 Git 仓库，并将其缓存到本地存储。包含 Kubernetes 原生的配置清单、Helm Chart 以及 Kustomize 配置清单。履行这些职责的组件就是Repository Server。
调谐 -- Application Controller（GitOps的Agent）
这个阶段会将Repository Server获得的配置清单与反映集群当前状态的实时配置清单进行对比，一旦检测到应用处于OutOfSync状态，Application Controller就会采取修正措施，使集群的实际状态与期望状态保持一致。
呈现 -- API Server
由 Argo CD 的API Server负责，它本质上是一个 gRPC/REST Server，提供了一个无状态的可视化界面，用于展示结果。
