编辑

通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

多租户的 Azure Kubernetes 服务 (AKS) 注意事项

Azure
Azure Kubernetes 服务 (AKS)

Azure Kubernetes 服务 (AKS) 通过减少 Azure 云平台的运营开销，简化了在 Azure 中部署托管 Kubernetes 群集的过程。 作为一个托管的 Kubernetes 服务，Azure 可以自动处理运行状况监视和维护等关键任务。 由 Azure 平台来管理 AKS 控制平面，你只需为运行应用程序的 AKS 节点付费。

AKS 群集可通过不同的方案和方式在多个租户之间共享。 在某些情况下，不同的应用程序可以在同一群集中运行。 在其他情况下，同一应用程序的多个实例可以在同一共享群集中运行，每个租户一个实例。 所有这些类型的共享通常使用概括性术语多租户进行描述。 Kubernetes 没有一流的最终用户或租户概念。 不过，它提供了多种功能，可帮助你管理不同的租户要求。

本文介绍在构建多租户系统时非常有用的一些 AKS 功能。 有关 Kubernetes 多租户的常规指南和最佳做法，请参阅 Kubernetes 文档中的多租户。

多租户类型

确定如何在多个租户之间共享 AKS 群集的第一步是评估可用的模式和工具。 一般情况下，Kubernetes 群集中的多租户主要分为两类，尽管仍有许多差异。 Kubernetes 文档介绍了多租户的两个常见用例：多个团队和多个客户。

多个团队

多租户的一种常见形式是在组织内的多个团队之间共享群集。 每个团队都可以部署、监视和操作一个或多个解决方案。 这些工作负载通常需要相互通信，并与位于同一群集或其他托管平台的其他内部或外部应用程序通信。

此外，这些工作负载需要与托管在同一群集中或作为 Azure 上的 PaaS 服务运行的服务进行通行，例如关系数据库、NoSQL 存储库或消息传送系统。

在此方案中，团队成员通常通过 kubectl 等工具直接访问 Kubernetes 资源。 或者，成员可通过 GitOps 控制器（如 Flux 和 Argo CD）或其他类型的发布自动化工具进行间接访问。

有关此方案的详细信息，请参阅 Kubernetes 文档中的多个团队。

多个客户

多租户的另一种常见形式通常涉及服务型软件 (SaaS) 供应商。 或者，服务提供商为其客户运行一个工作负载的多个实例，这些实例被视为独立的租户。 在此方案中，客户不能直接访问 AKS 群集，而只能访问自己的应用程序。 此外，他们甚至不知道应用程序在 Kubernetes 上运行。 成本优化通常是一个关键问题。 服务提供商使用 Kubernetes 策略（如资源配额和网络策略）确保工作负载彼此充分隔离开来。

有关此方案的详细信息，请参阅 Kubernetes 文档中的多个客户。

隔离模型

根据 Kubernetes 文档，多租户 Kubernetes 群集由多个用户和工作负载（通常称为租户）共享。 此定义包括由组织中不同团队或部门共享的 Kubernetes 群集。 它还包含由服务型软件 (SaaS) 应用程序的针对每个客户的实例共享的群集。

群集多租户是管理许多单租户专用群集的替代方法。 多租户 Kubernetes 群集的操作员必须将租户相互隔离开。 此隔离可最大程度地减少已发生泄露的或恶意的租户对群集以及对其他租户造成损害。

当多个用户或团队共享节点数量固定的同一群集时，可能存在某个团队使用的资源超出平均份额的问题。 资源配额是管理员用于解决此问题的工具。

根据隔离提供的安全级别，我们可以区分软多租户和硬多租户。

  • 软多租户适用于单个企业，其中的租户是相互信任的不同团队或部门。 在此方案中，隔离旨在保证工作负载完整性、协调不同内部用户组之间的群集资源，并防范可能的安全攻击。
  • 硬多租户用于描述异类租户彼此不信任的情况，通常是从安全性和资源共享角度来看。

在计划构建多租户 Azure Kubernetes 服务 (AKS) 群集时，应考虑 Kubernetes 提供的资源隔离层和多租户：

  • 群集
  • 命名空间
  • 节点池或节点
  • Pod
  • 容器

此外，还应考虑在多个租户之间共享不同资源带来的安全影响。 例如，在同一节点上计划不同租户的 Pod 可以减少群集中所需的计算机数量。 另一方面，可能需要防止共置特定的工作负载。 例如，你可能不允许来自组织外部的不受信任的代码与处理敏感信息的容器在同一节点上运行。

尽管 Kubernetes 无法保证完全隔离租户，但它提供的功能可能足以满足特定用例需求。 最佳做法是将每个租户及其 Kubernetes 资源隔离到各自的命名空间中。 然后可使用 Kubernetes 基于角色的访问控制 (RBAC) 和网络策略强制实施租户隔离。 例如，下图显示了一个典型的 SaaS 提供商模型，在该模型中，系统在同一群集上托管同一应用程序的多个实例，其中每个租户一个实例。 每个应用程序都分别位于单独的命名空间中。

此图显示一个 SaaS 提供程序模型，该模型托管同一群集中同一应用程序的多个实例。

