企业级多租户最佳做法

Google Kubernetes Engine (GKE) 中的多租户是指在租户之间共享一个或多个集群。在 Kubernetes 中，租户可定义为以下任意一项：

• 负责开发和运营一个或多个工作负载的团队。

• 由一个或多个团队运营的一组相关工作负载。

• Deployment 之类的单个工作负载。

集群多租户的实现通常有助于降低费用或确保为各个租户施行一致的管理政策。但是，如果 GKE 集群或其关联的 GKE 资源配置不正确，可能会导致无法实现成本节约、政策施行错误，或不同租户的工作负载之间发生破坏性交互。

本指南介绍了为企业组织安全高效地设置多个多租户集群的最佳做法。

假设和要求

本指南中的最佳做法以企业环境的多租户使用场景为基础，因此存在以下假设和要求：

• 该组织是一家拥有许多使用 Kubernetes 且希望共享计算和管理资源的租户（至少两个应用/服务团队）的公司。

• 每个租户都是一个负责开发单一工作负载的团队。

• 除了应用/服务团队之外，还有其他团队也使用和管理集群，包括平台团队成员、集群管理员、审核人员等。

• 平台团队拥有集群并负责定义每个租户团队可以使用的资源数量；每个租户可以申请更多资源。

• 每个租户团队都应该能够通过 Kubernetes API 部署其应用，而无需与平台团队沟通。

• 每个租户都不应该能够影响共享集群中的其他租户，除非采用了 API 调用、共享数据源等这些明确的设计决策。

我们将以上述设置作为模型来演示多租户最佳做法。虽然这种设置可能无法完美地描述所有企业组织，但它可以轻松进行扩展，从而涵盖类似场景。

设置文件夹、项目和集群

对于在 GKE 中部署多租户集群的企业组织而言，需要在其他 Google Cloud 系统中进行额外配置，以便管理较简单的单应用、单团队 Kubernetes 部署中所不存在的复杂任务。这包括用于隔离管理关注点和将组织结构映射到云身份和帐号的项目配置，以及用于管理数据库、日志记录和监控、存储和网络等其他 Google Cloud 资源的配置。

建立文件夹和项目层次结构

如需确定贵组织如何管理 Google Cloud 资源并实施关注点分离，请使用文件夹和项目。文件夹可让不同的团队设置跨多个项目级联的政策，而项目则可用于隔离各种环境（例如生产环境与预演环境）和团队。例如，大多数组织都有一个负责管理网络基础架构的团队和另一个负责管理集群的团队。每种技术都被视为一个独立技术栈，需要专门的专业知识水平、问题排查流程和访问权限。

父级文件夹最多可以包含 300 个文件夹，并且文件夹最多可以嵌套 10 层。如果您拥有超过 300 个租户，则可以采用嵌套层次结构安排这些租户，以免超出限制。

<> 演示此做法

在我们的企业环境中，我们创建了三个顶级文件夹，专供以下各团队的资源使用：

• Network Team：专供网络团队用于管理网络资源的文件夹。此文件夹包含与租户网络和集群网络对应的子文件夹；我们将在集中控制网络部分中对这些网络进行详细介绍。每个子文件夹包含每种环境（开发、预演和生产）的一个项目，该项目用于托管 Virtual Private Cloud (VPC) 以提供组织中的所有网络连接。

• Cluster Team：专供平台团队用于管理每种环境的集群的文件夹。此文件夹包含与每种环境（开发、预演和生产）对应的子文件夹，而每个子文件夹包含一个或多个可容纳集群的项目。

• Tenants：专用于管理租户的文件夹。此文件夹包含与每个租户对应的子文件夹，用于托管该租户的非集群资源；每个子文件夹可以包含个别租户所需的一个或多个项目（甚至子文件夹）。

请注意，我们建议网络团队和租户团队使用每种环境的项目，但建议集群团队使用每种环境的文件夹，其中每个文件夹用于组织每种环境所用的项目（例如，生产文件夹包含生产项目）。采用这种配置的原因是集群团队具有特殊的隔离需求，而项目是隔离 Google Cloud 资源的主要方法。例如，集群团队可能会出于以下原因选择在每个项目中仅托管一个集群：

