Argo CD 实践教程 03

我们将通过解释Argo CD是什么以及该平台所基于的底层技术来开始本章，以便我们可以设置基础。我们将解释Argo CD的核心概念，并且在深入了解它之前，我们将通过你需要知道的必要词汇。 然后，我们将描述Argo CD的架构概述和GitOps方面的典型工作流。我们将详细描述每个核心组件及其职责，以便我们能够理解并排除潜在问题。 最后，我们将在本地机器上的Kubernetes集群中安装Argo CD，并尝试使用它部署应用程序，并通过Argo CD观察GitOps阶段。 在本章中，我们将介绍以下主要的主题：

• 什么是Argo CD？
• 核心概念与词汇
• 解释体系结构
• 同步原则

2.1 技术要求

在本章中，你需要访问一个Kubernetes集群，我们将使用以下工具之一在本地运行:

• Kind:https://kind.sigs.kubernetes.io/
• K3s:https://rancher.com/docs/k3s/latest/en/
• minikube:https://minikube.sigs.kubernetes.io/docs/
• MicroKubernetes:https://microkubernetes.io/docs 我们将使用Helm图表在本地集群中部署Argo CD和演示应用程序。我们需要在本地机器上安装Helm CLI (https://helm.sh/docs/intro/quickstart/))。我们将使用Visual Studio Code (https://code.visualstudio.com))来编辑Helm图表值。代码可以在https://github.com/PacktPublishing/ ArgoCD - in - Practice的ch02文件夹中找到。

2.2 什么是Argo CD？

几年来，我们大多数人都在应用程序中使用相同的独立类型的环境，这些环境分为开发、测试、准备和生产。在Kubernetes中表示这些集群的方式在很多方面都有所不同，并且取决于许多其他因素，例如团队的规模和预算。其中一个因素可能是每个环境中的不同集群，也可能是通过名称空间在一个集群中进行分隔。在任何情况下，我们都会使用必要的部署资源为应用程序创建新的命名空间，并添加为环境配置应用程序所需的任何内容（配置项、密钥、入口等）。 上述方法的缺点是随着时间的推移会存在配置漂移。例如，我们的开发集群或命名空间将具有最新的应用开发版本或Kubernetes资源（例如网络策略）中的更改，但我们需要手动将所有更改应用到其余环境。解决此问题的一个简单解决方案是使用诸如Helm、Kustomize或jsonnet之类的包管理器，这样我们就可以以可重复的方式定义应用程序的资源，并将其作为单一授权点。例如，使用Helm，我们可以创建几个不同的版本，并将每个版本部署到每个环境中，但这同样很难跟踪，并且增加了额外的复杂性。 但是，如果我们采用GitOps方法会怎样？整个配置将保存在一个Git存储库中，该存储库将是获取请求和审核任何更改的真实来源。最后，如果我们有一个与第1章GitOps和Kubernetes中描述的类似的控制器，会怎么样？理想情况下，控制器会自动应用Git存储库中的所有配置。每次手动更改Kubernetes资源和所需状态（位于Git存储库中且不匹配）时，控制器都会尝试重新应用所需状态，以便始终将Git存储库作为事实来源。

2.2.1 熟悉Argo CD

我们之前描述的是GitOps，它在Argo CD更强大。Argo CD是Kubernetes的一个声明式GitOps的持续交付工具。GitOps的核心组件之一是应用程序控制器，它在实际中对正在运行的应用程序进行连续的观察，并将当前应用程序状态与期望的目标状态进行比较，目标状态的真实源是Git存储库。以下用例可以使用Argo CD:

• 自动部署：在任何Git提交操作，或CT管道运行和手动同步触发器之后，Argo CD控制器将以自动化的方式将所需的状态从Git存储库推到集群中。这是在使用Argo Events自动化框架（https://argoproj.github.io/argo-events/）或手动用户请求时实现的。
• 可观察性： Argo CD提供了一个UI、CLI和Argo CD通知引擎（https://argocd-notifications.readthedocs.io/en/stable/），通过它我们可以识别应用程序的状态是否与Git中期望的状态同步。
• 多租户：使用基于角色的访问控制（RBAC）策略进行授权，能够管理和部署到多个集群。 Argo项目是一个由许多工具组成的大家庭，如之前所述，其中包括以下内容：
• Argo CD （ https://argoproj.github.io/cd）
• Argo Rollouts（https://argoproj.github.io/rollouts）
• Argo Events（https://argoproj.github.io/events）
• Argo Workflows（https://argoproj.github.io/workflows） 所有这些组件都是相互补充的，它们形成了一些伟大的GitOps和DevOps的文化和实践。

2.3 核心概念与词汇

在本节中，我们将描述Argo CD的一些核心组件，如协调，并详细描述Argo CD的核心对象的自定义资源定义（CRDs）。同时，我们将设置一个词汇表，以便我们可以为Argo CD操作提供一个通用的语言。最后，我们将观察协调循环以及Argo CD的工作原理。

2.3.1 Argo CD 协调

如前所述，Argo CD有责任将Git存储库中描述的期望状态与集群中的活动状态相匹配，并将其交付到我们首选的环境中。这被称为协调，Argo CD处于一个从Git存储库到kubernet的协调循环中，如下图所示，假设我们使用Helm：

图2.1-调节回路 正如我们在图2.1中看到的，Argo CD监视Git存储库，首先运行一个Helm模板来生成库清单YAML，并将它们与集群中所需的状态进行比较，这称为同步状态。如果Argo CD识别出任何差异，那么模板文件将与库贝克特一起应用，并相应地更改库贝克特所需的状态，这可以自动化或手动完成。此外，Argo CD观察实时的库伯内特对象，并将它们与库伯内特对象的期望状态进行比较，这称为应用程序的运行状况状态。 这里一个很好的观察是，Argo CD没有使用舵轮安装，而是使用标准的kubectl。这样做的原因是Argo CD支持许多模板工具，它的职责是将所需的状态部署为GitOps声明性工具，而不是作为任何这些工具的包装器。

2.3.2 词汇

在介绍了GitOps和Argo CD核心概念后，我们需要定义一些我们已经使用过，并将在整本书中使用的必要词汇：

• 应用程序：由清单描述的一组Kubernetes资源。这些在Argo CD中被定义为自定义资源定义（CRDs）：https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#customresourcedefinitions。
• 应用程序源类型：我们用于构建应用程序的工具，如Helm, Kustomize,和jsonnet。
• 目标状态：应用程序的期望状态，如Git存储库中所示，这是真相的来源。
• 活动状态：该应用程序的活动状态，这意味着部署了什么类型的Kubernetes资源。
• 同步状态：显示活动状态与目标状态相匹配的状态。简单地说，就是部署在Kubernetes中的应用程序是否符合Git存储库中描述的期望状态相匹配。
• 同步：将应用程序移动到目标状态的一个阶段，通过应用Kubernetes集群中的更改来实现的。
• 同步操作状态：同步阶段的状态，无论是失败还是成功。
• 刷新：比较Git中的最新代码与实时状态，并检查有什么不同的地方。
• 运行状况：它正在运行的应用程序的运行状况以及是否可以为请求提供服务。