可通过多种方式使用 Azure Kubernetes 服务 (AKS) 设计和生成多租户解决方案。 在基础结构部署、网络拓扑和安全性方面，每个方法都各有利弊。 这些方法会影响隔离级别、实现工作量、操作复杂性和成本。 可根据需求在控制平面和数据平面中应用租户隔离。

控制平面隔离

如果在控制平面级别应用隔离，可保证不同的租户无法访问或影响彼此的资源，例如 Pod 和服务。 此外，也不会影响其他租户应用程序的性能。 有关详细信息，请参阅 Kubernetes 文档中的控制平面隔离。 在控制平面级别实现隔离的最佳方式是将每个租户的工作负载及其 Kubernetes 资源隔离到单独的命名空间中。

根据 Kubernetes 文档，命名空间是一个抽象概念，用于支持单个群集中资源组的隔离。 命名空间可用于隔离共享 Kubernetes 群集的租户工作负载：

  • 命名空间允许自己的虚拟工作区内存在不同的租户工作负载，而不会有影响彼此工作的风险。 组织内的各个团队可使用命名空间将他们的项目相互隔离，因为他们可在不同命名空间中使用相同的资源名称，而不会有名称重叠的风险。
  • RBAC 角色和角色绑定是命名空间范围的资源，团队可使用这些资源来限制租户用户和进程只能访问其命名空间中的资源和服务。 不同的团队可以定义角色，以将权限或功能列表分组到单个名称下。 然后将这些角色分配给用户帐户和服务帐户，从而确保只有授权标识才能访问给定命名空间中的资源。
  • CPU 和内存的资源配额是命名空间对象。 团队可使用资源配额来确保共享同一群集的工作负载与系统资源消耗充分隔离开来。 此方法可确保在单独命名空间中运行的每个租户应用程序都有运行所需的资源，并避免可能会影响共享同一群集的其他租户应用程序的近邻干扰问题。
  • 网络策略是命名空间对象，团队可采用此类策略来强制指定给定租户应用程序允许哪些网络流量。 可使用网络策略从网络角度来分隔共享同一群集的不同工作负载。
  • 在不同命名空间中运行的团队应用程序可以使用不同的服务帐户访问同一群集、外部应用程序或托管服务中的资源。
  • 使用命名空间提高控制平面级别的性能。 如果共享群集中的工作负载组织到多个命名空间中，Kubernetes API 在运行操作时要搜索的项更少。 这种组织方式可以降低对 API 服务器的调用延迟，并提高控制平面的吞吐量。

有关命名空间级别的隔离的详细信息，请参阅 Kubernetes 文档中的以下资源：

数据平面隔离

数据平面隔离可确保不同租户的 Pod 和工作负载与彼此充分隔离。 有关详细信息，请参阅 Kubernetes 文档中的数据平面隔离。

网络隔离

在 Kubernetes 中运行最新的基于微服务的应用程序时，通常想要控制哪些组件可以相互通信。 默认情况下，AKS 群集中的所有 Pod 都可以无限制地发送和接收流量，包括共享同一群集的其他应用程序。 为了提高安全性，可定义网络规则来控制流量流。 网络策略是一种 Kubernetes 规范，用于为 Pod 之间的通信定义访问策略。 可使用网络策略来分隔共享同一群集的租户应用程序之间的通信。

Azure Kubernetes 服务 (AKS) 提供两种方式来实现网络策略：

  1. Azure 有自己的网络策略实现，称为 Azure 网络策略。
  2. Calico 网络策略是一种由 Tigera 构建的开源网络和网络安全解决方案。

这两个实现都使用 Linux IPTables 来实施指定的策略。 网络策略被转换为允许和禁止的 IP 对集。 然后，这些对将编程为 IPTable 筛选规则。 对于配置有 Azure CNI 网络插件的 AKS 群集，只能使用 Azure 网络策略。 但是，Calico 网络策略同时支持 Azure CNI 和 kubenet。 有关详细信息，请参阅在 Azure Kubernetes 服务中使用网络策略保护 Pod 之间的流量。

有关详细信息，请参阅 Kubernetes 文档中的网络隔离。

存储隔离

Azure 提供一组丰富的托管型平台即服务 (PaaS) 数据存储库（如 Azure SQL 数据库和 Azure Cosmos DB），以及可用作工作负载的永久性卷的其他存储服务。 在共享 AKS 群集上运行的租户应用程序可以共享数据库或文件存储，也可以使用专用数据存储库和存储资源。 有关在多租户方案中管理数据的不同策略和方法的详细信息，请参阅多租户解决方案中存储和数据的体系结构方法。

Azure Kubernetes 服务 (AKS) 上运行的工作负载也可以使用永久性卷来存储数据。 在 Azure 上，可创建永久性卷 作为 Azure 存储支持的 Kubernetes 资源。 可手动创建数据卷并将其直接分配给 Pod，也可让 AKS 使用永久性卷声明自动创建数据卷。 AKS 提供内置存储类来创建 Azure 磁盘、Azure 文件存储和 Azure NetApp 文件支持的永久性卷。 有关详细信息，请参阅 AKS 中应用程序的存储选项。 出于安全性和复原能力的原因，应避免通过 emptyDir 和 hostPath 在代理节点上使用本地存储。

当 AKS 内置存储类不适合一个或多个租户时，可生成自定义存储类来满足不同的租户要求。 这些要求包括卷大小、存储 SKU、服务级别协议 (SLA)、备份策略和定价层。

