规划舰队资源

正如您在舰队管理概览中所了解的那样，舰队是一种分组机制，用于大规模管理、配置和保护 Kubernetes 集群。舰队是一种强大的工具，可让您无需在多集群环境中执行重复操作，并且可以对大型集群组提供一致性和全面的可观测性。大量 GKE 功能只能通过舰队提供。

您用于创建舰队的分组策略可能会因您的组织的技术和业务需求而异。例如，一个组织可能会根据集群中运行的应用类型对集群进行分组，而另一个组织可能会根据区域、环境或其他相关因素对集群进行分组。在其他条件相同的情况下，组织内的舰队数量根据需要减少会很方便。

本指南适用于希望在其组织中开始使用舰队的 Cloud 架构师。该指南提供了一些有关将集群整理到舰队的实用指导，包括：

  • 您希望创建全新的集群时。
  • 您希望创建包含现有集群的舰队时。

此处介绍的模式适用于许多组织，但并非规划舰队的唯一方式。舰队非常灵活，您可以决定为集群使用不同的分组模式。

在阅读本页面之前，请确保您熟悉以下概念：

舰队和资源限制

创建舰队时，存在以下一般限制：

  • 给定的 Google Cloud 项目只能关联单个舰队（或不关联任何舰队），不过该舰队可以包含多个项目中的集群。与舰队关联的项目称为舰队的舰队宿主项目。
  • 集群在任何给定时间都只能是单个舰队的成员。
  • 给定项目中的所有集群都必须位于同一舰队中，或者都不位于任何舰队中。如果项目已包含舰队成员，则无法将该项目中的集群注册到其他舰队。
  • 舰队中的集群数量的默认限制为 250 个，但您可以根据需要申请更高的限制。

出于多种原因，将多个集群放在同一项目中会很方便。但是，在规划将哪些集群全部放在一个项目中时，请考虑以下限制：

一般原则

以下是在决定是否将集群全部分组到一个舰队中时应提出的一般问题。我们将在后面的部分中详细介绍这些问题的应用方式。

  • 资源之间是否相关？
    • 具有大量跨服务通信的资源最适合在舰队中共同管理。
    • 同一部署环境（例如生产环境）中的资源应在舰队中共同管理。
  • 谁管理资源？
    • 统一（或至少相互信任）控制资源至关重要，这可确保舰队的完整性。

为新集群规划舰队

本部分介绍了如何在拥有一组已知应用但灵活选择这些应用的部署位置时规划舰队。这可能是因为您尚未开发这些应用，或者正在将这些应用从其他容器平台迁移过来。或者，您可能已经在现有集群中运行应用，但希望将应用迁移到新集群，以实现首选架构。

确定舰队后，您可以为每个舰队创建一个新项目，在每个项目中创建一个舰队，然后创建集群并将其注册到预期的舰队。

审核工作负载

首先，列出您要部署的所有 Kubernetes 工作负载（例如 Deployment）。此列表不必是文本列表；您可能只是想了解您需要的工作负载。然后，按照本节其余部分中的步骤逐步将一组应用划分为多个子集，直到获得所需的最少分组集。这会定义您需要的舰队和集群。

考虑业务单位

您的组织可以采用联合 IT 结构，即组织有一个中央 IT 团队，每个业务部门也有单独的 IT 团队。在这种情况下，每个联合 IT 团队可能都希望管理自己的舰队。如果两个业务部门的工作负载（例如银行审计和交易）出于监管原因完全无法相互通信，请使用单独的舰队。

按环境隔离工作负载

适用于许多组织的常见模式是按环境对集群进行分组。典型的配置是有三个主要环境：开发、非生产（或预演）和生产。应用更改通常会逐步部署（或提升）到列表中的每个环境。因此，对于同一底层应用（例如同一基础容器映像名称），每个环境中都有单独的部署。如需查看如何在组织中创建环境的示例，请参阅企业基础蓝图。

一个舰队应仅包含来自一个环境的集群。三个环境（每个环境中有一个舰队）可能足以满足许多组织的需求。如需查看每个环境都有一个舰队以及如何逐步部署应用的示例，请参阅企业应用蓝图。

合并冗余工作负载实例

如果应用需要高可用性，一种模式是在两个或更多区域中运行该应用。这涉及两个或多个运行配置非常相似的部署的集群，这些集群作为一个整体进行管理。它们通常有一个跨越所有集群中的应用实例的负载均衡器，或者使用 DNS 负载均衡。

