多租户的 Azure Kubernetes 服务 （AKS） 注意事项

Azure Kubernetes 服务（AKS） 通过将操作开销卸载到 Azure 云平台，简化了在 Azure 中部署托管 Kubernetes 群集。 由于 AKS 是托管的 Kubernetes 服务，因此 Azure 处理运行状况监视和维护和控制平面等关键任务。

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

本文介绍生成多租户系统时可以使用的 AKS 的一些功能。 有关 Kubernetes 多租户的一般指南和最佳做法，请参阅 Kubernetes 文档中 多租户。

多租户类型

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

多个团队

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

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

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

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

多个客户

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

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

隔离模型

根据 Kubernetes 文档，多租户 Kubernetes 群集由多个用户和工作负载共享，这些用户和工作负载通常称为租户 。 此定义包括不同团队或部门在组织内共享的 Kubernetes 群集。 它还包含 SaaS 应用程序共享的每个客户实例的群集。

群集多租户是管理多个单租户专用群集的替代方法。 多租户 Kubernetes 群集的操作员必须相互隔离租户。 这种隔离可最大程度地减少被入侵或恶意租户对群集和其他租户造成的损害。

当多个用户或团队与固定数量的节点共享同一群集时，一个团队可能会使用比其资源公平份额更多的群集。 管理员可以使用 资源配额 来解决此问题。

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

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

计划生成多租户 AKS 群集时，应考虑 Kubernetes 提供的资源隔离层和多租户层，包括：

• 簇
• Namespace
• 节点池或节点
• 荚
• 容器

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

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

可通过多种方式使用 AKS 设计和生成多租户解决方案。 其中每个方法都有其自己的一组权衡，在基础结构部署、网络拓扑和安全性方面。 这些方法会影响隔离级别、实现工作量、操作复杂性和成本。 可以根据要求在控件和数据平面中应用租户隔离。

控制平面隔离

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

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

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

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

• 命名空间
• 访问控制
• 配额

数据平面隔离

数据平面隔离可保证不同租户的 Pod 和工作负荷彼此隔离足够。 有关详细信息，请参阅 Kubernetes 文档中 数据平面隔离。

网络隔离

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

AKS 提供两种方法来实现网络策略：

• Azure 对其网络策略（称为 Azure 网络策略）的实现。
• Calico 网络策略 是由 Tigera创立的开源网络和网络安全解决方案。

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

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

存储隔离

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

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

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

例如，可以为每个租户配置自定义存储类。 然后，可以使用它将标记应用到其命名空间中创建的任何永久性卷，以对其成本进行退款。 有关详细信息，请参阅 在 AKS中使用 Azure 标记。

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

节点隔离

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

可以使用 污点、容忍、节点标签、节点选择器，以及 节点相关性 来限制租户的 Pod 仅在特定节点或节点池上运行。

通常，AKS 在各种级别提供工作负荷隔离，包括：

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

可以组合这些技术。 例如，可以在 Azure 专用主机组 中运行每租户群集和节点池，以实现硬件级别的工作负荷隔离和物理隔离。 还可以创建支持 联邦信息进程标准（FIPS）、机密 VM或 基于主机的加密的共享或每租户节点池。

使用节点隔离轻松地将一组节点或节点池的成本关联和退款到单个租户。 它与解决方案采用的租赁模型密切相关。

有关详细信息，请参阅 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 的事件驱动自动缩放程序（KEDA）的外部消息传送系统的挂起请求数或指标。
• 确保分隔每个租户的数据并实施安全措施，以避免不同租户之间的数据泄漏。
• 请确保 跟踪 Azure 成本 并将其关联到单个租户，具体取决于其实际使用情况。 非Microsoft解决方案（如 kubecost）可帮助计算和细分不同团队和租户的成本。
• 使用单个部署可以更直接地进行维护，因为只需更新一组 Azure 资源并维护单个应用程序。 但是，也可能更危险，因为对基础结构或应用程序组件所做的任何更改都可能会影响整个客户群。
• 还应考虑缩放限制。 当你拥有一组共享的资源时，你更有可能达到 Azure 资源规模限制。 为了避免达到资源配额限制，可以跨多个 Azure 订阅分配租户。

水平分区部署

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

权益：

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

风险：

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

垂直分区部署

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

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

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

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