例如，可为每个租户配置一个自定义存储类。 然后可使用自定义存储类将标记应用于租户命名空间中创建的任何永久性卷，以便向租户收取费用。 有关此方案的详细信息，请参阅在 Azure Kubernetes 服务 (AKS) 中使用 Azure 标记。

有关详细信息，请参阅 Kubernetes 文档中的存储隔离。

节点隔离

可以将租户工作负载配置为在单独的代理节点上运行，以避免“嘈杂邻居”问题并降低信息泄露风险。 在 AKS 中，可为在隔离、安全性、法规合规性和性能方面有严格要求的租户创建单独的群集，或只创建专用节点池。

可使用污点、容忍度、节点标签、节点选择器和节点相关性来限制租户的 Pod 只能在一组特定节点或节点池上运行。

通常，AKS 在各个级别提供工作负载隔离：

  • 在内核级别，通过在共享代理节点上的轻型虚拟机中运行租户工作负载，并使用基于 Kata 容器的 Pod 沙盒。
  • 在物理级别，通过在专用群集或节点池上托管租户应用程序。
  • 在硬件级别，通过在 Azure 专用主机上运行租户工作负载，保证代理节点 VM 运行专用物理计算机。 硬件隔离可确保没有其他虚拟机放置在专用主机上，这为租户工作负载提供了额外的隔离层。

你可以结合使用这些技术。 例如，可以在 Azure 专用主机组中运行每租户群集和节点池，从而在硬件级别实现工作负载隔离和物理隔离。 还可以创建支持联邦信息处理标准 (FIPS)、机密虚拟机 (CVM) 或基于主机的加密的共享节点池或每租户节点池。

通过节点隔离，可以轻松将一组节点或节点池与单个租户关联，并向该租户收取费用。 这与你的解决方案采用的租户模型密切相关。

有关详细信息，请参阅 Kubernetes 文档中的节点隔离。

租户模型

Azure Kubernetes 服务 (AKS) 提供了更多类型的节点隔离和租户模型。

自动单租户部署

在自动化单租户部署模型中，为每位租户部署一组专用资源，如以下示例所示：

该图显示了三位租户，各自具有单独的部署。

每个租户工作负载都在一个专用 AKS 群集中运行，并访问一组不同的 Azure 资源。 通常，使用此模型生成的多租户解决方案广泛使用基础结构即代码 (IaC)。 例如，Bicep、Azure 资源管理器、Terraform 或 Azure 资源管理器 REST API 有助于启动和协调租户专用资源的按需部署。 需要为每位客户预配完全独立的基础结构时，可使用此方法。 规划部署时，请考虑使用部署标记模式。

优点：

  • 此方法的主要优势在于，每个租户 AKS 群集的 API 服务器是独立的。 此方法可保证各租户在安全性、网络和资源消耗级别方面是完全隔离的。 设法控制容器的攻击者将只能访问属于单个租户的容器和所装载的卷。 完全隔离租户模型对于某些法规合规性开销较高的客户至关重要。
  • 租户不太可能影响彼此的系统性能，这可避免近邻干扰问题。 此注意事项包括针对 API 服务器的流量。 API 服务器是任何 Kubernetes 群集中的关键共享组件。 自定义控制器会针对 API 服务器生成大量不受监管的流量，这可能会导致群集不稳定。 这种不稳定会导致请求失败、超时和 API 重试风暴。 运行时间 SLA（服务级别协议）功能支持横向扩展 AKS 群集的控制平面以满足流量需求。 不过，对那些在工作负载隔离方面有强烈要求的客户而言，预配专用群集可能是更好的解决方案。
  • 可以逐步在租户之间推出更新和更改，从而减少系统范围服务中断的可能性。 可以轻松地向租户收取 Azure 费用，因为每个资源都由单个租户使用。

风险：

  • 成本效益低，因为每个租户都使用一组专用资源。
  • 持续维护可能非常耗时，因为需要在多个 AKS 群集之间复制（每个租户都有一个群集）。 请考虑自动执行操作过程，并逐步通过环境应用更改。 如果还考虑其他跨部署操作，例如整个资产的报告和分析，将会有所帮助。 同样，请确保规划如何跨多个部署查询和操作数据。

完全多租户部署

在完全多租户部署中，单个应用程序处理所有租户的请求，并且所有 Azure 资源都是共享的，包括 AKS 群集。 在这种情况下，你只需要部署、监视和维护一组基础结构。 所有租户都使用该资源，如下图所示：

该图显示了三位租户，均使用一个共享部署。

优点：

  • 这种模型很有吸引力，因为使用共享组件运行解决方案的成本较低。 使用此租户模型时，可能需要部署更大的 AKS 群集，并为任何共享数据存储库采用更高的 SKU 来维持所有租户资源（如数据存储库）生成的流量。

