Gitops工作流

传统CI/CD工作流概述

在进一步深入之前，让我们首先了解传统的CI/CD是如何工作的，因为大多数开始持续交付之旅的组织通常是通过自动化CI/CD管道开始的。
在这个简化的示例中，假设有一个单独的微服务存储库，它将微服务的代码与其部署YAML清单文件捆绑在一起。如果您还记得的话，YAML文件定义或声明微服务如何在集群中运行。当开发人员将代码推送到Git时，持续集成工具启动单元测试，最终构建被推送到容器注册表的Docker容器映像。

通过这种典型的基于CI/CD推送的管道，Docker容器映像然后使用某种定制的bash脚本或通过其他直接与Kubernetes的API对话的方法部署到实际的集群中。

典型的CI/CD方法带来了一些自身的挑战，如下所示：

• 安全保障

通过这种方法，您的CI工具将映像推送到集群中并部署到集群中。为了让CI系统将更改应用到集群，您必须与CI工具共享API凭据。这意味着您的CI工具成为一个高价值的目标。如果有人闯入您的CI工具，他们将完全控制您的生产集群，即使您的生产集群是高度安全的。

• 灾难恢复

当您需要在完全崩溃的情况下重新创建集群时会发生什么？如何还原应用程序以前的状态？您必须运行所有CI作业来重建所有内容，然后将所有工作负载重新应用到新集群。典型的CI管道不像使用Gitops时那样容易记录其状态。

GitOps部署工作流概述

GitOps的核心机制在其CI/CD工具中，关键部分是支持Git-cluster同步的连续部署(CD)。它是专门为版本控制系统和声明性应用程序堆栈设计的。您的团队中的每个开发人员都熟悉Git，并且能够发出拉请求。现在，他们也可以使用Git来加速和简化应用程序到Kubernetes的部署。

下面是创建或更新新特性的典型开发人员工作流：

1. 一个新特性的请求被推送到GitHub进行审查。
2. 该代码由一名同事审查和批准。
3. 代码修订并重新批准后，合并为Git。
4. Git merge触发CI和构建管道，运行一系列测试，然后最终构建新映像并将新映像保存到注册表中。
5. 部署自动化程序监视映像注册表，注意映像，从注册表中提取新映像，并在配置repo中更新其YAML。
6. 部署同步器检测集群已过时，从配置repo中提取更改的清单，并将新特性部署到生产中。

Kubernetes中的GitOps工作流

开放人员提交代码，VCS触发自动测试和build container，之后将image推送至镜像仓库，最后自动部署资源到K8s集群，资源清单文件中从镜像仓库拉取镜像。