Argo CD 实践教程 04

2.4 解释体系结构

在本节中，我们将深入描述Argo CD的架构，并将深入研究Argo CD的核心组件。最后，我们将在本地Kubernetes集群中运行Argo CD，并运行一些示例，以获得更好的实践经验。

2.4.1 建筑概述

Argo CD核心组件已经作为库伯内特控制器实现，所以在单独研究每个组件之前，我们需要了解Kubernetes控制器是如何工作的。 在实践中，Kubernetes控制器会观察集群的状态，然后在需要时应用或请求更改。因此，在实践中，控制器将尝试保持当前集群状态与所需状态相似。控制器观察一个Kubernetes资源对象——至少一个对象，它有一个表示所期望状态的规范字段。

2.4.2 Argo CD的核心组件

Argo CD是一组各种组件和工具。是时候详细探索和了解形成Argo CD大脑的每个核心组成部分的责任了：

• **API服务器：**与Kubernetes类似，Argo CD有一个API服务器，它可以公开其他系统可以与之交互的API，如Web UI、CLI、Argo事件和CI/CD系统。API服务器负责以下工作：
• 管理应用程序并报告它们的状态
• 触发应用程序的一组操作
• Git存储库和Kubernetes 集群的管理
• 身份验证和SSO
• RBAC策略实施
• **存储库服务器：**存储库服务器的主要职责是维护保存应用程序清单的Git存储库的本地缓存。其他Argo服务根据以下输入向存储库服务器发出请求，以获取Kubernetes清单：
• 存储库的URL
• Git修订版
• 应用程序路径
• 模板特定的设置：参数、ksonnet环境和heml yaml
• **应用程序控制器：**应用程序控制器连续地观察应用程序的活动状态，并与Git存储库中的期望状态进行比较。每当出现漂移和状态不同步时，控制器将尝试修复它，并将当前状态与所需的状态相匹配。它的最后一个职责之一是为应用程序的生命周期事件执行任何用户定义的钩子。 该架构的详细概述如下图所示：

微信图片_20230529223254.png

图2.2-Argo CD的架构 在图2.2中可以看到，Argo工具和外部工具直接与Argo CD的API服务器交互。如前所述，Argo CD轮询存储库以获取所需的状态，并且在默认情况下，它每3分钟轮询一次Git存储库。如果我们想避免这种延迟，还有一些其他的选项可以立即触发同步阶段。 Argo CD附带一个UI，我们可以手动启动同步阶段，我们将在本章的后面进行探讨。 Argo CD有一个与API服务器交互的CLI，如上所示。对于一个真实的例子，假设我们可以使用来自CI/CD或我们的本地机器的CLI来同步一个应用程序与以下命令： argocd app sync myapp ** **最后一个选项是设置Webhook配置，正如我们在图中看到的那样，它会立即启动同步阶段。Argo CD支持来自GitHub、GitLab、比特桶、比特桶服务器和Gogs的Git网络钩子通知。

2.4.3 Argo CD的核心对象或资源

Argo CD可以使用Kubernetes清单声明式地定义应用程序、项目、存储库和集群凭据和设置。这些被定义为crd。让我们来深入研究一下Argo CD的核心对象/资源：

• 应用程序： Argo CD实现了一个名为应用程序的CRD，它在实际上代表了我们希望部署在Kubernetes集群（环境）中的应用程序的实例。其示例如下：

 apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
 name: guestbook
 namespace: argocd
spec:
 project: default
 source:
 repoURL: https://github.com/argoproj/argocd-exampleapps.git
 targetRevision: HEAD
 path: guestbook
 destination:
server: https://kubernetes.default.svc
 namespace: guestbook

• 应用项目：就像一个应用程序一样，有一个叫做应用项目的CRD。这使我们能够对相关的应用程序进行分组，例如通过对它们进行标记。一个真正的例子是应用程序和实用程序服务之间的分离。其示例如下：

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
 name: applications
 namespace: argocd
 finalizers:
 - resources-finalizer.argocd.argoproj.io
spec:
 description: Example Project
 # Allow manifests to deploy from any Git repos
 sourceRepos:
 - '*'
 # Only permit applications to deploy to the guestbook 
namespace in the same cluster
 destinations:
 - namespace: guestbook
 server: https://kubernetes.default.svc
 # Deny all cluster-scoped resources from being created, 
