GitOps: Kubernetes CI/CD 的缺失环节

GitOps: The Missing Link for CI/CD for Kubernetes

原文https://containerjournal.com/features/gitops-the-missing-link-for-ci-cd-for-kubernetes/  作者：Steve Waterworth

GitOps has emerged as an essential process as organizations evaluate frameworks to optimize CI/CD on Kubernetes. DevOps teams are exploring how GitOps redefines CI/CD, with Git serving as the central, immutable state declaration for faster deployments and more audit-friendly secure environments. GitOps offers teams well-documented improvements in productivity, security, and compliance, which ultimately translate into a better experience for the user. 

随着组织评估以优化 Kubernetes 上的 CI/CD，GitOps 已成为一个必不可少的过程。DevOps 团队正在探索 GitOps 如何重新定义 CI/CD，将 Git 作为中心的、不可变的状态声明，以实现更快的部署和更便于审计的安全环境。GitOps为团队提供了在生产力、安全性和合规性方面有据可查的改进，最终转化为更好的用户体验。

Multiple Teams, One Git 多个团队，一个 Git

The use of Git as a version control system—usually with GitHub or GitLab—is the cornerstone of GitOps. That’s why it is increasingly considered essential for CI/CD. A number of Git superlatives accurately describe how GitOps serves as a consolidated and cohesive way of managing and operating cloud-native infrastructure applications: “Git is where everything lives,” “Git provides a single source of truth,” and so on. Through GitOps’ declarative processes, Git also lends itself well to Kubernetes, since Kubernetes clusters are also managed in a declarative way—in other words, it’s all in the YAML. 

使用 Git 作为版本控制系统——通常与 GitHub 或 GitLab 一起使用——是 GitOps 的基石。这就是为什么它越来越被认为对 CI/CD 至关重要。许多 Git 最高级的说法准确地描述了 GitOps 如何作为管理和操作云原生基础设施应用程序的统一和有凝聚力的方式：“Git 是一切的所在”，“Git 提供了单一的事实来源”，等等。通过 GitOps 的声明式流程，Git 也非常适合 Kubernetes，因为 Kubernetes 集群也是以声明式方式管理的——换句话说，一切都在 YAML 中。

Git serves as the immutable state declaration for CI/CD cloud-native environments. This state declaration is automated. It is reconciled continuously through controllers and represents the current state of an application running on Kubernetes clusters. In this way, developer teams’ pull and merge requests are all done on Git—with audit trails remaining for all changes. The testing and security teams will continue to do their checks, making any needed modifications and creating pull requests on Git. From Git, only those with permission can apply the code to the declared state of the Kubernetes cluster. 

Git 充当 CI/CD 云原生环境的不可变状态声明。这个状态声明是自动的。它通过控制器不断协调，并代表在 Kubernetes 集群上运行的应用程序的当前状态。通过这种方式，开发团队的拉取和合并请求都在 Git 上完成——所有更改都保留审计跟踪。测试和安全团队将继续进行检查，进行任何必要的修改并在 Git 上创建拉取请求。从 Git 中，只有获得许可的人才能将代码应用于 Kubernetes 集群的声明状态。

Observability for All Stakeholders 所有利益相关者的可观察性

Since application and infrastructure configuration remains in its immutable state on Git, the CI/CD process is observable to all team members. The developer can create pull requests, but they can also monitor deployments during the CD stage—usually with read-only access. If there is a problem, the developer can access the repository, make a change and commit it for deployment directly. In a more restrictive environment, the developer would need to alert the operations team that the change from Git must be completed.
由于应用程序和基础架构配置在 Git 上保持不变状态，因此所有团队成员都可以观察到 CI/CD 过程。开发人员可以创建拉取请求，但他们也可以在 CD 阶段监控部署——通常具有只读访问权限。如果出现问题，开发人员可以访问存储库，进行更改并直接提交部署。在限制性更强的环境中，开发人员需要提醒运营团队必须完成来自 Git 的更改。

Thanks to Git’s audit capabilities, which includes a trail of all changes made to the configuration, DevOps can either release the application or roll it back to the original state—even once deployed—by using Git commands to replace an error-prone version. The ability to roll back to a known stable version can reduce mean-time-to-recovery (MTTR) to minutes in most cases, even when managing a platform with thousands of clusters. The GitOps software agent or controllers will then reconcile the application to a known working state. The entire process is observable by the developer and operations teams in Git. 

得益于 Git 的审计功能，其中包括对配置所做的所有更改的跟踪，DevOps 可以发布应用程序或将其回滚到原始状态——即使在部署后——通过使用 Git 命令替换容易出错的版本。在大多数情况下，回滚到已知稳定版本的能力可以将平均恢复时间 (MTTR) 减少到几分钟，即使在管理具有数千个集群的平台时也是如此。GitOps 软件代理或控制器随后会将应用程序协调到已知的工作状态。Git 中的开发人员和运营团队可以观察到整个过程。

CI/CD Control CI/CD 控制

In a large organization, it is rare for a single CI/CD pipeline to handle the deployment of all projects. Different projects can be located in separate Git repositories, for example, while some teams—often spread around different geographic locations—may work on a number of projects with their own CI/CD pipelines. The distributed nature of today’s DevOps teams is another example that highlights the value of GitOps, as that one central and immutable source of truth for all distributed teams.

在大型组织中，很少有单个 CI/CD 管道来处理所有项目的部署。例如，不同的项目可以位于不同的 Git 存储库中，而一些团队（通常分布在不同的地理位置）可能会使用自己的 CI/CD 管道处理多个项目。当今 DevOps 团队的分布式特性是另一个突出 GitOps 价值的例子，它是所有分布式团队的一个核心且不可变的事实来源。