• 集群配置：某些配置（如 Identity and Access Management (IAM)）是按项目进行的。将不同的集群放置在不同的项目中可确保一个项目中的错误配置不会同时影响环境中的所有集群，并可让您逐步部署和验证对配置的更改。

• 工作负载安全性：默认情况下，与同一项目中的工作负载相比，在不同项目中运行的工作负载彼此隔离的程度更高。将集群托管在专用项目中可确保一个集群中已遭入侵、行为异常或恶意的工作负载在有限的范围内产生影响。

• 资源配额：配额是按项目确定并实施的。 跨项目分布集群可限制单个工作负载（例如，在自动扩缩的集群中）的影响范围，避免耗尽整个环境的限制。

将某些低风险政策应用于“所有生产集群”可能仍然会有帮助，无论这些集群被隔离到哪个项目中。借助每种环境的文件夹，集群团队可以轻松应用这些种类的政策。这些文件夹还可与聚合日志接收器配合使用，轻松导出每种环境的日志。

您可以根据贵组织的需求对此建议的拓扑轻松进行扩展或简化。例如，规模较小且服务等级目标 (SLO) 较宽松的组织可能会选择将其每种环境的集群保留在单个项目中，在这种情况下，就无需使用每种环境的文件夹。您也可以根据需要减少集群数量。

集中控制网络

如需集中控制网络资源（如子网、路由和防火墙），请使用共享 VPC 网络。 共享 VPC 中的资源可以使用内部 IP 地址跨项目边界安全高效地相互通信。每个共享 VPC 网络均由一个集中式宿主项目定义和拥有，并可供一个或多个服务项目使用。

借助共享 VPC 和 IAM，您可以将网络管理与项目管理分离开来。这种分离有助于您实现最小权限原则。例如，集中式网络团队可以管理网络，而无需对参与项目拥有任何权限。同样，项目管理员可以管理其项目资源，而无需操作共享网络的任何权限。

设置共享 VPC 时，您必须在 VPC 中配置子网及其次要 IP 范围。如需确定子网规模，您需要了解预期的租户数量、预期运行的 Pod 和 Service 数量以及 Pod 的最大大小和平均大小。通过计算所需的总集群容量，您可以了解所需的实例大小，进而确定节点总数。了解节点总数后，您便可以计算总 IP 空间用量，进而确定所需的子网大小。

以下是在设置网络时您还应考虑的一些因素：

• 一个宿主项目最多可以附加 1000 个服务项目，一个组织最多可以有 100 个共享 VPC 宿主项目。

• Node、Pod 和 Service 的 IP 范围都必须是唯一的。您无法创建主要 IP 地址范围和次要 IP 地址范围重叠的子网。

• 指定 GKE 集群的最大 Pod 数和最大 Service 数受集群次要范围的限制。

• 集群中节点的最大数量受集群子网的主要 IP 地址范围大小和集群的 Pod 地址范围大小的限制。

• 为了更全面灵活地控制 IP 地址管理，您可以配置可在一个节点上运行的最大 Pod 数量。减少每个节点的 Pod 数量也会减少每个节点分配的 CIDR 范围，从而减少所需的 IP 地址数量。

您可以借助 GKE IPAM 计算器开源工具来计算集群的子网数。IP 地址管理 (IPAM) 可有效利用 IP 空间/子网，同时避免重叠的范围导致连接选项无法正常运行。

如果租户需要进一步隔离在共享集群（例如专用 Compute Engine 虚拟机）外部运行的资源，他们可以使用自己的 VPC 与由网络团队运行的共享 VPC 建立对等互连连接。这样做可提供额外的安全保障，但会增加复杂性和许多其他限制。如需详细了解对等互连，请参阅使用 VPC 网络对等互连。在以下示例中，所有租户均已选择每种环境共享一个租户 VPC。

创建安全可靠的高可用性集群

如需将您的集群架构设计为兼具高可用性和可靠性，您可以实施以下建议：

