GitOps：一款基于Kubernetes的高速CI/CD框架

“把世界设想成一套代码库，而非Kubernetes环境。”

——Kelsey Hightower

这篇文章主要面向希望使用Kubernetes和Docker进行高速持续交付的用户而言。当我们提到“高速”时，我们的意思是每个产品团队可以安全地每天多次交付更新 ——包括即时部署，实时观察结果，并通过反馈进行推进或者回滚。其目标，是让产品团队尽可能快地通过持续实验来改善客户体验。

如果您还不熟悉GitOps，这是一套可以对现代应用程序进行敏捷化软件生命周期管理的框架。感兴趣的朋友可以通过阅读我们的系列博文了解更多，今天让我们从《Gitops——Pull Request的操作[1]》开始。

用户案例：高速CI/CD改变游戏规则

一个团队如何从每周一次手动部署提升到每天超过三十次的无需额外工作的部署？

Qordoba是一支来自旧金山的团队，他们利用机器学习技术为各大国际品牌交付经过优化的本地服务。他们的一个团队正在使用基于Kubernetes的微服务作为Qordoba后端的一部分。通过采用我们推荐的GitOps实践与工具，他们从根本上提高了自身塑造用户体验的能力：

修复生产环境软件错误所需的预计时间：使用Weave Cloud后，所需时间缩短60％
响应客户请求的预计时间：使用Weave Cloud后，时间缩短约43％
正常运行时间从99％提升到100％（到目前为止……）

Qordoba从每周部署1或2次提升到了每天部署超过30次。更重要的是，每一项部署实质上都是“零成本”的。这意味着：其需要的时间很短，不致中途中断并导致团队无法将系统恢复至良好状态，且所有变更皆可实现回滚。零成本部署解放了开发团队，让他们专注于用户体验和业务逻辑——即真正能够创造价值的工作，并按照自己适应的速度进行迭代，且无需担心失败成本。

了解更多：GitOps介绍资料

我在KubeCon 2017上和Google的项目经理William Denniss共同演示了这个用例。

一些背景：Weaveworks已经在AWS上拥有长达两年的生产环境的Kubernetes云服务运行周期。最近我们总结了一些最佳实践，我们称之为“GitOps”[2]。 GitOps基于经过验证的DevOps技术——大体类似于CI/CD和声明式基础设施即代码——而构建，为Kubernetes应用程序提供了一套联合的、可自动生成的生命周期框架。我们在KubeCon上和Google Cloud Platform一起推出了“免费”的GitOps功能[3]。

如果您有兴趣了解我们是如何做到这一点的，例如创建一条高速CI/CD流水线，那么我建议您查看这个演示文稿（视频[4]和幻灯片[5]）。

KubeCon是一项社区活动，所以在本演讲中，William和我谈论了解决方案的模式、Kubernetes部署运维工程师的技术角色以及其它与之配合的开源项目。

即时Kubernetes CI/CD与Weave Cloud

如果你喜欢这个演示文稿以及GitOps的创意，那么你可能会打算新手上手一试。最便捷的方式当然是通过由Google上提供的Weave Cloud设置。

这些会让你获得：

一条可以在几分钟内搭建的Kubernetes流水线
一键部署的应用（当然，如果有必要仍然需要手动分段）
全面的可观察性、仪表板与警报

Weave Cloud可以轻松将您的Git存储库接入至任何CI。其为CI/CD建立一套Kubernetes集群，以便您可以从之前提到的Qordoba持续与高速交付中受益。在Google云上，您的GKE群集可以轻松连接到Google的容器构建器和存储库。但我们希望再次强调：Weave Cloud可以与任何集群、任何网络、任何CI以及任何Git库协同工作——我们不会强迫你选择自己不喜欢的道路。

有鉴于此，您可以通过Git PR、CLI或GUI对应用程序进行更新和回滚。最后，我们提供集成化“全栈式”监控和管理，以完成运整个操作循环。 Weave提供的集成方案意味着开发人员可以观察部署情况，从而衡量并应对各类变化及其产生的影响。下图所示为一套示例UI。

开源GitOps

我们的云服务为利用Kubernetes实现GitOps提供了一种方便且令人满意的方式。但是如果你是一位希望建立并了解自己开源流水线的开发者呢？请阅读下面的内容来了解可供选择的一些GitOps方法。

方法1——使用Weave Flux部署Operator

我们建议您使用Operator模式来监听和编排部署到您Kubernetes集群中的服务。William Denniss在我们KubeCon演示资料的第15-21页中描述了这种方法。使用Operator，代理可以代表集群来监听与自定义资源变更相关的事件，并通过一致性方式加以应用。换句话说，Operator负责执行Git和集群之间的协调工作。

Operator是由Weave Flux这个开源项目实现的。这个项目的诞生，源自我们为了简化Weave Cloud将微服务部署到Kubernetes而作出的大量痛苦尝试。请参阅这篇博客文章《GitOps管道》[6]，文中阐述了编排部署相较于通过CI+脚本（“CI操作”）手工编写代码的种种优势。

Flux被应用于我们的Weave Cloud服务。我们建议你在云端加以尝试或自行探索设置方法。我们同样欢迎外部的开源代码贡献者和对Flux感兴趣的公司参与项目当中。多种CI和部署工具都能够通过部署Operator受益——请与我们联系。

