关注留言点赞，带你了解最流行的软件开发知识与最新科技行业趋势。

在这份关于 Argo CD 的详细指南中，了解它的工作原理，了解部署的拉动与推送概念，以及 GitOps 与持续交付。

Argo CD 是一种持续交付 (CD) 工具，已在 DevOps 中流行起来，用于将应用程序交付到 Kubernetes 上。它依赖于一种称为 GitOps 的部署方法。GitOps 是一种机制，可以从最后已知的 Git 提交版本中拉取最新的代码和应用程序配置，并将其直接部署到 Kubernetes 资源中。广泛采用和流行是因为 Argo CD 帮助开发人员在一个平台上管理基础设施和应用程序生命周期。

要深入了解 Argo CD，我们必须首先了解持续交付对于大多数应用程序团队是如何工作的，以及它与 GitOps 有何不同。

什么是持续交付？

持续交付 (CD) 是一种软件交付流程/框架，它使开发人员能够将代码更改持续推送到生产服务器中，而无需通过基于推送的管道访问基础设施。此过程减少了代码到达其最终用户所需的时间并提高了发布速度。这是一个可重复的过程，可以扩展您的应用程序以满足最终用户不断增长的需求。

持续交付如何工作？

持续交付是应用程序交付生命周期的一部分，它将应用程序构建后部署到资源中。在这种情况下，我们的基础设施将是不使用 Argo CD 的 Kubernetes。或者，如果我们使用 Jenkins，流程将如下所示：

1. 为了向最终用户发布功能升级或错误修复，预配置的持续集成 (CI) 管道将根据 Docker 文件构建 Docker 映像。Ops
2. 然后，脚本会将其推送到已配置的 Docker 存储库。
3. 要将此映像移动到 Kubernetes 中， deployment.YAML文件将使用新的映像标签和名称进行更新，以便从 Docker 注册表中获取最新的映像。

CD 进入 Kubernetes 的挑战

在 Kubernetes 兴起之前，CD 大多数应用程序团队使用 Jenkins 和 Spinnaker 等工具启用 CD。Kubernetes的架构复杂，由于Kubernetes架构的复杂性，这些工具无法高效部署到Kubernetes中并无错部署。这些问题使得使用 Jenkins 等工具与 Kubernetes 一起工作具有挑战性。

部署到 Kubernetes 时传统 CD 面临的挑战：

工具安装与管理

需要安装 Kubectl 和 Helm 等工具。这些增加了业务活动。

访问 Kubernetes 集群

必须在 CD 工具中配置访问管理，以启用对 Kubernetes 集群的授权并执行更改。如果 Kubernetes 集群在云提供商上运行，则必须在集群外部配置和共享这些凭据。

安全和运营挑战

配置将随着集群的增加而增加，这会增加操作开销。虽然增加的运营开销可能并不具有挑战性，但当集群凭证与外部服务和工具共享时，它会危及系统的安全性。

扩展基础架构时出现的问题

每个团队都需要自己的一组 Kubernetes 集群凭据，以便用户可以访问集群中的特定应用程序资源。在使用像 Jenkins 这样部署到多个集群的 CD 工具大规模运行 Kubernetes 时，需要为每个新集群重新配置。

缺乏知名度

当 CD 工具在没有 GitOps 或 Kubernetes 原生 CI/CD 管道的情况下将应用程序部署到 Kubernetes 中时，该工具将无法看到部署后将配置应用于 deployment.YAML 文件。一旦执行了 kubectl 命令，团队必须等到有人报告事件。此外，执行情况仍不明朗。

Argo CD 可以高效地持续交付到 Kubernetes 中，它的工作原理是 GitOps。在了解 GitOps 之前，让我们在接下来的 GitOps 部分了解推送与基于拉取的 CI/CD。

什么是 GitOps，它与传统 CD 有何不同？

传统的 CD 和 GitOps 在基于推和基于拉的部署的核心原则上有所不同。