下图显示了租户 A 和 B 在共享 AKS 群集上运行的情况，而租户 C 在单独的 AKS 群集上运行。

显示三个租户的

下图显示了租户 A 和 B 在同一节点池上运行的情况，而租户 C 在专用节点池上运行。

显示三个租户的

此模型还可以为不同的层提供不同的 SLA。 例如，基本层可以提供 99.9% 运行时间，标准层可以提供 99.95% 运行时间，高级层可以提供 99.99% 运行时间。 可以使用启用更高可用性目标的服务和功能来实现更高的 SLA。

权益：

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

风险：

• 需要设计 Kubernetes 应用程序以支持多租户部署和单租户部署。
• 如果计划允许在基础结构之间迁移，需要考虑如何将客户从多租户部署迁移到其自己的单租户部署。
• 需要一致的策略和单一窗格（或一个观点）来监视和管理更多 AKS 群集。

自动缩放

若要跟上租户应用程序生成的流量需求，可以启用 群集自动缩放程序 来缩放 AKS 的代理节点。 自动缩放有助于系统在以下情况下保持响应：

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

为节点池启用自动缩放时，可以根据预期的工作负荷大小指定最小和最大节点数。 通过配置最大节点数，可以确保群集中所有租户 Pod 有足够的空间，而不管它们运行的命名空间如何。

流量增加时，群集自动缩放会添加新的代理节点，以防止 Pod 由于 CPU 和内存等资源短缺而进入挂起状态。

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

可以使用 Pod 自动缩放根据资源需求自动缩放 Pod。 HorizontalPodAutoscaler 会根据 CPU 或内存利用率或自定义指标自动缩放 Pod 副本数。 通过使用 KEDA，可以根据来自外部系统的事件数（例如 Azure 事件中心 或 Azure 服务总线）来驱动 Kubernetes 中任何容器的缩放。

垂直 Pod 自动缩放程序（VPA） 可为 Pod 实现高效的资源管理。 通过调整分配给 Pod 的 CPU 和内存，VPA 可帮助你减少运行租户应用程序所需的节点数。 节点减少可降低总拥有成本，并帮助避免干扰邻居问题。

将 容量预留组 分配给节点池，以便为不同的租户提供更好的资源分配和隔离。

保养

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

安全

以下部分介绍使用 AKS 的多租户解决方案的安全最佳做法。

群集访问

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

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

• AKS 的访问和标识选项
• AKS 托管的 Microsoft Entra 集成
• 在 AKS 中使用 Microsoft Entra ID Kubernetes 基于角色的访问控制

工作负荷标识

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

部署到 AKS 群集的租户工作负荷可以使用 Microsoft Entra 应用程序凭据来访问 Microsoft受 Entra ID 保护的资源，例如 Azure Key Vault 和 Microsoft Graph。 Microsoft Kubernetes 的 Entra Workload 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 虚拟机监控程序构建。 它通过利用父 VM 节点中的资源的嵌套轻型 Kata VM 实现每个 Pod 的隔离。 在此模型中，每个 Kata Pod 在嵌套的 Kata 来宾 VM 中获取其自己的内核。 使用此模型可将许多 Kata 容器放置在单个来宾 VM 中，同时继续在父 VM 中运行容器。 此模型在共享 AKS 群集中提供强隔离边界。

有关详细信息，请参阅：

• 使用 AKS Pod 沙盒
• 对 AKS 上的片卡塔 VM 隔离容器的支持，用于 Pod 沙盒

Azure 专用主机

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

将 Azure 专用主机与 AKS 配合使用有几个好处，包括：

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

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

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

卡彭特

Karpenter 是为 Kubernetes 构建的开源节点生命周期管理项目。 将 Karpenter 添加到 Kubernetes 群集可以提高在该群集上运行工作负荷的效率和成本。 Karpenter 监视 Kubernetes 计划程序标记为不可安排的 Pod。 它还动态预配和管理可满足 Pod 要求的节点。

Karpenter 提供对托管群集中的节点预配和工作负荷放置的精细控制。 此控制通过优化资源分配、确保每个租户的应用程序之间的隔离以及降低运营成本来提高多租户。 在 AKS 上构建多租户解决方案时，Karpenter 提供了有用的功能来帮助管理不同的应用程序要求以支持不同的租户。 例如，可能需要一些租户的应用程序在 GPU 优化节点池上运行，而另一些应用程序在内存优化节点池上运行。 如果应用程序需要较低的存储延迟，则可以使用 Karpenter 来指示 Pod 需要在特定可用性区域中运行的节点，以便可以并置存储和应用程序层。

