没有GitOps的大规模Kubernetes是个坏主意

随着Kubernetes环境开始扩展，跨多个环境或多个云一致管理集群配置会变得困难。不同团队部署的集群在节点大小、自动缩放、网络或RBAC策略方面可能不会（至少在最初）满足或共享相同的配置，而这些对于整体治理和安全性很重要。因此，所需的集群配置无法在不同的集群之间完全复制。当然，在不同集群扩展时手动识别漂移并保持一致性不是一个可行的选择。

DevOps团队应该能够通过一组描述集群所需状态的策略管理模板来解决这些一致性挑战。这些模板应该允许DevOps团队为集群创建基于标准的定义，然后通过一个界面，以最小的工作量在所有集群中复制它们。

本文将描述企业在大规模部署Kubernetes集群时面临的问题和挑战。我们还描述了GitOps流程和工具如何让组织在改进安全性和合规性最佳实践的同时，获得对这些高度分布式环境的适当控制。

管理挑战和集群蔓延

向虚拟化的转变带来了虚拟机蔓延的问题，部署的虚拟机数量太多，无法对虚拟机进行有效管理。容器化和Kubernetes的广泛使用也造成了类似问题。

现在，由于大型分布式团队跨本地工作站、数据中心、公共云、边缘站点提供多个Kubernetes集群，有时在终端客户站点的内部部署，企业通常必须应对集群和工作负载蔓延的混乱环境。

用Kubernetes环境的企业IT必须确保内部和现场团队启动的集群符合策略。为面向最终用户的应用程序部署创建的集群必须特别小心地进行监控，不得偏离所需的配置。然而，集群的蔓延和云原生基础设施的碎片化使得执行全球策略变得尤其困难。

配置蔓延

Kubernetes以其声明性API而闻名：集群中的每个组件，从配置设置到应用程序，无论多么小，都是通过名为resource的配置片段进行配置的，通常表示为YAML文件。这意味着，完整地描述和配置集群可能需要创建和维护几十个或数百个不同的资源，从而导致管理噩梦。过多的工具会在这些资源上引入额外的抽象和功能（例如模板），比如Jsonnet、Helm和Kustomize，可能会加剧这个问题。

宠物集群

回到虚拟化时代，拥有“宠物”虚拟机（难以升级或维护的大型单体虚拟机，并造成容错瓶颈）是不可避免的。Kubernetes和容器领域也出现了类似的问题：随着企业开始大规模部署集群，拥有几个大型“宠物”集群成为一个常见问题。这些集群有时可能有多达1200个节点。

这种规模的集群必须分成多个节点组，每个节点组都需要自己的管理和维护。随着集群节点数量的增加，集成到集群中的CNI插件和其他解决方案可能开始出现故障或运行到意外行为。一个更好的解决方案是拥有大量小型集群，每个集群都是为一个用例而专门构建的，然后拥有更好的整体自动化来大规模管理集群。这解决了必须管理宠物集群的问题，但反过来又产生了必须管理大量集群的新问题。这就是GitOps风格的自动化能够真正增加价值的地方。

Kubernetes的理想状态管理

Kubernetes最大的优点之一是它的声明性系统，可以处理在其范围内运行的所有应用程序所需的状态管理。当删除属于复制集的Kubernetes pod时，Kubernetes控制器会将正在运行的pod数量与pod部署规范进行比较。一个新的pod会自动安排以保持所需数量的副本。控制器监督所有Kubernetes资源的生命周期，如部署、状态集、作业等。

在幕后，工作负载状态在etcd中维护，etcd是Kubernetes的默认键值数据库，它是部署在集群上的资源配置的唯一真实来源。etcd数据库维护工作负载的配置定义和当前状态。如果出现差异，kube controller manager负责重新创建与原始定义匹配的资源。

但是，默认情况下，Kubernetes没有一种机制来监视集群本身及其属性的更改，并自动协调状态。例如，如果删除了整个命名空间，Kubernetes不会重新创建命名空间或其中的对象。Kubernetes的这个缺点就是GitOps出现的原因。

用于有效集群管理的GitOps

GitOps是一个操作框架，其中使用源代码管理和CI/CD的中央存储库，采用关于版本控制和源代码管理的标准开发最佳实践，并将其扩展到基础设施的管理。

在多云和多集群环境中，GitOps可以是一个非常有价值和有效的过程，用于自动化Kubernetes集群和周围基础设施的配置管理、部署、更新和策略管理。

当使用GitOps原则大规模运维集群时，DevOps团队没有在用户的工作站、客户站点、开发/测试/生产环境中手工构建集群，而是将一组集群资源标准化为YAML、Kustomize或Helm（或其组合），这些资源可以分组为“模板”；每个模板捕获特定类型集群所需的状态属性。所需的状态属性可以是关于集群的形状和大小、主节点和工作节点的数量、要在集群中部署的附加组件、要实施的网络和安全策略等。模板存储在Git存储库中的一个专用存储库中，所有配置都存储在该存储库中。对模板的任何更新都会进行版本控制，这从治理和合规性的角度来看很有帮助。