风险：

  • 在这种情况下，单个应用程序处理所有租户的请求。 你应设计和实施安全措施，以防租户的调用充斥应用程序。 这些调用可能会降低整个系统的速度，并影响所有租户。
  • 如果流量配置文件是高度可变的，则应配置 AKS 群集自动缩放程序来改变 Pod 和代理节点的数量。 根据系统资源使用情况（例如 CPU 和内存）进行配置。 或者，可根据自定义指标横向扩展和横向缩减 Pod 和群集节点的数量。 例如，可浏览使用 Kubernetes Event-driven Autoscaling (KEDA) 的外部消息传送系统的待处理请求数或指标。
  • 请确保将每个租户的数据分隔并实施安全措施，以避免不同租户之间出现数据泄漏。
  • 请确保根据各个租户的实际使用情况，跟踪 Azure 费用并将其关联到各个租户。 第三方解决方案（如 kubecost）可帮助你计算和细分不同团队和租户的费用。
  • 单个部署的维护更加简单，因为只需更新一组 Azure 资源并维护单个应用程序。 但是，由于对基础结构或应用程序组件所做的任何更改可能会影响整个客户群，因此风险也往往更高。
  • 还应考虑规模限制。 如果拥有一组共享资源，则更有可能达到 Azure 资源规模限制。 为避免达到资源配额限制，可以考虑将租户分布到多个 Azure 订阅中。

水平分区部署

或者，可考虑对多租户 Kubernetes 应用程序进行水平分区。 此方法包括在所有租户之间共享一些解决方案组件，并为各个租户部署专用资源。 例如，可以生成单个多租户 Kubernetes 应用程序，然后为每位租户创建一个单独的数据库，如下图所示：

该图显示三个租户，每个租户都使用一个专用数据库和一个共享 Kubernetes 应用程序。

优点：

  • 水平分区部署可帮助缓解近邻干扰问题。 如果已确定 Kubernetes 应用程序上的大部分流量负载是由特定组件造成的，请考虑此方法，你可为每个租户单独部署这些特定组件。 例如，数据库可能会吸收系统的大部分负载，因为查询负载很高。 如果单个租户向解决方案发送大量请求，则数据库的性能可能会受到负面影响，但其他租户的数据库（和共享组件，如应用层）仍不受影响。

风险：

  • 使用水平分区的部署，仍需考虑组件的自动部署和管理，尤其是单个租户使用的组件。
  • 对于那些由于内部策略或合规性原因而无法与其他租户共享资源的客户，此模型可能无法提供所需的隔离级别。

垂直分区部署

可使用将租户垂直分区到多个 AKS 群集或节点池的混合模型，充分利用单租户模型和完全多租户模型的优势。 与前两种租户模型相比，此方法具有以下优势：

  • 可结合使用单租户部署和多租户部署。 例如，可让大多数客户在多租户基础结构上共享 AKS 群集和数据库。 不过，还可以为那些需要更高性能和隔离程度的客户部署单租户基础结构。
  • 可以将租户部署到多个区域 AKS 群集（可能具有不同的配置）。 如果租户分布在不同的地理位置，则此方法最为有效。

可实现此租户模型的不同变体。 例如，可选择以不同的费用提供具有不同层级功能的多租户解决方案。 定价模型可以提供多个 SKU，每个 SKU 在资源共享、性能、网络和数据隔离方面提供递增的性能和隔离级别。 请考虑以下层级：

  • 基本层：租户请求由与其他租户共享的单个多租户 Kubernetes 应用程序来处理。 数据存储在所有基本层租户共享的一个或多个数据库中。
  • 标准层：租户请求由在单独命名空间中运行的专用 Kubernetes 应用程序来处理，单独的命名空间在安全性、网络、资源消耗方面提供隔离边界。 所有租户的应用程序（每个租户一个应用程序）与其他标准层客户共享同一 AKS 群集和节点池。
  • 高级层：租户应用程序在专用节点池或 AKS 群集中运行，以保证更高级的服务级别协议、更佳的性能和更高程度的隔离。 此层可以根据用于托管租户应用程序的代理节点的数量和 SKU，提供灵活的成本模型。 可以使用 Pod 沙盒作为通过专用群集或节点池隔离不同租户工作负载的替代解决方案。

下图显示以下方案：租户 A 和 B 在共享 AKS 群集中运行，而租户 C 在单独的 AKS 群集中运行。

该图显示三个租户。租户 A 和 B 共享一个 AKS 群集。租户 C 有一个专用 AKS 群集。

同样，下图显示以下方案：租户 A 和 B 在同一节点池中运行，而租户 C 在一个专用节点池中运行。

该图显示三个租户。租户 A 和 B 共享一个节点池。租户 C 有一个专用节点池。

此模型还可以为不同的层级提供不同的服务级别协议。 例如，基本层可以提供 99.9% 的运行时间，标准层可以提供 99.95% 的运行时间，而高级层可以提供 99.99% 的运行时间。 可以通过支持更高可用性目标的服务和功能来实现更高的服务级别协议 (SLA)。

优点：

  • 由于仍在共享基础结构，因此仍可获得共享多租户部署的一些成本优势。 可以部署在多个基本层和标准层租户应用程序之间共享的群集和节点池，这些应用程序对代理节点使用更便宜的 VM 大小。 这种方法可保证更高的密度并节省成本。 对于高级层客户，可部署价格更高且具有更大 VM 大小和最大数量的 Pod 副本和节点的 AKS 群集和节点池。
  • 可在专用系统模式节点池中运行系统服务，例如 CoreDNS、Konnectivity 或 Azure 应用程序网关入口控制器。 可使用污点、容忍度、节点标签、节点选择器和节点相关性在一个或多个用户模式节点池上运行租户应用程序。
  • 可使用污点、容忍度、节点标签、节点选择器和节点相关性来运行共享资源。 例如，可在专用节点池上配置入口控制器或消息传送系统，以及特定的 VM 大小、自动缩放程序设置和可用性区域支持。

