部署蓝图

Last reviewed 2024-04-19 UTC

本部分介绍可用于部署蓝图、蓝图的命名规则以及蓝图建议的替代方案的流程。

综合应用

如需实现本文档中所述的架构，请完成本部分中的步骤。

在新组织中部署蓝图

如需在新的 Google Cloud 组织中部署蓝图，请完成以下操作：

  1. 使用企业基础蓝图创建基础设施。请完成以下操作：

    1. 创建组织结构，包括用于分离环境的文件夹。
    2. 配置基本 IAM 权限以向开发者平台管理员授予访问权限。
    3. 创建 VPC 网络。
    4. 部署基础设施流水线。

    如果您不使用企业基础蓝图，请参阅不使用企业基础蓝图部署蓝图。

  2. 开发者平台管理员使用基础设施流水线创建多租户基础设施流水线、应用工厂和舰队范围流水线。

  3. 开发者平台管理员使用多租户基础设施流水线部署 GKE 集群和共享基础设施。

  4. 应用运维人员使用应用工厂对新应用进行初始配置。运维人员在应用工厂代码库中添加一个或多个条目，以触发应用专用资源的创建。

  5. 应用开发者在其应用专用基础设施中使用应用 CI/CD 流水线，将应用部署到多租户基础设施。

不使用企业基础蓝图部署蓝图

如果您不在企业基础蓝图上部署企业应用蓝图，请完成以下步骤：

  1. 创建以下资源：
    • 包含 development、nonproduction 和 production 文件夹的组织层次结构
    • 每个文件夹中的共享 VPC 网络
    • 可提供 GKE 集群需要的 IP 地址范围的 IP 地址方案
    • GKE 集群的 DNS 机制
    • 符合您的安全状况的防火墙政策
    • 通过专用 IP 地址访问 Google Cloud API 的机制
    • 与您的本地环境连接的机制
    • 用于安全和审核用途的中心化日志
    • 用于监控威胁的 Security Command Center
    • 符合您的安全状况的组织政策
    • 可用于部署应用工厂、多租户基础设施流水线和舰队范围流水线的流水线
  2. 部署资源后，继续执行在新组织中部署蓝图中的第 2 步。

将蓝图整合到现有 GKE 部署中

此蓝图要求您先部署开发者平台，然后再将应用部署到开发者平台。下表介绍了当您已有在 Google Cloud 上运行的容器化应用时可如何使用蓝图。

现有使用情况 迁移策略

已有 CI/CD 流水线。

即使应用构建和部署使用不同的产品，您也可以使用蓝图的舰队和集群架构。我们建议您至少将映像镜像到两个区域。

现有组织结构与企业基础蓝图不匹配。

建议至少有两个环境，以实现更安全的顺序部署。您不一定要在不同的共享 VPC 或文件夹中部署环境。但是，请勿将属于不同环境的工作负载部署到同一集群中。

不使用 IaC。

如果您当前的应用部署过程不使用 IaC，则可以使用 Terraform on Google Cloud 成熟度模型来评估就绪情况。导入现有资源到另一个 Terraform 项目（其组织方式与此蓝图类似），并将多租户流水线和每租户流水线分隔开来。如需创建新集群，您可以使用适用于 Google Cloud 的 Terraform 模块。

集群分布在同一环境的多个项目中。

您可以将多个项目中的集群分组到一个舰队中。验证您的命名空间在同一舰队内具有唯一含义。在将集群添加到舰队之前，请让团队将其应用移至具有唯一名称（例如，不是 default）的命名空间。

然后，您可以将命名空间分组到范围内。

所有集群位于单一区域中。

您无需在生产环境和非生产环境中使用多个区域也可采用此蓝图。

存在不同的环境组。

您可以修改蓝图，以支持多于或少于三个环境。

集群创建工作委托给应用开发或应用运维团队。

为了获得最安全、最一致的开发者平台，您可以尝试将集群的所有权从应用团队转移到开发者平台团队。如果无法这样做，您仍然可以采用许多蓝图做法。例如，您可以将不同应用团队拥有的集群添加到舰队。但是，在将集群与独立所有权相结合时，请勿使用 Workload Identity 或 Anthos Service Mesh，因为它们无法充分控制谁可以声明哪些工作负载身份。请使用自定义组织政策来阻止团队在 GKE 集群上启用这些功能。

