Woman with passion. Photographer from Poland.
背景
我目前所在的公司，很多业务都托管在阿里云平台上，同时也使用了 AWS 来支持一部分服务。在 Kubernetes 方面，我们几乎全部使用阿里云的托管服务——ACK Serverless 集群。为了保证系统的可监控性，最初我们选择了阿里云 Marketplace 上的 prometheus-operator 来监控集群。
然而，使用阿里云开箱即用的 Prometheus 方案时，我们遇到了一些奇怪的问题，虽然具体问题不一一展开，但总的来说，这些问题让我们非常头疼和烦恼。因此，在经过一段时间的思考后，我们决定放弃阿里云提供的监控方案，转而使用 kube-prometheus-stack 官方的 Helm chart。
解决方案
我们决定将 kube-prometheus-stack 作为新的监控方案。这个 Helm chart 包相对简单易用，我们只需要修改其中的 values 文件，便能将其配置成适合我们环境的监控方案。为了便于管理，我们将这个 chart 包放到了我们自己的 GitLab 仓库中。
需要部署时，我们只需从 GitLab 拉取最新的 chart 包，稍作修改（有时甚至不需要修改），然后通过 Helm 来进行部署。
问题与挑战
虽然这种方式在操作上简化了很多，但随之而来的是一个问题：当相关人员对 chart 包做出修改时，我们需要手动更新 Kubernetes 集群中的 Prometheus。
这种手动更新的方式显然不够高效，也有可能浪费我们宝贵的时间，甚至同事们也可能会因此产生困扰。因此，我们需要一种更自动化的解决方案来解决这个问题。
引入 GitOps
经过讨论，我们决定引入 ArgoCD 来解决这个问题。ArgoCD 作为一个声明式的 GitOps 工具，能帮助我们自动化地管理 Kubernetes 上的资源。 当 GitLab 中的 chart 包发生变动时，ArgoCD 会自动检测到并更新我们集群中的 Prometheus，而无需我们手动介入。
基础设施即代码
在理解 GitOps 之前，我们需要先理解什么是基础设施即代码。 基础设施即代码（Infrastructure as Code, IaC），顾名思义，表示使用代码（而非手动流程）来定义基础设施，研发人员可以像对待应用软件一样对待基础设施，例如：
• 可以创建包含基础架构规范的声明式配置文件，从而便于编辑和分发配置。 • 可以确保每次配置的环境都完全相同。 • 可以进行版本控制，所有的变更都会被记录下来，方便溯源。 • 可以将基础设施划分为若干个模块化组件，并通过自动化以不同的方式进行组合。 当然，广义上的 IaC 不仅仅只关于基础设施，还包含了网络、安全、配置等等，所以广义上的 IaC 又叫 X as Code。
比如你想在 AWS 中创建服务器，配置网络，部署 Kubernetes 集群以及各种工作负载，你只需要定义好 Terraform 或 Ansible 的声明式配置，以及 Kubernetes 的配置清单即可，免去一切繁杂的手动操作。
关于 IaC 和 GitOps 的区别，可以参考 The GitOps FAQ。
GitOps
GitOps 这个概念最早是由 Weaveworks 的 CEO Alexis Richardson 在 2017 年提出的，它是一种全新的基于 Git 仓库来管理 Kubernetes 集群和交付应用程序的方式。它包含以下四个基本原则：
1. 声明式（Declarative）：整个系统必须通过声明式的方式进行描述，比如 Kubernetes 就是声明式的，它通过 YAML 来描述系统的期望状态； 2. 版本控制和不可变（Versioned and immutable）：所有的声明式描述都存储在 Git 仓库中，通过 Git 我们可以对系统的状态进行版本控制，记录了整个系统的修改历史，可以方便地回滚； 3. 自动拉取（Pulled automatically）：Git 仓库中声明的期望状态发生了任何变更，都可以立即应用到系统中，而且不需要安装配置额外工具（比如 kubectl），也不需要配置 Kubernetes 的认证授权； 4. 持续调谐（Continuously reconciled）：Reconciliation 其实最早是 Kubernetes 里的一个概念，表示的是确保系统的实际状态与期望状态一致的过程。具体的实现方式是在目标环境中安装一个 agent，一旦实际状态与期望状态不匹配，agent 就会进行自动修复。这里的修复比 Kubernetes 的故障自愈更高级，即使是手动修改了集群的编排清单，集群也会被恢复到 Git 仓库中的清单所描述的状态。
GitOps = IaC + Git + CI/CD，即基于 IaC 的版本化 CI/CD。它的核心是使用 Git 仓库来管理基础设施和应用的配置，并且以 Git 仓库作为基础设施和应用的单一事实来源，你从其他地方修改配置（比如手动改线上配置）一概不予通过。
Git 仓库中的声明式配置描述了目标环境当前所需基础设施的期望状态，借助于 GitOps，如果集群的实际状态与 Git 仓库中定义的期望状态不匹配，Kubernetes reconcilers 会根据期望状态来调整当前的状态，最终使实际状态符合期望状态。
另一方面，现代应用的开发更多关注的是迭代速度和规模，拥有成熟 DevOps 文化的组织每天可以将代码部署到生成环境中数百次，DevOps 团队可以通过版本控制、代码审查以及自动测试和部署的 CI/CD 流水线等最佳实践来实现这一目标，这就是 GitOps 干的事情。
GitOps vs DevOps
从广义上来看，GitOps 与 DevOps 并不冲突，GitOps 是一种技术手段，而 DevOps 是一种文化。GitOps 是一种实现持续交付（Continuous Delivery）、持续部署（Continuous Deployment）和基础设施即代码（IaC）的工具和框架，它是支持 DevOps 文化的。
从狭义上来看，GitOps 与 DevOps 有以下几个区别：
首先
，GitOps 是以目标为导向的。它使用 Git 来维护期望状态，并不断调整实际状态，最终与期望状态相匹配。而 DevOps 更多关注的是最佳实践，这些实践可以普遍应用于企业的每一个流程。
其次
，GitOps 采取声明式的操作方法，而 DevOps 同时接受声明式和命令式的方法，所以 DevOps 除了适用于容器环境之外，还适用于虚拟机和裸机环境。
最后
，GitOps 重新定义了云原生场景下的 CI/CD，它以 Git 作为中心的不可变状态声明，以加快持续部署速度。
Push vs Pull
CD 流水线有两种模式：Push 和 Pull。
Push 模式
目前大多数 CI/CD 工具都使用基于 Push 的部署模式，例如 Jenkins、CircleCI 等。这种模式一般都会在 CI 流水线运行完成后执行一个命令（比如 kubectl）将应用部署到目标环境中。
这种 CD 模式的缺陷很明显：
• 需要安装配置额外工具（比如 kubectl）； • 需要 Kubernetes 对其进行授权； • 需要云平台授权； • 无法感知部署状态。也就无法感知期望状态与实际状态的偏差，需要借助额外的方案来保障一致性。
Kubernetes 集群或者云平台对 CI 系统的授权凭证在集群或云平台的信任域之外，不受集群或云平台的安全策略保护，因此 CI 系统很容易被当成非法攻击的载体。
Pull 模式
Pull 模式会在目标环境中安装一个 Agent，例如在 Kubernetes 集群中就靠 Operator 来充当这个 Agent。Operator 会周期性地监控目标环境的实际状态，并与 Git 仓库中的期望状态进行比较，如果实际状态不符合期望状态，Operator 就会更新基础设施的实际状态以匹配期望状态。
只有 Git 的变更可以作为期望状态的唯一来源，除此之外，任何人都不可以对集群进行任何更改，即使你修改了，也会被 Operator 还原为期望状态，这也就是传说中的不可变基础设施。
目前基于 Pull 模式的 CD 工具有 Argo CD， Flux CD 以及 ks-devops。
GitOps 的优势
一般 GitOps 首选的都是基于 Pull 的部署模式，因为这种模式有很多不可替代的优势。
更强大的安全保障
上面已经提到了，使用 GitOps 不需要任何 Kubernetes 或者云平台的凭证来执行部署，Kubernetes 集群内的 Argo CD 或者 Flux CD 只需要访问 Git 仓库，并通过 Pull 模式来更新即可。
另一方面，Git 由用于跟踪和管理代码变更的强大密码学支持，拥有对变更进行签名以证明作者身份和来源的能力，这是保障集群安全的关键。
Git 作为事实的唯一真实来源
因为所有的应用包括基础设施的声明式配置都保存在 Git 中，并把 Git 作为应用系统的唯一事实来源，因此可以利用 Git 的强大功能操作所有东西，例如版本控制、历史记录、审计和回滚等等，无需使用 kubectl 这样的工具来操作。
提高生产力
Git 也是开发人员非常熟悉的工具，通过 Git 不断迭代，可以提高生产率，加快开发和部署速度，更快地推出新产品，同时提高系统的稳定性和可靠性。
更容易合规的审计
使用 GitOps 的基础设施可以像任何软件项目一样使用 Git 来管理，所以同样可以对其进行质量审计。当有人需要对基础设施进行更改时，会创建一个 Pull Request，等相关人员对其进行 Code Review 之后，更改才可以应用到系统中。
Argo CD
基于 GitOps 理念，很快诞生出了一批 声明式的持续交付（Declarative Continuous Deployment） 工具，比如 Weaveworks 的 Flux CD 和 Intuit 的 Argo CD，虽然 Weaveworks 是 GitOps 概念的提出者，但是从社区的反应来看，似乎 Argo CD 要更胜一筹。
Argo 项目最初是由 Applatix 公司于 2017 年创建，2018 年这家公司被 Intuit 收购，Argo 项目就由 Intuit 继续维护和演进。Argo 目前包含了四个子项目：Argo Workflows、Argo Events、Argo CD 和 Argo Rollouts，主要用于运行和管理 Kubernetes 上的应用程序和任务，所有的 Argo 项目都是基于 Kubernetes 控制器和自定义资源实现的，它们组合在一起，提供了创建应用程序和任务的三种模式：服务模式、工作流模式和基于事件的模式。2020 年 4 月 7 日，Argo 项目加入 CNCF 开始孵化，并于 2022 年 12 月正式毕业，成为继 Kubernetes、Prometheus 和 Envoy 之后的又一个 CNCF 毕业项目。
Argo CD 遵循 GitOps 模式，使用 Git 仓库作为定义所需应用程序状态的真实来源，Argo CD 支持多种 Kubernetes 清单：
• kustomize • helm charts • ksonnet applications • jsonnet files • Plain directory of YAML/json manifests • Any custom config management tool configured as a config management plugin
Argo CD 可在指定的目标环境中自动部署所需的应用程序状态，应用程序部署可以在 Git 提交时跟踪对分支、标签的更新，或固定到清单的指定版本。
核心架构
先来看一下官方提供的这个架构图，注意默认情况下Argo CD部署时会配置多种组件和Kubernetes controllers。这些Kubernetes controllers更倾向于CRD而不是模块化的组件，因此在架构图中并没有将其表现出来，与此相似的还有一些如configmap、service、secret的配置。
官方的架构图中将整个Argo CD系统分为四个逻辑层级：UI、Application、Core和Infra。逻辑层还有助于使图表更易于理解，因为依赖关系以自上而下的关系表示。这意味着来自顶层的组件将被允许依赖于来自任何底层的任何组件。然而，来自底层的组件永远不会依赖于来自上层的任何组件。
• UI：这是表示层。用户主要通过这一层的组件与 Argo CD 进行交互（包括WebUI和CLI）。 • Application：支持来自 UI 层的组件所需的功能。 • Core：主要的 Argo CD gitops 功能由核心层的组件和 Kubernetes 控制器实现。 • Infra：表示 Argo CD 作为其基础设施的一部分所依赖的工具。
以下是各个组件的主要职责，我们在平时维护的时候可以根据这些信息来快速定位故障：
• Webapp：Argo CD 附带一个强大的 Web 界面，允许管理部署在给定 Kubernetes 集群中的应用程序； • CLI：Argo CD 提供了一个 CLI，用户可以使用它与 Argo CD API 进行交互。 CLI 还可用于自动化和脚本编写； • API Server：定义由 Argo CD 公开的专有 API，该 API 为 Web 应用程序和 CLI 功能提供支持； • Application Controller：应用程序控制器负责协调 Kubernetes 中的应用程序资源和项目资源，并将所需的应用程序状态（在 Git 中提供）与实时状态（在 Kubernetes 中）同步； • ApplicationSet Controller：ApplicationSet Controller 负责协调 ApplicationSet 资源，applicationset是argo创建的一个CRD； • Repo Server：Repo Server 在 Argo CD 架构中起着重要作用，因为它负责与 Git 存储库交互，为属于给定 application 的所有 Kubernetes 资源生成所需的状态； • Redis：Argo CD 使用 Redis 来提供缓存层，减少发送到K8S的API Server和Git服务器的请求。它还支持一些 UI 操作； • Kube API：Argo CD 控制器将连接到K8S的API Server以执行操作。因此如果需要管理多个集群时，在部署了argocd之外的集群是不需要部署任何argocd的客户端程序的，只需要创建一个ServiceAccount用于管理权限； • Git：作为 gitops 工具，Argo CD 要求在 Git 存储库中提供所需的 Kubernetes 资源状态。 我们在这里使用git来代表实际的 git 存储库、Helm 存储库或 OCI 工件存储库。 Argo CD 支持所有这些选项； • Dex：Argo CD 依赖于 Dex 来提供与外部 OIDC 提供商的身份验证。当然，可以使用其他工具代替 Dex；
工作流架构
从功能架构来看，Argo CD 主要有三个组件：API Server、Repository Server 和 Application Controller。从 GitOps 工作流的角度来看，总共分为 3 个阶段：检索、调谐和呈现。
检索 – Repository Server
检索阶段会克隆应用声明式配置清单所在的 Git 仓库，并将其缓存到本地存储。包含 Kubernetes 原生的配置清单、Helm Chart 以及 Kustomize 配置清单。履行这些职责的组件就是 Repository Server。
调谐 – Application Controller
调谐（Reconcile）阶段是最复杂的，这个阶段会将 Repository Server 获得的配置清单与反映集群当前状态的实时配置清单进行对比，一旦检测到应用处于 OutOfSync 状态，Application Controller 就会采取修正措施，使集群的实际状态与期望状态保持一致。
呈现 – API Server
最后一个阶段是呈现阶段，由 Argo CD 的 API Server 负责，它本质上是一个 gRPC/REST Server，提供了一个无状态的可视化界面，用于展示调谐阶段的结果。同时还提供了以下这些功能：
• 应用管理和状态报告； • 调用与应用相关的操作（例如同步、回滚、以及用户自定义的操作）； • Git 仓库与集群凭证管理（以 Kubernetes Secret 的形式存储）； • 为外部身份验证组件提供身份验证和授权委托； • RBAC 增强； • Git Webhook 事件的监听器/转发器。
核心概念
官方文档假定我们熟悉核心 Git、Docker、Kubernetes、持续交付（Continuous Delivery）和 GitOps 概念，对一些特定于 Argo CD 的概念进行了介绍，这里摘取了一些个人认为比较重要且基础的概念进行二次阐述。
• Application：Argocd中的核心概念之一，在K8S中以CRD的形式存在，用来表示一组由manifest定义的K8S资源集合。例如我们需要部署一个服务，该服务涉及的K8S资源可能包括若干个deployment、svc以及configmap等多种类型，在argocd中将其统一按照Application的概念进行划分，这些资源都归属于同一个Application下进行配置。 • Target state：期望该Application下的各种资源类型的运行状态，由对应Git仓库中的文件进行定义。 • Live state：目前该Application下的各种资源类型的运行状态。 • Sync status：实时状态是否与目标状态匹配，部署的应用程序是否与Git仓库中定义的状态一致。正常情况下应是Synced并且指向该Git的最新版本分支。 • Sync：将 Git 中的最新代码与实时状态进行对比并将变更同步到K8S集群中，将其可以视为主动触发同步git状态的操作。 • Sync operation status：同步是否成功。 • Refresh：将Git中的最新代码与实时状态进行对比。 • Health：应用程序的健康状况，如是否正常运行，能否接收并处理外部请求等。
环境准备
K8s 集群环境分为 Test, Pre, Prod。本次部署是在 Test 环境。
因为集群都托管在 AKS 上面，所有操作都在 Lens
里面，它里面有自带的 Terminal，还是非常方便的。另外，域名因为涉及到公司的东西，所以这里的 Ingress YAML 文件用的是自己的测试域名：
https://k8slens.dev/
部署
Argo CD 有两种不同的部署模式：
多租户
Argo CD 最常用的部署模式是多租户，一般如果组织内部包含多个应用研发团队，就会采用这种部署模式。用户可以使用可视化界面或者 argocd CLI 来访问 Argo CD。argocd CLI 必须先通过 argocd login "server-host" 来获取 Argo CD 的访问授权。
$ argocd login SERVER [flags]
## Login to Argo CD using a username and password
$ argocd login argocd.grpc.kubernetes.click
## Login to Argo CD using SSO
$ argocd login argocd.grpc.kubernetes.click --sso
## Configure direct access using Kubernetes API server
$ argocd login argocd.grpc.kubernetes.click --core
多租户模式提供了两种不同的配置清单：
非高可用
推荐用于测试和演示环境，不推荐在生产环境下使用。有两种部署清单可供选择：
• install.yaml - 标准的 Argo CD 部署清单，拥有集群管理员权限。可以使用 Argo CD 在其运行的集群内部署应用程序，也可以通过接入外部集群的凭证将应用部署到外部集群中。
https://github.com/argoproj/argo-cd/blob/master/manifests/install.yaml
• namespace-install.yaml - 这个部署清单只需要 namespace 级别的权限。如果你不需要在 Argo CD 运行的集群中部署应用，只需通过接入外部集群的凭证将应用部署到外部集群中，推荐使用此部署清单。还有一种花式玩法，你可以为每个团队分别部署单独的 Argo CD 实例，但是每个 Argo CD 实例都可以使用特殊的凭证（例如 argocd cluster add "CONTEXT" --in-cluster --namespace "YOUR NAMESPACE"）将应用部署到同一个集群中（即 kubernetes.svc.default，也就是内部集群）。
https://github.com/argoproj/argo-cd/blob/master/manifests/namespace-install.yaml
⚠️注意：namespace-install.yaml 配置清单中并不包含 Argo CD 的 CRD，需要自己提前单独部署： kubectl apply -k https://github.com/argoproj/argo-cd/manifests/crds\?ref\=stable
高可用
与非高可用部署清单包含的组件相同，但增强了高可用能力和弹性能力，推荐在生产环境中使用。
• ha/install.yaml - 与上文提到的 install.yaml 的内容相同，但配置了相关组件的多个副本。
https://github.com/argoproj/argo-cd/blob/master/manifests/ha/install.yaml
• ha/namespace-install.yaml - 与上文提到的 namespace-install.yaml 相同，但配置了相关组件的多个副本。
https://github.com/argoproj/argo-cd/blob/master/manifests/ha/namespace-install.yaml
Core
Core 模式也就是最精简的部署模式，不包含 API Server 和可视化界面，只部署了每个组件的轻量级（非高可用）版本。
用户需要 Kubernetes 访问权限来管理 Argo CD，因此必须使用下面的命令来配置 argocd CLI：
$ kubectl config set-context --current --namespace=argocd # change current kube context to argocd namespace
$ argocd login --core
也可以使用命令 argocd admin dashboard
手动启用可视化界面。
具体的配置清单位于 Git 仓库中的 https://github.com/argoproj/argo-cd/blob/master/manifests/core-install.yaml。
除了直接通过原生的配置清单进行部署，Argo CD 还支持额外的配置清单管理工具。
Kustomize
Argo CD 配置清单也可以使用 Kustomize 来部署，建议通过远程的 URL 来调用配置清单，使用 patch 来配置自定义选项。
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: argocd
resources:
- https://raw.githubusercontent.com/argoproj/argo-cd/v2.12.3/manifests/ha/install.yaml
Helm
Argo CD 的 Helm Chart 目前由社区维护，地址： https://github.com/argoproj/argo-helm/tree/master/charts/argo-cd。
接下来开始部署 Argo CD：
$ kubectl create namespace argocd
$ kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.12.3/manifests/install.yaml
由于本集群是 Test 环境，所以没有部署高可用。
如果你要用在生产环境，则可以使用下面的命令部署一个 HA 高可用的版本：
$ kubectl create namespace argocd
$ kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.12.3/manifests/ha/install.yaml
这将创建一个新的命名空间 argocd，Argo CD 的服务和应用资源都将部署到该命名空间。
$ kubectl get pods -n argocd
NAME READY STATUS RESTARTS AGE
argocd-application-controller-0 1/1 Running 0 103s
argocd-applicationset-controller-68b9bdbd8b-jzcpf 1/1 Running 0 103s
argocd-dex-server-6b7745757-6mxwk 1/1 Running 0 103s
argocd-notifications-controller-5b56f6f7bb-jqpng 1/1 Running 0 103s
argocd-redis-f4cdbff57-dr8jc 1/1 Running 0 103s
argocd-repo-server-c4f79b4d6-7nh6n 1/1 Running 0 103s
argocd-server-895675597-fr42g 1/1 Running 0 103s
如果你对 UI、SSO、多集群管理这些特性不感兴趣，只想把应用变更同步到集群中，那么可以直接安装核心组件即可： kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.12.3/manifests/core-install.yaml。
然后我们可以在本地（选择对应的版本）安装 CLI 工具方便操作 Argo CD：
$ curl -sSL -o usr/local/bin/argocd https://github.com/argoproj/argo-cd/releases/download/v2.12.3/argocd-linux-amd64
为 argocd CLI 赋予可执行权限：
$ chmod +x usr/local/bin/argocd
argocd cli的配置文件默认存储在~/.config/argocd/config目录下
现在我们就可以使用 argocd 命令了。如果你是 Mac，则可以直接使用 brew install argocd
进行安装。
Argo CD 会运行一个 gRPC 服务（由 CLI 使用）和 HTTP/HTTPS 服务（由 UI 使用），这两种协议都由 argocd-server 服务在以下端口进行暴露：
• 443 - gRPC/HTTPS • 80 - HTTP（重定向到 HTTPS）
我们可以通过配置 Ingress 的方式来对外暴露服务，其他 Ingress 控制器的配置可以参考官方文档 https://argo-cd.readthedocs.io/en/stable/operator-manual/ingress/ 进行配置。
Argo CD 在同一端口 (443) 上提供多个协议 (gRPC/HTTPS)，所以当我们为 argocd 服务定义单个 nginx ingress 对象和规则的时候有点麻烦，因为 nginx.ingress.kubernetes.io/backend-protocol 这个 annotation 只能接受一个后端协议（例如 HTTP、HTTPS、GRPC、GRPCS）。
为了使用单个 ingress 规则和主机名来暴露 Argo CD APIServer，必须要配置 nginx-ingress-controller 的 Deployment 添加nginx.ingress.kubernetes.io/ssl-passthrough
这个 annotation 来传递 TLS 连接并校验 Argo CD APIServer 上的 TLS。
Ingress 配置：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: argocd-server-ingress
namespace: argocd
annotations:
nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
nginx.ingress.kubernetes.io/ssl-passthrough: "true"
spec:
ingressClassName: nginx
rules:
- host: argocd.kubernetes.click #由于这里的域名涉及到公司的东西，所以先用我自己的
http:
paths:
- path:
pathType: Prefix
backend:
service:
name: argocd-server
port:
name: https
部署：
$ kubectl apply -f ing-https.yaml
上述规则在 Argo CD APIServer 上校验 TLS，该服务器检测到正在使用的协议，并做出适当的响应。请注意，nginx.ingress.kubernetes.io/ssl-passthrough 注解要求将 --enable-ssl-passthrough
标志添加到 nginx-ingress-controller 的命令行参数中。
由于 ingress-nginx 的每个 Ingress 对象仅支持一个协议，因此另一种方法是定义两个 Ingress 对象。一个用于 HTTP/HTTPS，另一个用于 gRPC。
如下所示为 HTTP/HTTPS 的 Ingress 对象：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: argocd-server-http-ingress
namespace: argocd
annotations:
nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
nginx.ingress.kubernetes.io/backend-protocol: "HTTP"
spec:
ingressClassName: nginx
rules:
- http:
paths:
- path:
pathType: Prefix
backend:
service:
name: argocd-server
port:
name: http
host: argocd.kubernetes.click
tls:
- hosts:
- argocd.kubernetes.click
secretName: argocd-secret # do not change, this is provided by Argo CD
部署：
$ kubectl apply -f ing-http.yaml
gRPC 协议对应的 Ingress 对象如下所示：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: argocd-server-grpc-ingress
namespace: argocd
annotations:
nginx.ingress.kubernetes.io/backend-protocol: "GRPC"
spec:
ingressClassName: nginx
rules:
- http:
paths:
- path:
pathType: Prefix
backend:
service:
name: argocd-server
port:
name: https
host: argocd.grpc.kubernetes.click
tls:
- hosts:
- grpc.argocd.k8s.local
secretName: argocd-secret # do not change, this is provided by Argo CD
部署：
$ kubectl apply -f ing-grpc.yaml
然后我们需要在禁用 TLS 的情况下运行 APIServer。编辑 argocd-server 这个 Deployment 以将 --insecure
标志添加到 argocd-server 命令，或者简单地在 argocd-cmd-params-cm ConfigMap 中设置 server.insecure: "true"
即可。
创建完成后，我们就可以通过 argocd.kubernetes.click 来访问 Argo CD 服务了，不过需要注意我们这里配置的证书是自签名的，所以在第一次访问的时候会提示不安全，强制跳转即可。
安全提示
默认情况下 admin 帐号的初始密码是自动生成的，会以明文的形式存储在 Argo CD 安装的命名空间中名为 argocd-initial-admin-secret 的 Secret 对象下的 password 字段下，我们可以用下面的命令来获取：
$ kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d && echo
使用用户名 admin 和上面输出的密码即可登录 Dashboard。
当然也可以通过CLI工具来快速获取初始密码:
$ argocd admin initial-password -nargocd
0kAwIdvMOa2yvHoO
This password must be only used for first time login. We strongly recommend you update the password using `argocd account update-password`.
默认的首页如下所示：
同样我们也可以通过 ArgoCD CLI 命令行工具进行登录：
$ argocd login argocd.grpc.kubernetes.click
WARNING: server certificate had error: tls: failed to verify certificate: x509: certificate signed by unknown authority. Proceed insecurely (y/n)? y
Username: admin
Password:
'admin:login' logged in successfully
Context 'argocd.grpc.kubernetes.click' updated
需要注意的是这里登录的地址为 gRPC 暴露的服务地址。
CLI 登录成功后，可以使用如下所示命令更改密码：
$ argocd account update-password
* Enter current password:
* Enter new password:
*** Confirm new password:
Password updated
Context 'argocd.kubernetes.click' updated
# 随后再次退出然后即可使用新密码进行重新登录
$ argocd outlog argocd.grpc.kubernetes.click
Logged out from 'argocd.grpc.kubernetes.click'
$ argocd version
argocd: v2.13.1+af54ef8
BuildDate: 2024-11-20T18:35:51Z
GitCommit: af54ef8db5adfa77a08d4d05b1318a2198084c22
GitTreeState: clean
GoVersion: go1.23.3
Compiler: gc
Platform: darwin/arm64
argocd-server: v2.12.3+6b9cd82
在正式开始使用 Argo CD 之前，需要先了解两个基本概念。
Argo CD Application
Argo CD 中的 Application 定义了 Kubernetes 资源的来源（Source）和目标（Destination）。来源指的是 Git 仓库中 Kubernetes 资源配置清单所在的位置，而目标是指资源在 Kubernetes 集群中的部署位置。
来源可以是原生的 Kubernetes 配置清单，也可以是 Helm Chart 或者 Kustomize 部署清单。
目标指定了 Kubernetes 集群中 API Server 的 URL 和相关的 namespace，这样 Argo CD 就知道将应用部署到哪个集群的哪个 namespace 中。 简而言之，Application 的职责就是将目标 Kubernetes 集群中的 namespace 与 Git 仓库中声明的期望状态连接起来。
Application 的配置清单示例：
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: gitops-demo
namespace: argocd
spec:
project: demo
syncPolicy:
automated:
prune: true
selfHeal: true
destination:
namespace: default
server: "https://kubernetes.default.svc"
source:
path: helm-guestbook # 从 Helm 存储库创建应用程序时，chart 必须指定 path
repoURL: "https://github.com/argoproj/argocd-example-apps"
targetRevision: HEAD
helm:
parameters:
- name: replicaCount
value: "2"
valueFiles:
- values.yaml
参数解释：
• syncPolicy : 指定自动同步策略和频率，不配置时需要手动触发同步。 • sourceRepos：项目中的应用程序可以从中获取清单的仓库引用。 • destinations：项目中的应用可以部署到的集群和命名空间。 • syncOptions : 定义同步方式。 • automated : 检测到实际状态与期望状态不一致时，采取的同步措施。 • selfHeal : 当集群世纪状态不符合期望状态时，自动同步。 • prune : 自动同步时，删除 Git 中不存在的资源。
如果有多个团队，每个团队都要维护大量的应用，就需要用到 Argo CD 的另一个概念：项目（Project）。
Argo CD Project
Argo CD 中的项目（Project）可以用来对 Application 进行分组，不同的团队使用不同的项目，这样就实现了多租户环境。项目还支持更细粒度的访问权限控制：
• 限制部署内容（受信任的 Git 仓库）； • 限制目标部署环境（目标集群和 namespace）； • 限制部署的资源类型（例如 RBAC、CRD、DaemonSets、NetworkPolicy 等）； • 定义项目角色，为 Application 提供 RBAC（例如 OIDC group 或者 JWT 令牌绑定）。
ApplicationSet 的配置清单示例：
# applicationset.yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: guestbook
spec:
goTemplate: true # 使用 go template 模板
goTemplateOptions: ["missingkey=error"] # 当模板中缺少键时，抛出错误
generators: # 生成器，用于生成参数
- list: # 列表生成器
elements: # 元素
- cluster: dev
url: https://1.2.3.4
- cluster: staging
url: https://9.8.7.6
- cluster: prod
url: https://kubernetes.default.svc
template:
metadata:
name: "{{.cluster}}-guestbook"
spec:
project: demo
source:
repoURL: https://github.com/argoproj/argocd-example-apps
targetRevision: HEAD
path: helm-guestbook
helm:
valueFiles:
- "{{.cluster}}.yaml"
syncPolicy:
syncOptions:
- CreateNamespace=true
destination:
server: "{{.url}}"
namespace: guestbook
在上面的资源对象中，我们定义了一个 ApplicationSet 资源对象，其中使用了模板和生成器：
• goTemplate: true：表示使用 go template 的模板 • goTemplateOptions: ["missingkey=error"]：当模板中缺少键时，抛出错误 • generators：生成器，用于生成参数，ApplicationSet 控制器当前支持多种生成器： • 包含 JSON 值的文件将被解析并转换为模板参数。 • Git 存储库中的各个目录路径也可以用作参数值。 • 列表生成器：根据集群名称/URL 值的固定列表生成参数，如上例所示。 • 集群生成器：集群生成器不是基于 clusters 的字面列表（与列表生成器一样），而是根据 Argo CD 中定义的集群自动生成集群参数。 • Git 生成器：Git 生成器根据生成器资源中定义的 Git 存储库中包含的文件或文件夹生成参数。 • 矩阵生成器：矩阵生成器结合了其他两个生成器生成的参数。 • template：模板，用于生成 Application 资源对象
这里我们通过列表生成器定义了多个生成器元素，里面包含 cluster 和 url 两个参数，ApplicationSet 控制器会根据这些参数生成多个 Application 资源对象，每个 Application 资源对象都会部署到对应的集群和命名空间中，每个 Application 资源就是通过这些参数将模板中的内容渲染生成。
无论使用哪个生成器，生成器生成的参数都会替换为 ApplicationSet 资源的 template: 部分中的 {{parameter name}} 值。我们这里列表生成器定义了 cluster 和 url 参数，然后将它们分别替换为模板的 {{cluster}} 和 {{url}} 值。
我们可以直接使用 argocd appset 命令来创建：
$ argocd appset create applicationset.yaml
ApplicationSet 'guestbook' created
Name: argocd/guestbook
Project: demo
Server: {{.url}}
Namespace: guestbook
Source:
- Repo: https://gitee.com/cnych/argocd-example-apps
Target: HEAD
Path: helm-guestbook
Helm Values: {{.cluster}}.yaml
SyncPolicy: <none>
$ argocd appset list
NAME PROJECT SYNCPOLICY CONDITIONS REPO PATH TARGET
argocd/guestbook demo nil [{ParametersGenerated Successfully generated parameters for all Applications 2024-12-19 15:44:47 +0800 CST True ParametersGenerated} {ResourcesUpToDate ApplicationSet up to date 2024-12-19 15:44:47 +0800 CST True ApplicationSetUpToDate}] https://gitee.com/cnych/argocd-example-apps helm-guestbook HEAD
可以看到现在渲染了 3 个 Application 资源对象，和我们前面在 ApplicationSet 资源对象中定义的集群和 URL 是一一对应的，当然我们也可以在 Dashboard 界面中查看：
app list status
更多关于生成器的详细信息可以前往 https://argo-cd.readthedocs.io/en/latest/operator-manual/applicationset/Generators/ 查看。
配置集群
由于 Argo CD 支持部署应用到多集群，所以如果你要将应用部署到外部集群的时候，需要先将外部集群的认证信息注册到 Argo CD 中，如果是在内部部署（运行 Argo CD 的同一个集群，默认不需要配置），直接使用 https://kubernetes.default.svc 作为应用的 K8S APIServer 地址即可。
argocd 原生是支持同时管理多个集群的，同时因为 argocd 是部署在K8S集群中，所以 argocd 本身所处的集群默认是存在配置中的。我们可以通过 CLI 或者 webUI 来查看默认的集群，需要注意的是如果还没有在集群中部署应用的话，argocd 是不会主动去探测集群的状态的。
首先列出当前 kubeconfig 中的所有集群上下文：
$ kubectl config get-contexts -o name
213039632249357055-c9639b0d78a2347f1842e1860db74175d
添加新集群只能通过 CLI 来进行操作，webUI 可以对集群进行重命名和删除等操作。
从列表中选择一个上下文名称并将其提供给 argocd cluster add CONTEXTNAME
，比如对于上下文，运行：
$ argocd cluster add 213039632249357055-c9639b0d78a2347f1842e1860db74175d
$ argocd cluster list
SERVER NAME VERSION STATUS MESSAGE PROJECT
https://kubernetes.default.svc test-id 1.28+ Successful
将集群添加到argocd之后会在集群中添加一个名为 argocd-manage r的 ServiceAccount。
配置 Git 仓库
ArgoCD 中的 Git 仓库和 Repo 是一对多的关系，也就是说一个 Git 仓库可以用于创建多个 APP ，所以这里我们需要先配置 Git 仓库。
特别注意，Project在创建成功之后是无法修改的。如果想要使用 Project 对多个项目进行管理，建议先创建Project ，再配置 Git 仓库，最后配置 APPS
如果有比较大量的 Git 仓库存储需求，建议考虑自行搭建一个 Gitlab 服务器，当然使用公共的 Gitlab、 Github 和Helm仓库等都是可以的。
ArgoCD 支持多种拉取仓库的方式，下面我们主要介绍 HTTPS 这两种较为常见的方式。
HTTPS 方式连接一般比较简单，常用于拉取一些公共 Git 仓库。如下面示范的拉取 ArgoCD 官方的 Git 仓库作为示例：
创建成功后我们可以在 UI 中看到该仓库的状态为 Successful。
在 CLI 中也能看到详细的状态信息
也可以用 CLI 添加：
$ argocd repo add https://github.com/argoproj/argocd-example-apps --username ******* --password *******
查看添加是否成功:
$ argocd repo list
TYPE NAME REPO INSECURE OCI LFS CREDS STATUS MESSAGE PROJECT
git https://github.com/argoproj/argocd-example-apps false false false false Successful demo
创建应用
方式有三种：
• CLI • CRD • UI
Git 仓库 https://github.com/argoproj/argocd-example-apps.git 是一个包含留言簿应用程序的示例库，我们可以用该应用来演示 Argo CD 的工作原理，这里也可以替换成你们公司自己的私有仓库地址。
通过 CLI 创建应用
我们可以通过 argocd app create xxx
命令来创建一个应用：
$ argocd app create --help
Create an application
Usage:
argocd app create APPNAME [flags]
Examples:
# Create a directory app
argocd app create guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path guestbook --dest-namespace default --dest-server https://kubernetes.default.svc --directory-recurse
# Create a Jsonnet app
argocd app create jsonnet-guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path jsonnet-guestbook --dest-namespace default --dest-server https://kubernetes.default.svc --jsonnet-ext-str replicas=2
# Create a Helm app
argocd app create helm-guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path helm-guestbook --dest-namespace default --dest-server https://kubernetes.default.svc --helm-set replicaCount=2
# Create a Helm app from a Helm repo
argocd app create nginx-ingress --repo https://charts.helm.sh/stable --helm-chart nginx-ingress --revision 1.24.3 --dest-namespace default --dest-server https://kubernetes.default.svc
# Create a Kustomize app
argocd app create kustomize-guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path kustomize-guestbook --dest-namespace default --dest-server https://kubernetes.default.svc --kustomize-image gcr.io/heptio-images/ks-guestbook-demo:0.1
# Create a app using a custom tool:
argocd app create kasane --repo https://github.com/argoproj/argocd-example-apps.git --path plugins/kasane --dest-namespace default --dest-server https://kubernetes.default.svc --config-management-plugin kasane
Flags:
......
直接执行如下所示命令即可：
$ argocd app create guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path guestbook --dest-server https://kubernetes.default.svc --dest-namespace default
application 'guestbook' created
通过 UI 创建应用
定位到 argocd.kubernetes.click 页面，登录后，点击 +New App 新建应用按钮。将应用命名为 guestbook，使用 default project，并将同步策略设置为 Manual：
• 先来看基础配置Application Name和Project Name都是对应argocd中的参数，也是对应我们前面部署的两个crd • SYNC POLICY可以选择自动同步还是手动同步 • PRUNE RESOURCES可以选择是否删除在 git 中移除的资源，如某个 git 版本中创建了一个 svc，随后又删除了，如果不勾选该选项，则 argocd 不会自动删除该 svc • SELF HEAL可以理解为自愈，即检测到定义的资源状态和git中不一致的时候，是否自动同步为一致；如 git 中定义副本数为 10，随后手动扩容至 20 但并未修改git中的配置文件，勾选这一项则会触发 argocd 自动将副本数缩减回10 • SKIP SCHEMA VALIDATION跳过语法检查，个人不建议开启 • AUTO-CREATE NAMESPACE可以设置如果对应的 namespace 不存在的话是否自动创建 • APPLY OUT OF SYNC ONLY类似于增量部署而不是全量部署，仅部署和 git 版本中不一样的资源，而不是全部重新部署一次，可以降低 K8S 集群的压力 • REPLACE会将部署的命令从默认的kubectl apply变更为kubectl replace/create，可以解决部分资源修改之后无法直接 apply 部署的问题，同时也有可能会导致资源的重复创建 • RETRY可以设定部署失败后重试的次数和频率 • PRUNE PROPAGATION POLICY：
创建：
SOURCE
这里主要用于指定 git 仓库、对应的分支及具体的子目录
DESTINATION
这里用来指定部署的 K8S 集群和 namespace。
HELM
为默认的，你这里也可以选择其他的
拉到最上面，你也可以以 YAML
文件的方式创建：
填写完以上信息后，点击页面上方的 Create 安装，即可创建 guestbook 应用，创建完成后可以看到当前应用的处于 OutOfSync 状态：
Argo CD 默认情况下每 3 分钟会检测 Git 仓库一次，用于判断应用实际状态是否和 Git 中声明的期望状态一致，如果不一致，状态就转换为 OutOfSync。默认情况下并不会触发更新，除非通过 syncPolicy 配置了自动同步。
通过 CRD 创建
除了可以通过 CLI 和 Dashboard 可以创建 Application 之外，其实也可以直接通过声明一个 Application 的资源对象来创建一个应用，如下所示：
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook
spec:
destination:
namespace: default
server: "https://kubernetes.default.svc"
source:
path: guestbook
repoURL: "https://github.com/argoproj/argocd-example-apps"
targetRevision: HEAD
project: default
syncPolicy:
automated: null
应用：
kubectl apply -f app.yaml
部署应用
由于上面我们在创建应用的时候使用的同步策略为 Manual，所以应用创建完成后没有自动部署，需要我们手动去部署应用。同样可以通过 CLI
和 UI 界面
两种同步方式。
应用创建完成后，我们可以通过如下所示命令查看其状态：
$ argocd app get argocd/guestbook
Name: argocd/guestbook
Project: demo
Server: https://kubernetes.default.svc
Namespace: demo
URL: https://argocd.grpc.kubernetes.click/applications/guestbook
Source:
- Repo: https://github.com/argoproj/argocd-example-apps
Target: HEAD
Path: helm-guestbook
SyncWindow: Sync Allowed
Sync Policy: Manual
Sync Status: OutOfSync from HEAD (d7927a2)
Health Status: Missing
GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE
Service demo guestbook-helm-guestbook OutOfSync Missing
apps Deployment demo guestbook-helm-guestbook OutOfSync Missing
应用程序状态为初始 OutOfSync 状态，因为应用程序尚未部署，并且尚未创建任何 Kubernetes 资源。要同步（部署）应用程序，可以执行如下所示命令：
$ argocd app sync argocd/guestbook
Name: argocd/guestbook
Project: demo
Server: https://kubernetes.default.svc
Namespace: demo
URL: https://argocd.grpc.kubernetes.click/applications/guestbook
Source:
- Repo: https://github.com/argoproj/argocd-example-apps
Target: HEAD
Path: helm-guestbook
SyncWindow: Sync Allowed
Sync Policy: Manual
Sync Status: OutOfSync from HEAD (d7927a2)
Health Status: Missing
GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE
Service demo guestbook-helm-guestbook OutOfSync Missing
apps Deployment demo guestbook-helm-guestbook OutOfSync Missing
# 同步
$ argocd app sync argocd/guestbook
TIMESTAMP GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE
2024-12-18T17:59:58+08:00 Service demo guestbook-helm-guestbook OutOfSync Missing
2024-12-18T17:59:58+08:00 apps Deployment demo guestbook-helm-guestbook OutOfSync Missing
2024-12-18T17:59:59+08:00 Namespace demo Running Synced namespace/demo created
2024-12-18T17:59:59+08:00 Service demo guestbook-helm-guestbook Synced Healthy
2024-12-18T17:59:59+08:00 Service demo guestbook-helm-guestbook Synced Healthy service/guestbook-helm-guestbook created
2024-12-18T17:59:59+08:00 apps Deployment demo guestbook-helm-guestbook OutOfSync Missing deployment.apps/guestbook-helm-guestbook created
2024-12-18T17:59:59+08:00 apps Deployment demo guestbook-helm-guestbook Synced Progressing deployment.apps/guestbook-helm-guestbook created
Name: argocd/guestbook
Project: demo
Server: https://kubernetes.default.svc
Namespace: demo
URL: https://argocd.grpc.kubernetes.click/applications/argocd/guestbook
Source:
- Repo: https://github.com/argoproj/argocd-example-apps
Target: HEAD
Path: helm-guestbook
SyncWindow: Sync Allowed
Sync Policy: Manual
Sync Status: Synced to HEAD (d7927a2)
Health Status: Progressing
Operation: Sync
Sync Revision: d7927a27b4533926b7d86b5f249cd9ebe7625e90
Phase: Succeeded
Start: 2024-12-18 17:59:57 +0800 CST
Finished: 2024-12-18 17:59:59 +0800 CST
Duration: 2s
Message: successfully synced (all tasks run)
GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE
Namespace demo Running Synced namespace/demo created
Service demo guestbook-helm-guestbook Synced Healthy service/guestbook-helm-guestbook created
apps Deployment demo guestbook-helm-guestbook Synced Progressing deployment.apps/guestbook-helm-guestbook created
此命令从 Git 仓库中检索资源清单并执行 kubectl apply 部署应用，执行上面命令后 guestbook 应用便会运行在集群中了，现在我们就可以查看其资源组件、日志、事件和评估其健康状态了。
通过 UI 同步
直接添加 UI 界面上应用的 Sync 按钮即可开始同步：
sync 操作
同步完成后可以看到我们的资源状态，甚至还可以直接查看应用的日志信息：
Sync 完成
也可以通过 kubectl 查看到我们部署的资源：
$ kubectl get all -n demo
NAME READY STATUS RESTARTS AGE
pod/guestbook-helm-guestbook-6fd56f9f49-bw5hh 1/1 Running 0 6m36s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/guestbook-helm-guestbook ClusterIP 172.16.197.226 <none> 80/TCP 6m37s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/guestbook-helm-guestbook 1/1 1 1 6m37s
NAME DESIRED CURRENT READY AGE
replicaset.apps/guestbook-helm-guestbook-6fd56f9f49 1 1 1 6m37s
和我们从 Git 仓库中同步 guestbook 目录下面的资源状态也是同步的，证明同步成功了。
Helm 项目
如果有多个团队，每个团队都要维护大量的应用，就需要用到 Argo CD 的另一个概念：项目（Project）。Argo CD 中的项目（Project）可以用来对 Application 进行分组，不同的团队使用不同的项目，这样就实现了多租户环境。项目还支持更细粒度的访问权限控制：
• 限制部署内容（受信任的 Git 仓库）； • 限制目标部署环境（目标集群和 namespace）； • 限制部署的资源类型（例如 RBAC、CRD、DaemonSets、NetworkPolicy 等）； • 定义项目角色，为 Application 提供 RBAC（例如 OIDC group 或者 JWT 令牌绑定）。
比如我们这里创建一个名为 demo 的项目，将该应用创建到该项目下，只需创建一个如下所示的 AppProject 对象即可：
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
# 项目名
name: demo
namespace: argocd
spec:
# 目标
destinations:
# 此项目的服务允许部署的 namespace，这里为全部
- namespace: "*"
# 此项目允许部署的集群，这里为默认集群，即为Argo CD部署的当前集群
server: https://kubernetes.default.svc
# 允许的数据源
sourceRepos:
- https://gitee.com/cnych/argocd-example-apps
该对象中有几个核心的属性：
• sourceRepos：项目中的应用程序可以从中获取清单的仓库引用 • destinations：项目中的应用可以部署到的集群和命名空间 • roles：项目内资源访问定义的角色
直接创建该对象即可：
$ kubectl get appproject -n argocd
NAME AGE
default 47h
demo 6s
更多配置信息可以前往文档 https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/ 查看，项目创建完成后，在该项目下创建一个 Application，代表环境中部署的应用程序实例。
更多配置信息可以前往文档 https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/ 查看，项目创建完成后，在该项目下创建一个 Application，代表环境中部署的应用程序实例。
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: gitops-demo
namespace: argocd
spec:
destination:
namespace: default
server: "https://kubernetes.default.svc"
project: demo
syncPolicy:
automated:
prune: true
selfHeal: true
source:
path: helm-guestbook # 从 Helm 存储库创建应用程序时，chart 必须指定 path
repoURL: "https://github.com/argoproj/argocd-example-apps"
targetRevision: HEAD
helm:
parameters:
- name: replicaCount
value: "2"
valueFiles:
- values.yaml
这里我们定义了一个名为 gitop-demo 的应用，应用源来自于 helm 路径，使用的是 values.yaml 文件，此外还可以通过 source.helm.parameters
来配置参数。
同步策略可以选择使用自动的方式，该策略下面还有两个属性可以配置：
• PRUNE RESOURCES：开启后 Git Repo 中删除资源会自动在环境中删除对应的资源。
删除资源
• SELF HEAL：自动痊愈，强制以 Git Repo 状态为准，手动在环境中修改不会生效。
自动痊愈
部署：
$ kubectl apply -f test-app.yaml
正常创建后这个应用就会自动部署了，根据我们配置会生成两个副本。
app status由于 Argo CD 默认并不是实时去监测 Config Repo 的变化的，如果要更快的检测到变化我们可以使用 Git Webhook 的方式。
默认情况下 Argo CD 每三分钟轮询一次 Git 存储库，以检测清单的更改。为了消除轮询延迟，可以将 API 服务器配置为接收 Webhook 事件。
Argo CD 支持来自 GitHub、GitLab、Bitbucket、Bitbucket Server 和 Gogs 的 Git webhook 通知。
然后在 argocd-secret 这个 Kubernetes Secret 中，使用上面配置的 Git 提供商的 Webhook 密钥配置以下密钥之一。
gitlab token$ kubectl edit secret argocd-secret -n argocd
apiVersion: v1
kind: Secret
metadata:
name: argocd-secret
namespace: argocd
type: Opaque
data:
...
stringData:
# github webhook secret
webhook.github.secret: shhhh! it's a GitHub secret
# gitlab webhook secret
webhook.gitlab.secret: shhhh! it's a GitLab secret
# bitbucket webhook secret
webhook.bitbucket.uuid: your-bitbucket-uuid
# bitbucket server webhook secret
webhook.bitbucketserver.secret: shhhh! it's a Bitbucket server secret
# gogs server webhook secret
webhook.gogs.secret: shhhh! it's a gogs server secret
可以直接使用 stringData 来配置 secret，这样就不用去手动编码了。 因为 GitOps 的核心是 Git，所以我们一定要将部署到集群中的资源清单文件全都托管到 Git 仓库中，这样才能实现 GitOps 的自动同步部署。上面我们是在 CI 流水线中去修改 Git 仓库中的资源清单文件，其实我们也可以通过其他方式去修改，比如 Argo CD 也提供了一个新的工具 Argo CD Image Updater
。
