为什么说可观察性是解锁 GitOps 的关键

GitOps 是一种新的软件开发范式，承诺简化和完全自动化软件部署过程。GitOps 不依赖 IT 人员或笨拙的脚本来配置环境，而是将所有环境定义成代码，并通过一致和可预测的方式一起部署环境和应用程序。所有的东西都放在源代码控制系统中，使用的是大多数开发人员都熟悉的工具。

GitOps 承诺可以大幅提升开发人员的生产力。但就像任何新的技术一样，挑战存在于细节之中。GitOps 的一个复杂之处在于确保活动环境的充分可见性，以便确保环境可以与所需的配置保持同步。在本文中，我将解释为什么可观察性对 GitOps 如此重要，以及 GitOps 平台 ArgoCD 是如何解决可观察性问题的。

持续交付 为生产部署准备好环境，只需按下一个按钮就可以部署变更。使用传统的方式，通常是将变更合并到主分支（也就是所谓的推送部署）。

在新的 GitOps 环境中，通过向集中式环境代码库提交变更来触发部署（也就是所谓的拉取部署）。

持续交付负责构建可以部署到生产环境中的工件。这是持续集成（CI）之后的下一步。它准备了一个即将用于部署的软件版本，然后等待团队评估变更并决定是否发布它。

持续部署向前迈进了一步，不需要等待人工评估新版本和按下发布按钮。在持续部署中，每个变更都会被自动测试，如果满足某些预定的质量标准，就会自动部署到生产环境中。

GitOps 模型 要求使用源代码控制系统（通常是基于 Git）进行应用程序和基础设施的配置管理。Git 版本控制系统作为 GitOps 的唯一事实来源。基于这个单一的事实来源，GitOps 使用声明性配置调整生产环境来匹配所需的状态。

GitOps 通过 Git 拉取请求自动管理基础设施的配置和部署。它依赖包含系统完整状态的 Git 代码库来实现对系统状态变更的完整审计跟踪。

GitOps 更强调开发者经验，开发团队可以使用他们熟悉的过程和工具来管理基础设施。GitOps 在选择工具方面提供了几乎全面的灵活性。

使用 GitOps 有很多方面的原因，大多数都与更快、更可靠、更高质量交付软件的能力有关。以下是经常被提及的 GitOps 的好处。

• 提高生产力——GitOps 通过集成反馈循环实现了完全自动化的持续部署，与传统的 CI/CD 管道相比，这缩短了部署时间。DORA 研究小组的 DevOps 状态报告 显示，表现最好的 DevOps 团队有四个特点：高部署频率（DF）、低变更发布时间（MLT）、低恢复服务时间（MTTR）和低变更失败率（CR）。GitOps 可以直接改进这四个指标。

• 改进了开发者体验——在操作 Kubernetes 集群时，GitOps 不需要执行 kubectl 命令。开发人员不必了解和维护 Kubernetes 的内部机制，他们可以使用熟悉的工具（如 Git）声明式地管理 Kubernetes 更新和特性，Kubernetes 集群中的任何操作都是由 GitOps 控制器自动执行的。新加入的开发人员可以更快上手，并在几天（而不是几个月）内提升工作效率，有经验的开发人员可以继续利用他们已掌握的与现有工具相关的知识。

• 提升了稳定性——在 GitOps 工作流中，所有的变更都会自动创建审计日志。这种可审核性提升了稳定性，因为我们可以很容易看到哪些变更导致了生产问题。这还可用于遵循任何必要的标准，如 SOC 2。

• 改进的可靠性和回滚——Git 提供了回滚和 fork 特性，让团队可以实现可靠和可重复的回滚。因为 Git 是集群配置的事实来源，所以团队只有一个可用恢复生产问题的单一来源。这将恢复时间从几小时缩短到了几分钟。

• 一致性和标准化——GitOps 提供了一种通过一致的方式修改基础设施、应用程序和 Kubernetes 插件的模型，提供了跨企业的可见性，并确保所有团队都有一致的端到端工作流。

• 安全保证——Git 可以签署变更并证明作者和来源，还可以提供强大的加密来跟踪和管理变更。这为 Kubernetes 集群的完整性和安全性提供了高度的信任。

在云原生应用程序架构中，传统的监控方法已经达到了极限。现在的焦点正在从监控转移到可观察性。

• 系统监控根据预定义的指标来确定系统的运行状况，从而检测出一组已知的问题。例如，容器监控 旨在回答两个问题：出了什么问题，以及为什么会出问题。随着时间的推移，我们可以通过分析容器在问题发生之前预测和预防问题的发生。

