关于kubernetes:GitOps初阶指南将DevOps扩展至K8S

1次阅读

共计 3624 个字符，预计需要花费 10 分钟才能阅读完成。

本文转自 Rancher Labs

在过来十年的编程中，呈现了一些革命性的转变。其中之一是源于围绕 DevOps 的实际，它将开发和运维团队整合到一个共享的工作流程中，此外还有继续集成和继续交付（CI/CD），通过 CI/CD，Devops 团队能够向代码库提供继续的更新。另一个改革来自于从单体代码库到基于云的微服务的迁徙，这些微服务运行在由 Kubernetes 等编排平台治理的容器中。

即便有 Kubernetes 这样的平台来编排协调，在集群零碎或云端运行的基于容器的应用程序仍旧可能是简单的、难以调配和治理的。GitOps 是一套新兴的实际，旨在通过利用 Devops 和 CI/CD 世界的技术来简化这一治理工作。

GitOps 的要害是基础设施即代码（IaC）的理念，它采纳与 DevOps 用于提供应用程序一样的办法来提供基础设施。所以，不仅是利用，还有底层的主机和网络都被形容在文件中，这些文件能够像版本控制系统中的其余代码一样，而后由自动化流程来将事实世界的利用与这些文件中形容的利用进行交融。

用 GitOps 的说法，版本控制系统中的代码是对于利用在生产中应该是什么样子的惟一假相起源（single source of truth）。

Weaveworks 是在 GitOps 概念遍及方面奉献最大的公司。稍后咱们会具体介绍 Weaveworks 在其中表演的角色，但首先，咱们先来看看该公司对 GitOps 的定义，它有两个方面：

Kubernetes 和其余云原生技术的运维模式，为对立部署、治理和监控容器化集群和利用提供了一套最佳实际。
GitOps 是一条通往治理利用的开发者体验之路；在这里，端到端的 CI/CD 流水线和 Git workflow 能够同时利用于运维和开发。

换句话说，GitOps 是一套特定的实际，旨在治理 Kubernetes 和相似的平台。随着越来越多的开发团队采纳 DevOps 实际，并将代码迁徙到云端，GitOps 也将会适宜更宽泛的利用。但要理解 GitOps 的秘诀和它所能解决的问题，咱们须要谈谈它的组成部分。

在 GitOps 中 Git 指的是由 Linus Torvalds 在 2005 年开发的极为风行的分布式版本控制系统。Git 是一个工具，它容许开发者团队在一个利用程序代码库上独特工作，存储各种代码分支，在将它们合并到生产代码之前，他们能够对这些代码进行修补。Git 的一个要害概念是拉取申请，即开发人员正式要求将他们正在编写的一些代码整合到代码库的另一个分支中。

Git 拉取申请为团队成员提供了一个合作和探讨的机会，而后再就是否应该将新代码增加到应用程序中达成共识。Git 还会存储旧版本的代码，如果出了问题，能够很容易地回滚到上一个好的版本，并能够让你疾速查看两次批改之间的变动。Git 最为人所知的局部可能是作为 GitHub 这一云端托管版本控制系统的底层，但 Git 自身也是一个开源软件，能够部署在任何中央，无论是公司外部的服务器还是你的 PC。

须要留神的是，尽管咱们通常认为 Git 是一个计算机编程工具，但实际上取决于你如何应用它。Git 很乐意将任何文本文件作为你的“代码库”，例如，它能够被作者用来记录单干作品的编辑状况。这一点很重要，因为 GitOps 的外围代码库大多由申明式配置文件而非可执行代码组成。

在咱们持续之前，最初要强调一件事—— 只管名字中就有“Git”，但 GitOps 实际上并不必要应用 Git。 曾经投入使用其余版本控制软件（如 Subversion）的团队也能够实现 GitOps。但在 Devops 畛域，Git 被宽泛用于实现 CI/CD，所以大多数 GitOps 我的项目最终都会应用 Git。

对于 CI/CD 的残缺解释其实不在本文探讨的范畴内，然而因为 CI/CD 是 GitOps 工作的外围，因而咱们须要对其进行简略的介绍。CI/CD 中的一半继续集成是由版本控制仓库（如 Git）实现的。开发者能够对代码库进行继续的小改良，而不是每隔几个月或几年就推出微小的、繁多的新版本。继续部署这一块是通过被称为流水线（pipeline）的自动化零碎来实现的，这些流水线能够构建、测试和部署新的代码到生产中。