• 为每个集群创建一个集群管理项目，以降低项目级配置（例如 IAM 绑定）对众多集群产生不利影响的风险，并帮助隔离配额和结算服务。集群管理项目与租户项目不同，后者供各个租户用于管理其 Google Cloud 资源等。

• 将生产集群设为专用，以停用对节点的访问权限并管理对控制平面的访问权限。同时建议将专用集群用于开发和预演环境。

• 确保集群的控制平面为区域级，以为多租户提供高可用性；对控制平面造成的任何干扰都会影响租户。请注意，运行区域级集群会影响费用。Autopilot 集群已预配置为区域性集群。

• 确保集群中的节点至少跨越三个可用区，以实现可用区级可靠性。如需了解同一区域的各可用区之间的出站流量费用，请参阅网络价格文档。

自动扩缩集群节点和资源

为了满足租户的需求，建议启用自动扩缩功能来让系统自动扩缩集群中的节点。 自动扩缩功能有助于确保系统在各种租户的命名空间部署了繁重工作负载的情况下或在应对区域级服务中断之时，保持良好的运行状况和响应能力。

启用自动扩缩功能时，您可以根据预期的工作负载大小指定集群中的最小和最大节点数。通过指定最大节点数，您可以确保集群中有足够的空间供所有 Pod 使用，无论它们在哪个命名空间中运行。集群自动扩缩功能会根据最小/最大边界重新扩缩节点池，这有助于在系统负载减少时降低运营成本，并避免在可用集群资源不足时 Pod 进入待处理状态。如需确定最大节点数，请确定每个租户所需的最大 CPU 数和最大内存量，然后将这些值加在一起，这样即可获得在所有租户都达到资源用量上限时集群应能够处理的总容量。然后，您可以根据最大节点数并考虑可供集群使用的 IP 子网空间，选择实例大小和数量。

您可以利用 Pod 自动扩缩功能来根据资源需求自动扩缩 Pod。 Pod 横向自动扩缩程序 (HPA) 根据 CPU/内存利用率或自定义指标扩缩 Pod 副本的数量。Pod 纵向自动扩缩 (VPA) 可用于自动扩缩 Pod 资源需求。除非有自定义指标可用，否则不得将 VPA 与 HPA 一起使用，因为两个自动扩缩程序可能会互相竞争。因此，请先使用 HPA，稍后只有在需要时才使用 VPA。

确定集群的大小

在确定集群的大小时，您需要考虑以下几个重要因素：

• 集群的大小取决于您计划运行的工作负载类型。工作负载的密度越高，成本效益越高，但发生资源争用的可能性也会越大。

• 集群的最小规模由其所跨越区域的数量决定：区域级集群有 1 个节点，地区级集群有 3 个节点。

• 对于每个项目，每个区域最多有 50 个集群，每个地区最多有 50 个地区级集群。

• 对于每个集群，未使用 GKE Ingress 控制器时，每个集群最多有 5,000 个节点，每个节点池最多有 1,000 个节点；使用 GKE Ingress 控制器时，每个集群最多有 1,000 个节点，每个节点最多有 110 个 Pod，每个 Pod 最多有 30 万个容器。

安排维护期

为了减少集群/节点升级和维护期间的停机时间，请将维护期安排在非高峰时段内。在升级期间，如果移动工作负载以重新创建节点，则可能会出现暂时性中断。为了确保将此类中断所带来的影响降到最低程度，请将升级作业安排在非高峰时段进行，并对您的应用部署进行设计，使其尽可能无缝处理部分中断。

使用 Ingress 设置 HTTP(S) 负载均衡

为帮助管理租户的已发布 Service 以及管理发往这些 Service 的传入流量，请创建一个 HTTP(s) 负载均衡器以允许每个集群使用一个 Ingress；在这种情况下，每个租户的 Service 均会在该集群的 Ingress 资源中注册。如需创建和配置 HTTP(S) 负载平衡器，您可以创建一个 Kubernetes Ingress 资源来定义流量如何到达您的 Service，以及如何将流量路由到租户的应用。通过将 Service 注册到 Ingress 资源，这些 Service 将会采用一致的命名惯例，并反映同一 Ingress，例如 tenanta.example.com 和 tenantb.example.com。