• 可观察性旨在基于三个关键元素（日志、指标和跟踪）来了解系统状态。可观察性是系统的一个特征——就像系统的伸缩性、可靠性或安全性一样，它也可以是可观察的。在云原生环境中，从一开始就应该将可观察性构建到应用程序中。

监控和可观察性紧密相连。可观察的系统更容易被监控。监控是可观察性的一部分，有效的监控是有效的可观察系统所带来的结果。

可观察性通过以下三个主要元素来提供洞见。

1. 日志——提供离散的系统事件的记录。

2. 指标——在设定的时间间隔内度量和处理数值和统计数据。

3. 跟踪——提供事件序列来反映逻辑路径。

这三种类型的洞见为大多数关键问题提供了答案，包括部署的当前状态与预期状态的比较。它们对系统的所有方面——从预期的架构和配置到 UI、资源和行为——来说都很重要。

GitOps 模型强调简化复杂的 Kubernetes 管理任务的能力。其核心概念是通过对集中式 Git 代码库的变更触发生产环境部署，并完全自动化地修改 Kubernetes 集群。

要启用真正的 GitOps 过程，需要两种类型的可观察性。

• 内部可观察性——例如，GitOps 控制器需要知道 Kubernetes 集群中发生了什么，以便与所需的配置进行比较并做出调整。

• 外部可观察性——在集群内外运行的其他系统需要知道 GitOps 系统的自动化工作流。为此，GitOps 系统需要发布能够被云原生监控系统消费的指标。

在 GitOps 过程中，Git 是系统预期状态的唯一事实来源，而可观察性为系统的实际状态提供了唯一事实来源。因此，它可以帮助 GitOps 开发人员了解系统的状态。

例如，如果你打算基于 Git 代码库中的部署清单在集群中运行三个 NGINX pod。GitOps 系统将使用 Kubernetes 控制器来确定实际运行的 pod 数量及其当前的配置。如果它检测到错误的实例数量或对 pod 配置做出了任何修改（这被称为配置漂移），它会创建一个“diff 警报”。

一旦系统感知到发生了漂移（即期望和实际实例数量之间的不匹配），diff 警报可以触发相关的 Kubernetes 控制器。控制器将尝试同步实际状态和期望状态。等到 diff 警报消失，系统就会认为实际状态与期望状态匹配，这意味着应用程序已经“同步”了。

整个过程的关键之处是感知到漂移。如果你不知道系统处于不同步状态，就无法同步或修复状态。因此，内部可观察性对于 GitOps 和确保实际状态保持同步来说是至关重要的。

外部可观察性有三个要素。

• 需要在 Kubernetes 集群中运行监控系统。有一些成熟的工具支持云原生环境——常见的一个选择是 Prometheus。

• 一个根据 Git 配置来修改集群的 GitOps 控制器。

• 由 GitOps 控制器或相关系统发布的指标。

有了这三个元素，监控系统就可以从集群的 GitOps 自动化系统中获取指标，主动通知生态系统的其他部分正在发生哪些变更。换句话说，其他系统会收到应用程序正在同步的“提示”，而不是在回顾时才发现它并产生不必要的警告。

我们将以流行的 GitOps 项目 Argo 为例。

Argo 是一个开源项目集合，帮助开发人员更快、更安全地交付软件。Argo 是 Kubernetes 原生的，这让开发人员可以轻松地部署和发布他们自己的应用程序。

Argo 支持使用高级的渐进式部署策略进行持续部署，开发人员可以定义发布服务所需的一系列操作。

在 GitOps 工作流中，Argo 促进了应用程序的部署和生命周期管理过程。它让开发人员能够无缝地操作环境和基础设施、自动化部署、回滚，并让故障排除变得更容易。

Argo 使用 Kubernetes 清单持续监控 Git 代码库、验证提交、主动从代码库获取变更，并将它们与集群资源进行同步。这个同步协调过程确保集群配置的状态始终与 Git 中描述的状态匹配。

这就是 GitOps 的确切定义——Argo 可以帮助团队在他们现有的 Kubernetes 集群中轻松地实现完整的 GitOps 过程，而不需要改变现有的工作流程。

此外，Argo 还消除了常见的配置漂移问题。当集群中的元素随着时间的推移偏离期望的配置时，就会出现配置漂移。这些意外的配置差异是导致部署失败的一个最常见的原因。Argo 可以自动消除配置漂移，或者至少显示出集群的部署历史，以便识别出漂移并导致漂移的变更。

