集群多租户

Autopilot Standard

本页面介绍 Google Kubernetes Engine (GKE) 上的集群多租户。这包括由单个组织的不同用户共享的集群，以及由软件即服务 (SaaS) 应用的客户专用实例共享的集群。集群多租户是管理许多单租户集群的替代方案。

本页面还总结了可用于管理多租户集群的 Kubernetes 和 GKE 功能。

什么是多租户？

多租户集群由多个用户和/或工作负载共享，这些用户和/或工作负载被称为“租户”。多租户集群的运营方必须将租户彼此隔离，以最大限度地减少被盗用的租户或恶意租户可能对集群和其他租户造成的损害。此外，必须在租户之间公平地分配集群资源。

在规划多租户架构时，您应该考虑 Kubernetes 中的资源隔离层：集群、命名空间、节点、Pod 和容器。您还应该考虑在租户之间共享不同类型资源的安全隐患。例如，将来自不同租户的 Pod 调度到同一节点上可以减少集群中所需的机器数量。另一方面，您可能需要阻止某些工作负载共置。例如，您可能不允许来自组织外部的不受信任的代码与处理敏感信息的容器在同一节点上运行。

虽然 Kubernetes 不能保证租户之间完全安全地隔离，但它为特定使用场景提供了足够的相关功能。您可以将每个租户及其 Kubernetes 资源分隔到各自的命名空间中。然后，您可以使用政策来强制执行租户隔离。政策通常按命名空间划分，可用于限制 API 访问、资源使用以及允许容器执行的操作。

多租户集群的租户共享以下资源：

扩展程序、控制器、插件和自定义资源定义 (CRD)。
集群控制平面。这意味着集群操作、安全性和审核是集中管理的。

与运营多个单租户集群相比，运营多租户集群有几个优点：

减少管理开销
减少资源碎片
新租户无需等待集群创建

多租户使用场景

本部分介绍如何为各种多租户使用用例配置集群。

企业多租户

在企业环境中，集群的租户是组织内的不同团队。通常，每个租户对应一个命名空间，这是因为每个租户对应一个集群或每个租户对应一个 Google Cloud 项目的多租户替代模型更难管理。同一个命名空间内的网络流量不受限制，必须明确允许命名空间之间的网络流量。可以使用 Kubernetes 网络政策强制实施这些政策。

集群的用户根据其权限分为三种不同的角色：

集群管理员: 此角色适用于在整个集群中管理所有租户的管理员。集群管理员可以创建、读取、更新和删除任何政策对象。他们可以创建命名空间并将其分配给命名空间管理员。
命名空间管理员: 此角色适用于特定单一租户的管理员。命名空间管理员可以管理其命名空间中的用户。
开发者: 拥有此角色的成员可以创建、读取、更新和删除命名空间内的非政策对象，如 Pod、Job 和 Ingress。开发者只在他们有权访问的命名空间中拥有这些权限。

如需了解如何为企业组织设置多个多租户集群，请参阅企业多租户最佳做法。

SaaS 提供商多租户

SaaS 提供商集群的租户是应用的各个客户专用实例，以及 SaaS 的控制平面。要充分利用按命名空间划分的政策，应将各个应用实例安排到其各自的命名空间中，SaaS 控制平面的组件也应如此。最终用户无法直接与 Kubernetes 控制平面交互，而是使用 SaaS 的界面，由后者与 Kubernetes 控制平面进行交互。

例如，博客平台可以在多租户集群上运行。在这种情况下，租户是每个客户的博客实例和平台自己的控制平面。平台的控制平面和每个托管博客都将在不同的命名空间中运行。客户将通过平台的界面来创建和删除博客、更新博客软件版本，但无法了解集群的运作方式。

多租户政策实施

GKE 和 Kubernetes 提供了几项可用于管理多租户集群的功能。以下部分概述了这些功能。

访问权限控制

GKE 有两个访问权限控制系统：Identity and Access Management (Cloud IAM) 和基于角色的访问权限控制 (RBAC)。IAM 是 Google Cloud 的访问权限控制系统，用于管理 Google Cloud 资源的身份验证和授权。您可以使用 IAM 授予用户访问 GKE 和 Kubernetes 资源的权限。RBAC 内置于 Kubernetes 中，并为集群中的特定资源和操作授予细化的权限。

如需详细了解这些选项以及何时使用每个选项，请参阅访问权限控制概览。

如需了解如何使用这些访问权限控制系统，请参阅 RBAC 方法指南和 IAM 方法指南。

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

网络政策

通过集群网络政策，您可以控制集群的 Pod 之间的通信。政策指定 Pod 可以与哪些命名空间、标签和 IP 地址范围进行通信。

如需查看在 GKE 上启用网络政策强制执行的说明，请参阅网络政策方法指南。

要学习如何编写网络政策，请参考网络政策教程。

资源配额

资源配额用于管理命名空间中对象使用的资源量。您可以按 CPU 和内存用量或对象数量来设置配额。通过资源配额，您可以确保租户不会使用超过其分配份额的集群资源。

如需了解详情，请参阅资源配额文档。

基于政策的 Pod 准入控制

如需阻止违反安全边界的 Pod 在集群中运行，请使用准入控制器。准入控制器可以根据您定义的政策检查 Pod 规范，并且可以阻止违反这些政策的 Pod 在集群中运行。

GKE 支持以下类型的准入控制：

Policy Controller：声明预定义政策或自定义政策，并使用舰队在集群中大规模强制执行政策。Policy Controller 是开源 Gatekeeper Open Policy Agent 的实现，是 GKE Enterprise 的一项功能。
PodSecurity 准入控制器：强制执行与各个集群或特定命名空间中的 Pod 安全标准对应的预定义政策。

Pod 反亲和性

您可以利用 Pod 反亲和性来防止不同租户的 Pod 被调度到同一节点上。反亲和性限制以 Pod 标签为基础。例如，下面的 Pod 规范描述了一个标签为 "team": "billing" 的 Pod，以及一个阻止该 Pod 与没有该标签的 Pod 调度到一起的反亲和性规则。

apiVersion: v1
kind: Pod
metadata:
  name: bar
  labels:
    team: "billing"
spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - topologyKey: "kubernetes.io/hostname"
        labelSelector:
          matchExpressions:
          - key: "team"
            operator: NotIn
            values: ["billing"]

这种做法的缺点是恶意用户可以通过将 team: billing 标签添加到任意 Pod 来规避规则。仅使用 Pod 反亲和性机制不足以在具有不受信任的租户的集群上安全地强制执行政策。

如需了解详情，请参阅 Pod 反亲和性文档。

使用污点和容忍机制来实现专用节点

节点污点是控制工作负载调度的另一种方法。您可以使用节点污点来将专用节点留给某些租户使用。例如，您可以将配备 GPU 的节点专门留给那些工作负载需要 GPU 的特定租户。对于 Autopilot 集群，仅支持工作负载分离支持节点容忍设置。根据需要，节点自动预配功能会自动添加节点污点。

如需将某个节点池专门留给某个租户，请将具有 effect: "NoSchedule" 的污点应用于该节点池。然后，只有具备相应容忍设置的 Pod 可以被调度到该节点池中的节点。

这种做法的缺点是恶意用户可以通过为其 Pod 添加相应容忍设置来访问专用节点池。仅使用节点污点和容忍机制不足以在具有不受信任的租户的集群上安全地强制执行政策。

如需了解详情，请参阅 Kubernetes 文档中的污点和容忍。

后续步骤

阅读企业级多租户最佳做法。