灵活执行

只有当有一个执行引擎可以确保集群的实际状态始终与Git中描述的所需状态一致时，使用模板来捕获集群的所需状态才有用。强制引擎应该允许使用模板中描述的属性创建新集群，并修复现有集群以遵守模板。

让我们以大规模Kubernetes集群上的RBAC策略管理为例，说明如何在Kubernetes世界中实现有效的基于模板的管理和实施。

Kubernetes的一个好处是能够使用一个简单的命令行工具——kubectl来大规模配置和管理集群。然而，让所有的开发和运维团队成员——从自由开发者到CTO——访问kubectl来管理集群并不是一个理想的方案。理想的情况是有一个易于使用的机制来为不同集群的用户配置RBAC策略，从而精确定义他们的访问级别。

然而，默认情况下，管理Kubernetes RBAC策略非常复杂。Kubernetes迫使用户筛选编辑和更新各种YAML文件的复杂性，以正确配置和更新RBAC策略。许多（如果不是大多数的话）商业Kubernetes解决方案都没有提供一种替代方案来简化大规模的流程。

上面描述的GitOps风格的模型可以大大简化这个过程。在这个模型中，DevOps SRE工程师定义了一个或多个“RBAC模板”，用于捕获Kubernetes用户角色和命名空间或集群范围内的角色绑定。RBAC模板一旦定义，就可以应用于一个或多个集群，为一组用户授予对这些集群的适当访问级别。

“RBAC模板”以声明的方式以不变的方式存储在Git存储库中，而不强制用户访问YAML文件。一旦执行引擎被指示将集群与存储库（通常是存储库中的路径）关联，存储库路径的内容将定义RBAC设置的“真相来源”，然后定期同步，以确保随着时间的推移继续执行这些设置。

一个合适的系统不仅必须强制执行一个新的基本状态，而且还应该能够在提交的请求被批准并合并到所需状态之前对其进行测试。在Git上达到最终不变状态的过程是迭代的，并且保持灵活性，因此它不仅执行策略，而且促进了更改。它还应该对Git和集群上的所有合并请求和更改提供完整的审计跟踪——这是Git的优点之一。

不要漂移

能够轻松无缝地审核对集群所做的更改，这些更改可能与Git存储库上的配置不同，这一点非常关键，称为“漂移”。如上所述，一个正确实现的模板系统应该提供“漂移分析”，系统可以通过一个命令确定并报告与部署的集群以及模板中捕获的所需状态是否存在差异。根据变更的严重性和重要性，当向相关Ops所有者做出变更时，应发出警报。

对于Flux或Argo CD，当Kubernetes中的特定对象发生变化时，可能会发生漂移——无论是管理员无意中更改的，还是在网络攻击过程中更改的。集群配置策略和其他设置已被覆盖（而不是在GitHub上手动更改，然后在集群级别更改）。

因此，所有的更改都应该首先在Git中进行，然后才能投入生产，这样Git上的配置和集群中的配置就可以保持一致。Git的状态代表着不变的“单一真相来源”，也是云原生安全和合规性的一个主要组成部分。

该过程不应该涉及逐行手动检查，以确定声明定义的和正在运行的资源是否不同。如果发生漂移，应自动识别对集群所做的更改。集群配置将不再符合Git中定义的状态，因此使用正确的工具，可以自动识别补救更改并将其应用于集群，同时发送警报。换句话说，配置中的漂移应该始终是明显的，并且是系统的重要方面。

起点

可以手动手工制作和管理单个或少量集群的配置。然而，当试图以一致的方式手动管理10个或更多Kubernetes集群时，困难变得明显，尤其是当单个集群较大时。

可以说，如果没有GitOps工具和流程，一个小型DevOps团队试图管理多集群环境是不可行的，GitOps工具和流程是大规模集群配置管理和实施的基础。从长远来看，一个多集群环境可以很容易地由50多个命名空间和多个团队访问的数不清的微服务组成。

如上所述，GitOps工具和流程已成为解决大规模部署集群时组织面临的许多管理、安全、合规性和其他挑战的最终途径。通过帮助消除“宠物集群”、漂移、集群蔓延、缺乏集中控制、缺乏标准化，以及其他快速消耗DevOps资源和sap生产力的问题，GitOps成为了一个必要的运维框架。GitOps为CI/CD提供的以Git为中心的管理和集中控制还可以通过自动化许多操作甚至开发人员团队成员本应负责的任务来提高生产率。

可以说，作为一个框架，GitOps可以用来实现Kubernetes最初创建的目的：为部署在多个高度分布式容器化环境中的应用程序提供显著的计算优势、资源节约和兼容性。

原文链接：

https://thenewstack.io/kubernetes-at-scale-without-gitops-is-a-bad-idea/