将集群分组到舰队后，您仍可以审核和强制执行政策。您可以使用自定义组织政策要求集群在与集群项目所在环境文件夹相对应的舰队中创建。您可以使用舰队默认配置来要求新集群使用政策控制。

默认建议的替代方案

本部分介绍本指南中包含的默认建议的替代方案。

决策区域 可能的替代方案

所有应用都在相同的一组五个集群中运行。

蓝图使用一组五个集群（两个在生产环境中，两个在非生产环境中，一个在开发环境中）。您可以修改蓝图，以创建更多这样的五集群组。

将应用分配到各个五集群组。请勿将应用的范围或舰队命名空间绑定到其他组的集群。建议您将应用隔离到不同的集群组中，以完成以下活动：

  • 将具有特殊监管要求（例如 PCI-DSS）的应用分组到一起。
  • 隔离在集群升级期间需要特殊处理的应用（例如，使用永久性卷的有状态应用）。
  • 隔离使用有风险的安全配置文件的应用（例如，使用内存不安全语言处理用户提供的内容）。
  • 隔离需要使用 GPU，并且对费用和性能敏感的应用。
  • 如果您接近关于节点数量的 GKE 集群限制（15,000 个节点），则可以创建一组新集群。
  • 为需要在 VPC Service Controls 边界内运行的应用使用不同的共享 VPC。在边界内创建一个集群组，并在边界外创建一个集群组。

避免为每个应用或租户创建新的集群组，因为这种做法可能会导致以下情况之一：

  • 即使使用最小的可用实例类型，应用也无法利用最小集群大小（3 个虚拟机 x 2 个区域）的优势。
  • 无法获得将不同应用装箱带来的费用节省。
  • 容量增长规划非常繁琐且不确定性高，因为规划单独应用于每个应用。对大量应用进行汇总式的容量预测会更加准确。
  • 为新租户或应用创建新集群时发生延迟，导致租户对平台的满意度下降。例如，在某些组织中，必需的 IP 地址分配可能需要一些时间，并且需要额外的批准。
  • 达到 VPC 网络中的专用集群限制。

生产环境和非生产环境中的集群分布在两个区域。

如需缩短多个区域中的最终用户的延迟时间，您可以将生产和非生产工作负载部署到两个以上的区域（例如，生产环境三个区域，非生产环境三个区域，开发环境一个区域）。此部署策略会增加在其他区域中维护资源的费用和开销。

如果所有应用都具有较低的可用性要求，您可以将生产和非生产工作负载仅部署到一个区域（一个生产环境、一个非生产环境和一个开发环境）。此策略有助于降低费用，但无法确保提供与双区域或多区域架构相同的可用性级别。

如果应用具有不同的可用性要求，您可以为不同的应用创建不同的集群组（例如，cluster-set-1 有两个生产环境、两个非生产环境和一个开发环境，cluster-set-2 有一个生产环境、一个非生产环境和一个开发环境）。

中心辐射型拓扑比共享 VPC 更符合您的要求。

您可以在中心辐射型配置中部署蓝图，其中每个环境（开发、生产和非生产）都托管在各自的 spoke 中。中心辐射型拓扑可以增强环境的隔离。如需了解详情，请参阅中心辐射型网络拓扑。

每个应用都有一个单独的 Git 代码库。

某些组织对所有源代码使用单个 Git 代码库 (monorepo) 而不是多个代码库。如果您使用 monorepo，则可以修改蓝图的应用工厂组件来支持您的代码库。请完成以下操作：

  • 在现有代码库中创建一个子目录，而不是为每个新应用创建一个新代码库。
  • 不要向应用开发者群组授予新代码库的所有者权限，而是授予现有代码库的写入权限，并将应用开发者群组设为必需的审核者，以便审核对新的子目录做出的更改。使用 CODEOWNERS 功能和分支保护。

后续步骤