AKS 通过 Karpenter 在 AKS 群集上启用节点自动预配。 大多数用户应使用节点自动预配模式来启用 Karpenter 作为托管加载项。 有关详细信息，请参阅 节点自动预配。 如果需要更高级的自定义，可以选择自承载 Karpenter。 有关详细信息，请参阅 AKS Karpenter 提供程序。

机密 VM

可以使用 机密 VM 将一个或多个节点池添加到 AKS 群集，以解决租户严格的隔离、隐私和安全要求。 机密 VM 使用基于硬件的 受信任的执行环境。 AMD Secure Encrypted Virtualization - Secure Nested Paging （SEV-SNP） 机密 VM 拒绝虚拟机监控程序和其他主机管理代码访问 VM 内存和状态，这增加了对操作员访问的防御和深度保护层。 有关详细信息，请参阅 使用 AKS 群集中的机密 VM。

联邦信息流程标准（FIPS）

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

使用 Azure 磁盘自带密钥 （BYOK）

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

• 在 AKS中使用 Azure 磁盘 BYOK。
• Azure 磁盘存储的服务器端加密。

基于主机的加密

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

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

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

• 基于主机的 AKS 加密
• 在 AKS 中使用 Azure 磁盘 BYOK
• Azure 磁盘存储 服务器端加密

联网

以下部分介绍了使用 AKS 的多租户解决方案的网络最佳做法。

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

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

专用 AKS 群集

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

授权 IP 地址范围

提高群集安全性和最小化攻击的第二个选项是使用 授权 IP 地址范围。 此方法将公共 AKS 群集的控制平面的访问限制为 IP 地址和无类 Inter-Domain 路由（CIDR）范围的已知列表。 使用授权 IP 地址时，它们仍公开，但访问仅限于一组范围。 有关详细信息，请参阅 在 AKS中使用授权 IP 地址范围保护对 API 服务器的访问。

专用链接集成

Azure 专用链接服务 是一个基础结构组件，允许应用程序通过虚拟网络中定义的 Azure 专用终结点 私下连接到服务，并连接到 Azure 负载均衡器 实例的前端 IP 配置。 借助 专用链接，服务提供商可以安全地将其服务提供给可从 Azure 内部或本地连接的租户，而不会造成数据外泄风险。

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

有关如何为 Azure 托管的多租户解决方案配置专用链接的详细信息，请参阅 多租户和专用链接。

反向代理

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

• NGINX 入口控制器 是一种常用的反向代理服务器，支持高级功能，例如负载均衡、SSL 终止和第 7 层路由。
• Traefik Kubernetes 入口提供程序 是 Kubernetes 入口控制器，可用于通过支持入口规范来管理对群集服务的访问。
• HAProxy Kubernetes 入口控制器 是 Kubernetes 的另一个反向代理，它支持标准功能，例如 TLS 终止、基于 URL 路径的路由等。
• Azure 应用程序网关入口控制器（AGIC） 是 Kubernetes 应用程序，这使得 AKS 客户可以使用 Azure 本机 应用程序网关 L7 负载均衡器将租户应用程序公开到公共 Internet 或内部向虚拟网络中运行的其他系统公开。

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

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

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

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

与 Azure Front Door 集成

Azure Front Door 是一个全局第 7 层负载均衡器，也是来自Microsoft的新式云内容分发网络（CDN），提供全球用户和 Web 应用程序之间的快速、可靠和安全访问。 Azure Front Door 支持将 AKS 托管的多租户应用程序公开到公共 Internet 时可以使用的功能，例如请求加速、SSL 终止、响应缓存、边缘的 WAF、基于 URL 的路由、重写和重定向。

例如，你可能想要使用 AKS 托管的多租户应用程序为所有客户的请求提供服务。 在此上下文中，可以使用 Azure Front Door 管理多个自定义域，每个租户一个。 可以在边缘终止 SSL 连接，并将所有流量路由到配置了单个主机名的 AKS 托管的多租户应用程序。

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

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

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

