持续集成和交付到 Google Kubernetes Engine 的最佳实践

本指南介绍了持续集成和持续交付 (CI/CD) 到 Google Kubernetes Engine (GKE) 的一系列最佳做法。这些最佳做法涉及从源代码控制到部署策略等众多主题。它们专门针对 GKE，CI/CD 一般最佳做法仍然适用。如需了解详情，请参阅 DevOps 技术：持续集成和 DevOps 技术：持续交付。

持续集成

持续集成 (CI) 是一种做法，开发者通过该方法可以尽可能频繁地将其所有代码更改集成回主分支。这样做的目的是在进程中尽早暴露出问题，以便更快地解决故障。CI 流水线通常由开发者推送代码更改来触发。流水线涉及验证这些更改的步骤，例如执行 lint 请求、测试和构建。CI 流水线通常会生成一个工件，您可以在部署过程的后续阶段中部署该工件。

创建可实现快速迭代的流水线

开发者进行代码更改到应用版本运行之间的时间应尽可能短。在开发涉及开发者快速迭代的功能分支的过程中，这种速度尤为重要。理想情况下，CI 流水线的运行时间不应超过 10分钟。如果无法做到这一点，请创建两种类型的 CI 流水线：

  • 快速流水线：这些流水线通常在 10 分钟内完成运行。这些流水线适用于功能分支，但并不全面。快速流水线可能导致工件不稳定。

  • 完整流水线：这些流水线的运行时间可能超过 10 分钟，可运行更全面的测试和检查。完整流水线在合并请求或拉取请求上运行，并提交到主分支。

遵循构建容器的最佳做法

如需创建更小、弹性更佳的映像，并且使容器更易于构建和运行，请务必遵循构建容器的最佳做法。

测试容器映像

在 CI 流水线中，请确保对代码和构建工件运行所有必需的测试。这些测试应包含单元测试、功能测试、集成测试以及负载或性能测试。

测试构建的容器映像的结构也很重要。测试结构可确保所有命令都会按在容器内部预期的那样运行。通过测试，您还可以检查特定文件是否位于正确位置，以及内容是否正确。

如需测试容器映像，您可以使用容器结构测试框架。

在流水线中尽早建立安全机制

在开发生命周期中尽早进行安全检查和平衡。通过在构建工件或部署之前找到安全风险，您可以减少为解决这些风险所用的时间和费用。

为有助于尽早完成检测，您可以在流水线中实施以下安全措施：

  • 要求主题专家审核集成到您的生产代码库中的任何代码。

  • 在流水线中尽早执行 lint 请求和静态代码分析。此测试可帮助您在代码中找到缺陷（例如未转义输入、接受 SQL 查询的原始输入数据）或漏洞。

  • 通过漏洞扫描扫描构建的容器映像是否存在漏洞。

  • 使用 Binary Authorization 防止将包含漏洞的映像部署到您的集群。Binary Authorization 需要有 GKE Enterprise 订阅。 为了提升您对生成的映像的信心，借助 Binary Authorization，您还可以要求由不同实体或系统提供的证明。例如，这些证明可能包括：

    • 已通过漏洞扫描
    • 已通过质量检查测试
    • 获得产品所有者签核

持续交付

借助持续交付 (CD)，您可以随时发布代码。CD 在 CI 流水线生成的工件上运行。CD 流水线的运行时间会比 CI 流水线的运行时间长得多，尤其是在您使用更为复杂的部署策略（例如蓝绿部署）时。

使用 GitOps 方法

GitOps 是存储在 Git 代码库和 CI/CD 工具中的声明式基础架构的概念，用于将该基础架构部署到您的环境。使用 GitOps 方法时，请确保对应用和集群的所有更改都存储在源代码库中并且始终都可以访问。

使用 GitOps 方法具有以下优势：

  • 您可以在通过合并请求或拉取请求部署更改之前对更改进行审核。
  • 您可以使用一个位置随时回头查看应用和集群的状态。
  • 集群和应用快照可让您在发生故障时更轻松地进行恢复。

