规划舰队资源

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

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

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

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

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

在阅读本指南之前，您应该先熟悉舰队管理概览中介绍的概念。本指南还假定您熟悉基本的 Kubernetes 概念和 Google 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 边界

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

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

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

后续步骤