风险：

  • 需要将 Kubernetes 应用程序设计为同时支持多租户部署和单租户部署。
  • 如果计划允许在基础结构之间进行迁移，则需要考虑如何将客户从多租户部署迁移到自己的单租户部署。
  • 需要一致的策略和单一虚拟管理平台（一个视点）来监视和管理更多 AKS 群集。

自动缩放

为满足租户应用程序生成的流量需求，可启用群集自动缩放程序来缩放 Azure Kubernetes 服务 (AKS) 的代理节点。 自动缩放可帮助系统在以下情况下正常响应：

  • 流量负载在一年内的特定工作时间或时段内增加。
  • 部署到群集的租户或共享负载过重。
  • 由于区域性服务中断，代理节点不可用。

为节点池启用自动缩放时，根据预期的工作负载大小指定节点数上限和下限。 通过配置节点数上限，可确保为群集中所有租户 Pod 提供足够的空间，而不管它们在哪个命名空间内运行。

流量增加时，群集自动缩放会添加新代理节点，以避免 Pod 因 CPU 和内存资源不足而进入挂起状态。

同样，当负载减少时，群集自动缩放会根据指定的边界减少节点池中的代理节点数，这有助于降低运营成本。

可根据资源需求使用 Pod 自动缩放来自动缩放 Pod。 水平 Pod 自动缩放程序 (HPA) 基于 CPU/内存利用率或自定义指标自动缩放 Pod 副本数。 使用 Kubernetes Event-driven Autoscaling (KEDA)，可以基于租户应用程序使用的外部系统（如 Azure 事件中心或 Azure 服务总线）的事件数量，推动 Kubernetes 中任何容器的缩放。

维护

要降低在群集或节点池升级期间可能影响租户应用程序的停机风险，请安排 AKS 计划内维护 在非高峰时段进行。 通过计划内维护，可以安排每周维护时段来更新运行租户应用程序和节点池的 AKS 群集的控制平面，从而最大程度地降低工作负载的影响。 可以通过指定某一日期或特定日期的时间范围，在群集上安排一个或多个每周维护时段。 所有维护操作都将在安排的时段内进行。

安全

群集访问

在组织内的多个团队之间共享 AKS 群集时，需要实现最小特权原则以将不同的租户彼此隔离开来。 具体而言，需要确保用户在使用 kubectl、Helm、Flux、Argo CD 或其他类型的工具时，只能访问自己的 Kubernetes 命名空间和资源。

有关 AKS 的身份验证和授权的详细信息，请参阅以下文章：

工作负载标识

如果在单个 AKS 群集上托管多个租户应用程序，并且每个应用程序都位于单独的命名空间中，则每个工作负载都应使用不同的 Kubernetes 服务帐户和凭据来访问下游 Azure 服务。 服务帐户是 Kubernetes 中的主要用户类型之一。 Kubernetes API 保存和管理服务帐户。 服务帐户凭据存储为 Kubernetes 机密，可供已获授权的 Pod 用于与 API 服务器进行通信。 大多数 API 请求都会提供服务帐户或普通用户帐户的身份验证令牌。

部署到 AKS 群集的租户工作负载可使用 Microsoft Entra 应用程序凭据访问 Microsoft Entra ID 保护的资源，例如 Azure Key Vault 和 Microsoft Graph。 适用于 Kubernetes 的 Microsoft Entra 工作负载 ID 与 Kubernetes 本机功能集成来与任何外部标识提供者联合。

Pod 沙盒

AKS 包含一种称为 Pod 沙盒的机制，该机制会在容器应用程序与容器主机的共享内核和计算资源（如 CPU、内存和网络）之间提供隔离边界。 Pod 沙盒与其他安全措施或数据保护控制措施互补，可帮助租户工作负载保护敏感信息并满足法规、行业或治理合规性要求，例如支付卡行业数据安全标准 (PCI DSS)、国际标准化组织 (ISO) 27001 以及健康保险可移植性和责任法案 (HIPAA)。

在单独的群集或节点池上部署应用程序的功能使你可以强隔离不同团队或客户的租户工作负载。 使用多个群集和节点池可能适合许多组织和 SaaS 解决方案的隔离要求，但在某些情况下，具有共享 VM 节点池的单个群集效率更高，例如，在同一节点上运行不受信任的 Pod 或在同一节点上共置 DaemonSet 和特权容器，以便更快地进行本地通信和功能分组。 Pod 沙盒 可以帮助你在同一群集节点上强隔离租户应用程序，而无需在单独的群集或节点池中运行这些工作负载。 其他方法需要你重新编译代码或者会导致其他兼容性问题，但 AKS 中的 Pod 沙盒可以在增强的安全 VM 边界内运行未修改的任何容器。