如需详细了解 GitOps 方法以及可在源代码库中使用的不同模式，请参阅 GitOps 概念。

用于声明式基础架构的一些常见工具包括 Hashicorp 提供的 Terraform 和 Google Cloud 提供的 Config Connector。如需亲身体验如何使用 GitOps 和其他工具管理基础架构，请参阅使用 Terraform、Cloud Build 和 GitOps 以代码形式管理基础架构教程。如需了解如何以 GitOps 形式管理应用，请参阅使用 Cloud Build 实现 GitOps 形式的持续交付。

提升容器映像而非重新构建容器映像

容器映像不应重新构建，因为它们会通过 CI/CD 流水线的不同阶段。重新构建可能会造成代码分支中出现细微差异。这些差异可能会导致应用在生产环境中失败，或者导致在生产容器映像中意外添加未经测试的代码。为了确保您测试的容器映像是您部署的容器映像，最好构建一次，并根据您的环境进行提升。这项建议假定您按照构建容器的最佳做法中所述将特定于环境的配置与软件包分开。

考虑使用更高级的部署和测试模式

GKE 可让您灵活地使用多种模式部署和测试您的应用。您选择的部署模式在很大程度上取决于您的业务目标。例如，您可能需要在完全不停机的情况下部署更改，或者先将更改部署到一个环境或部分用户，然后再正式发布某项功能。

您可以采用下面一些不同的部署模式：

  • 重新创建部署：先完全缩容现有应用版本，然后再扩容新的应用版本。

  • 滚动更新部署：更新一部分正在运行的应用实例，而不是一次更新所有正在运行的应用实例。然后，逐步更新更多正在运行的应用实例，直到它们全部更新为止。

  • 蓝绿部署：通过升级后的应用版本，将另外并行的一组实例部署到现有的生产实例。在准备好部署后，您可以将流量切换到新实例。

如需详细了解这些策略，请参阅应用部署和测试策略。

为不同环境使用不同的集群

分离环境是任何部署目标的一项重要考虑因素。理想情况下，您应该为以下每个环境使用不同的集群：

  • 开发环境：这是开发者在其中部署应用以进行测试和实验的环境。这些部署需要与应用或系统的其他部分（例如数据库）集成。此环境的集群通常具有较少的开关，开发者可以更好地控制其集群配置。

  • 预生产环境（预演或质量检查）：这些环境应尽可能与生产环境类似。它们用于对更改进行大规模测试，例如集成测试、负载测试、性能测试或回归测试。

  • 生产环境：这是生产工作负载以及面向用户的应用和服务在其中运行的环境。

如需详细了解这些环境，请参阅 Kubernetes 中的“环境”部分以及持续软件交付所面临的挑战。

使预生产环境接近生产环境

理想情况下，预生产集群与生产集群相同，但为了节省费用，可以对预生产集群缩容副本。保持集群类似可确保任何测试都在与生产环境相同或类似的条件下完成。预生产集群与生产集群之间的对等性还会降低部署到生产环境时由于环境差异而导致意外故障的可能性。

声明式基础架构和 GitOps 可帮助您实现与您的环境更接近的对等性，因为您可以更加轻松地重复底层集群的配置。为确保您的环境具有类似的政策和配置条件，您还可以使用 Config Sync 等工具。

为生产环境中发生的故障做好准备

再多的测试也无法保证应用在生产环境中的行为正常。故障可能是由于包含未经考虑的数据的边缘用例或未经用户测试的访问模式导致的。请务必监控您的应用在生产环境中的状态，并采用自动回滚和部署机制，以便您可以快速应对 bug 或服务中断并进行修复。在生产环境中出现问题时，借助更强大的部署策略，您可以降低问题造成的影响并减少受影响的最终用户数。

核对清单摘要

下表汇总了我们建议您在 GKE 中使用 CI/CD 流水线时执行的任务：

范围 任务
持续集成
持续交付

后续步骤