大多数 CI/CD 流程都采用推送机制，这意味着事物会在事件触发时移动到各自的目的地。例如，当开发人员完成他的代码编写后，他必须执行一组命令将他的代码移动到服务器中进行部署。在 Kubernetes 环境中，开发人员必须在管道中使用 Kubectl 和 Helm 等工具配置集群以应用更改。

Argo 是一个使用基于拉动机制的 CD 工具。基于拉取的 CD 机制意味着目的地触发事件从源 (Git) 拉取数据以部署在目的地。由于稍后将在博客中解释的原因，Argo CD 驻留在集群中，将最新验证版本的代码拉入集群以进行部署。这种模式有很多好处，比如提高安全性和易用性。

这种基于拉取的机制称为 GitOps，其中像 Git 这样的源代码管理系统被视为应用程序和配置数据的唯一真实来源。

Argo CD 是如何工作的？

与推送式部署相比，Argo CD 采用反向流机制。新机制使 Argo CD 能够从 Kubernetes 集群内部运行。Kubernetes 面临传统 CD 机制的挑战，因为 CI/CD 工具（如 Jenkins）位于集群外部，而 Argo CD 位于集群内部。在集群内部时，Argo CD 从 Git 中拉取更改并将它们应用到驻留的集群中。Argo CD 不是像老一代工具那样在集群内部推动更改，而是防止敏感信息暴露给 Kubernetes 集群和环境之外的其他工具。

Argo CD 可以通过两个简单的步骤设置：

1. 将 Argo CD 代理部署到集群。
2. 配置 Argo CD 以跟踪 Git 存储库的更改。

当 Argo CD 监视器发生变化时，它会自动将它们应用到 Kubernetes 集群。当开发人员将新代码更新提交到 Git 存储库时，自动化 CI 管道将自动启动构建过程并构建容器映像。然后根据配置，CI 管道将推送和更新 Kubernetes 清单文件。管道将更新deployment.yaml文件中的新映像版本名称和详细信息。Argo CD 可以跟踪这个新的更新，拉取镜像，并将其部署到目标集群上。

当 Kubernetes 集群准备就绪时，Argo CD 会发送一份关于应用程序状态以及同步已完成且正确的报告。Argo CD 也在另一个方向工作，监控 Kubernetes 集群中的变化，如果它们与 Git 中的当前配置不匹配则丢弃它们。

使用 Argo CD 时应遵循的最佳实践

1. 用于应用程序源代码和应用程序配置的独立 Git 存储库
2. 用于系统配置的单独 Git 存储库

为什么要分离存储库？

为应用程序源代码和应用程序配置使用单独存储库的主要原因是因为应用程序配置代码不仅存在于部署文件中，而且还存在于 Kubernetes 使用的 configmaps、secrets、storage、svc 等中。这些文件的更改独立于源代码。

当开发人员或 DevOps 想要更改service.yaml文件时，它是应用程序配置而不是软件代码的一部分，他必须运行整个 CI 管道以将这些更改同步到生产中。CI 管道仅在更新代码更改时运行。将应用程序配置和软件代码组合在一起会使设置变得复杂且效率低下。

因此，一旦 DevOps 更改了 git 存储库上的配置，Argo CD 就会意识到这些更改并更新目标集群，因为一旦 Git 存储库中的配置文件发生变化，它就会不断监视存储库。

使用 Argo CD 的好处

• K8s 配置可以定义为 Git 存储库中的代码。
• 配置文件不适用于开发人员/DevOps 的个人笔记本电脑。
• 更新可以作为标签、分支或 Git 提交时固定的特定清单版本进行跟踪。
• 用于更新集群的相同且唯一的界面
• Git 作为唯一的真实来源
• 避免无法追踪的 kubectl 命令应用程序
• 带有审计跟踪的版本控制更改
• 使用 GitLab、GitHub、Microsoft、OAuth2、OIDC、LinkedIn、LDAP 和 SAML 2.0 等提供商的单点登录 (SSO)
• 支持在 GitLab、GitHub 和 BitBucket 中触发 webhook 操作

轻松回滚

