Argo CD 实践教程 03

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

在本章中，你需要访问一个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文件夹中找到。

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

我们之前描述的是GitOps，它在Argo CD更强大。Argo CD是Kubernetes的一个