出站连接

当 AKS 托管的应用程序连接到大量数据库或外部服务时，群集可能面临源网络地址转换（SNAT）端口耗尽的风险。 SNAT 端口 生成唯一标识符，这些标识符用于维护在同一组计算资源上运行的应用程序启动的不同流。 通过在共享 AKS 群集上运行多个租户应用程序，可能会进行大量出站调用，这可能会导致 SNAT 端口耗尽。 AKS 群集可以通过三种不同的方式处理出站连接：

• Azure 负载均衡器：默认情况下，AKS 会预配标准 SKU 负载均衡器来设置和用于出口连接。 但是，如果不允许公共 IP 地址或出口需要额外的跃点，则默认设置可能无法满足所有方案的要求。 默认情况下，使用 出站规则 使用的默认公共 IP 地址创建公共负载均衡器。 出站规则允许显式定义公共标准负载均衡器的 SNAT。 此配置允许使用负载均衡器的公共 IP 地址为后端实例提供出站 Internet 连接。 如有必要，为了避免 SNAT 端口耗尽，可以将公共负载均衡器的出站规则配置为使用更多公共 IP 地址。 有关详细信息，请参阅 通过出站规则使用负载均衡器的前端 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 群集部署到具有以前配置的子网的现有虚拟网络中。 如果不使用标准负载均衡器体系结构，则必须建立显式出口。 因此，此体系结构需要将出口流量显式发送到设备，例如防火墙、网关或代理。 或者，体系结构允许网络地址转换（NAT）由分配给标准负载均衡器或设备的公共 IP 来完成。

监测

可以使用 Azure Monitor 和 容器见解 监视在共享 AKS 群集上运行的租户应用程序，以及计算单个命名空间的成本明细。 使用 Azure Monitor 监视 AKS 的运行状况和性能。 它包括收集 日志和指标、遥测分析和收集的数据可视化效果，以确定趋势，并配置警报，主动通知你关键问题。 可以启用 容器见解 以扩展此监视。

还可以采用开源工具，例如 Prometheus 和 Grafana，这些工具通常用于 Kubernetes 监视。 或者，可以采用其他非Microsoft工具来监视和观测。

成本

成本治理是实施策略以控制成本的持续过程。 在 Kubernetes 上下文中，组织可以使用多种方法来控制和优化成本。 这些方法包括使用本机 Kubernetes 工具来管理和管理资源使用情况和消耗，以及主动监视和优化底层基础结构。 计算每租户成本时，应考虑与租户应用程序使用的任何资源相关的成本。 你遵循的向租户收取费用的方法取决于解决方案采用的租赁模型。 以下列表更详细地介绍了租赁模型：

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

可以使用开源工具（如 KubeCost）监视和管理 AKS 群集的成本。 可以将成本分配范围限定为部署、服务、标签、Pod 和命名空间，这样可以灵活地向群集的用户退款或向后显示用户。 有关详细信息，请参阅 kubecost成本治理。

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

统辖

当多个租户共享同一基础结构时，管理数据隐私、合规性和法规要求可能会变得复杂。 需要实施强大的安全措施和数据治理策略。 共享 AKS 群集存在更高的数据泄露、未经授权的访问和不符合数据保护法规的风险。 每个租户可能具有独特的数据治理要求和符合性策略，因此很难确保数据的安全性和隐私性。

Microsoft Defender for Containers 是一种云原生容器安全解决方案，可为 Kubernetes 环境提供威胁检测和保护功能。 通过使用 Defender for Containers，可以在 Kubernetes 群集中托管多个租户时增强数据治理和合规性状况。 使用 Defender for Containers 帮助保护敏感数据，通过分析容器行为和网络流量来检测和响应威胁，并满足法规要求。 它提供审核功能、日志管理和报告生成，以演示监管机构和审核员的合规性。

贡献

本文由Microsoft维护。 它最初由以下参与者编写。

主体作者：

• 保罗·萨尔瓦托里 |首席客户工程师

其他参与者：

• 博丹·切希克 |高级客户工程师
• 约翰·唐斯 |首席软件工程师
• 查德·基特尔 |首席软件工程师
• 阿森·弗拉基米尔斯基 |首席客户工程师

相关资源

• 为多租户解决方案的架构师和开发人员 资源