1 Argo 项目介绍
ArgoCD：专用于Kubernetes的声明式GitOps CD工具
Argo 项目于 2017 年由 Applatix 公司创立，2018 年初被 Intuit 收购；
之后，BlackRock 为 Argo 项目贡献了 Argo Events 这一子项目；
Argo 及其子项目为 Workflow、Trigger 和 Application 的管理提供了一种简单便捷的方式
- Argo 的所有组件都通过专用的 Kubernetes CRD 实现
-
支持使用或集成其他 CNCF 项目，如 gRPC、Prometheus、NATS、Helm 和 CloudEvents 等
Argo 生态目前主要由四个子项目组成
- Argo Workflows
- 第一个 Argo 项目
- 基于 Kubernetes 平台的原生工作流引擎，支持 DAG 和 step-based工作 流
- Argo Events
- Kubernetes 上的基于事件的依赖管理器，用于触发Kubernetes中的Argo工作流和其他操作
- Argo CD
- 由 Argo 社区和 Intuit 维护的开源项目
- 支持 GitOps 范式的的声明式 Kubernetes 资源管理
- Argo Rollouts
- ArgoCD 的高级交付策略工具
- 支持声明式渐进式交付策略，例如 canary 、blue-green等
1.1 ArgoCD 简介
ArgoCD 是什么？
- 将应用程序部署到 Kubernetes 之上的 GitOps 工具
-
核心组件：Application Controller 及相关的一组 CRD 组成
-
基础工作模型
- 以特定 Repository （配置仓库）为应用程序部署和管理的唯一可信源，该 Repository 负责定义 Application 的期望状态
- Application Controller 负责将 Repository 中定义的 Application 运行于一个特定的目标 Kubernetes Cluster 之上
- Application Controller 持续监视、对比 Application 的期望状态和实际状态，并确保实际状态与期望状态一致
1.2 ArgoCD 的主要功能
可协同使用各种配置管理工具（如 ksonnet/jsonnet、Helm 和 kustomize）确保应用程序的真实状态与 GitRepo 中定义的期望状态保持一致
将应用程序自动部署到指定的目标环境
持续监控已部署的应用程序
基于 Web 和 CLI 的操作接口，以及应用程序可视化
部署或回滚到 GitRepo 仓库中提交的应用程序的任何状态
PreSync、Sync、PostSync Hooks 以支持复杂的应用程序部署策略
- 例如 blue/green 和 canary upgrades；
SSO集成
- 劫持 OIDC、LDAP、SAML 2.0、GitLab、Microsoft、LinkedIn 等；
Webhook 集成
- GitHub、BitBucket和GitLab
可以独立使用，也可以作为现有Pipeline的一部分使用，例如与 Argo Workflow、Jenkins以及GitLab CI 等配合使用
1.3 声明式配置
在当前的 argo cd 版本中只提供了以下三个 CRD
Application CRD
- 定义由 ArgoCD 管理的应用程序
-
定义的这些应用程序受控于Application Controller
ApplicationSet CRD
- 以模板化形式自动生成由 ArgoCD 管理的应用程序
-
支持从多个不同的角度构建模板，例如不同的 Git Repo ，或者不同的 Kubernetes Cluster 等
-
ApplicationSet 受控于专用的 ApplicationSet Controller
AppProject CRD
- 为 Application 提供逻辑分组，同时提供如下功能
- 限制可用部署的内容，例如指定受信任的 Git Repository 白名单
- 限制应用程序可以部署到目标位置，包括目标集群和目标名称空间
- 限制可以部署或者不能部署的资源类型，例如 RBAC、CRD、DaemonSet 等
- 于是为了更好管控我们的 application ，那么每一个 application 都必须隶属于每一个 app project
，未指定隶属于哪一个 app project 时，则隶属于名为 “default” 的默认项目
-
default 项目可以被修改，但不能删除
2 核心工作模型
2.1 核心工作模型-Application
ArgoCD 的两个核心概念为 Application 和 App Project，它们可分别基于 Application CRD 和 AppProject CRD 创建
Application 从本质上来说，它包含如下两个部分
- 一组在 Kubernetes 上部署和运行某个应用的资源配置文件
- 这组资源相关的 source 和 destination
- source：定义从何处获取资源配置文件，包括 repoURL 和配置文件所在的目录，在 source 字段中我们需要指明下面两个字段
- repoURL：仓库 url ，如果是一个私有仓库还需要账户和密码，或者是 ssh 密钥，所以这种情况下我们就需要先将仓库事先定义出来，所谓事先定义也就是在 argo cd 之上允许我们先把仓库单独的配置出来，而后在我们的 application 上进行引用
- path：在定义的仓库中很有可能有多个子目录，而我们此次 application 部署的目标，只是某个子目录下面包含的配置文件，所以 path 字段就是用来指明该仓库下的那个子目录包含了我们的配置文件
- destination：定义这组资源配置文件中定义的对象应该创建并运行于何处，其中的 Cluster 可以是 ArgoCD 所在集群之外的其它集群
- cluster：所谓 cluster 其实就是对应的 K8S api-server 的接口访问地址
- namespace：指定需要部署的 ns
支持的配置管理工具：
- Helm、Kustomize、Jsonnet
当我们定义好了 application 并创建到我们的 K8S 集群之上，从而实现将应用程序将仓库中托出来并部署到环境之上以后，这个过程就叫做 sync
而仓库中所定义的状态和集群中定义的状态未必在每时每刻都是处于完全相同状态的，所以 argo cd 的 operator 会检测出这里的不同之处，那检测出不同之处该如何加以标识呢？所以在 ArgoCD Application 还存在两个非常重要的属性：Sync Status 和 Health Status
- Sync Status（同步状态）：Application 的实际状态与 Git Repo （git 仓库）中定义的期望状态是否一致；
- Synced：一致
- OutOfSync：不一致
- Health Status（健康状态）：Application 的健康状态，是各资源的健康状态的聚合信息。该状态表明已经将应用程序从仓库中同步并部署到了集群上去了，但是在我们的集群上很有可能没有健康运行。
- Healthy：健康
- Processing：处于尝试转为健康状态的进程中，也就是在 git repo 中修改了配置内容需要同步到集群上，或者是已经同步到集群中但是状态还是在拉启状态，并运行的过程中
- Degraded：降级
- Missing：缺失，即在 GitRepo 中存在资源定义，但并未完成部署
上图中所展现出来的 app 状态就是 healthy ，其次 synced 表示为一致状态，这就表示已经完成从创库中到集群的同步，同步结果为 syncok
2.2 核心工作模型-Project
project 核心作用就是能够将 Application 进行分组的逻辑组件
主要用于将租户或团队间的 Application 彼此隔离，并且支持在组内部署的 application 功能特性进行细粒度的权限管控
支持为内部 Application 上的 Source（只能在那个 rul 上拉取配置或那个仓库中进行拉取） 和 Destination（只能部署到对应的 K8S 集群上） 分别指定各自的黑白名单
所以可以通过 project 将大团队或大项目的不同类别将其分别开来，实现颗粒化管理
如上图：
可以看到集群都可以是在同一个 K8S 中，但是我们可以将同一个 K8S 上的不同 NS 分割到不同的组织或租户上使用，这就是 agro cd project 的使用