保护多租户集群

使用网络政策控制 Pod 通信

如需控制集群的每个命名空间中各 Pod 之间的网络通信，请根据租户的要求创建网络政策。初步建议是屏蔽托管不同租户的应用的命名空间之间的流量。您的集群管理员可以应用 deny-all 网络政策来拒绝所有入站流量，以避免一个命名空间中的 Pod 意外将流量发送到其他命名空间中的 Service 或数据库。

例如，以下网络政策会限制从所有其他命名空间到 tenant-a 命名空间的入站流量：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: tenant-a
spec:
  podSelector:
    matchLabels:

  ingress:
  - from:
    - podSelector: {}

使用 GKE Sandbox 运行工作负载

运行不受信任的工作负载的集群比其他集群更容易受到安全漏洞的影响。您可以借助 GKE Sandbox 来强化多租户环境中各工作负载之间的隔离边界的安全性。为管理安全性，我们建议先从 GKE Sandbox 入手，然后使用 Pod 安全政策填补漏洞。

GKE Sandbox 基于开源容器沙盒项目 gVisor 构建，可在容器和主机操作系统之间额外增加一层保护，从而使多租户工作负载得以进一步隔离。容器运行时通常以特权用户身份在节点上运行，在这种情况下，它可以访问对主机内核的大多数系统调用。在多租户集群中，一个恶意租户可以获得对主机内核和其他租户的数据的访问权限。GKE Sandbox 可缓解这些威胁，因为它可减少容器与主机直接交互的需求，从而缩小主机的受攻击面并限制恶意操作者的行动。

GKE Sandbox 在容器和主机操作系统之间提供了两种隔离边界：

• 使用 Go 编写的用户空间内核，可处理系统调用并限制与主机内核的交互。每个 Pod 都有自己的独立用户空间内核。

• 用户空间内核还会在命名空间和 seccomp 过滤系统调用中运行。

创建 Pod 安全政策

如需阻止 Pod 在集群中运行，请创建 Pod 安全政策 (PSP)，以指定 Pod 在集群中必须满足的条件。如需实施 Pod 安全政策控制，您可以启用准入控制器并授权目标 Pod 的服务帐号使用这项政策。您可以在 Kubernetes 基于角色的访问权限控制 (RBAC) 中授权对 Pod 使用政策，方法是将 Pod 的 serviceAccount 绑定到有权使用这些政策的角色。

在定义 PSP 时，我们建议将与 system:authenticated 绑定的政策定义为限制性最强，并根据需要将例外情况中绑定的政策定义为较为宽松。

例如，下面是一项具有限制性的 PSP，这项政策要求用户以非特权用户身份运行、禁止提升至 root 权限，并且需要使用多种安全机制：

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
spec:
  privileged: false
  # Required to prevent escalations to root.
  allowPrivilegeEscalation: false
  # The following is redundant with non-root + disallow privilege
  # escalation, but we can provide it for defense in depth.
  requiredDropCapabilities:
    - ALL
  # Allow core volume types.
  volumes:
    - 'configMap'
    - 'emptyDir'
    - 'projected'
    - 'secret'
    - 'downwardAPI'
    # Assume that persistentVolumes set up by the cluster admin
    # are safe to use.
    - 'persistentVolumeClaim'
  hostNetwork: false
  hostIPC: false
  hostPID: false
  runAsUser:
    # Require the container to run without root privileges.
    rule: 'MustRunAsNonRoot'
  seLinux:
    # Assumes the nodes are using AppArmor rather than SELinux.
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'MustRunAs'
    ranges:
      # Forbid adding the root group.
      - min: 1
        max: 65535
  fsGroup:
    rule: 'MustRunAs'
    ranges:
      # Forbid adding the root group.
      - min: 1
        max: 65535

设置以下参数可避免对容器进行提权：

• 如需确保容器的子级进程获得的权限不能超过其父级进程的权限，请将 allowPrivilegeEscalation 参数设置为 false。