在这些场景中，请将所有这些集群都放入同一舰队中。不同区域中的集群通常不需要位于不同的舰队中，除非出于监管或其他原因需要这样做。

规划包含现有集群的舰队

本部分介绍了如何在现有集群上运行工作负载且不打算迁移这些工作负载时规划舰队。这些集群可能在 Google Cloud内或 Google Cloud之外。在此方案中，目标是在组织内创建一组舰队，并将现有集群分配给这些舰队。

确定舰队后，您可以为每个舰队创建一个新项目，在每个项目中创建一个舰队，然后将集群注册到预期的舰队。

审核集群

首先，列出您的组织中的所有 Kubernetes 集群。Cloud Asset Inventory 是一种在组织中搜索 Kubernetes 集群资源的方法。

然后，您可以按照本节其余部分中的步骤逐步将一组应用划分为多个子集，直到获得所需的最少分组集。这会定义您需要的舰队。

考虑业务单位

您的组织可以采用联合 IT 结构，即组织有一个中央 IT 团队，每个业务部门也有单独的 IT 团队。这些按业务部门划分的 IT 团队可能创建了您现有的集群。通常在这种情况下，您会按业务部门对一组集群进行分区。例如，出于监管原因，某些业务部门的工作负载（例如银行审计和交易）完全无法相互通信。

如果业务部门纯粹是为了进行成本核算，但使用一个通用的 IT 团队，请考虑将其集群合并到一个舰队中，尤其是业务部门之间存在明显的服务间依赖关系时。

按环境对集群进行分组

确定贵组织中使用的环境。典型的环境名称包括开发环境、非生产（或预演）环境和生产环境。

如果每个集群明显只位于一个环境中，请按环境隔离集群列表。不过，如果某些集群包含从逻辑上属于不同环境的工作负载，我们建议您将应用重新部署到仅包含属于单个逻辑环境的应用的集群中。

最大限度地减少集群所有者的数量

将现有项目合并到舰队中时，考虑到 IAM 政策 (container.admin) 和 RBAC (admin ClusterRoleBinding)，可能会有不同的用户组有权在这些集群上充当管理员。如果您打算使用需要相同性的功能，则目标应该是让所有集群都具有相同的一组管理员，并且舰队只有一小部分管理员。如果集群必须具有不同的管理员，并且目标是使用那些需要相同性的功能，则这些集群可能不属于同一个舰队。

例如，如果集群 C1 和 C2 的管理员不同，且彼此不信任，也不愿意与管理舰队的中央平台团队共享管理员权限，那么这两个集群就不应归入同一舰队。

如需详细了解相同性以及哪些功能需要使用相同性，请参阅舰队的工作原理。

考虑舰队功能

无论您使用的是新集群还是现有集群，您选择的舰队功能也会影响您如何最佳地组织舰队。例如，如果您选择使用舰队范围的工作负载身份联合，则建议您在设置舰队范围的工作负载身份验证时以最大限度地降低风险的方式组织舰队；或者，如果您想要使用 Cloud Service Mesh，则可能需要某些集群位于同一舰队中。如果您使用 Virtual Private Cloud (VPC)，则某些功能要求每个舰队使用一个 VPC。

如需详细了解如何采用舰队功能以及相关要求和限制，请参阅本系列中的下一篇指南规划舰队功能。

考虑 VPC 边界

对于新集群和现有集群，另一个需要考虑的问题是，您是否已选择或想要在 Google Cloud 上使用虚拟私有云 (VPC) 创建自己的专用网络。VPC 边界内的集群（例如，具有 VPC Service Controls 的共享 VPC 中的集群）可以同时位于一个舰队。如果您同时拥有受限和非受限的共享 VPC，则最好将它们放入单独的舰队中。

如果您打算使用 VPC Service Controls 边界，则通常有些工作负载位于边界内，有些工作负载位于边界外。您应计划在每个环境（或至少是生产环境和紧邻生产环境之前的环境）中，为每个舰队分别提供 VPC Service Controls 版本和非 VPC Service Controls 版本。

在规划使用 VPC 的舰队时，请注意某些舰队功能具有特定的 VPC 要求，例如要求使用这些功能的所有集群都位于同一 VPC 网络内。

后续步骤