如果一个新的代码提交被推送到 Git 存储库并且更改被应用到具有 Argo CD 自动同步的集群，集群就会失败。DevOps 可以从最近已知的最佳存储库版本列表中恢复到之前的工作状态，就像 Windows 还原点一样。此外，人们不需要处理手动铆接每个集群和进行清理的费力过程，因为 Argo CD 将自行完成所有这些工作。

使用 Argo CD 避免雪花簇

Argo CD 正在监视 Git 存储库和集群中的更改。每当 Git 存储库或集群发生变化时，Argo CD 都会比较这两种状态以检查是否存在任何错误配置或差异。如果它们与 Git 存储库中定义的所需状态与集群的实际状态不匹配，Argo CD 将变为活动状态并按照集群中的描述快速同步集群。因此，在这种情况下，如果有人去集群中进行手动更改，Argo CD 将检测到它并同步到所需的状态。它会覆盖手动更改。

自动覆盖有助于系统保持稳定，并保证 Git 存储库在任何时间点都是唯一的真实来源。它还提供了集群的完全透明性，并使其成为 Snowflake 集群。

从头开始重新创建集群

当一个集群完全崩溃，并且必须从头开始构建它时，Argo CD 可以指向 Git 存储库，其中定义了完整的集群配置。它将重新创建与前一个相同的状态。这是一个完全自主的过程，开发人员和 DevOps 不必担心灾难恢复后清理过程。这是可能的，因为 Argo CD 以声明方式接受集群配置作为代码。

Argo CD 提供了哪些超过标准 GitOps 的优势？

通过简单的访问控制实现更好的团队协作

生产集群必须具有有限的访问权限，并且应该只允许您的部分团队成员访问。为了对这些集群配置不同的访问规则，Argo CD 可以为授权开发人员和工程师启用拉取请求批准。这有助于管理集群权限。无需在 Kubernetes 上创建集群角色和用户帐户。

集群外部 DevOps 生态系统中的 CI/CD 工具或其他外围工具等非人类用户可以在驻留在集群内部的 Argo CD 中进行配置。Argo CD 的这种架构可确保这些凭据保留在集群内，从而使系统健壮且安全。

Argo CD 架构概述

Argo CD 是一个 Kubernetes 原生的 CD 工具，支持和读取各种 Kubernetes 清单文件，例如 YAML、Ksonnet、Jsonnet、Helm 图表和 Kustomize。它可以跟踪分支、标签的更新，或者在 Git 提交时固定到特定版本的清单。

Argo CD 控制平面由三个主要组件组成：

• 应用控制器
• 接口服务器
• 资料库服务

应用控制器

由于应用程序控制器组件，Argo CD 可以检测 Git 中的更改并与 repo 同步。此功能可以将过时或修改后的目标配置同步到上次批准的 Git 版本。应用程序控制器在 repo 服务创建的本地缓存和 Git 存储库之间同步，因为这是一个资源密集度较低的过程。应用程序控制器还可以配置为在目的地接受代码和配置的直接更改，而无需恢复到 Git 上最后已知的配置。此权限必须仅授予选定的团队资源。进行此直接更改时，它会通知 DevOps 和开发人员有关更新 Git 存储库的配置差异。

接口服务器

API 服务器与 Kubernetes API 服务器一样，是一种将 Kubernetes 和 Argo CD 的组件暴露给 CLI 或 Web GUI 或其他第三方工具等界面的服务。这些 API 主要用于执行应用程序部署和管理、执行任何用户定义的操作的回滚、管理存储在 K8s 秘密中的集群凭据以及执行 RBAC Git webhook 等功能。

资料库服务

访问 Git 存储库对于 Argo CD 来说总是很耗时；每次访问 Git 存储库都将构成拉取请求。因此，这个内部存储库服务使应用程序清单的本地缓存和 Kubernetes 集群上的 Git 存储库成为 Git 存储库的副本。它负责生成和返回有关输入数据的 Kubernetes 清单，如存储库 URL、Git 修订（即分支、标签）、应用程序路径和特定于模板的设置；服务器生成 Kubernetes 清单。