except for Namespace
 clusterResourceWhitelist:
 - group: ''
 kind: Namespace

• 存储库凭据：在现实生活中，我们需要使用私有存储库，为了让Argo CD具备访问它们的能力，我们需要提供某种访问凭据。Argo CD在实践中使用了Kubernetes的秘密和配置图。因此，我们需要创建必要的秘密Kubernetes资源与一个特殊的Kubernetes标签，rgocd.argoproj.io/secret-type：存储库。一个秘密的例子可以找到如下：

apiVersion: v1
kind: Secret
metadata:
name: private-repo
 namespace: argocd
 labels:
 argocd.argoproj.io/secret-type: repository
stringData:
 url: Error! Hyperlink reference not valid.
 sshPrivateKey: |
 -----BEGIN OPENSSH PRIVATE KEY-----
 ...
 -----END OPENSSH PRIVATE KEY-----

• 集群凭据：与存储库凭据一样，如果Argo CD管理多个集群，并且它不包含在Argo CD已经运行的集群中，那么我们需要访问另一个Kubernetes集群。这里的区别是库伯内特斯的标签，因为它是一种不同的秘密类型。argocd.argoproj.io/secret-type：集群。另一个秘密的例子如下：

apiVersion: v1
kind: Secret
metadata:
 name: mycluster-secret
 labels:
 argocd.argoproj.io/secret-type: cluster
type: Opaque
stringData:
 name: mycluster.com
 server: https://mycluster.com
 config: |
 {
 "bearerToken": "<authentication token>",
 "tlsClientConfig": {
 "insecure": false,
 "caData": "<base64 encoded certificate>"
 }
 }

现在我们已经熟悉了Argo CD所需的重要核心对象和资源，现在是时候在本地运行Argo CD，并在实践中看看它是如何工作的了。

2.4.4 使用Helm本地运行Argo CD

