必须得谈谈Kubernetes GitOps

GitOps是Kubernetes崛起期间发生的最具影响力的进化之一。当我们发现GitOps时，我们已经建立了第一个即时云原生平台一年多了。这毁了我们。我们决定放弃一堆工作，重新开始新的GitOps规程，这是正确的选择。

在一个微服务和微产品在整个平台生态系统中层出不穷的世界中，随着时间的推移，管理这些数十个、数百个、很快数千个微组件变得越来越困难。但是GitOps能够通过简单的git存储库的一个分支和一些描述所部署内容的文件，将所有这些恢复到控制之下。

让我们一起探索Kubernetes GitOps。

GitOps不是什么

当第一次看到GitOps这个术语时，许多人认为这是他们已经在做的事情。如果你使用git，这会自动驱动你的DevOps管道——这就是GitOps，对吗？显然不是。

以下是一些你并没有执行GitOps的指标：

——如果你没有使用Kubernetes，你很可能不会使用GitOps。

——如果你正在使用Kubernetes，但有一个包含命令kubectl apply或helm install（或任何其他“将此推到Kubernete”脚本或“同步所有内容”任务）的交付管道，那么你正在做GitOps的前身，最近被称为ScriptOps。

——如果你使用Kubernetes，但手动运行kubectl apply或helm install来向集群交付内容，那么你就是在执行ClickOps（即使是命令）。

——即使你登录Argo CD并使用UI将应用程序指向git目录，该UI活动也是ClickOps操作，在执行GitOps时也应避免。ClickOps可能只能在短暂的技术高峰环境中进行。

GitOps是什么

GitOps将你的git provider与Kubernetes引擎相结合，并作为所需状态（托管在git中）的应用程序控制平面。如果设置正确，GitOps商店可以在git存储库的一个主分支中建立整个组织中所有Kubernetes资源的注册表。

在考虑GitOps时，最好设想一堵无法穿透的墙，将CI（自动化管道）与CD（交付）隔开，而这道屏障就是GitOps的主要分支。作为一名工程师，持续交付（CD）将不再是你的责任；这是CD引擎的工作。你在持续集成（CI）中唯一的交付角色是建立所需的状态。

为什么应该用GitOps#gitpuns

架构简单性

Kubernetes操作是通过以YAML格式向Kubernete提供所需内容来执行的。

Git非常擅长对YAML等平面文件的分布式系统进行版本控制，并跟踪它们何时更改以及为什么更改。

当你添加了一个GitOps引擎，它可以从git中提取所需的状态，将其应用到集群，并在无休止的协调循环中报告同步状态，它会产生一个强大而简单的架构，它植根于工程师已经在使用的经验证的分布式技术。

可发现性

Kubernetes资产管理的GitOps方法以及如何在集群中扩展应用程序优于任何其他方法。一个好的GitOps工程师可以走进一个新的GitOps环境，并几乎立即产生影响。

该规程允许你在单个git存储库的单个主分支中注册表示为YAML文件的应用程序树。如果你以这种方式引导集群，那么熟悉GitOps的任何人都将能够遵循该树并发现所有所需的状态，并且已经知道内容是如何交付的。

由于集群注册表的可发现性，GitOps工程师将成为组织中最有价值的成员之一，也是最可替换的成员之一。

这应该能让人感觉到GitOps注册表应该是什么样子：https://github.com/kubefirst/GitOps-template/tree/1.10.9/registry

安全

CI工具是不良行为者的常见攻击工具。使用GitOps，CI工具不需要访问集群。相反，集群将使用到GitOps git存储库的只读连接来获取其部署和配置。保护git存储库成为一个新的游戏，它更容易管理，特别是如果你在Terraform中管理git存储。

系统审核日志

如果你的基础设施的每一项更改都是由于单个存储库中的一个拉取请求而应用的，那么应用的拉取请求的历史记录就是所发生的所有事情的审计日志，以及谁批准了它以及git自己提供的所有其他内容。对于工程师来说，这是一个比ScriptOps组织通常提供的更方便的过程。

回滚

在git中托管声明的所需状态的另一个优点是，它能够回滚任何引入的问题，在许多情况下，只需在GitOps存储库中恢复有问题的提交。这是一项简单的工程技能，现在可以解决一些大问题。

灾难恢复

如果你的集群总是从单个git repo注册表获取并同步应用程序，那么替换该集群就像将新集群指向同一个注册表点一样简单，它将使自己成为同一个集群。主机名和流量并发在这些细节中有一些麻烦的地方，但这是作为GitOps管理员的目标之一。

如果你手动删除Kubernetes中的部署，并且它是GitOps的一部分，它会立即返回。GitOps存储库主分支源将不断尝试成为实际状态，而无需任何脚本作业。这是保持高服务可用性的最佳姿势。

GitOps的工作原理

Git存储库

你需要创建一个GitOps存储库，其中包含一个可以注册集群的文件夹。对于单个集群，你可以将此文件夹称为“注册表”。

GitOps引擎

GitOps通过在Kubernetes集群中放置Argo CD或Flux CD等GitOps引擎来工作。你需要将引擎配置为只读访问GitOps git存储库。当你安装这个GitOps引擎时，你会将它指向这个目录，以便将你的集群与应用程序结合起来。

GitOps架构决策

一旦你配置了管理集群（一个管理和编排管理系统和基础设施的集中集群），你就有了一个GitOps架构决策，来决定运行应用程序的工作负载集群（生产集群、预处理器等），以及它们应该各自拥有自己的GitOps引擎还是使用管理集群的引擎。

分布式GitOps架构

分布式GitOps架构（有时称为引导或独立）是唯一一种防止管理集群需要访问生产集群的模型。对于具有更高安全要求或受制于合规性边界的组织，这是一种理想的姿态。

分布式GitOps架构要求每个工作负载集群都有自己的Argo CD专用实例。如果在Argo CD实例中实现了单点登录，这对管理员来说不会是很大的负担。

这种模式还将Argo CD上的资源需求分配给每个集群，使其能够在整个生态系统中横向扩展GitOps计算。调整GitOps引擎本身时，较小的爆炸半径也是一个很好的好处。

集中式GitOps架构

一些组织采用集中的GitOps架构，其中管理集群Argo CD实例可以推送访问，以将所需状态强制到下游工作负载集群。该架构允许从一个Argo CD实例查看所有环境的应用程序，这在许多方面都很方便，这使得GitOps模板化技术（如ApplicationSet）得以应用。

在GitOps中提取秘密

如果所有系统都是用git声明性定义的，那么如何处理秘密？外部秘密operator可能是解决此问题的最佳工具。它提供了一个自定义资源定义（CRD），允许定义映射到选择的秘密工具（如Hashicorp Vault或云秘密存储）的外部秘密资源。这允许你在git中引用秘密，而不需要将它们放在那里。

自动化CI管道中的GitOps交付

要将应用程序交付到CI管道中的环境，只需更新表示GitOps存储库中应用程序实例的YAML文件。这就是“所需状态”这个词的真正含义。它是一个文件夹中的文件，你可以在其中定义Kubernetes中应该包含的内容。

选择GitOps技术

在设计新的Kubernetes平台时，选择正确的GitOps驱动程序是最重要的架构决策之一。OpenGitOps提供了一套原则，以供应商不可知的方式定义GitOps规程，以帮助指导您完成决策过程。