同样，咱们在这里始终在议论代码，这通常会让人联想到用 C 语言、Java 或 JavaScript 等编程语言编写的可执行代码。但在 GitOps 中，咱们所治理的“代码”次要是由配置文件组成的。这不是一个小细节，而是 GitOps 工作的外围。正如咱们所说，这些配置文件是形容咱们的零碎应该是什么样子的“惟一真谛起源（single source of truth）”。它们是申明式的，而不是指导性的。这意味着，配置文件不会说“启动十台服务器”，而会简略地说“这个零碎包含十台服务器”。

GitOps 方程中的 CI 那一半容许开发人员疾速推出对这些配置文件的调整和改良；当自动化软件代理全力以赴确保应用程序的实时版本可能反映配置文件中的形容时，CD 这一部分会以 GitOps 语言趋向于申明式模型。

正如咱们所提到的，GitOps 的概念最后是围绕治理 Kubernetes 利用而呈现的。通过咱们当初对 GitOps 的理解，让咱们重温一下 Weaveworks 的 GitOps 探讨，看看他们是如何形容如何对基于 GitOps 准则治理的 Kubernetes 进行更新的。上面是对整个流程的总结：

一个开发者为一个新性能提出 Git 拉取申请。
审查和批准代码，而后将其合并到主代码库中。
合并会触发 CI/CD 流水线、自动测试和重建新代码，并将其部署到仓库。
软件代理留神到更新，从仓库中提取新代码，并更新配置仓库中的配置文件（用 YAML 编写）。
Kubernetes 集群中的软件代理依据配置文件，检测到集群曾经过期，拉取更改，并部署新性能。

显然，这里的第 4 步和第 5 步做了很多沉重的工作。将 Git 仓库中的 “ 真谛起源 “ 与事实世界中的 Kubernetes 利用进行神奇同步的软件代理，就是让 GitOps 成为可能的魔法。正如咱们所说，在 GitOps 术语中，让实时零碎更像配置文件中形容的现实零碎的过程叫做交融。当实时零碎和现实零碎不同步时，那就是一致。现实状况下，交融能够通过自动化流程来实现，但自动化所能做的事件是有限度的，有时人工干预是必要的。

咱们在这里用通用术语形容了这个过程，但事实上，如果你真的去看 Weaveworks 的页面，咱们提到的“软件代理”是该公司 Weave Cloud 平台的一部分。“GitOps”这个词是由 Weaveworks 的 CEO Alexis Richardson 发明的，它的局部作用是让 Weaveworks 平台对曾经沉迷在 DevOps 和 CI/CD 世界的开发者有吸引力。

但 Weaveworks 从未声称本人垄断了 GitOps，GitOps 更多的是一种理念和一套最佳实际，而不是某种具体的产品。 正如提供 CI/CD 解决方案的公司 CloudBees 的博客所指出的那样，GitOps 代表了一种凋谢的、厂商中立的模式，它是针对亚马逊、谷歌和微软等大型云厂商推出的管理型专有 Kubernetes 解决方案而开发的。CloudBees 提供了本人的 GitOps 解决方案，这个畛域的另一些玩家也是如此。

Atlassian 是一家为麻利开发者制作了许多工具的公司，它有一篇对于 GitOps 的历史和目标的深度博文（https://www.atlassian.com/git…），值得你花工夫去理解。在他们看来，GitOps 代表了作为 devops 的理念的逻辑延长。具体来说，GitOps 是对基础架构即代码（IaC）这一概念的论述，而基础架构自身就是 DevOps 环境下产生的一种思维。在 Atlassian 看来，GitOps 补救了现有 DevOps 技术与分布式、云托管利用的非凡需要之间的要害差距，现有 DevOps 技术是为了解决系统管理问题而倒退起来的。各个云厂商提供的主动交融是 GitOps 的特别之处。

尽管 GitOps 明天依然专一于 Kubernetes，但咱们心愿咱们曾经明确了它如何实用于更宽泛的分布式、基于云的利用世界。开源平安厂商 WhiteSource 的一篇博文概述了 GitOps 的劣势：