With the Git repository serving as the focal point, not every team member requires access to the entire infrastructure. This is especially important for production environments running on Kubernetes clusters, and can be further enforced with GitOps permissions that are namespace-scoped. 

以 Git 存储库作为焦点，并非每个团队成员都需要访问整个基础架构。这对于在 Kubernetes 集群上运行的生产环境尤为重要，并且可以通过命名空间范围内的 GitOps 权限进一步实施。

In many ways, GitOps creates an additional layer of control that replaces and automates kubectl command line access. Access to kubectl commands to create, deploy and manage clusters can—and should—be strictly controlled via RBAC policies. 

在许多方面，GitOps 创建了一个额外的控制层来替换和自动化 kubectl 命令行访问。可以而且应该通过 RBAC 策略严格控制对 kubectl 命令的访问以创建、部署和管理集群。

Of critical importance is how declarative changes are applied to the Kubernetes-controlled configuration in an automated fashion. As the immutable source of truth, an alert is issued when changes are made to cluster configurations and applications running in production. In other words, everything that is in Git should be running in the same way in the Kubernetes cluster, including the way the cluster or clusters are configured. 

至关重要的是如何以自动化方式将声明性更改应用于 Kubernetes 控制的配置。作为不可变的真实来源，当对集群配置和生产中运行的应用程序进行更改时，会发出警报。换句话说，Git 中的所有内容都应该在 Kubernetes 集群中以相同的方式运行，包括集群的配置方式。

Namespaces are typically assigned to delineate development workspaces, as opposed to the production workspace. For the operations team members, namespace permissions enable access to ingress controllers, service meshes and RBAC access to make changes during CD in a cluster. 

命名空间通常用于描述开发工作区，而不是生产工作区。对于运营团队成员，命名空间权限允许访问入口控制器、服务网格和 RBAC 访问权限，以便在集群中的 CD 期间进行更改。

The Great GitOps Takeaway for CI/CD

The conceptual part of GitOps to support CI/CD for Kubernetes is fairly straightforward. In addition to the complexities of configuring and managing Kubernetes clusters, the support of CI/CD  through GitOps—the “missing link”—also necessitates a careful selection of tool choices. In other words, the right tool or platform is usually required for the adoption of GitOps, unless the DevOps team opts to create its own platform, which is not recommended. The use of Git as a central repository alone is thus not enough to initiate proper GitOps processes. 

GitOps 支持 Kubernetes 的 CI/CD 的概念部分相当简单。除了配置和管理 Kubernetes 集群的复杂性之外，  通过 GitOps（“缺失的一环”）支持 CI/CD 还需要仔细选择工具。换句话说，采用 GitOps 通常需要正确的工具或平台，除非 DevOps 团队选择创建自己的平台，这是不推荐的。因此，仅将 Git 用作中央存储库不足以启动正确的 GitOps 流程。

Tried-and-tested tools for creating and managing applications for Kubernetes exist, but can fall short for GitOps support. Many, if not most, DevOps teams rely on open source Jenkins for CI on Kubernetes, for example, as part of the production pipeline. But Jenkins—while a worthy tool for CI—was not designed to provide a number of features that GitOps usually requires.  Deploying commits with Jenkins scripts means that DevOps cannot roll back releases. It also does not offer other GitOps functionalities such as RBAC, full audit trails and many version control features. 

用于创建和管理 Kubernetes 应用程序的久经考验的工具已经存在，但可能无法支持 GitOps。例如，许多（如果不是大多数）DevOps 团队都依赖开源 Jenkins 作为 Kubernetes 上的 CI 作为生产管道的一部分。但是 Jenkins——虽然对于 CI 来说是一个有价值的工具——并不是为了提供 GitOps 通常需要的许多功能而设计的。 使用 Jenkins 脚本部署提交意味着 DevOps 无法回滚发布。它也不提供其他 GitOps 功能，例如 RBAC、完整审计跟踪和许多版本控制功能。

Open source alternatives created specifically for GitOps CI/CD on Kubernetes are worthy of investigation. As a GitOps Kubernetes operator, for example, open source Flux is emerging as a mainstream platform supporting CD for the production pipeline, including post-deployment cluster management in all the ways described above. 

专门为 Kubernetes 上的 GitOps CI/CD 创建的开源替代方案值得研究。例如，作为 GitOps Kubernetes 运营商，开源Flux正在成为支持生产管道 CD 的主流平台，包括上述所有方式的部署后集群管理。

For a more opinionated Flux experience, open source Weave GitOps Core simplifies the first steps to automate CI/CD across multiple clusters. The process of setting up a GitOps process with Weave GitOps Core should involve just a few simple commands on the console. 

为了获得更自以为是的 Flux 体验，开源Weave GitOps Core简化了跨多个集群自动化 CI/CD 的第一步。使用 Weave GitOps Core 设置 GitOps 进程的过程应该只涉及控制台上的几个简单命令。

In conclusion, GitOps can support CI/CD for Kubernetes deployments in key ways. But while relying on Git as the central repository is necessary, the use of it alone for GitOps is not enough. This is why open source tools created specifically for CI/CD—such as Flux and Weave GitOps Core—are required to support the missing link that GitOps offers CI/CD. 

总之，GitOps 可以在关键方面支持 Kubernetes 部署的 CI/CD。但是，虽然依赖 Git 作为中央存储库是必要的，但仅将其用于 GitOps 是不够的。这就是为什么需要专门为 CI/CD 创建的开源工具（例如 Flux 和 Weave GitOps Core）来支持 GitOps 提供 CI/CD 的缺失环节。