• 如需禁止在容器之外提升权限，请停用对主机命名空间组件（hostNetwork、hostIPC 和 hostPID）的访问权限。这也会阻止窥探同一节点上其他 Pod 的网络活动。

使用 Workload Identity 授予对 Google Cloud 服务的访问权限

为确保安全地向工作负载授予对 Google Cloud 服务的访问权限，请在集群中启用 Workload Identity。Workload Identity 可帮助管理员管理 Kubernetes 工作负载用于访问 Google Cloud 服务的 Kubernetes 服务帐号。创建启用了 Workload Identity 的集群时，系统会为集群所在的项目建立一个身份命名空间。通过该身份命名空间，集群可以将 Kubernetes 服务帐号名称映射到虚拟 Google 服务帐号句柄（用于对租户 Kubernetes 服务帐号进行 IAM 绑定），从而自动验证 GKE 应用服务帐号的身份。

限制对控制平面的网络访问

为了保护您的控制平面，请仅允许已获授权的网络进行访问。在 GKE 中，启用授权的网络后，您可以向多达 50 个 CIDR 范围授权，并仅允许这些范围内的 IP 地址访问您的控制层面。GKE 已使用传输层安全协议 (TLS) 和身份验证机制来提供从公共互联网对控制层面端点的安全访问。您可以通过授权网络进一步将访问限制到一组指定 IP 地址。

租户预配

创建租户项目

如需托管租户的非集群资源，请为每个租户创建一个服务项目。这些服务项目包含特定于租户应用的逻辑资源（例如日志、监控、存储分区、服务帐号等）。所有租户服务项目都会连接到租户宿主项目中的共享 VPC。

使用 RBAC 优化租户访问权限

您可以使用 Kubernetes RBAC 为租户定义更精细的集群资源访问权限。在最初通过 IAM 授予租户群组的只读权限之外，为每个租户群组定义命名空间级的 Kubernetes RBAC 角色和绑定。

之前我们确定了两个租户群组：租户管理员和租户开发者。 对于这些群组，我们将定义以下 RBAC 角色和访问权限：

除了创建 RBAC 角色和绑定来为 Google Workspace 或 Cloud Identity 群组分配其命名空间内的各种权限之外，租户管理员通常还需要能够管理这些群组中的用户。为此，您可以向租户管理员委派 Google Workspace 或 Cloud Identity 权限来管理其各自的群组成员资格，也可以让租户管理员与您组织中拥有 Google Workspace 或 Cloud Identity 权限的团队合作处理这些更改，究竟选择哪种方式要视贵组织的要求而定。

您可以将 IAM 和 RBAC 权限与命名空间结合使用，以限制用户与 Cloud Console 上的集群资源的交互。如需了解详情，请参阅按命名空间启用访问权限和查看集群资源。

使用 Google 群组绑定权限

如需高效地管理集群中的租户权限，您可以将 RBAC 权限绑定到您的 Google 群组。 这些群组的成员资格由您的 Google Workspace 管理员维护，因此您的集群管理员不需要详细了解您的用户。

举例来说，假设我们有一个 tenant-admins@mydomain.com Google 群组，并且 admin1@mydomain.com 用户是该群组的成员，那么以下绑定可为该用户提供对 tenant-a 命名空间的管理员访问权限：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: tenant-a
  name: tenant-admin-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: tenant-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: "tenant-admins@mydomain.com"

创建命名空间

如需在同一集群上的各租户之间提供逻辑隔离，请实施命名空间。在 Kubernetes RBAC 流程中，集群管理员会为每个租户群组创建命名空间。租户管理员在其各自的租户命名空间内管理用户（租户开发者）。然后，租户开发者可以使用集群和租户特定的资源来部署其应用。

避免达到命名空间限制

