Argo CD 实践教程 05

这一部分介绍了核心概念，并讨论了如何将Argo CD作为SRE进行操作。
本书的这一部分包括以下章节:

• 第三章，操作Argo CD
• 第四章，访问控制

第3章 操作Argo CD

我们将通过使用高可用性(HA)清单安装带有Kustomize的Argo CD来开始本章，并介绍一些我们将在遵循GitOps方法时执行的配置选项。我们将在实时Argo CD安装的ConfigMap中进行更改，以了解如何以GitOps的方式修改Argo CD的不同设置。
然后，我们来看看Argo CD的不同组件（HA）清单引入的方法，以及我们还可以做些什么来使我们的安装成为高度可用的。虽然Kubernetes集群具有多控制平面和工作节点，但它仍然可能发生故障。因此，我们将学习如何准备灾难恢复以及如何将安装从一个群集移至另一个群集，包括所有状态。
最后，我们将了解哪些指标会被公开，以及如何让设置在应用程序同步成功或失败时通知最终用户或向CI/CD系统发送自定义挂钩。
在本章中，我们将介绍以下主题：

• 声明式配置
• 设置HA安装
• 规划灾难恢复
• 启用可观察性
• 通知最终用户

3.1 技术要求

在本章中，你需要访问Kubernetes集群。然而，这一次，本地的计划将不够。这是因为我们将使用HA清单，需要在多个节点上运行，以便Pod可以在它们之间分布。任何至少有三个节点的群集都可以；云提供商并不重要。在我的案例中，我将使用AWS的EKS集群，你可以使用eksctl（https://eksctl.io）等工具轻松设置。你可以将其视为生产就绪型安装。
这一次，我们将使用Kustomize在集群上安装Argo CD，因此你需要将其作为工具之一进行安装(https://kubectl.docs.kubernetes.io/installation/kustomize/）。你还需要kubectl (https://kubernetes.io/docs/tasks/tools/#kubectl).
我们还将对一些Git存储库进行更改，因此需要安装Git(https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)以及代码编辑器，如Visual Studio Code(VS Code)
（https://code.visualstudio.com）。你还需要在Git托管的平台（如GitHub）上拥有一个帐户，并且必须熟悉使用Git命令来创建提交和远程拉入。本章的代码可以在ch03文件夹中https://github.com/PacktPublishing/ArgoCD-in-Practice找到。

3.2 声明式配置

在一个集群中有多种方式可以安装Argo CD。首先，我们可以直接应用它位于https://github.com/argoproj/argo-cd/blob/master/manifests/install.yaml的清单——这将安装最新版本。但是，也有为每个版本生成的清单，比如https://github.com/argoproj/argo-cd/blob/v2.0.0/manifests/install.yaml。使用kubectl，你将需要应用原始的清单，所以链接将会有点不同（你将需要在进入前面的链接后点击原始按钮）：
**kubectl apply -f https://raw.githubusercontent.com/argoproj/ argo-cd/v2.0.0/manifests/install.yaml **
** **使用位于https://github.com/argoproj/argo-helm/tree/master/charts/argo-cd的官方头盔图表。这个选项已经涵盖在第2章，开始与Argo CD，连同自动驾驶。
另一种可能性是，使用库文件，类似于Argo CD存储库，我们有库文件文件夹（你可以在那里找到kustomization.yaml文件，比如https://github.com/argoproj/argo-cd/tree/master/manifests/base。我们将更详细地查看这个选项，包括如何配置它以及如何使它自我管理（这次，不是使用自动驾驶）。除此之外，我们还有一个HA安装的模板清单。接下来我们将探讨这些问题。

3.2.1 使用Kustomizei安装HA

** **对于语言转换，我目前在我的机器上有4.3.0版本。你可以通过运行以下命令找到当前版本：

kustomize version 

** **前面的命令的输出应类似于如下内容：

{Version:kustomize/v4.3.0 
GitCommit:cd17338759ef64c14307991fd25d52259697f1fb 
BuildDate:2021-08-24T19:24:28Z GoOs:darwin GoArch:amd64}

模板安装的代码可以在https://github.com/PacktPublishing/https://github.com/PacktPublishing/在实践中的ch03/模板安装文件夹中找到。
按照以下步骤操作：
1.创建一个存储库，以保留安装配置。这将遵循GitOps的方法，因为每一个更改都将通过一个拉请求来完成。为了简单起见，我们试图将所有演示放在同一个存储库中，所以安装在一个文件夹中。但是，建议将它放在一个单独的存储库中。为了使用GitOps的好处，建议不要直接推动更改，而是通过拉请求进行更改，以便进行同行评审。
2.在存储库中，创建一个名为资源的新文件夹。
3.在资源文件夹中，添加一个名为命名空间.yaml的新文件。这是我们将设置将安装Argo CD的名称空间的地方。这是该文件的内容：

 apiVersion: v1
kind: Namespace
metadata:
   name: argocd

4.直接在之前创建的存储库的根目录中添加一个名为kustomization.yaml的新文件，该新文件包含以下内容。正如你所看到的，这指向了Argo CD的v2.1.1 HA清单（这是撰写本文时的最新版本），并引用了我们刚刚创建的名称空间.yaml文件：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: argocd
bases:
 - github.com/argoproj/argo-cd/manifests/ha/clusterinstall
?ref=v2.1.1
resources:
 - resources/namespace.yaml

5.从存储库的根目录中，运行以下命令。第一部分，构建。，将生成清单，而第二部分kubectlappll-f-将以声明性方式将清单应用到集群中：

kustomize build . | kubectl apply -f -

输出应该以这样的内容开始（还有更多的行；我们刚刚提供了前七个行，以便你可以验证这是正确的工作方式）：

namespace/argocd created
customresourcedefinition.apiextensions.k8s.io/
applications.argoproj.io created
customresourcedefinition.apiextensions.k8s.io/
appprojects.argoproj.io created
serviceaccount/argocd-application-controller created
serviceaccount/argocd-dex-server created
serviceaccount/argocd-redis-ha created
serviceaccount/argocd-redis-ha-haproxy created

6.提交并将所有内容推送到远程存储库。
如果我们有一个有效的安装，下一步将是检查UI，我们可以用端口向前来做（如果需要，你可以使用另一个端口）：

kubectl port-forward svc/argocd-server -n argocd 8085:80

** ** 打开浏览器到https://localhost:8085/；你应该看到登录页面，我们已经在第二章中讨论过，开始使用Argo CD，以及如何连接（和更改管理密码）。你可能会得到一个证书警告，因为Argo CD正在使用自签名证书，但此时，访问该网站应该没有风险。对于生产安装，你还需要创建一个附带证书的负载平衡器服务，以便你可以将TLS卸载到它中。
在下一节中，你将学习如何将Argo CD转换为可以通过Argo CD本身进行管理的应用程序，从而允许简单和声明性的配置更新。

3.2.2 Argo CD自我管理

Argo CD可以以管理集群中其他应用程序的方式管理自己。这类似于自动飞行员（https://argocd-autopilot.readthedocs.io/en/stable/）在引擎盖下所做的事情。在本节中，我们将创建一个Argo CD应用程序，该应用程序指向我们保存库清单的文件夹。通过这种方式，Argo CD将开始监视该存储库和文件夹中的更改。我们对文件夹进行的任何新提交都将自动应用。
首先，我们必须在存储库中创建一个名为argocd-app.yaml的文件，其中包含以下内容。Argo CD应用程序由三部分组成：目标，即应用清单的地方，我们用来创建特定限制（例如，此应用程序应只将资源部署到集群和特定名称空间），以及资源存储库，包括分支和存储库文件夹：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
 name: argocd
spec:
destination:
 namespace: argocd
 server: https://kubernetes.default.svc
project: default
source:
 path: ch03/kustomize-installation
 repoURL: https://github.com/PacktPublishing/ArgoCD-inPractice.git
 targetRevision: main

现在，我们将此应用于kubectl：

 kubectl apply -f argocd-app.yaml -n argocd  

** **输出值应类似于以下内容：

 application.argoproj.io/argocd created  

** **通过创建这个应用程序，我们告诉Argo CD，在https://github.com/PacktPublishing/ArgoCD-in-Practice.git存储库中，在ch03/kustomize-installation文件夹中，应该应用一些清单。这些是Argo CD安装的清单。就控制循环而言，我们所希望的状态是来自集群的状态，因此在观察状态阶段之后，不应该采取任何操作。主要的事情是，从现在开始，Argo CD每3分钟（默认情况下）监视一次存储库，并检查新的提交。如果找到任何清单，它将重新计算清单，并尝试将它们应用到集群中。这就是Argo CD可以通过它来管理自己的机制。
如果你已经停止了我们之前启用的转发端口，你可以使用以下命令重新启用它：

 kubectl port-forward svc/argocd-server -n argocd 8085:80  

然后，如果你进入https://localhost：8085，你将看到第一个被Argo CD同步的应用程序，即Argo CD本身：

图3.1——Argo CD管理的Argo CD
现在，让我们来看看一些简单的配置更新，我们可以通过创建一个提交并将其推送到远程位置来自动应用到Argo CD上。

3.2.3 配置更新

自从Argo CD的2.1版本以来，我们在主配置图中有了一个新的设置，它允许我们修改用于检查Git存储库上的新更新的默认时间间隔。每180秒，它就会检查是否推送了新的提交。我们可以使用超时。调节参数对其进行修改。在引入这个参数之前，我们必须更改应用程序控制器的状态集，以便使用-app-resync标志设置一个不同的值（自2.1版本以来就已经弃用了）。
要更新此调整超时，我们将创建一个称为补丁的新文件夹，与资源文件夹的级别相同。在它里面，我们将创建一个名为argocd-cm.yaml的新文件。我们没有替换整个配置图；相反，我们正在对它应用一些补丁——在本例中，只是 timeout.reconciliation字段。此新文件的内容如下：

apiVersion: v1
kind: ConfigMap
metadata:
 name: argocd-cm
data:
 timeout.reconciliation: 300s

我们还需要通过添加对我们为配置图所做的更改的引用来更新kustomization.yaml文件。这个文件现在应该是这样看的：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: argocd
bases:
 - github.com/argoproj/argo-cd/manifests/clusterinstall?ref=v2.1.1
resources:
 - resources/namespace.yaml
patchesStrategicMerge:
 - patches/argocd-cm.yaml

接下来，我们需要创建一个提交，其中包含新的argocd-cm.yaml文件和我们对kustomization.yaml所做的更改，然后将其推到远程存储库。Argo CD每180秒检查一次新的提交，因此它将识别更改并应用它。在这样做之后，它将每300秒检查一次新的提交。
文档说，仅仅更新这个设置是不够的——我们还需要手动重新启动 argocd-repo-server部署，以便加载新的配置。可以使用以下命令完成：

kubectl rollout restart -n argocd deployment argocd-repo-server

** **输出值应类似于以下内容：

deployment.apps/argocd-repo-server restarted

** **让Argo CD管理本身是很有用的，因为我们可以对它正在运行的安装进行更改，从我们刚才看到的小型配置更新到升级版本。所有这些都将由Argo CD自动应用，使它成为一个类似于任何其他由Argo CD管理的应用程序。正常的GitOps流应该包括使用更改创建一个拉出请求，以便你的对等体可以查看它们。在我们的例子中，为了简单起见，我们直接推到远程默认分支，因此它们将立即应用。接下来，我们将发现如何通过查看所有不同的Argo CD组件以及我们将应用于它们的更改来实现HA安装。

3.3 设置HA安装

由于我们已经在Kustomize中使用了HA选项，让我们看看安装了哪些组件，它们如何处理HA部分，如果还有什么我们可以做：

• API服务器：它可以处理所有的外部交互，因此，如果你正在使用CLI或UI或创建客户端，你将与API进行通信。HA清单已经为这个吊舱设置了两个实例。

• 存储库服务器：它负责创建应用于集群的最终清单；清单生成很复杂，因为Argo CD支持的所有模板，如Helm2或3、Kustomize和Jsonnet。HA清单有两个复制品。

• 应用程序控制器：这是工作被启动的地方，控制循环被实现的地方，以及应用程序同步发生的地方。最初，你只能有一个实例，但是现在，每个集群碎片可以有一个实例。HA清单使用了控制器的一个实例。

• Redis缓存：清单生成是一个昂贵的操作，Argo CD试图保存清单在一个Redis实例；如果缓存失败，就没有问题，因为它可以重新计算，但预计性能会损失。在这里，我们可能有正常和HA表现之间最大的变化。在HA模式下，我们得到了一个额外的HAProxy部署和三个Redis的副本——即一个主服务器和两个从服务器。

• Dex服务器：当你使用外部标识提供程序，如安全断言标记语言（SAML）、OpenID连接（OIDC）或轻量级目录访问协议（LDAP）时，它负责用户身份验证。它是可选的，但是如果你想，例如，连接你的GitHub或谷歌帐户到Argo CD，你将需要这个组件。

  让我们用HA来讨论一下。

3.3.1 API服务器

API服务器是我们所有请求的入口点，无论它们是来自UI、CLI，还是来自自定义客户机，比如curl。它没有任何状态，所以我们可以根据负载来放大或缩小它。这也意味着我们可以通过更改其部署的副本数量来保持HA安装。通过使用HA选项，我们得到了两个副本，但是让我们看看如何将这个数字更新到三个，以及需要做哪些其他更改。
除了副本之外，我们还可以选择更新ARGOCD_API_SERVER_REPLICAS环境变量，使其具有与我们正在使用的相同数量的副本。这用于计算暴力密码攻击的限制。假设，对于一个实例，30个并发登录请求将触发与服务器不同的响应，对于三个实例，负载将被分散，所以你将只得到10个。这意味着我们所拥有的实例越多，我们需要使用的限制就越低。现在，如果你不更新该变量，那么该应用程序仍然可以工作，但如果你确实更新了它，那么它将会更安全。
要拥有 argocd-server部署的三个副本，我们需要执行以下操作。在补丁程序文件夹中创建一个名为argocd-server-deployment.yaml的新文件。其内容应如下：

apiVersion: apps/v1
kind: Deployment
metadata:
 name: argocd-server
spec:
 replicas: 3
 template:
 spec:
 containers:
 - name: argocd-server
 env:
 - name: ARGOCD_API_SERVER_REPLICAS
 value: '3'

然后，我们需要将该条目添加到kustomization.yaml文件中，以便将考虑到我们的更改。我不会在这里显示整个文件，只是从补丁策略合并开始的部分：

patchesStrategicMerge:
 - patches/argocd-cm.yaml
 - patches/argocd-server-deployment.yaml

在，像往常一样，我们必须用这两个文件创建一个git提交，然后将其推到远程，这样Argo CD就可以看到新的版本并将更改应用到安装中。

3.3.2 存储库服务器

存储库（repo）服务器是生成要应用于集群的资源的重要组件。通常，在我们的GitOps回购中，我们不使用简单的清单；相反，我们使用模板引擎，如头盔、十四行诗和Kustomize。此组件正在将这些模板转换为准备与kubectlapcle命令一起应用的清单。它去获取Git回购的内容，基于它知道是否使用帮助、注释或其他东西（例如，如果它找到一个名为图表的文件。yaml，它知道它是一个帮助图表）。在发现模板引擎是什么之后，它将运行诸如掌舵模板和模板构建等命令，以生成最终的清单。对于Helm，它可能需要提前更新掌舵程序来获取任何外部依赖项。
在这个存储库服务器应用程序中发生了很多事情，这意味着如果我们运行它的多个实例，我们将能够并行生成更多的清单。提供足够的资源以使这些容器不会因为内存不足的错误或CPU上的限制而被杀死也是有意义的。如果你有数千个应用程序已经部署了Argo CD，那么你可以轻松地运行10多个存储库服务器实例，并为每个实例分配诸如4到5个cpu和8到10 GB内存之类的东西。从HA清单中，我们已经有了两个实例了，但是我们将修改它，使它有三个实例。我们不会放置任何资源请求或限制，因为我们使用本地集群，但是对于实际集群，强烈建议这样做。
注意-修复服务器的性能
** **我使用存储库服务器的经验受到了Helm 2的使用的严重影响。当我们将大部分图表迁移到Helm 3时，我们运行了一些测试，并意识到这一移动显著减少了清单生成时间（至少在某些情况下，这在我们的设置中仍然经常发生）。因此，你应该稍微保留一下前面的容器资源建议，并自己进行计算。
我们可能需要修改的另一个重要参数是模板引擎的超时。Argo CD分叉帮助或引导命令，并为这些操作设置90秒的超时。有时，这可能还不够，比如当库斯提兹使用大的远程基地，或者当赫尔姆需要模板大的图表，如 kube-prometheus-stack （https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack它曾经被称为普罗米修斯操作员）或istio (https://istio.io/latest/docs/setup/install/helm/).因此，你可以运行一些测试，看看什么对你有用。如果要增加超时时间，则可以使用ARGOCD_EXEC_TIMEOUT环境变量。
在包含以下内容的补丁文件夹中创建一个名为argocd-repo-server-deployment.yaml的新文件，其中已经为存储库服务器设置了3个副本，并且为模板超时设置了3分钟：

apiVersion: apps/v1
kind: Deployment
metadata:
 name: argocd-repo-server
spec:
 replicas: 3
 template:
 spec:
 containers:
 - name: argocd-repo-server
env:
 - name: "ARGOCD_EXEC_TIMEOUT"
 value: "3m"

我们还需要更新kustomization.yaml文件，以便它包含对我们刚刚在补丁文件夹中创建的新文件的引用（我在这里添加了补丁策略合并部分，其中包括更改，而不是文件的全部内容）：

patchesStrategicMerge:
 - patches/argocd-cm.yaml
 - patches/argocd-server-deployment.yaml
 - patches/argocd-repo-server-deployment.yaml

创建Git提交并将其推到远程，这样Argo CD就可以更新存储库服务器部署。

3.3.3 应用控制器

最初，这是一个不能有多个副本的组件，因为有一个控制循环是所有同步的启动器。因此，拥有多个副本将引入为同一应用程序同时启动两个或多个同步的可能性。但是从1.8版本开始，你可以有多个副本，每个实例都要处理在Argo CD中注册的一部分集群。
例如，如果你有9个集群，其中Argo CD正在安装应用程序，并且你启动了三个应用程序控制器，那么每个控制器将处理其中的三个集群。缩放它们对于HA安装不是必需的，但它在这个方向上确实有帮助，因为一个控制器的故障只影响部分集群，而不是所有的集群。它还通过将负载分解为多个实例，从而有助于实现Argo CD的整体性能。
要告诉Argo CD应用程序控制器它可以拥有多少个碎片（或实例），你可以使用其状态集中的ARGOCD_CONTROLLER_REPLICAS环境变量。让我们来看看为控制器的Kustomize安装设置为3个副本（这意味着三个碎片）的覆盖层会是什么样子的。在补丁文件夹下创建一个名为argocd-应用程序控制器statefulset.yaml的文件，内容如下：

apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: argocd-application-controller
spec:
 replicas: 3
 template:
spec:
 containers:
 - name: argocd-application-controller
 env:
 - name: ARGOCD_CONTROLLER_REPLICAS
 value: "3"

现在，更新kustomization.yaml文件的补丁策略合并部分，如下所示：

patchesStrategicMerge:
 - patches/argocd-cm.yaml
 - patches/argocd-server-deployment.yaml
 - patches/argocd-repo-server-deployment.yaml
 - patches/argocd-application-controller-statefulset.yaml

创建提交，推送到远程，Argo CD将处理其余的部分。
可能只有一个目标集群，这意味着所有应用程序，无论它们是开发、测试、质量保证还是生产，都将只安装在一个集群上。在这种情况下，有多个应用程序控制器的实例并没有意义，但是你应该为容器分配大量的CPU和内存。你应该检查官方文档（https://argo-cd.readthedocs.io/en/stable/operator-manual/high_availability/#argocd-application-controller）中的—操作处理器、状态处理器和—库并行限制标志，并为它们设置更高的值，以允许你的实例处理更多的应用程序。
注意：环境变量中的复制副本
** **该模式至少可以在两个地方使用：API服务器和应用程序控制器。在这里，副本的数量被注入到具有环境变量的容器中。这样，这比从每个实例中调用Kubernetes API来找出数字要简单得多。即使开发人员有额外的开销来确保他们更新了这两个地方，它仍然值得这样做。

3.3.4 Redis缓存

Redis被Argo CD用作一次性缓存，这意味着如果Redis没有响应，给出一些错误，或者根本没有安装，系统仍然可以工作，尽管这可能会影响其性能。所以，这是一个可选的组件，但也是一个高度推荐的组件。
这是因为从Git存储库生成的清单将保存在Redis缓存中，因此如果缺少Redis，则必须在每次同步请求时重新创建它们。只有在对Git存储库有新的提交（将提交的SHA视为键）时，才会删除缓存。如果缓存丢失，则需要重新创建一切，这意味着应用程序仍然可以工作，但性能不佳。
HA装置附带了一个状态集，带有Redis的三个副本——一个主服务器和两个从。它还附带了一个位于Redis前面的HAProxy部署。如果Redis主服务器由于某种原因而失败，并且其中一个从服务器被提升为新的主服务器，那么HAProxy将使其对客户端应用程序透明。
就HA而言，Redis安装有一个非常好的设置，所以不需要做任何更改。
注意-Redis清单
** **Argo CD使用的Redis清单是由位于https://github.com/DandyDeveloper/charts/tree/master/charts/redis-ha的Helm表生成的。当我们使用库或简单清单选项时，帮助图表已经模板化并转换为简单资源。Helm安装有一个redis-ha图表，因此直接使用它。

3.3.5 Dex服务器

Dex（https://github.com/dexidp/dex）用于在涉及外部系统时委托身份验证，例如在使用OIDC时。因为dex保存内存缓存，我们不能使用多个实例；否则，我们会有不一致的风险。如果它下降，我们面临的风险是无法使用外部系统登录。这并不重要，因为Argo CD继续做所有必要的和解，所以它仍然应该连接到Git回购和Kubernetes 集群的目的地，这意味着它的工作不会停止。登录停机应该是临时的，因为通过作为一个副本部署安装，控制器将重新启动实例（有时，当涉及到节点问题时，它会在我们的帮助下这样做）。
如果你只使用本地用户（我们将在第4章，访问控制中了解更多关于他们的信息）或管理特殊用户，那么你可以通过将副本的数量设置为零来禁用dex安装。
HA是减少服务中断风险的最佳实践之一。即使Argo CD实例关闭了一小段时间，你也不希望在执行任何类型的生产部署或回滚时发生这种情况。因此，通过在Argo CD组件中构建冗余和弹性来消除单点故障变得至关重要。幸运的是，我们从盒子里拿出了HA的清单。一旦我们了解了如何将每个组件修改为高可用性，我们就可以采取更多步骤来改进服务，从使用更多的副本到拆分Kubernetes集群，我们将应用程序部署到更多的应用程序控制器。接下来，我们将讨论灾难恢复，这是关于让系统在失效后恢复到工作状态。这可以帮助我们在HA还不够的地方把事情恢复正常。