AKS 上的 Pod 沙盒基于在 AKS 的 Azure Linux 容器主机堆栈上运行的 Kata 容器来提供硬件强制隔离。 AKS 上的 Kata 容器基于安全强化的 Azure 虚拟机监控程序构建。 每个 Pod 的隔离是通过利用父 VM 节点中的资源的嵌套轻型 Kata VM 实现的。 在此模型中，每个 Kata Pod 会在嵌套的 Kata 来宾 VM 中获取自己的内核。 此模型使你能够在单个来宾 VM 中放置多个 Kata 容器，同时继续在父 VM 中运行容器。 该模型在共享 AKS 群集中提供了强隔离边界。

有关详细信息，请参阅：

Azure 专用主机

Azure 专用主机是一项服务，它提供专用于单个 Azure 订阅的物理服务器，并在物理服务器级别提供硬件隔离。 可以在区域、可用性区域和容错域中预配这些专用主机，并且可以将 VM 直接放入预配的主机中。

将 Azure 专用主机与 AKS 配合使用可以实现多种优势，包括：

  • 硬件隔离可确保没有其他 VM 放置在专用主机上，这为租户工作负载提供了额外的隔离层。 专用主机部署在相同的数据中心，与其他非隔离主机共享相同的网络和底层存储基础结构。

  • Azure 专用主机提供对 Azure 平台发起的维护事件的控制。 可以选择维护时段来减少对服务的影响，并帮助确保租户工作负载的可用性和隐私性。

Azure 专用主机可帮助 SaaS 提供商确保租户应用程序满足保护敏感信息的监管、行业和治理合规性要求。 有关详细信息，请参阅向 Azure Kubernetes 服务 (AKS) 群集添加 Azure 专用主机。

机密虚拟机

可以使用机密虚拟机 (CVM) 将一个或多个节点池添加到 AKS 群集，以满足租户严格的隔离、隐私和安全要求。 CVM 使用基于硬件的受信任执行环境 (TEE)。 AMD 安全加密虚拟化 - 安全嵌套分页 (SEV-SNP) 机密 VM 拒绝虚拟机监控程序和其他主机管理代码访问 VM 内存和状态，这为操作员访问添加了一层深度防御保护。 有关详细信息，请参阅在 AKS 群集中使用 CVM。

美国联邦信息处理标准 (FIPS)

FIPS 140-3 是美国政府标准，它定义了信息技术产品和系统中加密模块的最低安全要求。 通过为 AKS 节点池启用 FIPS 合规性，可以增强租户工作负载的隔离性、隐私性和安全性。 FIPS 合规性可确保使用经过验证的加密模块进行加密、哈希和其他与安全相关的操作。 使用启用了 FIPS 的 AKS 节点池时，可以通过利用可靠的加密算法和机制来满足法规和行业合规性要求。 Azure 提供了有关如何为 AKS 节点池启用 FIPS 的文档，使你能够增强多租户 AKS 环境的安全状况。 有关详细信息，请参阅为 AKS 节点池启用 FIPS。

通过自带密钥 (BYOK) 使用 Azure 磁盘

Azure 存储会加密存储帐户中的所有静态数据，包括 AKS 群集的 OS 和数据磁盘。 默认情况下，数据使用 Microsoft 管理的密钥进行加密。 为了更进一步控制加密密钥，可以提供客户管理的密钥，用于对 AKS 群集的 OS 和数据磁盘进行静态加密。 有关详细信息，请参阅：

基于主机的加密

AKS 上的基于主机的加密进一步增强了租户工作负载隔离、隐私和安全性。 启用基于主机的加密时，AKS 会加密基础主机上的静态数据，帮助确保敏感租户信息受到保护，防止未经授权的访问。 启用端对端加密后，会使用平台管理的密钥对临时磁盘和临时 OS 磁盘进行静态加密。

在 AKS 中，OS 和数据磁盘默认使用服务器端加密和平台管理的密钥。 这些磁盘的缓存也通过平台管理的密钥进行静态加密。 你可以使用信封加密（也称为包装）来指定你自己的密钥加密密钥 (KEK)，从而加密数据保护密钥 (DEK)。 OS 和数据磁盘的缓存也通过你指定的 BYOK 进行加密。

基于主机的加密为多租户环境增添了一个安全层。 每个租户在 OS 和数据磁盘缓存中的数据都使用客户管理的密钥或平台管理的密钥进行静态加密，具体取决于所选磁盘加密类型。 有关详细信息，请参阅：

网络

限制对 API 服务器的网络访问

在 Kubernetes 中，API 服务器接收在群集中执行操作的请求，例如创建资源或缩放节点数目。 在组织内的多个团队之间共享 AKS 群集时，请使用以下任一解决方案保护对控制平面的访问。

专用 AKS 群集

通过使用专用 AKS 群集，可以确保 API 服务器与节点池之间的网络流量保留在虚拟网络中。 在专用 AKS 群集中，控制平面或 API 服务器具有一个内部 IP 地址，该地址只能通过 AKS 群集所在的同一虚拟网络中的 Azure 专用终结点进行访问。 同样，同一虚拟网络中的任何虚拟机都可以通过专用终结点以私密方式与控制平面进行通信。 有关详细信息，请参阅创建专用 Azure Kubernetes 服务群集。

授权 IP