方法2——GitOps，Kelsey方法的实现基础

Kelsey Hightower有一个非常好的习惯，即提供简单但始终以开发人员为关注重点的精彩演示。他在KubeCon的主题演讲自然也不例外。

Kelsey的演讲主要探讨如何使用Github和Google Cloud进行持续交付，而其出发点为“kubectl就是新的SSH……如果您正在使用kubectl从笔记本电脑部署软件到生产环境，那么您已经错失了几项重要步骤……”。接下来他提供了一个demo，展示了如何通过CI与分段实现从Git到生产环境的直观仪表板实现步骤。这些步骤简洁直观且干货满满，我建议观看他演讲的视频[7]。

Kelsey的分析建立在两个前提上：

Kubernetes的部署未能完全解决问题。他说：“有多少人拥有端到端的连续交付流水线？”一旦决定使用kubernetes，这将成为一个可望而不可及的目标……并导致你投入大量时间。”
开发人员希望通过Git来驱动变更，并观察结果。他说：“在理想情况下，如果我变更了代码，肯定希望单纯通过一条URL来告诉我它在哪里运行……如果你能给我度量指标，告诉我它运行得如何，那肯定更好。最好的结果是，你能够给予可见性，用户就不会再怀疑像kubectl这样的工具是否真像你宣传的那么好——因为现在他们已经能够实际观察到集群中发生了什么。”

这与我们在GitOps上希望达到的目标大致相同。其中的关键在于，将Git视为您技术堆栈中所有状态的理想来源——包括集群、配置，应用程序和工具——并配合使用声明式基础设施即代码。请阅读我们的第一篇博客文章《Pull Request的操作[8]》了解更多详情。

选择你的GitOps探索之旅

在这篇文章中，我们提供了三种尝试高速CI/CD的方法。

一项开箱即用的服务，使用Weave Cloud提供的从Git到GKE集群的默认CI/CD流水线，包括监控、可观察性、审计和功能，且支持弹性伸缩。这项服务也适用于其他Kubernetes供应方案及您自己的CI。
引入Weave Flux，我们在第1条中也需要使用到这款独立且开源的部署执行程序。其能够运行您所使用的任何Kubernetes集群。
Kelsey演示了如何设置自己的简单GitHub-to-Google流水线。

这三种方法在实际效果上完全一致。下面我们来具体作出比较。

Weave Cloud服务最易于上手，因为它为您设置了GitOps流水线，并且包含对GitOps可观察性的大量支持，这本身就是一个重要的问题。借用Kelsey的原话——我们希望“让人们看到……实现目标的最好办法就是为人们提供一套仪表板，借此展示实际发生的状况”。

Weave Flux开源Operator只聚焦于CI/CD中的“CD”部分。通过使用Flux，用户将可以对发布工作流程进行大规模重复与管理——且实现难度要比使用“kubectl”或将脚本捆绑到CI工具上容易得多。 Flux是一种协调与通知代理，能够“与本地Kubernetes交互”，以便对任何Kubernetes对象进行集群变更，包括实现对同步代码、配置文件、容器、标签等的更改。您还可以获得诸如“回滚”，“自动”，“手动”部署等策略（还有更多，例如蓝/绿和金丝雀部署等）。

Kelsey的方法当然也可以进一步分解成更小的部分。他提供了从Git到CI到GKE的集成示例，但并没有提到像Flux Operator这样的程序化代理。将Kelsey的方法与Flux结合起来显然是种合乎逻辑的作法。事实上，我们的KubeCon演示文稿在第21页就展示了这种集成方法：

还要注意的是，Kelsey建议在他的演示中使用一套精心设计的仪表板——Grafana。我们对此深表赞同，并在我们的云服务中也提供这样的工具——同时还集成有Slack。

隐私问题如何解决？

这是迄今为止关于GitOps最常问到的问题。

好消息是，我们在Bitnami的朋友创建了一个专门用于GitOps工作流程的Sealed Secrets开源项目[9]。 Sealed Secrets是一款定制化Kubernetes资源定义控制器，它甚至允许您在Git中存储敏感信息（即secrets）——这在以前是完全无法想象的。另请参阅《构建Serverless应用程序流水线[10]》，由同样参加了KubeCon大会、来自Bitnami公司的Sebastien Goasguen提供。

另外，您可以将Weave Cloud的部署功能与Sealed Secrets结合使用，从而创建一套连续的部署流水线——其中所有操作皆基于Git实现，且您应用程序的全部所需状态都会在Git仓库中声明，包括您的隐私。

Helm效果如何？

Helm charts是一种将复杂Kubernetes应用程序打包并进行原子部署的好方法。要了解更多关于Helm的信息，我推荐Vic Iglesias带来的这段很酷的KubeCon谈话[11]。

我们正在努力将Helm charts作为GitOps工作流程中的首要对象。这是一个非常令人兴奋的想法：它结合了Helm的好处，即“chart”封装与模板；外加GitOps本身的好处，其中包括：各版本部署历史记录，用于帮助重新创建集群; 实现集群状态更新自动化以反映charts及其自定义更新；以及通过集群状态更新自动化以反映容器镜像的开启等等：）