最后，Argo 旨在为 Kubernetes 开发人员提供更好的体验，让他们能够在轻松应用高级部署策略的同时保持熟悉的用户体验。它被实现为 Kubernetes 自定义资源定义（CRD），这意味着它就像现有的 Kubernetes 对象一样，具有开发人员可以使用的扩展。

总的来说，Argo 让 GitOps 的实施变得更容易，原因如下。

• 更高效的工作流程——开发人员可以使用熟悉的流程和工具部署代码。

• 改进的可靠性和一致性——使用自动化代理来确保 Git 中定义的期望状态与集群的状态相同。

• 提高生产力——完全自动化的 CD 和不复杂的设置。

• 降低了部署的复杂性——部署变成了发生在幕后的透明的过程。

• 渐进式交付——在传统设置中，设置蓝 / 绿或金丝雀部署等策略非常困难，而这些在 Argo 中都是现成的。

• 预同步（Pre-sync）——检查变更是否有效，是否需要对集群做出修改；

• 同步（Sync）——对集群做出修改；

• 后同步（Post-sync）——验证修改是否正确。

这个过程包含了一次或多次对整个集群进行走查，找到漂移，并对漂移做出反应。每一次走查中的资源的顺序是按照类型（命名空间，然后是 Kubernetes 资源，然后是自定义资源）和名称来决定的。

在每一波走查中，如果有任何资源不同步，Argo CD 将对其进行调整，然后继续扫描集群。请注意，如果第一波走查中的资源不正常，则应用程序可能无法成功同步。

Argo CD 在每一波同步走查之间会有延迟，以便让其他控制器有机会对变化做出反应。这也防止 Argo CD 在更新以反映当前对象状态之前过快地评估资源运行状况。

Argo CD 提供了通知功能，让你可以持续监控 Argo CD 应用程序，并接收有关应用程序状态发生重大变化的警报。它提供了一种灵活的使用模板和触发器设置通知的方式——你可以定义通知的内容以及 Argo CD 应该何时发送通知。

Argo 的另一部分是 Argo Workflows，它让你可以自动化 Kubernetes 集群中与 CI/CD 管道相关的任务。Argo Workflows 可以生成几个默认的控制器指标，你也可以定义自定义指标来提供与工作流状态有关的信息。

Argo Workflows 可以生成两种类型的指标。

• 控制器指标——提供与控制器状态有关的信息。

• 自定义指标——提供与工作流状态有关的信息。你可以使用工作流规范定义自定义指标。指标生成器的所有者负责生成自定义指标。

例如，你可以定义自定义的 Prometheus 指标，并在工作流或模板级别应用它们。这些指标在各种情况下都很有用。

• 强制应用阈值——跟踪你的模板或工作流的持续时间，并在它们超过阈值时收到警报。

• 跟踪故障——查看你的模板或工作流在特定时间内发生故障的频率。

• 指标报告——为内部指标设置报告，如模型训练分数和错误率。

GitOps 正逐渐成为主流的开发实践。我解释了为什么可观察性是 GitOps 系统不可分割的一部分，并描述了两种类型的可观察性。

• 内部可观察性——GitOps 控制器需要识别集群中的配置漂移并纠正它们。

• 外部可观察性——需要将 GitOps 控制器所做的变更通知给运维人员和其他系统。

我还简要地展示了如何在一个流行的开源 GitOps 平台——Argo 中实现这两者。

GitOps 基于几种复杂的机制，了解它们的最好方法是使用 Argo CD 进行一次测试。也可以参考官方 入门教程，它展示了如何安装 Argo CD 以及将一个小应用程序部署到 Kubernetes 集群中。尝试“搞乱”你的测试集群，看看 Argo 如何获取变更并将集群恢复到你想要的状态。

要更深入地了解 Argo CD 同步过程，请参阅官方文档中关于 同步阶段和同步波 的介绍。

Gilad David Maayan 是一名技术作家，曾与 150 多家技术公司合作，包括 SAP、Imperva、Samsung NEXT、NetApp 和 Check Point，为开发人员和 IT 管理者提供与技术和思想领导力相关的内容。

原文链接：

https://www.infoq.com/articles/observability-gitops/

相关阅读：

GitOps 多环境部署问题及解决方案(https://xie.infoq.cn/article/c9922fd7a3ff219807e0863d0)

To B 企业云原生持续交付的探索实践(https://www.infoq.cn/article/YxiiqTH4UM8lxt96Xvs7)