提高群集安全性并最大限度地减少攻击的第二个选项是使用授权 IP。 此方法将限制对公共 AKS 群集的控制平面的访问，只允许已知的 Internet 协议 (IP) 地址和无类别域际路由选择 (CIDR) 列表访问。 使用授权 IP 时，它们仍是公开的，但仅限一组 IP 范围访问。 有关详细信息，请参阅使用 Azure Kubernetes 服务 (AKS) 中的已授权 IP 地址范围保护对 API 服务器的访问。

Azure 专用链接服务 (PLS) 是一个基础结构组件，支持应用程序通过 Azure 专用终结点 (PE) 以私密方式连接到服务，该终结点在虚拟网络中定义并连接到 Azure 负载均衡器 (ALB) 实例的前端 IP 配置。 借助 Azure 专用链接，服务提供商可以安全地向其租户提供服务，这些租户可以从 Azure 或本地进行连接，而不会有数据外泄风险。

可使用 Azure 专用链接服务集成，以安全方式为租户提供与其 AKS 托管工作负载的专用连接，而无需在公共 Internet 上公开任何公共终结点。

有关如何为 Azure 托管多租户解决方案配置专用链接的常规指南，请参阅多租户和 Azure 专用链接。

反向代理

反向代理是负载均衡器和 API 网关，通常用于在租户应用程序前面保护、筛选和调度传入请求。 热门的反向代理支持负载均衡、SSL 终止和 7 层路由等功能。 通常实现反向代理的目的在于帮助提高安全性、性能和可靠性。 热门的 Kubernetes 反向代理包括以下实现：

使用 AKS 托管反向代理来保护和处理多个租户应用程序的传入请求时，请考虑以下建议：

  • 在专用节点池上托管反向代理，将该节点池配置为使用具有高网络带宽且启用加速网络的 VM 大小。
  • 将托管反向代理的节点池配置为自动缩放。
  • 为避免租户应用程序的延迟和超时增加，请定义自动缩放策略，以便入口控制器 Pod 的数量可以随流量波动即时扩展和收缩。
  • 请考虑将租户应用程序的传入流量分散到入口控制器的多个实例中，以提高可伸缩性和隔离级别。

使用 Azure 应用程序网关入口控制器 (AGIC) 时，请考虑实施以下最佳做法：

  • 将入口控制器使用的应用程序网关配置为自动缩放。 启用自动缩放后，应用程序网关和 WAF v2 SKU 会根据应用程序流量需求来进行横向扩展或横向缩减。 此模式可为应用程序提供更好的弹性，无需猜测应用程序网关大小或实例计数。 此模式使你可以不要求网关在用于预期最大流量负载的峰值预配容量上运行，从而可节省成本。 必须指定实例计数下限（并且可选择指定上限）。
  • 当租户应用程序数超过站点数上限时，请考虑部署多个应用程序网关入口控制器 (AGIC) 实例，使每个实例都关联到一个单独的应用程序网关。 假设每个租户应用程序都在专用命名空间中运行，请使用多命名空间支持，将租户应用程序分布到更多应用程序网关入口控制器 (AGIC) 实例中。

与 Azure Front Door 集成

Azure Front Door 是一个全局 7 层负载均衡器，是 Microsoft 的新式云内容分发网络 (CDN)，可确保全局范围内的用户和 Web 应用程序之间的访问是快速、可靠且安全的。 Azure Front Door 支持请求加速、SSL 终止、响应缓存、边缘 WAF、基于 URL 的路由、重写和重定向等功能，你可在向公共 Internet 公开 AKS 托管多租户应用程序时利用这些功能。

例如，你可能希望使用 AKS 托管多租户应用程序来处理所有客户的请求。 在这种情况下，可使用 Azure Front Door 管理多个自定义域（每个租户一个）。 可在边缘终止 SSL 连接，并将所有流量路由到配置了单个主机名的 AKS 托管多租户应用程序。

该图演示了 Azure Front Door 和 AKS 的连接方式。

可将 Azure Front Door 配置为根据后端应用程序的域名修改请求源主机头。 客户端发送的原始 Host 标头通过 X-Forwarded-Host 标头传播，多租户应用程序的代码可以使用此信息将传入请求映射到正确的租户。

Azure Front Door 上的 Azure Web 应用程序防火墙 (WAF) 为 Web 应用程序提供集中保护。 你可使用 Azure WAF 使在 Internet 上公开公共终结点的 AKS 托管租户应用程序免受恶意攻击。

可使用 Azure 专用链接服务通过内部负载均衡器源，将 Azure Front Door Premium 配置为以私密方式连接到 AKS 群集上运行的一个或多个租户应用程序。 有关详细信息。请参阅使用专用链接将 Azure Front Door Premium 连接到内部负载均衡器源。

出站连接

