集群多租户

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

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

什么是多租户?

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

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

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

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

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

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

多租户使用用例

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

企业多租户

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

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

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

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

SaaS 提供商多租户

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

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

多租户政策实施

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

访问权限控制

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

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

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

网络政策

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

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

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

资源配额

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

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

Pod 安全政策

PodSecurityPolicies 是一种 Kubernetes API 类型,用于验证创建和更新 Pod 的请求。 PodSecurityPolicies 定义 Pod 规范中的安全敏感字段的默认值和要求。 您可以创建政策来限制部署那些会访问主机文件系统、网络、PID 命名空间、等资源的 Pod。

如需了解详情,请参阅 PodSecurityPolicies 方法指南

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 添加相应容忍设置来访问专用节点池。仅使用节点污点和容忍机制不足以在具有不受信任的租户的集群上安全地强制执行政策。

如需了解如何使用节点污点机制来控制调度,请参阅节点污点方法指南页面

后续步骤