知无涯

我们将创建一个名为argocd-proj.yaml的新文件，并将其存储在与argo-app.yaml文件（这些文件也可以在我们的官方回购中找到，网址为https://github.com/PacktPublishing/ArgoCD在ch04/kustomize安装中的实践文件夹）。为了展示如何项目与其令牌一起使用，我们将创建一个新项目并将其用于现有的argocd应用一旦我们有了它，我们将需要为项目创建一个角色，为角色，并创建一个令牌。现在，我们将创建一个单独的本地帐户，只具有指定的apiKey功能。

在本章中，我们将探讨如何设置用户访问Argo CD的权限，以及从终端或CI/CD管道连接CLI的选项，以及如何执行基于角色的访问控制。我们将查看单点登录（SSO）选项，通常这是一个需要付费的功能，但由于Argo CD完全开源且没有商业提供，因此您可以直接使用。我们将涵盖的主要主题如下：• 声明式用户• 服务账户• 单点登录。

我们通过安装Argo CD开始了这一章。我们选择了一个由云提供商管理的集群，因为我们需要更多的节点来试验HA部署。我们体验了Argo CD如何更新自己，以及如何对安装进行配置更改。虽然生产Kubernetes集群具有高度可用性，并且云提供商将为我们管理它，但仍然存在可能发生灾难的场景，因此我们需要有一个可工作的灾难恢复策略。我们看到了如何创建Argo CD状态的备份，然后在一个新的集群中恢复它。

这一部分介绍了核心概念，并讨论了如何将Argo CD作为SRE进行操作。

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

几年来，我们大多数人都在应用程序中使用相同的独立类型的环境，这些环境分为开发、测试、准备和生产。在Kubernetes中表示这些集群的方式在很多方面都有所不同，并且取决于许多其他因素，例如团队的规模和预算。其中一个因素可能是每个环境中的不同集群，也可能是通过名称空间在一个集群中进行分隔。在任何情况下，我们都会使用必要的部署资源为应用程序创建新的命名空间，并添加为环境配置应用程序所需的任何内容（配置项、密钥、入口等）。上述方法的缺点是随着时间的推移会存在配置漂移。

本章介绍了GitOps的含义以及Kubernetes的哪些部分使其成为可能。我们检查了API服务器如何连接一切以及控制器如何工作，介绍了其中的一些控制器，并解释了它们如何在无穷无尽的控制循环中对状态变化做出反应。我们仔细研究了Kubernetes的声明性特性，从命令命令开始，然后打开路径，不仅应用文件夹，还应用Git存储库。在中，我们实现了一个非常简单的控制器，让你可以了解Argo CD的功能。在下一章中，我们将开始探索Argo CD、其工作原理、概念和架构，以及有关同步原理的详细信息。

GitOps一词是在2017年由Weaveworks的人创造的，他们也是名为Flux的GitOps工具的作者。从那以后，我看到了GitOps是如何成为一个流行词的，直到被命为development-operations(DevOps)之后的下一个重要事物。如果你搜索定义和解释，你会发很多：它被定义为通过 pull requests（PRs）进行操作()，或者采用开发实践（版本控制、协作、合规、持续集成/持续部署（CI/CD）),并将其运用于基础设施自动化。不过，我认为有一个定义很突出。