首先，我们将使用Kind (https://kind.sigs.kubernetes.io/)，以在本地创建一个新的集群。创建一个类型的.yaml文件，并在配置中使用它来创建集群：

kind: Cluster
apiVersion: kind.x-Kubernetes.io/v1alpha4
nodes:
- role: control-plane
 kubeadmConfigPatches:
 - |
 kind: InitConfiguration
 nodeRegistration:
 kubeletExtraArgs:
 node-labels: "ingress-ready=true"
 extraPortMappings:
 - containerPort: 80
 hostPort: 80
 protocol: TCP
 - containerPort: 443
 hostPort: 443
 protocol: TCP

使用以下YAML和节点标签配置，我们将只允许入口控制器在与标签选择器匹配的特定节点上运行。 为了创建集群，我们需要运行以下命令，并等待，直到创建成功完成：

 $ kind create cluster --config=kind.yaml --name=ch02  

** **该命令的输出应如下所示：

image.png

图2.3-Kind集群状态 在创建完成后，我们需要使用以下命令来设置这个新集群的上下文：

 $ kubectl config set-context kind-ch02  

我们已经准备好使用模板工具Helm安装Argo CD，图表可以在这里找到：https://github.com/argoproj/argo-helm/tree/master/charts/argo-cd 首先，我们需要将Argo CD的Helm存储库添加到我们的本地机器上，这样我们就可以使用以下命令来部署特定的图表：

 $ helm repo add argo https://argoproj.github.io/argo-helm  

然后，让我们使用以下命令在Argo CD名称空间下安装ArgoCD：

$ kubectl create namespace argocd
 $ helm install ch02 --namespace argocd argo/argo-cd

** **由于我们没有安装任何入口控制器，我们可以访问Argo CD UI，或者如果我们使用端口转发部署的相关端口，我们可以通过CLI与API交互：

 $ kubectl port-forward service/ch02-argocd-server -n argocd 8080:443  

现在UI可以访问了，让我们获得 argocd-initial-admin-secret 的密码，它是在Argo CD部署后自动创建的：

 $ kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d  

2.4.5 运行第一个Argo CD应用程序

现在，是时候使用Argo CLI在Argo CD中运行第一个应用程序了。首先，我们需要创建必要的CRD来描述Argo CD的应用程序，并将其安装在NGINX集群中：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
 name: nginx
 namespace: argocd
 finalizers:
 - resources-finalizer.argocd.argoproj.io
spec:
 syncPolicy:
 automated:
 prune: true
 selfHeal: true
 syncOptions:
 - CreateNamespace=true
 destination:
 namespace: nginx
 server: https://kubernetes.default.svc
 project: default
 source:
 chart: nginx
 repoURL: https://charts.bitnami.com/bitnami
 targetRevision: 13.2.10

如果我们仔细检查一下CRD，我们会发现我们正在使用Helm，这是Argo CD安装应用程序的众多方法之一。更具体地说，这是应用程序CRD清单中的特殊部分，表明Argo CD需要使用Helm：

source:
 chart: nginx
 repoURL: https://charts.bitnami.com/bitnami
 targetRevision: 13.2.10

下一步是使用kubectl应用命令来应用该清单：

 $ kubectl apply -f argo-app/

** **在UI中，点击SYNC按钮，如果一切运行成功，我们将看到一个绿色状态和相关的Kubernetes资源部署，如复制集（RS），在UI中：

image.png

图2.4-应用已同步 另一种不需要CRD就可以创建和同步新应用程序的方法是使用Argo CLI，但是当我们想要快速测试某些内容时，应该使用这种方法。 重要说明 ** **GitOps的目的是跟踪Git存储库中的所有内容，这是获取期望状态时的真实来源。如果我们只是使用CLI创建Argo CD应用程序，那么我们就跳过这个重要步骤，且我们违反了GitOps原则。 首先，我们需要登录到Argo CD服务器。对于本示例，只需使用前面的管理/管理步骤中的凭据：

 $ argocd login localhost:8080  

重要说明 你将从Argo CD得到一个警告，默认情况下，它不使用已知权威机构的签名证书。为了实验，你可以直接输入y，不安全继续地进行： 警告：服务器证书有错误： x509：由未知权限签名的证书。不安全地进行（y/n）?y 然后键入登录的用户名和密码，命令输出如下：

'admin:login' logged in successfully
 Context 'localhost:8080' updated

登录成功后，你就可以与Argo CD API服务器进行交互了。现在，让我们仅使用CLI创建相同的NGINX Argo CD应用程序：

$ argocd app create nginx --repo https://charts.bitnami.com/
bitnami \
 --helm-chart nginx --revision 13.2.10 \
 --dest-server https://kubernetes.default.svc \
 --dest-namespace nginx

** **虽然与以前相同，但应用程序不同步，我们需要显式地触发此操作。现在，我们不会使用UI，而是使用一个现实生活中的例子，Argo CLI。我们需要运行以下命令：

$ argocd app sync nginx

** **此命令将启动Argo CD NGINX应用程序的同步阶段，我们已经在声明性配置中设置了该阶段，如图2.4所示。 重要说明 ** **为了便于本示例，我们使用了管理用户。管理用户应该只用于初始配置，然后切换到本地用户或配置SSO集成（https://argo-cd.readthedocs.io/en/stable/operator-manual/user-management/)。更多的细节将在第3章，访问控制中描述。对于CI系统实现，我们需要为负责该CI的特定用户使用令牌。一个例子如下： $ argocd account generate-token --account ci-bot 。 你做到了，这是你第一次使用Helm在本地安装Argo CD，也是第一次实际部署Argo CD。但是Argo CD是一组工具，而Argo CD团队正在尝试简化和自动化我们在本节中所做的大部分手动步骤。现在，让我们看看如何使用Argo CD自动驾驶仪来简化本节中描述的所有步骤。

2.4.6 在本地使用Argo CD驾驶仪运行Argo CD

如果这是你第一次使用GitOps和Argo CD，那么你可能会对如何跨不同环境构建Git存储库和管理应用程序产生一些怀疑。Argo CD团队创建了一个名为Argo CD自动驾驶仪的工具，可以帮助你登录GitOps和Argo CD。创建了Argo CD自动驾驶仪来帮助操作员完成以下操作：

• 使用GitOps创建和管理引导Argo CD应用程序。
• 在GitHub存储库中设置一个正式的结构，以添加新的服务，并完成Argo CD的生命周期
• 在不同的可用环境中更新和推广应用程序
• 能够规划灾难恢复和使用所有必要的实用程序和应用程序来引导故障转移集群
• 很快，支持加密的秘密将在Argo CD应用程序中使用 我知道你对第一颗子弹感到惊讶；这就像Argo CD管理的开端。但答案是，为什么不呢？Argo CD是通过清单或帮助在集群中的另一个部署，因此你可以使用GitOps原则相应地更改其配置。 事实上，Argo CD自动驾驶仪做了一些神奇的事情。自动驾驶仪引导程序将在一个特定目录下的Git存储库中推送一个Argo CD应用程序清单。这将实际上管理Argo CD的安装，并且你将能够通过GitOps实践来管理它。 Argo CD自动驾驶仪架构 ** **再一次，我是一个视觉人，如果我们检查Argo CD自动驾驶架构，我们可以更好地理解：

image.png

图2.5-Argo CD自动驾驶仪架构 在启动阶段，当我们部署Argo CD时，自动驾驶仪与Kubernetes 集群通信，在此之后，就不需要再访问它了。从现在开始，唯一需要访问的是GitOps存储库。当我们将任何新的Argo CRD添加到库伯内特斯集群时，自动驾驶仪将需要访问Argo CD服务器。 自动驾驶仪 ** **是时候看看它是如何工作的真正例子了。首先，我们需要安装Argo CD自动驾驶仪，在这个页面的（https://argocd-autopilot.readthedocs.io/en/stable/Installation-Guide/）上，你可以根据你的操作系统选择相关的方法。我更喜欢使用Docker容器（https://argocd-autopilot.readthedocs.io/en/stable/Installation-Guide/#docker），这样我就可以最小化在我系统上本地安装的工具。 接下来，我们需要一个有效的Git存储库，其中Argo CD自动驾驶仪将推动相关的结构和显示。然后，我们需要一个有效的Git令牌，以便我们可以在克隆和推动更改方面与存储库进行交互。例如，如果我们使用GitHub，我们可以从开发人员设置中创建一个令牌，并创建一个个人访问令牌（https://docs.github.com/en/github/authenticating-to-github/keeping-your-account-and-data-secure/creating-a-personal-access-token）：

image.png

图2.6-创建 GitHub个人访问令牌 接下来，我们需要在Docker容器环境中导出GIT_REPO和GIT_TOKEN，这样我们就可以运行Argo CD自动驾驶仪：

$ export GIT_TOKEN=<your-personal-access-token>
 $ export GIT_REPO=https://<your-git-repo-url>
 $ argocd-autopilot repo bootstrap

最后一个命令推送清单，在Git存储库中创建必要的结构，同时，在kubernetes中为我们在这一章中设置的选定上下文集群中安装Argo CD。你可以在这里找到存储库的结构：https://github.com/spirosoik/ch02 。命令成功完成后，你可以访问Argo CD UI，输出如下：

 INFO argocd initialized. password: <generated password>
 INFO run:
 kubectl port-forward -n argocd svc/argocd-server 8080:80

** **运行端口转发命令后，使用生成的密码并打开http:// localhost：8080，以管理员身份登录到UI。我们将在UI中看到Argo CD已经在管理自己：

image.png

图2.7-ArgoCD自动驾驶仪启动图 现在，是时候创建一个测试Argo CD项目和应用程序再次使用Argo CD自动驾驶仪：

$ argocd-autopilot project create testing
$ argocd-autopilot app create hello-world \--app github.com/
argoproj-labs/argocd-autopilot/examples/demo-app/ -p testing 
--wait-timeout 2m
$ argocd-autopilot app create hello-world2 \--app github.com/
argoproj-labs/argocd-autopilot/examples/demo-app/ -p testing 
--wait-timeout 2m

** **在应用程序创建之后，在Argo CD完成其同步周期之后，我们的新项目将出现在根应用程序下：

image.png

图2.8-应用程序模式的Argo自动驾驶仪应用程序 Argo CD中的这种分组被称为应用程序的应用程序模式(https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#app-of-apps)。为了更好地理解这一点，我们的想法是，我们能够构建一个负责创建其他应用程序的主要应用程序。应用程序模式的强大之处在于，它为我们提供了一种声明性的方式来管理一组应用程序，并且可以协同部署和配置。 重要提示 Argo CD自动驾驶仪在写作时只支持Gitea和GitHub。 在Argo CD自动驾驶的实践部分之后，我们现在熟悉了Argo CD的核心概念，所以是时候通过Argo CD应用的同步原则进一步扩展我们的知识了。

2.5 同步原则

Argo CD的同步阶段是最重要的操作之一，如果你使用资源钩子和同步波，它可以变得非常强大。本节将详细解释这些操作，你将看到它们在真实环境中可以提供给你的无限功率。

2.5.1 资源挂钩

正如我们在前一节中所描述的，同步是将应用程序移动到目标状态的阶段，通过应用Kubernetes 集群中的更改来实现，该操作由Argo CD在多个步骤中执行。同步的各个阶段如下:

• 预同步
• 同步
• 同步后 这些操作被称为资源钩子，它允许我们在同步阶段之前、期间或之后运行任何其他操作。
• 使用预同步钩子来执行在同步阶段之前需要完成的任何操作。一个典型的例子是数据库迁移，因为我们需要首先运行这些迁移。
• 使用"跳过"来通知Argo CD以跳过清单的应用程序。
• 使用同步钩子来协调一个复杂的部署，这需要比Kubernetes的滚动更新策略更复杂，比如蓝/绿或金丝雀发布。
• 使用同步钩子后在部署运行集成和健康检查，或者在推特上发布新版本发布以及与其他系统的任何任何其他集成。
• 如果同步操作失败，请使用SyncFail钩子来运行清理或终结器逻辑。 资源钩子被应用于特定的Kubernetes 清单。例如，让我们假设我们有一个数据库的模式迁移，并且我们在Kubernetes Kind Job中运行它；资源钩子将只是一个Kubernetes 注释。该注释将向Argo CD指示该资源应该在同步操作期间执行的时间。以下清单如下一个示：

apiVersion: batch/v1
kind: Job
metadata:
 generateName: schema-migrate-
 annotations:
 argocd.argoproj.io/hook: PreSync

资源钩子是根据逻辑顺序和基于用例重新排序清单同步的一种好方法。

2.5.2 同步波

在高水平上，如前所述，有三个阶段，预同步、同步和后同步。在这三个阶段中，我们可以有一个或多个波，使我们能够在后续资源同步之前确保某些资源是健康的。 简而言之，你可以通过注释来排序同步库伯内特斯显示的方式。波可以同时假设正值和负值；如果未指定波，则默认情况下指定波为零。 配置一个波非常简单；只需在特定的清单中添加一个注释：

metadata:
   annotations:
      argocd.argoproj.io/sync-wave: "5"

一切都有效，因为我们实际上有两种方法来重新排序清单：

• 资源挂钩
• 同步波 首先，我们可以并行地使用这两种方式并组合它们。当同步操作开始时，Argo CD用以下步骤命令资源：

1. 首先，检查阶段注释。
2. 然后用较低的值进行波形注释。
3. 例如，首先是名称空间
4. 按名称

然后，Argo CD决定下一步将应用哪个波，这是将发现任何不同步或不健康的资源的地方。接下来，它应用这个波，并以重复的方式继续下去，直到所有的相位和波都同步和健康。让我们记住，如果一个应用程序在第一波中拥有可能是不健康的资源，那么这个应用程序就不能是健康的。 我们将在第5章中看到它们是如何在Argo CD引导K8s集群中工作的，在那里我们将在生产环境中看到Argo CD的真实例子。

2.6 总结

在本章中，我们熟悉了Argo CD的核心概念，并建立了一个Argo CD词汇，以便我们可以在接下来的章节中有一个共同的语言。我们详细检查了架构概述和Argo CD的工作方式。同时，我们在本地环境中运行Argo CD，并部署了我们的第一个Argo CD应用程序。最后，我们讨论了Argo CD的两个最强大的特性，资源钩子和同步波。 在下一章中，我们将开始探讨如何以声明性的方式操作Argo CD，并遵循最佳实践。

2.7 深入阅读

• 一个Argo CD架构概述: https://argo-cd.readthedocs.io/en/stable/operator-manual/architecture/
• 解释应用程序的应用程序模式: https://argo-cd.readthedocs.io/en/stable/operator-manual/cluster-bootstrapping/
• Argo CD自动驾驶仪：https://argocd-autopilot.readthedocs.io/en/stable/
• 合成波和挂钩: https://redhat-scholars.github.io/argocd-tutorial/argocd-tutorial/04-syncwaves-hooks.html