《使用 Kubernetes 实现云原生 DevOps（第二版）》

第 14 章 Kubernetes 中的持续部署 Kubernetes 中的持续部署

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

道无为而无不为。

老子

在本章中，我们将探讨一项关键的 DevOps 原则--持续集成和持续部署（CI/CD），并了解如何在基于 Kubernetes 的云原生环境中实现这一目标。我们将概述设置持续部署管道以与 Kubernetes 配合使用的一些选项，并使用 Google 的 Cloud Build 向您展示一个完整的工作示例。我们还将介绍 GitOps 的概念，并演示如何使用名为 Flux 的 GitOps 工具自动部署到 Kubernetes。

什么是持续部署？

持续部署（CD）是将成功的构建文件自动部署到生产环境中。与测试套件一样，部署也应集中管理并实现自动化。开发人员应能通过按一个按钮、或合并一个合并请求、或推送一个 Git 发布标签来部署新版本。

CD 通常与持续集成（CI）联系在一起：根据主线分支自动集成和测试开发人员的更改。这样做的目的是，如果你在分支上做的改动在合并到主线时会破坏构建，持续集成会立即让你知道，而不是等到你完成分支并做最终合并时才知道。持续集成和部署的组合通常被称为CI/CD。

持续部署的机制通常被称为管道：一系列自动操作，通过一系列测试和验收阶段，将代码从开发人员的工作站带到生产环境。

容器化应用程序的典型管道可能如下所示：

1. 开发人员将代码更改推送到版本库。

2. 构建系统会自动构建当前版本的代码并运行测试。

3. 如果所有测试都通过，容器映像就会发布到中央容器注册表中。

4. 新构建的容器会自动部署到暂存环境中。

5. 暂存环境需要进行一些自动和/或手动验收测试。

6. 经过验证的容器映像将部署到生产环境中。

关键的一点是，在各种环境中测试和部署的工件不是源代码，而是容器。在源代码和运行中的二进制文件之间，错误有很多种方式，而测试容器而不是代码可以帮助捕捉到很多错误。

CD 的最大好处是在生产中不会出现意外情况；除非二进制镜像已在暂存中测试成功，否则不会部署任何内容。

你可以在"A CI/CD Pipeline with Cloud Build "中看到这样一个 CD 管道的详细示例。

我应该使用哪种 CD 工具？

与往常一样，问题不在于可用工具的短缺，而在于选择的范围太广。有几款新的 CI/CD 工具是专门为云原生应用设计的，而 Jenkins 等历史悠久的传统构建工具现在也有了插件，可以让它们与 Kubernetes 和容器协同工作。

因此，如果你已经在做 CI/CD，你可能不需要切换到一个全新的系统。如果你正在将现有应用迁移到 Kubernetes，你很可能只需对现有管道做一些小调整就能做到这一点。

在下一节中，我们将简要介绍一些流行的托管和自托管 CI/CD 工具。当然，我们无法涵盖所有工具，但这里有一个快速列表，可以帮助您开始搜索。

托管的 CI/CD 工具

如果您正在为您的 CI/CD 管道寻找开箱即用的解决方案，而不需要维护底层基础设施，那么您应该考虑使用托管产品。主要的 Cloud 提供商都提供能很好地集成到其生态系统中的 CI/CD 工具，因此值得首先探索已成为您云账户一部分的工具。

Azure 管道

微软的 Azure DevOps 服务（前身为 Visual Studio Team Services）包括一个持续交付管道设施，名为Azure Pipelines，类似于 Google ...