理论上，一个集群中最多可以包含 10000 个命名空间，但在实践中，有很多因素可能会导致您无法达到这一限制。例如，在达到命名空间数量上限之前，您可能已达到整个集群的最大 Pod 数量 (150000) 和最大节点数量 (5000)；Secret 数量等其他因素可能会进一步降低有效限制。因此，除非实验表明您的使用场景运行良好，否则建议一次仅尝试接近一个限制条件的理论限值，并与其他限制保持大约一个数量级，这是一个很好的初步经验法则。如果您需要的资源量超过单个集群可支持的数量，则应创建更多集群。如需了解 Kubernetes 可伸缩性息，请参阅 Kubernetes 可伸缩性阈值一文。

实现命名空间命名标准化

如需简化跨多个托管在不同集群中的环境进行的部署，可以对您使用的命名空间命名惯例进行标准化。例如，避免将环境名称（开发、预演和生产）与命名空间名称绑定在一起，而应在环境之间使用相同的名称。使用相同名称可以避免各种环境使用不同的配置文件。

为租户工作负载创建服务帐号

您可以为租户命名空间中的每个不同工作负载创建特定于租户的 Google 服务帐号。这样做可以提供安全保障，确保租户能够管理其在各自的命名空间中拥有/部署的工作负载的服务帐号。每个命名空间的 Kubernetes 服务帐号会通过 Workload Identity 映射到一个 Google 服务帐号。

实施资源配额

为确保所有共享同一集群的租户都能够公平地访问集群资源，请实施资源配额。您可以根据每个租户部署的 Pod 数量以及每个 Pod 所需的内存量和 CPU 数量，为每个命名空间创建资源配额。

以下示例定义了一个资源配额，其中，tenant-a 命名空间中的 Pod 最多可以请求 16 个 CPU 和 64 GB 内存，且 CPU 和内存的上限分别为 32 个和 72 GB。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-a
spec:
  hard: "1"
    requests.cpu: "16"
    requests.memory: 64Gi
    limits.cpu: "32"
    limits.memory: 72Gi

监控、日志记录和用量

跟踪用量指标

如需获取集群中各个命名空间和标签的费用明细，您可以启用 GKE 用量计量功能。GKE 用量计量功能会跟踪有关集群工作负载的资源请求和资源用量的信息，您可以按命名空间和标签进一步细分这些信息。借助 GKE 用量计量功能，您可以估算共享同一集群的各部门/团队的费用明细，了解个别应用（甚至单个应用的组件）的使用规律，帮助集群管理员对用量高峰进行分类，并提供更好的容量规划和预算。

在多租户集群上启用 GKE 用量计量功能时，资源用量记录将会写入 BigQuery 表格中。您可以将租户特定的指标导出到相应租户项目中的 BigQuery 数据集，以便审核人员对这些指标进行分析，进而确定费用明细。审核人员可以使用开箱即用的 Google 数据洞察模板创建信息中心，以直观呈现 GKE 用量计量数据。

提供特定于租户的日志

如需为租户提供特定于其项目工作负载的日志数据，请使用 Cloud Monitoring 的日志路由器。为了创建特定于租户的日志，集群管理员会创建一个接收器，以将日志条目导出到租户的 Google Cloud 项目中创建的日志存储分区。如需详细了解如何配置这些类型的日志，请参阅 GKE 上的多租户日志记录。

提供特定于租户的监控信息

如需提供特定于租户的监控信息，集群管理员可以使用专用命名空间，其中包含一个 Prometheus to Stackdriver 适配器 (prometheus-to-sd) 以及一项按命名空间进行的配置。此配置可确保租户只能在其项目中监控自己的指标。不过，这种设计的缺点是管理您自己的 Prometheus 部署会产生额外费用。

以下是您在提供特定于租户的监控信息时可以考虑使用的其他方式：

• 团队接受 Cloud Monitoring 环境中的共享租户，并允许租户查看项目中的所有指标。

• 为每个租户部署一个 Grafana 实例，用于与共享 Cloud Monitoring 环境进行通信。配置 Grafana 实例，使其仅查看来自特定命名空间的指标。这种方式的缺点是管理这些额外的 Grafana 部署会产生费用和开销。 如需了解详情，请参阅在 Grafana 中使用 Cloud Monitoring。

核对清单摘要

下表汇总了在企业组织中创建多租户集群时建议执行的任务：