如果 AKS 托管应用程序连接到大量数据库或外部服务，则群集可能会面临 SNAT 端口耗尽的风险。 SNAT 端口生成用于维护不同流的唯一标识符，这些流是由同一组计算资源上运行的应用程序发起的。 在共享 Azure Kubernetes 服务 (AKS) 群集上运行多个租户应用程序时，可能会进行大量出站调用，这可能会导致 SNAT 端口耗尽。 AKS 群集可通过三种不同的方式处理出站连接：

  • Azure 公共负载均衡器：默认情况下，AKS 预配标准 SKU 负载均衡器，用于出口连接。 但是，如果不允许公共 IP，或如果流出量需要其他跃点，则默认设置可能无法满足所有方案的要求。 默认情况下，公共负载均衡器是使用出站规则所使用的默认公共 IP 地址创建的。 通过出站规则，可以为公共标准负载均衡器显式定义源网络地址转换 (SNAT)。 借助此配置，可以使用负载均衡器的公共 IP 为后端实例提供出站 Internet 连接。 如有必要，可将公共负载均衡器的出站规则配置为使用其他公共 IP 地址来避免 SNAT 端口耗尽。 有关详细信息，请参阅使用负载均衡器的前端 IP 地址通过出站规则建立出站连接。
  • Azure NAT 网关：可将 AKS 群集配置为使用 Azure NAT 网关来路由租户应用程序的出口流量。 NAT 网关允许每个公共 IP 地址最多 64,512 个出站 UDP 和 TCP 流量流，并且最多只能有 16 个 IP 地址。 为避免在使用 NAT 网关处理 AKS 群集的出站连接时面临 SNAT 端口耗尽的风险，可将更多公共 IP 地址或公共 IP 地址前缀关联到该网关。 有关详细信息，请参阅多租户的 Azure NAT 网关注意事项。
  • 用户定义路由 (UDR)：可自定义 AKS 群集的出口路由以支持自定义网络方案，例如不允许使用公共 IP 并要求群集位于网络虚拟设备 (NVA) 后面的那些方案。 为群集配置用户定义路由时，AKS 不会自动配置出口路径。 必须由你完成出口设置。 例如，你将通过 Azure 防火墙来路由出口流量。 必须将 AKS 群集部署到先前已配置子网的现有虚拟网络中。 如果不使用标准负载均衡器 (SLB) 体系结构，必须建立显式出口。 因此，此体系结构需要向防火墙、网关或代理等设备显式发送出口流量。 或者，体系结构允许网络地址转换 (NAT) 由分配给标准负载均衡器或设备的公共 IP 完成。

监视

可使用 Azure Monitor 和容器见解来监视共享 AKS 群集上运行的租户应用程序，并计算各个命名空间的成本明细。 使用 Azure Monitor，可以监视 Azure Kubernetes 服务 (AKS) 的运行状况和性能。 这包括收集日志和指标、分析遥测数据和直观显示所收集的数据，从而确定趋势并配置警报以在出现严重问题时主动发出通知。 可启用容器见解来扩展此监视。

还可采用社区广泛使用的开源工具（如 Prometheus 和 Grafana）来监视 Kubernetes。 或者，可以采用其他第三方工具来监视和观测。

成本

成本治理是持续实现策略以控制成本的过程。 在 Kubernetes 上下文中，组织可通过多种方式控制和优化成本。 其中包括原生 Kubernetes 工具，该工具用于管理和治理资源使用情况和消耗情况，并主动监视和优化底层基础结构。 计算每个租户成本时，应考虑与租户应用程序使用的任何资源相关的成本。 向租户收取费用的方法取决于解决方案所采用的租户模型。 有关更多详细信息，请参阅以下租户模型：

  • 完全多租户：当单个多租户应用程序处理所有租户请求时，由你负责跟踪资源消耗情况以及每个租户生成的请求数量。 然后向客户收取相应的费用。
  • 专用群集：当一个群集专用于单个租户时，可以轻松地向客户收取 Azure 资源费用。 总拥有成本取决于许多因素，其中包括虚拟机的数量和大小、网络流量导致的网络成本、公共 IP 地址、负载均衡器、存储服务（如租户解决方案使用的托管磁盘或 Azure 文件）等等。 可以在节点资源组中标记 AKS 群集及其资源，以便进行费用收取操作。 有关详细信息，请参阅向群集添加标记。
  • 专用节点池：可以将 Azure 标记应用于单个租户专用的新节点池或现有节点池。 应用到某个节点池的标记将应用到该节点池中的每个节点，并通过升级持久保存。 标记还会应用于在横向扩展操作期间添加到节点池的新节点。 添加标记有助于完成策略跟踪或费用收取等任务。 有关详细信息，请参阅向节点池添加标记。
  • 其他资源：可使用标记将专用资源的费用关联到给定租户。 具体而言，可使用 Kubernetes 清单标记公共 IP、文件和磁盘。 以这种方式设置的标记将保留 Kubernetes 值，即使你以后使用其他方法更新这些标记，也是如此。 当通过 Kubernetes 删除公共 IP、文件或磁盘时，将删除 Kubernetes 设置的任何标记。 在这些资源上不由 Kubernetes 跟踪的标记不受影响。 有关详细信息，请参阅使用 Kubernetes 添加标记。

可使用开源工具（如 KubeCost）监视和管理 AKS 群集成本。 成本分配的范围可限定为部署、服务、标签、Pod 和命名空间，这使你能够灵活地向群集用户收取费用或分析成本。 有关详细信息，请参阅使用 Kubecost 进行成本治理。

有关多租户应用程序的成本测量、分配和优化的详细信息，请参阅多租户解决方案中方成本管理和分配体系结构方法。 有关成本优化的一般指南，请参阅 Azure 架构良好的框架文章：成本优化支柱概述

作者

本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。

主要作者：

其他参与者：

后续步骤

查看面向多租户解决方案架构师和开发人员的资源。