通过

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

Azure Kubernetes Service （AKS） 群集的基线体系结构

Azure 应用程序网关
Azure 容器注册表
Azure 防火墙
Azure Kubernetes 服务 (AKS)
Azure 基于角色的访问控制

本文提供了用于部署 Azure Kubernetes Service （AKS） 群集的建议基线基础结构体系结构。 它遵循我们的设计原则，并与 AKS 的体系结构最佳做法和 Azure Well-Architected Framework 保持一致。 本文在多个不同的跨学科团队（如网络、安全和身份识别团队）部署这一通用基础设施时提供指导。

此体系结构不侧重于工作负荷。 它的重点是 AKS 群集本身。 这些信息是大多数 AKS 群集推荐的最低基线。 它与提供可观测性的Azure服务集成，提供支持多区域增长的网络拓扑，并保护群集内流量。

业务要求会影响目标体系结构，在应用程序上下文之间可能会有所不同。 将体系结构作为预生产和生产阶段的起点。

Kubernetes 是一个广泛的生态系统，可以扩展到Azure和Microsoft技术之外。 部署 AKS 群集时，你需要负责许多关于如何设计和运营群集的决策。 运行 AKS 群集涉及来自各种供应商的闭源组件，包括Microsoft，以及 Kubernetes 生态系统中的开源组件。 不断变化的局势需要我们定期重新审视决策。 采用 Kubernetes 时，你确认工作负荷需要其功能，并且工作负荷团队已准备好持续投资。

可以在 GitHub 上使用此体系结构的实现：AKS 基线参考实现作为替代起点，并将其配置为满足需求。

Note

参考体系结构需要了解 Kubernetes 及其概念。 如果您需要复习，请参阅 Kubernetes 的 Intro to Kubernetes 和 开发并部署应用程序在 Kubernetes 上 的培训路径。

网络配置

网络拓扑
规划 IP 地址
部署入口资源

群集计算

基础群集的计算
容器映像参考
策略管理

标识管理

将 Microsoft Entra ID 集成到群集中
为工作负荷集成 Microsoft Entra ID

安全的数据流

保护网络流
添加机密管理

业务连续性

节点和 Pod 可伸缩性
业务连续性决策
Availability zones多个区域

Operations

群集和工作负荷操作
监视和收集日志和指标
成本管理

Architecture

架构示意图，显示中心辐射型网络拓扑。

下载此架构的 Visio 文件

有关详细信息，请参阅 Azure 中的 Hub 辐射型网络拓扑。

网络拓扑

此体系结构使用中心辐射型网络拓扑。 在单独的虚拟网络中部署中心和辐射，这些虚拟网络通过虚拟网络对等互连连接。 此拓扑具有几个优点：

  • 实现分开管理。 可以应用治理并遵循最低特权原则（PoLP）。 它还支持Azure登陆区域的概念并实现职能分离。

  • 尽量减少 Azure 资源直接暴露于公共互联网。

  • 提供区域中心辐射型拓扑。 将来可以扩展中心辐射型网络拓扑，并提供工作负荷隔离。

  • 使用web application firewall服务来帮助检查所有 Web 应用程序的 HTTP 流量流。

  • 为跨越多个订阅的工作负荷提供支持。

  • 使体系结构具有可扩展性。 为了适应新的功能或工作负荷，可以添加新的分支，而不是重新设计网络拓扑结构。

  • 支持跨网络共享资源，例如防火墙和域名系统（DNS）区域。

  • 与Azure企业级登陆区域保持一致。

中心虚拟网络

集线器虚拟网络是连接与可观察性的核心点。 在此体系结构中，中心包含以下组件：

  • Azure Firewall 使用中心 IT 团队定义的全局防火墙策略，以强制实施组织范围规则

  • Azure Bastion 建立安全隧道进入专用网络外围，以便进行群集管理操作。

  • 用于 VPN 连接的网关子网

  • Azure监视网络可观测性

在网络内部，该体系结构有三个子网。

用于托管Azure防火墙的子网

Azure Firewall是托管防火墙服务。 Azure Firewall实例保护出站网络流量。 如果没有这层安全保护，流量可能会与恶意的非 Microsoft 服务通信，从而泄露敏感的工作负荷数据。 使用 Azure Firewall Manager 集中部署和配置多个Azure Firewall实例，并管理此 hub virtual network 体系结构类型的Azure Firewall策略。

用于托管网关的子网

此子网是虚拟专用网络 (VPN) 网关或 Azure ExpressRoute 网关的占位符。 网关在本地网络中的路由器与virtual network之间提供连接。

为了托管 Azure Bastion 而设置的子网

此子网用于 Azure Bastion。 可以使用 Azure Bastion 安全地访问 Azure 资源，无需将资源暴露在 Internet 上。 此体系结构使用Azure Bastion安全地连接到 AKS 群集的 API 服务器进行管理作。 子网仅用于管理和操作。

辐射型虚拟网络

辐射状虚拟网络包含 AKS 群集和其他相关资源。 分支包含有以下子网。

用于托管Azure Application Gateway的子网

Azure Application Gateway是运行在第七层的Web流量负载均衡器。 引用实现使用 Application Gateway v2 SKU，启用了 Azure Web Application Firewall。 Web Application Firewall保护传入流量免受常见网络攻击，包括机器人的攻击。 该实例具有接收用户请求的公共前端 IP 配置。 根据设计，Application Gateway需要专用子网。

用于托管入口资源的子网

若要路由和分发流量， Traefik 是满足 Kubernetes 入口资源的入口控制器。 此子网中存在Azure内部负载均衡器。 有关详细信息，请参阅 使用 AKS 的内部负载均衡器。

用于托管群集节点的子网

AKS 维护两个节点池，而这些节点池均为独立的节点组。 系统节点池托管运行核心集群服务的容器组。 用户节点池会运行你的工作负荷和入口控制器，来实现与工作负荷的入站通信。

为 Azure Container Registry 和 Azure Key Vault 创建 Azure Private Link 连接，以便用户可以通过辐射虚拟网络中的 专用终结点 访问这些服务。 专用终结点不需要专用子网。 还可以将专用终结点放置在中心虚拟网络中。 在基线实现中，端点将部署到辐射虚拟网络中的专用子网。 这种方法可减少通过对等网络连接的流量。 它将属于群集的资源保留在同一virtual network中。 还可以使用网络安全组（NSG）在子网级别应用精细的安全规则。

有关详细信息，请参阅 Private Link 部署选项。

AKS API 服务器的子网

可以将 AKS 群集配置为使用 API 服务器虚拟网络集成，后者将群集的 API 服务器终结点投影到虚拟网络中的委托子网中。 此配置称为 专用群集 ，因为它可确保 API 服务器、节点池和连接的客户端之间的所有流量完全保留在专用网络中。

AKS 托管的 Kubernetes API 服务器和客户端（群集内部客户端和外部客户端）之间的所有通信仅限于受信任的网络。

使用专用群集，可以使用 NSG 和其他内置网络控制来保护环境。 此配置禁止任何未经授权的公共访问在互联网与环境之间。 有关详细信息，请参阅 创建专用 AKS 群集。

规划 IP 地址

显示 AKS 集群的网络拓扑的图示。

下载此架构的 Visio 文件

此参考体系结构使用多种网络方法，其中每个方法都需要 IP 地址空间：

  • 用于群集节点、群集 API 服务器、Azure 服务的专用终结点以及应用程序网关等资源的 Azure 虚拟网络。

  • 群集使用 Azure 容器网络接口（CNI）覆盖层，它从独立于 Azure 虚拟网络的地址空间为 Pod 分配 IP 地址。

虚拟网络 IP 地址空间

Azure virtual network的地址空间应足够大，可以容纳所有子网。 请统计接收流量的所有实体。 Kubernetes 从子网地址空间中为实体分配 IP 地址。 规划Azure virtual network的 IP 地址时，请考虑以下几点：

  • 升级： AKS 定期更新节点，以确保底层虚拟机的安全功能和其他系统补丁保持最新状态。 在升级过程中，AKS 会创建一个临时托管 Pod 的节点，同时对升级节点进行封锁和清空。 该临时节点从群集子网接收 IP 地址。 确保有足够的地址空间用于临时节点 IP 地址。

    在此体系结构中，Pod 会从 Azure CNI 覆盖 Pod 地址空间中分配 IP 地址，包括滚动更新期间。 与其他 Kubernetes 网络方法相比，此方法减少了Azure virtual network中使用的 IP 地址总数。

  • 可 伸缩 性： 考虑系统节点和用户节点总数及其最大可伸缩性限制。 例如，如果要将系统横向扩展400%，则需要所有扩展节点的地址数是之前的四倍。

    由于此体系结构使用 Azure CNI 覆盖，因此 Pod 的可伸缩性不会影响virtual network的地址空间。

  • Private Link地址：考虑到与其他Azure服务通过Private Link通信所需的地址。 此体系结构为链接到容器注册表和密钥保管库（Key Vault）分别分配了两个地址。

  • 专用群集 API 服务器地址：API 服务器的虚拟网络集成可以帮助将 AKS API 服务器投射为虚拟网络中的一个终结点。 此功能需要 minimum 子网大小，因此请确保在网络规划过程中满足这些先决条件。

  • 保留 IP 地址： Azure保留特定地址供其使用。 他们不能被分配。

前面的列表并不详尽。 如果设计有其他会影响可用 IP 地址数量的资源，请考虑这些地址。

此体系结构专为单个工作负荷设计。 在生产 AKS 群集中，应始终将系统节点池与用户节点池分开。 在群集上运行多个工作负荷时，可能需要将用户节点池相互隔离。 这种隔离会导致更多子网，其大小较小。 入口资源可能更为复杂。 因此，可能需要多个入口控制器，每个控制器都需要额外的 IP 地址。

Pod IP 地址空间

Azure CNI 覆盖层使用专用地址空间将 IP 地址分配给 Pod，该空间与virtual network中使用的地址空间分开。 使用不与您的虚拟网络或任何对等虚拟网络重叠的 IP 地址空间。 但是，如果创建多个 AKS 群集，则可以在每个群集上安全地使用相同的 Pod 地址空间。

Azure CNI Overlay 为每个节点分配一个 /24 地址空间用于其 Pod。 请务必确保 Pod 地址空间足够大。 允许根据群集中的节点数量提供足够数量的 /24 块。 请记住，包括升级或横向扩展操作期间创建的任何临时节点。 例如，如果将 /16 地址空间用于无类域间路由（CIDR）范围，群集最多可以增长到大约 250 个节点。

每个节点最多支持 250 个 Pod，此限制包括升级期间临时创建的任何 Pod。

有关详细信息，请参阅 关于 Azure CNI Overlay IP 地址规划的指导。

其他 IP 地址空间注意事项

有关此体系结构的完整网络注意事项集，请参阅 AKS 基线网络拓扑。 关于规划 AKS 群集的 IP 地址的详细信息，请参阅 在 AKS 中配置 Azure CNI 网络。

加载项和预览功能

Kubernetes 和 AKS 不断发展，发布周期比本地环境软件更快。 此基线体系结构取决于特定的 AKS 预览功能和 AKS 加载项。 请考虑预览功能和加载项之间的以下差异：

  • AKS 团队将预览功能描述为 已推出和改进，因为许多预览功能在转入正式可用（GA）阶段之前，仅在该状态下停留了几个月。

  • AKS 附加组件和扩展提供额外的受支持功能。 AKS 管理其安装、配置和生命周期。

基线体系结构不包括每个预览功能或加载项。 相反，它只包括那些能为通用群集带来重大价值的群集。 由于这些功能来自于预览版，因此会相应地修改此基线体系结构。 你可能希望在预生产群集中评估一些其他预览功能或 AKS 加载项。 这些功能可以提高安全性、可管理性或其他要求。 使用非Microsoft加载项时，必须安装和维护它们，包括跟踪可用版本并在升级群集的 Kubernetes 版本后安装更新。

容器映像参考

群集可能包含工作负载和其他几个镜像，例如入口控制器。 其中一些映像可能驻留在公共注册表中。 将映像拉入群集时，请考虑以下几点：

  • 对群集进行验证以拉取镜像。

  • 如果使用公共映像，请将映像导入到与服务级别目标（SLO）一致的容器注册表中。 否则，映像可能会出现意外的可用性问题。 如果在您需要时映像不可用，则可能会出现操作问题。 请考虑使用专用容器注册表（如Azure Container Registry）而不是公共注册表的以下优势：

    • 可以阻止对您的图像进行未经授权的访问。
    • 你没有面向公众的依赖项。
    • 可以访问映像拉取日志来监控活动并排查连接问题。
    • 可以利用集成的容器扫描和映像合规性。

  • 从授权的注册表中拉取映像。 可以通过Azure Policy强制实施此限制。 在此参考实现中，群集仅从使用群集部署的专用Azure Container Registry实例中提取映像。

为基础群集配置计算资源

在 AKS 中，每个节点池通常映射到虚拟机规模集。 每个节点池中的节点都是虚拟机（VM）。

请考虑为系统节点池使用较小的 VM 大小以最大限度地降低成本。 此参考实现使用三个 D2dv5 节点部署系统节点池。 该大小足以满足系统 Pod 的预期负载。 操作系统临时性磁盘为 64 GB。

规划用户节点池的容量时，请考虑以下建议：

  • 选择更大的节点大小以容纳节点上设置的最大 Pod 数。 大型节点可最大程度地减少在所有节点上运行的服务的占用空间，例如监视和日志记录。

  • 如果您有特定的工作负载要求，请选择相应的 VM 类型。 例如，可能需要为某些工作负荷提供内存优化产品，或为其他工作负荷提供 GPU 加速产品。 有关详细信息，请参阅 Azure。

  • 至少部署两个节点，以便工作负荷可以遵循具有两个副本的高可用性模式。 使用 AKS，无需重新创建群集即可更改节点数。

  • 根据设计团队确定的要求，规划工作负荷的实际节点大小。 根据业务需求，此体系结构将 D4dv5 SKU 用于生产工作负荷。

  • 假设在为群集规划容量时，工作负荷最多消耗每个节点的 80%。 剩余的 20% 被保留用于 AKS 服务。

  • 根据容量规划设置每个节点的最大 Pod 数。 如果尝试建立容量基线，请从值 30 开始。 根据工作负荷、节点大小和 IP 地址约束的要求调整该值。

选择操作系统

大多数 AKS 群集使用 Linux 作为节点池的操作系统。 在此参考实现中，我们使用 Azure Linux，这是针对Azure优化的轻型强化 Linux 分发版。 如果需要，或者 Azure Linux 不符合要求，可以选择其他 Linux 分发版（如 Ubuntu）。 如果选择不同的操作系统，请确保为该映像适当调整操作系统磁盘的大小。 某些分发版需要比 Azure Linux 更多的空间，因此可能需要增加磁盘大小以避免部署或运行时问题。

如果工作负荷由混合技术组成，则可以在不同的节点池中使用不同的作系统。 但是，如果你不需要不同的操作系统，我们建议对所有工作负载节点池使用单个操作系统来降低操作复杂性。

为群集集成Microsoft Entra ID

保护对群集的访问和从群集的连接至关重要。 使用群集的角度了解内向外流量与外部流量之间的差异：

  • 内向外的访问：考虑 AKS 访问 Azure 组件，例如网络基础设施、容器注册表和密钥保管库。 仅授权群集能够访问的资源。

  • Outside-in access：为身份提供对 Kubernetes 集群的访问。 仅授权那些被允许访问 Kubernetes API 服务器和 Azure 资源管理器的外部实体。

AKS 访问 Azure 组件

可通过两种方式使用 Microsoft Entra ID 管理 AKS 对 Azure 的访问：服务主体或托管身份用于 Azure 资源。

在管理 AKS 访问 Azure 的两种方法中，我们建议使用托管身份。 使用服务主体时，必须手动或以编程方式管理和轮换机密信息。 使用托管身份，Microsoft Entra ID 可以为您管理身份验证，并及时轮换机密信息。

建议在 AKS 中启用和使用 托管标识，以便群集可以通过Microsoft Entra ID与外部Azure资源进行交互。 如果不立即使用Microsoft Entra ID集成，可以稍后添加它。

默认情况下，群集使用两个主要标识： 群集标识 和 kubelet 标识。 AKS 控制平面组件使用 群集标识 来管理群集资源，包括入口负载均衡器和 AKS 托管的公共 IP 地址。 kubelet 标识使用容器注册表进行身份验证。 某些加载项还支持通过使用托管标识进行身份验证。

当群集需要从容器注册表中拉取映像时，应该使用托管标识。 此操作要求群集获取注册表凭据，您可以通过将注册表的访问权限授予群集的 kubelet 托管标识来实现。 如果不使用托管标识，您可能会将该信息存储在 Kubernetes Secret 中，并使用 imagePullSecrets 来检索它。 不建议使用此方法，因为它引入了安全复杂性，包括事先知道机密的需要，并将其存储在 DevOps 管道中。 它还会增加操作开销，因为还必须轮换密钥。

在此体系结构中，群集访问由 Microsoft Entra ID 保护的 Azure 资源，并执行支持托管标识的操作。 根据群集执行的操作，将 Azure 基于角色的访问控制（Azure RBAC）和权限分配给群集的托管标识。 群集通过Microsoft Entra ID进行身份验证，然后根据分配给它的角色来允许或拒绝访问权限。 下面是此参考实现中的一些示例，其中Azure内置角色分配给群集：

  • 网络贡献者角色管理群集对辐射虚拟网络进行控制的能力。 使用此角色分配时，AKS 群集系统分配的标识可与内部入口控制器服务和 AKS 专用 API 服务器的专用子网配合使用。

  • Private DNS 区域参与者角色管理群集将区域直接链接到托管群集的辐射虚拟网络的能力。 专用群集通过使用私有 DNS 区域使 DNS 记录不会出现在公共互联网中。 但是，仍可以使用公共 DNS 地址创建专用 AKS 群集。 建议您通过将显式设置为enablePrivateClusterPublicFQDN来禁止此功能，以防止泄露控制平面的专用 IP 地址。 请考虑使用Azure Policy强制使用没有公共 DNS 记录的专用群集。

  • 监视指标发布者角色管理群集发送指标到 Azure Monitor 的功能。

  • AcrPull 角色管理群集从指定的容器注册表实例拉取映像的能力。

群集访问

Microsoft Entra 集成还简化了“外部访问”安全措施。 例如，您可能会想要使用 kubectl。 第一步，运行 az aks get-credentials 命令来获取群集的凭据。 Microsoft Entra ID 对被允许获得群集凭据的 Azure 角色进行身份验证，以确认您的标识。 有关详细信息，请参阅可用的群集角色权限。

Kubernetes 访问可以通过 AKS 通过 Microsoft Entra ID 支持，方法是将 Microsoft Entra ID 用作与本机 Kubernetes RBAC 集成的标识提供者，或使用本机 Azure RBAC 来控制群集访问。 下文将详细介绍这两种方法。

将 Kubernetes RBAC 与 Microsoft Entra ID 相关联

Kubernetes 通过以下 API 对象支持 RBAC：

  • 通过使用 Role 或 ClusterRole 对象为整个群集权限定义的一组权限。

  • 分配有权限执行操作的用户和组的绑定。 使用 RoleBinding 或 ClusterRoleBinding 对象定义绑定。

Kubernetes 具有一些内置角色，例如群集管理员、编辑和查看。 将这些角色绑定到 Microsoft Entra 用户和组，以通过企业目录服务管理访问权限。 有关详细信息，请参阅 将 Kubernetes RBAC 与 Microsoft Entra 集成配合使用。

请确保在 Microsoft Entra 访问审阅中包括群集和命名空间访问的 Microsoft Entra 组。

使用 Azure RBAC 进行 Kubernetes 授权

建议使用 Azure RBAC 和Azure角色分配在群集上强制执行授权检查。 此授权方法与 Microsoft Entra 身份验证集成。 可以在各种范围内分配角色，例如管理组、订阅或资源组。 然后，范围下的所有群集都会继承一组一致的角色分配，以确定谁有权限访问 Kubernetes 群集上的对象。

不建议将 Kubernetes 原生 RBAC 与 ClusterRoleBindings 和 RoleBindings 一起使用。

有关详细信息，请参阅 Azure RBAC 用于 Kubernetes 权限管理。

本地帐户

AKS 支持本机 Kubernetes 用户身份验证。 我们不建议使用这种方法为用户提供集群访问权限。 此方法基于证书，并在您的主标识提供者之外执行，这使得集中式用户访问控制和治理变得困难。 始终使用 Microsoft Entra ID 管理对群集的访问，并将群集配置为显式禁止本地帐户访问。

在此参考实现中，当系统部署群集时，明确禁止本地群集帐户的访问。

为工作负载集成Microsoft Entra ID

与为整个群集Azure系统分配的托管标识类似，可以在 Pod 级别分配托管标识。 工作负荷标识使托管工作负荷能够通过 Microsoft Entra ID 访问资源。 例如，假设工作负荷将文件存储在Azure Storage中。 当它需要访问这些文件时，Pod 以 Azure 托管标识的身份对资源进行身份验证。

在此参考实现中，AKS 上的 Microsoft Entra Workload ID 为 Pod 提供托管标识。 此方法与 Kubernetes 原生功能集成，以便与外部标识提供者进行联邦集成。 有关详细信息，请参阅工作负载标识联合。

选择网络模型

Important

在 2028 年 3 月 31 日，Azure Kubernetes Service（AKS）的 kubenet 网络将停用。

为避免服务中断，你需要在那之前升级到Azure容器网络接口（CNI）覆盖层，因为届时在AKS的kubenet上运行的工作负载将不再受支持。

AKS 支持多个网络模型，包括 kubenet、CNI 和 Azure CNI 覆盖。 CNI 模型是更高级的模型，可提供高性能。 在 Pod 之间通信时，CNI 的性能类似于virtual network中 VM 的性能。 CNI 还提供增强的安全控制，因为它支持使用Azure网络策略。 建议使用基于 CNI 的网络模型。

在非重叠 CNI 模型中，每个 Pod 从子网地址空间获取 IP 地址。 同一网络（或对等网络）中的资源可以直接通过其 IP 地址访问 Pod。 不需要网络地址转换（NAT）来路由该流量。

在此参考实现中，我们使用Azure CNI Overlay 网络。 它只为节点分配节点池子网中的 IP 地址，并为 Pod IP 使用优化的覆盖层。 由于 Azure CNI Overlay 网络比许多其他方法使用更少的虚拟网络 IP 地址，我们推荐在 IP 地址受限的部署中使用它。

有关网络模型的详细信息，请参阅 在 AKS 中配置 Azure CNI Overlay 网络和 在 AKS 中的网络连接与安全性的最佳实践。

部署入口资源

Kubernetes 入口资源会处理传入群集的流量的路由和分发。 入口资源分为两部分：

  • AKS 管理的内部负载均衡器： 负载均衡器通过一个专用静态 IP 地址公开入口控制器。 它作为接收入站流量的单一联络点。

    此体系结构使用Azure Load Balancer。 在专用于入口资源的子网中，Load Balancer 位于群集之外。 它接收来自Application Gateway的流量，通信是通过传输层安全性 （TLS） 传输的。 有关入站流量的 TLS 加密的详细信息，请参阅 入口流量流 部分。

  • 入口控制器： 此示例使用 Traefik。 它在群集的用户节点池中运行。 它从内部负载均衡器接收流量，终止 TLS，然后通过 HTTP 将其转发到工作负载 Pod。

入口控制器是群集的关键组件。 配置此组件时，请考虑以下几点。

  • 作为设计决策的一部分，将入口控制器限制在特定的操作范围内。 例如，可以允许控制器仅与运行特定工作负荷的 Pod 进行交互。

  • 避免在同一节点上放置副本，以分散负载并在一个节点发生故障时帮助确保业务连续性。 请使用 podAntiAffinity 实现此目的。

  • 使用 nodeSelectors 将 Pod 约束为仅在用户节点池上调度。 此设置可隔离工作负载和系统容器组。

  • 打开让特定实体向入口控制器发送流量的端口和协议。 在此体系结构中，Traefik 仅接收来自Application Gateway的流量。

  • 配置 readinessProbe 和 livenessProbe 设置，以指定的时间间隔对 Pod 的运行状况进行监控。 入口控制器应发送指示 Pod 运行状况的信号。

  • 请考虑将入口控制器的访问权限限制为特定资源，并限制其可执行的操作。 可以通过 Kubernetes RBAC 权限来实现这一限制。 例如，在此体系结构中，Traefik 会通过使用 Kubernetes ClusterRole 对象中的规则被授予观察、获取和列出服务和终结点的权限。

Note

根据你的要求、工作负荷、团队的技能集以及技术选项的可支持性，选择适当的入口控制器。 最重要的是，入口控制器必须满足 SLO 期望。

Traefik 是 Kubernetes 群集的开源选项，此体系结构中的 Traefik 仅用于说明。 它显示非Microsoft产品与Azure服务的集成。 例如，实现演示如何将 Traefik 与 Microsoft Entra Workload ID 和 Key Vault 集成。

还可以使用 Application Gateway 入口控制器，该控制器与 AKS 非常集成。 Application Gateway除了作为入口控制器的角色之外，还提供优势。 它充当群集的virtual network入口点，可以观察进入群集的流量。 如果应用程序需要web application firewall，请使用Application Gateway。 它还支持 TLS 终止。

路由器设置

入口控制器使用路由来确定流量发送到的位置。 路由指定接收流量的源端口以及有关目标端口和协议的信息。

下面是此体系结构的示例：

Traefik 使用 Kubernetes 提供程序配置路由。 annotations、tls 和 entrypoints 选项表示路由通过 HTTPS 提供。 middlewares 选项指定仅允许来自Application Gateway子网的流量。 如果客户端接受，则响应将使用 gzip 编码。 由于 Traefik 执行 TLS 终止，因此与后端服务的通信通过 HTTP 进行。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: aspnetapp-ingress
  namespace: a0008
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.class: traefik-internal
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
    traefik.ingress.kubernetes.io/router.tls.options: default
    traefik.ingress.kubernetes.io/router.middlewares: app-gateway-snet@file, gzip-compress@file
spec:
  tls:
  - hosts:
      - bu0001a0008-00.aks-ingress.contoso.com
  rules:
  - host: bu0001a0008-00.aks-ingress.contoso.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: aspnetapp-service
            port:
              number: 80

保护网络流

在此体系结构中，网络流包括以下类型的流量：

  • 从客户端到群集中运行的工作负荷的入口流量。

  • 从群集中的 Pod 或节点流出流量流出到外部服务。

  • Pod 到 Pod 之间的流量 。 此流量包括入口控制器和工作负荷之间的通信。 如果工作负荷由部署到群集的多个应用程序组成，那么这些应用程序之间的通信也属于此类别。

  • 管理流量 客户端与 Kubernetes API 服务器之间的流量。

显示群集流量流的 Diagram.

下载此架构的 Visio 文件

此体系结构具有多个安全层来保护所有类型的流量。

入口流量流

该体系结构仅接受来自客户端的 TLS 加密请求。 TLS v1.2 是具有一组受限密码的最低允许使用版本。 服务器名称指示 (SNI) 严格匹配已启用。 端到端 TLS 通过使用两个不同的 TLS 证书通过Application Gateway进行设置，如下图所示。

显示 TLS 协议终止的 图表

下载此架构的 Visio 文件

  1. 客户端将 HTTPS 请求发送到域名：bicycle.contoso.com。 该名称与Application Gateway的公共 IP 地址的 DNS A 记录相关联。 此流量经过了加密，有助于确保无法检查或更改客户端浏览器与网关之间的流量。

  2. Application Gateway 具有集成的 Web 应用程序防火墙，并协商 TLS 握手bicycle.contoso.com，只允许使用安全的密码套件。 Application Gateway是 TLS 终止点，这一点很重要，因为Application Gateway web application firewall需要检查纯文本请求和响应。 Key Vault存储 TLS 证书。 群集使用与Application Gateway集成的用户分配的托管标识对其进行访问。 有关详细信息，请参阅 TLS 终止 Key Vault 证书。

    Application Gateway处理Web应用程序防火墙的检测规则，并运行路由规则将流量转发到已配置的后端。

  3. 当流量从应用程序网关移动到后端时，它将再次使用另一个 TLS 证书进行加密，该证书是 *.aks-ingress.contoso.com 的通配符，因为流量会被转发到内部负载均衡器。 这种重新加密有助于确保不安全的流量不会流入群集子网。

  4. 入口控制器通过负载均衡器接收加密流量。 控制器是 *.aks-ingress.contoso.com 的另一个 TLS 终止点，并通过 HTTP 将流量转发到工作负荷 Pod。 证书存储在Key Vault中，容器Storage接口（CSI）驱动程序将它们装载到群集中。 有关详细信息，请参阅添加机密管理。

可以在通过工作负载 Pod 的每个跃点实现端到端的 TLS 传输。 在决定确保 Pod 到 Pod 流量安全时，请务必衡量性能、延迟和运行效果。 对于大多数单租户群集，采用适当的控制平面 RBAC 和成熟的软件开发生命周期实践，将 TLS 加密应用到入口控制器，并使用网络应用防火墙进行保护就足够了。 这种方法最大限度地减少了工作量管理的开销和因网络性能不佳而造成的开销。 工作负荷和合规性要求决定了执行 TLS 终止的位置。

出口流量流

在此体系结构中，我们建议群集中的所有出口流量都经过Azure Firewall。 还可以使用自己的类似网络虚拟设备。 不建议使用其他出口选项，例如 Azure NAT 网关或 HTTP 代理，因为它们不提供网络流量检查。 为了实现零信任（Zero Trust）控制和对流量的检测能力，请通过Azure Firewall发送所有出口流量。 使用用户定义的路由（UDR）实现此配置。 路由的下一跃点是 Azure 防火墙的专用 IP 地址。 Azure Firewall根据定义的规则或内置的威胁情报规则来决定是否阻止或允许出口流量。

Azure Firewall的替代方法是使用 AKS HTTP 代理功能。 离开群集的所有流量都会转到 HTTP 代理的 IP 地址，由 HTTP 代理转发或丢弃流量。

对于任一方法，请查看 AKS 所需的 出口网络流量规则。

Note

如果您使用公共负载均衡器作为通过UDR和Azure防火墙对于传入和传出流量的公共入口，那么您可能会看到非对称路由方案。 此体系结构在Application Gateway后面的专用入口子网中使用内部负载均衡器。 此设计选择可增强安全性，并消除非对称路由问题。 或者，可以在Application Gateway之前或之后通过防火墙路由入口流量，但在大多数情况下，此方法不是必需的，我们不建议这样做。 有关非对称路由的详细信息，请参阅将防火墙与 Azure 标准负载均衡器集成。

Zero Trust控件的例外情况是群集需要与其他Azure资源通信。 例如，集群可能需要从容器注册表中拉取更新的映像，或者从 Key Vault 获取密钥。 在这些方案中，建议使用 Private Link。

使用Private Link的优点是，特定的子网直接到达服务，群集和服务之间的流量不会通过 Internet。 缺点是，Private Link需要额外的配置，而不是在其公共终结点上使用目标服务。 此外，并非所有Azure服务或产品都支持Private Link。 对于这些情况，请考虑在子网上启用虚拟网络服务终结点以访问该服务。

如果Private Link或服务终结点不可用，可以通过其公共终结点访问其他服务，并通过Azure Firewall规则和目标服务的内置防火墙来控制访问。 由于此流量通过防火墙的静态 IP 地址，因此可以将这些地址添加到服务的 IP 允许列表。

通过公共终结点连接到Azure服务的一个缺点是，Azure Firewall需要更多规则来确保仅允许来自特定子网的流量。 在计划使用 Azure Firewall 对流出流量使用多个 IP 地址时，请考虑这些地址。 否则，您可能会面临端口耗尽的风险。 有关如何规划多个 IP 地址的详细信息，请参阅 创建具有多个 IP 地址的Azure Firewall。

Pod 之间的通信

默认情况下，Pod 可以接受来自群集中任何其他 Pod 的流量。 使用 Kubernetes NetworkPolicy 限制 Pod 之间的网络流量。 请仔细应用策略，否则可能出现关键网络流被阻止的情况。 仅 允许在需要时特定的通信路径，例如入口控制器与工作负载之间的流量。 有关详细信息，请参阅 Network 策略。

设置群集时启用网络策略，因为以后无法添加它。 对于实现 NetworkPolicy 的技术，有几种选择。 我们推荐使用 Azure 网络策略，此策略需要 Azure CNI。 其他选项包括 Calico 网络策略，这是一种广为人知的开源选项。 如果需要管理群集范围的网络策略，请考虑使用 Calico。 卡利科不受标准Azure support覆盖。

有关详细信息，请参阅Azure网络策略引擎之间的差异。

管理流量

作为运行群集的一部分，Kubernetes API 服务器会接收来自需要在群集上执行管理操作的资源的流量，例如用于扩展群集的创建资源请求。 这些资源的示例包括 DevOps 管道中的生成代理池、Azure Bastion子网中的Azure Bastion实例以及节点池本身。 建议设置专用 AKS 群集，而不是接受来自所有 IP 地址的此管理流量。

有关详细信息，请参阅 Define API 服务器授权的 IP 范围。

建议将 AKS 群集部署为专用群集。 所有控制平面和节点池流量都保留在专用网络上，不会向公共 Internet 公开。 此参考实现使用 API 服务器与虚拟网络的集成来创建私有群集。 较低级别的环境可能会为了方便而考虑放宽此私有集群的建议。 但是，生产 AKS 群集应始终部署为私有群集，以确保安全部署的基础标准。

到专用 AKS 群集的专用流量可能源自辐射虚拟网络、对等网络或远程网络中的专用终结点。 尽管 AKS 节点自然位于辐射网络中，但操作员执行管理任务时需要专用的网络路径，以安全地访问 AKS API 服务器。 可以通过以下方式建立此连接：

  • Tunnelling： 使用 Azure Bastion 直接打开到群集 API 服务器的隧道。
  • Jump-box：预配跳转盒 VM，并使用Azure Bastion通过 SSH 或 RDP 连接到它。 从那里，操作员通过其专用 IP 地址针对群集的 API 服务器发出请求。

在参考实现中，在执行群集管理作时，我们使用Azure Bastion隧道连接到 AKS API 服务器。 一般情况下，这种方法更易于管理，比部署和管理跳转盒 VM 的成本更低，在多个操作员之间协调不太复杂。 但是，如果满足以下任一要求，可以选择使用跳转盒 VM：

  • 操作员使用不安全的设备。 如果客户端设备不受信任，跳转盒 VM 可以提供更强的安全性强化。
  • 操作员通过不稳定的网络进行连接。 跳板机 VM 可以提供与集群的更稳定连接，尤其是在处理长时间运行或批处理管理作业时。
  • 操作员使用高级诊断工具。 某些类型的诊断工具（如数据包捕获）可能不适用于隧道应用。

添加机密管理

将机密存储在托管密钥存储中，例如Key Vault。 优点是托管密钥存储处理机密轮换。 它提供强加密和访问审计日志。 它还能将核心机密保留在部署管道之外。 在这套架构中，启用并配置了 Key Vault 防火墙，并使用 Private Link 连接到 Azure 资源，例如允许 Key Vault 访问机密和证书。

Key Vault与其他Azure服务很好地集成。 使用这些服务的内置功能来访问机密。 有关 Application Gateway 如何获取 TLS 证书以进行入口流的详细信息，请参阅 Ingress 流量流 部分。

Azure RBAC 权限模型允许您将工作负载身份分配给 Key Vault 机密用户角色或 Key Vault 读取者角色，并访问机密。 有关详细信息，请参阅使用 Azure RBAC 访问 Key Vault。

访问群集密钥

必须使用工作负载身份来允许 Pod 从特定存储库访问机密。 为了简化检索过程，请使用 secrets 存储 CSI 驱动程序。 当 Pod 需要密钥时，驱动程序会连接到指定的存储，从卷中检索密钥，并将该卷挂载到集群中。 然后，Pod 可以从卷文件系统获取机密。

CSI 驱动有许多提供程序来支持各种托管存储服务。 此实现将 Key Vault 与机密存储 CSI 驱动程序配合使用。 加载项从Key Vault检索 TLS 证书，并在运行入口控制器的 Pod 中加载驱动程序。 此操作在 Pod 创建过程中进行，卷会同时存储公钥和私钥。

工作负荷存储

此体系结构中使用的工作负荷是无状态的。 如果必须存储状态，建议将其保存在群集外部。 有关工作负荷状态的指南不在本文的介绍范围内。

有关详细信息，请参阅 AKS 中应用程序的 Storage 选项。

策略管理

管理 AKS 群集的有效方法是通过政策来执行治理。 Kubernetes 通过开放策略代理 (OPA) Gatekeeper 来实现策略。 对于 AKS，通过Azure Policy传递策略。 每个策略都适用于其范围内的所有群集。 OPA Gatekeeper 负责处理群集中的策略执行，并记录所有策略检查。 策略变更不会立即反映在群集中，因此可能会出现一些延迟。

若要管理 AKS 群集，可以通过多种方式使用Azure Policy：

  • 防止或限制在资源组或订阅中部署 AKS 群集。 为组织应用标准。 例如，可以遵循命名约定或指定标记。

  • 通过 Azure Policy for Kubernetes 保护 AKS 群集。

一个常见示例，其中策略非常有用，就是围绕容器映像的治理和验证。 容器映像可以是漏洞的来源，某些组织要求使用容器映像扫描工具验证不受信任的容器映像，然后获得批准，然后才能在生产群集中使用它们。 可以使用Azure Policy强制执行此过程，并阻止不受信任的容器映像部署到群集。 有关详细信息，请参阅 隔离设计模式。

设置策略时，请根据工作负荷的要求应用策略。 请考虑以下因素：

  • 决定是否设置策略集合（称为 计划），还是选择单个策略。 Azure Policy提供两个内置计划：基本和受限。 每个计划都是适用于 AKS 群集的内置策略的集合。 建议选择一项措施并为群集和资源选择其他策略，例如与群集交互的容器注册表、应用程序网关或密钥保管库。 根据组织的要求选择策略。

  • 决定您是要 审核 还是 拒绝 该操作。 在 审计 模式下，允许执行该操作，但标记为 不符合。 具有定期检查不合规状态并采取必要措施的流程。 在拒绝模式下，动作被阻止，因为它违反了策略规则。 选择“拒绝”模式时请小心，因为工作负荷可能过于限制，无法正常运行。

  • 确定工作负荷中是否有设计不合规的区域。 Azure Policy可以指定不受策略强制实施的 Kubernetes 命名空间。 我们建议你仍在 审核 模式下应用策略，以便了解这些实例。

  • 确定是否有内置策略未涵盖的要求。 可以创建自定义Azure Policy定义来应用自定义 OPA Gatekeeper 策略。 不要直接将自定义策略应用到群集。 有关详细信息，请参阅 创建并分配自定义策略定义。

  • 确定你是否具有组织层面的需求。 如果是，请在管理组级别添加这些策略。 即使组织有通用策略，群集也应该分配自己的工作负荷特定策略。

  • 确定是否必须将Azure策略分配给特定范围。 确保根据预生产环境验证生产策略。 否则，部署到生产环境时，可能会遇到意外的额外限制，这些限制未在预生产中考虑。

创建 AKS 群集时，此参考实现启用Azure Policy。 限制性措施是在 审核 模式下分配的，用于获取对不合规情况的可视性。

该实现还设置了不属于任何内置计划的额外策略。 这些策略在 “拒绝 ”模式下设置。 例如，有一种策略可以确保只从已部署的容器注册表实例中拉取映像。

请考虑创建自己的自定义计划。 将适用于您工作负载的策略组合到一个任务中。

若要观察 Azure Policy 在群集中如何工作，可以访问 gatekeeper-system 命名空间中所有 pod 的日志，以及 kube-system 命名空间中 azure-policy 和 azure-policy-webhook pod 的日志。

节点和Pod的可伸缩性

随着需求增加，Kubernetes 可以通过水平 Pod 自动缩放，将更多 Pod 添加到现有节点来进行扩展。 当 Kubernetes 无法再调度更多 Pod 时，就必须通过 AKS 群集自动缩放来增加节点数量。 完整的缩放解决方案必须能够同时缩放群集中的 Pod 副本和节点数。

有两种方法：自动缩放或手动缩放。

自动缩放和手动方法都需要监控 CPU 使用情况或自定义指标并设置警报。 在 Pod 扩展方面，应用程序操作员可以通过 Kubernetes API 调整 ReplicaSet 来增加或减少 Pod 复制的数量。 对于群集缩放，一种方法是在 Kubernetes 调度器失败时进行通知。 另一种方法是持续监控处于待处理状态的 Pod。 可以通过Azure CLI或Azure portal调整节点计数。

建议使用自动缩放方法，因为某些手动机制内置于自动缩放程序中。

作为一般方法，首先使用最少数量的 Pod 和节点进行性能测试。 使用这些值可以建立基准预期。 然后，使用性能指标和手动缩放的组合来查找瓶颈并了解应用程序对缩放的响应。 最后，利用此数据来设置参数以实现自动缩放。

水平 Pod 自动扩展器

Horizontal Pod Autoscaler (HPA) 是一种 Kubernetes 资源，用于调整 Pod 的数量。

在 HPA 资源中，我们建议您设置副本计数的最小值和最大值。 这些值会约束自动缩放边界。

HPA 可以根据 CPU 使用情况、内存使用情况和自定义指标进行缩放。 仅原生提供 CPU 使用率。 HorizontalPodAutoscaler 定义指定指标的目标值。 例如，规范设定了目标 CPU 使用率。 当 Pod 运行时，HPA 控制器使用 Kubernetes 指标 API 来检查每个 Pod 的 CPU 使用率。 它将该值与目标使用率进行比较，并计算比率。 然后，它使用该比率来确定 Pod 是过度分配还是分配不足。 它依赖于 Kubernetes 调度器将新 Pod 分配到节点或从节点中删除 Pod。

可能会发生竞态条件，例如 HPA 在缩放操作完成之前进行检查。 因此，结果可能是错误的比率计算。 有关详细信息，请参阅缩放事件的 Cooldown。

如果工作负荷是事件驱动型的，则常用的开源选项是 Kubernetes 事件驱动自动扩展 (KEDA)。 如果事件源（如消息队列）驱动工作负荷，而不是工作负荷被 CPU 绑定或内存绑定，请考虑 KEDA。 KEDA 支持许多事件源和缩放器。 使用 KEDA 可以在 KEDA 缩放器中缩放的事件源列表。 该列表包括 Azure Monitor 缩放程序，这是基于 Azure Monitor 指标缩放 KEDA 工作负荷的便捷方式。

群集自动缩放程序

cluster 自动缩放程序是一个 AKS 加载项组件，用于缩放节点池中的节点数。 在群集配置过程中添加它。 需要为每个用户节点池创建单独的群集自动缩放程序。

Kubernetes 计划程序会触发群集自动缩放程序。 当 Kubernetes 计划程序由于资源约束而无法计划 Pod 时，自动缩放程序会自动在节点池中设置新节点。 相反，群集自动缩放程序会检查节点未使用的容量。 如果节点没有按照预期的容量运行，Pod 将移到另一个节点，并删除未被使用的节点。

启用自动缩放程序时，设置最大和最小节点数。 建议的值取决于工作负荷的性能预期、希望群集增加多少以及成本影响。 最小数目是该节点池的预留容量。 在此参考实现中，由于工作负荷的简单性，最小值被设置为 2。

对于系统节点池，建议的最小值为 3。

业务连续性决策

要保持业务连续性，请为基础结构和应用程序定义 SLO。 有关详细信息，请参阅 定义可靠性目标的建议。 请查看最新 SLA for online services 一文中 AKS 的服务级别协议（SLA）条件。

群集节点

为了满足工作负荷的最低可用性级别，则节点池中需要多个节点。 如果一个节点出现故障，同一节点池和群集中的另一个节点可以继续运行应用程序。 为确保可靠性，建议系统节点池使用三个节点。 对于用户节点池，一开始至少要有两个节点。 如果需要更高的可用性或容量，可以横向扩展以添加更多节点。

通过将应用程序放置在称为用户节点池的单独节点池中，将应用程序与系统服务隔离。 这样，Kubernetes 服务将在专用节点上运行，不会与其他工作负荷竞争。 建议使用标记、标签和污点来识别节点池并调度工作负荷。 确保您的系统节点池加上CriticalAddonsOnly 污点，以防止应用程序 Pod 被调度到系统节点池上。

群集上的常规维护任务（例如及时更新）对于可靠性至关重要。 此外，建议通过探测来监控 Pod 的运行状况。

Pod 可用性

  • 指定 Pod 资源要求： 建议在部署中指定 Pod 资源要求。 然后，调度器可以适当地调度 Pod。 如果无法对 Pod 进行调度，可靠性就会显著降低。

  • 设置 Pod 中断预算： 此设置确定部署中可在更新或升级事件期间关闭的副本数。 有关详细信息，请参阅 Pod 中断预算。

    在部署中配置多个副本以处理硬件故障等中断。 对于计划中的事件（如更新和升级），中断预算有助于确保所需的 Pod 副本数可用于处理预期的应用程序负载。

  • 在工作负荷命名空间上设置资源配额： 命名空间上的资源配额有助于确保在部署上正确设置 Pod 请求和限制。 有关详细信息，请参阅 实施资源配额。

    Note

    如果在群集级别设置资源配额，则部署没有适当请求和限制的外部工作负荷时可能会出现问题。 在命名空间级别设置配额时，它可确保它们仅适用于工作负荷组件。

  • 设置 Pod 请求和限制： 设置请求和限制，使 Kubernetes 能够有效地将 CPU 和内存资源分配给 Pod。 它在节点上提供更高的容器密度。 请求和限制还可以提高可靠性，同时提高硬件使用率，降低成本。

    要估算工作负荷的极限值，则需要进行测试并建立基准。 从请求和限制的相等值开始。 然后逐渐调整这些值，直到建立导致群集不稳定的阈值。

    可以在部署清单中指定请求和限制。 有关详细信息，请参阅 设置 pod 请求和限制。

可用区

若要防止某些类型的服务中断，请使用 availability zones（如果区域支持这些服务）。 然后，控制平面组件和节点池中的节点都是 区域冗余的，这意味着它们分布在多个区域。 如果整个区域不可用，则该地区内另一个区域中的节点仍然可用。 每个节点池映射到一个单独的虚拟机规模集，用于管理节点实例和可伸缩性。 AKS 服务负责管理规模集操作和配置。 以下是启用多个区域时的一些注意事项：

  • Entire infrastructure： 选择可用区支持的区域。 有关详细信息，请参阅 Limitations。 要获得正常运行时间 SLA，则需要选择标准层或高级层。 使用可用性区域时，正常运行时间 SLA 更高。

  • Cluster：您只能在创建节点池时设置可用区。 之后无法对它们进行更改。 所有区域都应支持该节点大小，以便可以实现期望的分布。 基础虚拟机规模集跨区域提供相同的硬件配置。

    区域冗余不仅适用于节点池，还适用于控制平面。 AKS 控制平面跨越请求的区域，如节点池。 如果不在群集中使用区域支持，则无法保证控制平面组件分布在可用区。

  • Dependent resources： 若要实现使用"availability zones"的弹性优势，所有服务依赖项也必须支持这些"可用区"。 如果依赖服务不支持区域，则区域故障会导致该服务失败。

    例如，假设工作负荷使用不具有区域复原能力的数据库。 如果发生故障，AKS 节点可能会移动到另一个区域，但数据库不会随节点一起移动到该区域，因此工作负荷会中断。

为了简化架构，将 AKS 部署到一个单一区域，并且节点池分布在三个可用性区域。 基础结构的其他资源（如Azure Firewall和Application Gateway）也部署到具有多个区域支持的同一区域。 为容器注册表启用地理复制。

多个区域

启用可用性区域时，单靠这些区域无法充分覆盖，整个区域发生故障的情况仍然可能发生。 要获得更高的可用性，请在不同的地区运行多个 AKS 群集。

  • 在可用时，首选 配对区域。 使用配对区域的一个好处是平台更新时的可靠性。 Azure 确保每次仅更新配对区域中的一个。 一些地区没有配对。 如果区域没有配对，仍然可以通过选择其他区域来部署多区域解决方案。 考虑使用持续集成和持续交付 (CI/CD) 管道，可以对其进行配置，以协调从区域故障中恢复。 Flux 等特定 DevOps 工具可以简化多区域部署。

  • 如果Azure资源支持异地冗余，则提供冗余服务具有其辅助实例的位置。 例如，通过为容器注册表启用异地复制，它会自动将映像复制到所选Azure区域。 它还提供持续访问镜像的功能，即使主要区域遇到服务中断时也可以访问。

  • 选择一个可跨区域分发流量的流量路由器，具体取决于你的需求。 此体系结构部署Load Balancer，因为它可以跨区域分发非网络流量。 如果需要跨区域分配流量，请考虑Azure Front Door。 有关其他选项，请参阅 选择负载均衡器。

Note

多区域群集示例方案的 AKS 基线扩展了本文中的体系结构，以在主动-主动和高可用性配置中包含多个区域。

灾难恢复

理想情况下，如果主要区域中发生故障，则可以快速切换到另一个区域中的实例。 可以预先创建群集，或等待创建群集，直到它是必需的。 请考虑以下建议：

  • 使用多个区域。 如果主要区域有配对区域，请使用该配对区域。 如果没有，请根据数据驻留和延迟要求选择区域。

  • 使用可以有效复制的非状态工作负荷。 如果必须在群集中存储状态（我们不建议），请确保经常在另一个区域中备份数据。

  • 将恢复策略整合到 DevOps 管道中，例如复制到另一个区域，以满足 SLO。

  • 使用支持灾难恢复的功能设置每个Azure服务。 例如，在此体系结构中，启用容器注册表以用于异地复制。 如果某个区域发生故障，仍可从复制的区域拉取映像。

  • 以代码形式部署基础结构，包括 AKS 群集和所需的任何其他组件。 如果需要部署到另一个区域，可以重复使用脚本或模板来创建相同的实例。

群集备份

对于许多体系结构，可以设置一个新群集，并通过基于 GitOps 的 群集引导将其返回到运行状态，然后是应用程序部署。 但是，如果某些关键资源状态（如配置映射、作业和机密信息）无法在引导过程中捕获，请考虑您的恢复策略。 建议在 Kubernetes 中运行无状态工作负荷。 如果体系结构涉及基于磁盘的状态，则还必须考虑该内容的恢复策略。

当群集备份必须是恢复策略的一部分时，必须安装符合群集中业务需求的解决方案。 此代理负责将群集资源状态推送到您选择的目标，并协调基于Azure磁盘的持久卷快照。

VMware Velero 是一个常见的 Kubernetes 备份解决方案示例，可以直接安装和管理。 也可以使用 AKS 备份扩展提供托管的 Velero 实现。 AKS 备份扩展支持备份 Kubernetes 资源和持久卷，并在 Azure Backup 中将计划和备份范围外部化为保管库配置。

参考实现不实现备份，这涉及到额外的Azure资源来管理、监视、购买和安全。 这些资源可能包括 Azure 存储账户、Azure 备份保管库及其配置，以及 受信任的访问功能。 相反，GitOps 与运行无状态工作负荷的意图相结合是恢复解决方案。

选择并验证满足业务目标的备份解决方案，其中包括定义的恢复点目标和恢复时间目标。 在团队的运行手册中定义您的恢复过程，针对所有业务关键型工作负荷进行演练。

Kubernetes API 服务器 SLA

可以将 AKS 用作免费服务，但该服务层不提供有经济保障的 SLA。 若要获取 SLA，必须选择 Standard 层。 建议所有生产群集都使用标准层。 为预生产群集保留免费层，而高级层仅保留用于关键任务的工作负载。 使用Azure availability zones时，Kubernetes API 服务器 SLA 更高。 您的节点池和其他资源都有各自的服务等级协议。

有关每个服务的特定 SLA 的详细信息，请参阅 SLA for online services。

权衡

跨区域（尤其是区域）部署体系结构需要成本到可用性的权衡。 某些复制功能（如容器注册表中的异地复制）在高级 SKU 中可用，这更昂贵。 对于多区域部署，成本也会增加，因为流量跨区域传输时需要支付带宽费用。

此外，预期在可用区之间的节点通信中会有少量额外的网络延迟，而在区域之间的通信中延迟则会更明显。 衡量此体系结构决策对工作负荷的影响。

使用模拟和强制故障转移进行测试

通过模拟中断进行强制故障切换测试，以测试解决方案的可靠性。 模拟可包括停止一个节点、关闭特定区域的所有 AKS 资源以模拟区域故障，或调用外部依赖性故障。 还可以使用Azure Chaos Studio来模拟Azure和群集上的各种类型的服务中断。

有关详细信息，请参阅 Chaos Studio。

监视和收集日志和指标

建议使用 Azure Monitor Kubernetes 监视服务监视容器工作负荷的性能，因为你可以实时查看事件。 Azure Monitor 从正在运行的 Pod 捕获容器日志，并聚合它们以供查看。 它还从指标 API 收集有关内存和 CPU 使用率的信息，以监控正在运行的资源和工作负荷的运行状况。 还可以使用 Azure Monitor 监视 Pod 缩放时的性能。 它包括对所收集数据的监控、分析和可视化至关重要的遥测技术。

启用 Pod 的日志收集

ContainerLogV2 日志架构旨在通过简化的方法从 Kubernetes Pod 捕获容器日志。 日志条目合并到 Azure Log Analytics 工作区中的 ContainerLogV2 表中。

在 AKS 群集中，有两种用于配置 Pod 日志收集的主要方法。 这两种方法都允许自定义设置。 可以筛选命名空间、调整收集间隔、启用或禁用特定功能（如 ContainerLogV2 或 ContainerLogV2-HighScale），并指定要收集的数据流。

  • 如果需要在多个群集之间实现集中管理的可重用监控配置，或者希望群集配置在 Azure 原生资源中进行外部化，请使用 数据收集规则（DCR）。 DCR 是由 Azure Resource Manager 控制平面本地管理的 Azure 资源，你可以在 Bicep 文件中包含它们。 引用实现使用 DCR。

  • 或者，可以使用 ConfigMaps 定义监控，这些是通过 Kubernetes API 控制平面配置的非机密 Kubernetes YAML 对象。 运行在群集上的 Azure Monitor 代理监视 ConfigMap 对象。 它使用预定义的设置来确定要收集的数据。

启用这两种方法后，ConfigMap 设置优先于 DCR。 避免将 ConfigMap 和 DCR 配置混合用于容器日志收集，因为它可能会导致难以排查日志记录问题。

警报和 Prometheus 指标

中断和故障对工作负荷应用程序构成重大风险，这使得主动识别与基础结构运行状况和性能相关的问题至关重要。 监视环境并处理所学内容时，可减少中断并提高解决方案的可靠性。 若要预测群集中的潜在故障情况，请启用 Kubernetes 建议的 Prometheus 警报规则。

Pod 中托管的大多数工作负荷都会提供 Prometheus 指标。 Azure Monitor 可与 Prometheus 集成。 可以查看从容器、Pod、节点和群集收集的应用程序和工作负荷指标。

某些非Microsoft解决方案与 Kubernetes 集成，例如 Datadog、Grafana 或 New Relic。 因此，如果组织已经在使用这些解决方案，则可以利用它们。

Azure基础设施和Kubernetes控制平面日志

使用 AKS，Azure管理一些核心 Kubernetes 服务。 Azure将 AKS 控制平面组件的日志实现为 资源日志。 这些选项可帮助你排查群集问题，并且日志密度相对较低。 建议在大多数群集上启用以下选项：

  • ClusterAutoscaler：通过日志记录获取缩放作的可观测性。 有关详细信息，请参阅 检索群集自动调整程序的日志和状态。

  • KubeControllerManager：获取对 Kubernetes 与 Azure 控制平面之间交互的可观测性。

  • kube-audit-admin：在修改群集的活动中获取可观测性。 无需同时启用kube-audit和kube-audit-admin，因为kube-audit作为一个更大的集合，也包括只读操作。

  • guard：捕获 Microsoft Entra ID 和 Azure RBAC 审核。

在早期群集或工作负荷生命周期开发期间启用其他日志类别（例如 KubeScheduler 或 kube-audit）可能会有所帮助。 添加的群集自动缩放、Pod 放置和调度以及类似数据可帮助排除群集或工作负荷运行方面的故障。 如果在故障排除结束后仍然持续启用扩展故障排除日志，可能会导致在 Azure Monitor 中引入和存储数据的成本增加。

Azure Monitor 包括一组要从头开始的现有日志查询，但你也可以将其用作基础来帮助构建自己的查询。 随着库的增长，可以使用一个或多个 query 包保存和重用日志查询。 自定义查询库为 AKS 群集的运行状况和性能提供更高的可观测性。 它支持实现您的 SLOs。

有关监视 AKS 的最佳做法的详细信息，请参阅 使用 Azure Monitor 监视 AKS。

网络指标

基本的群集级网络指标可以通过本地平台和 Prometheus 指标获取。 可以进一步使用 AKS node 网络指标，通过 Prometheus 指标在节点级别公开这些网络指标。 大多数群集应包括网络可观测性，以提供额外的网络故障排除功能，以及检测节点级别的意外网络使用情况或问题。

参考实现使用 Azure Monitor，它还收集一些与网络相关的指标。 参考实现禁止直接从 Azure Monitor 收集某些网络指标，而是使用具有 managed Prometheus 的 Azure Monitor 工作区收集网络可观测性指标。

对于对传输控制协议 (TCP) 或用户数据报协议 (UDP) 丢包、延迟或 DNS 压力高度敏感的工作负荷，Pod 级网络指标非常重要。 在 AKS 中，可以使用 高级容器网络服务功能访问这些详细指标。 大多数工作负荷并不需要这种深度的网络可观测性。 除非 Pod 需要高度优化的网络，并且敏感度达到数据包级别，否则不应启用高级网络可观测性。

日志记录的成本优化

参考实现将 ContainerLogV2 表配置为使用基本计划作为起点。 Microsoft Defender for Containers和为参考实现创建的警报不会查询此表，因此基本计划可能是具有成本效益的选择，因为它降低了数据引入成本。

随着日志量和查询要求的发展，请根据需要选择最经济高效的表计划。 如果解决方案变得读取密集型，其中查询经常扫描表数据，则默认分析计划可能更合适。 Analytics 计划消除了查询费用，从而优化那些查询活动超过引入成本的情况。 监视使用情况模式并根据需要调整表计划时，可以在监视解决方案的成本和功能之间取得平衡。

有关详细信息，请参阅 根据 Log Analytics 工作区中的数据用量选择一个表格方案。

启用自我修复

通过设置活动性探测和就绪探测来监控 Pod 的运行状况。 如果 Kubernetes 检测到 Pod 无响应，它会重新启动 Pod。 健康状况探测器确定 Pod 是否处于健康状态。 如果 Kubernetes 检测到 Pod 无响应，它会重新启动 Pod。 就绪探针用于确定 Pod 是否已准备好接收请求和网络流量。

Note

AKS 具有 自动节点修复功能，为基础结构节点提供内置自我修复功能。

AKS 群集的例行更新

Kubernetes 群集第 2 天的部分操作是执行例行平台和 OS 更新。 每个 AKS 群集都有三层更新需要处理：

  • Kubernetes 版本（如 Kubernetes 1.32.3 到 1.32.7 或 Kubernetes 1.32.7 到 1.33.1），这可能附带 Kubernetes API 更改和弃用。 此层的版本更改会影响整个群集。

  • 每个节点上的虚拟硬盘 (VHD) 映像负责合并操作系统更新和 AKS 组件更新。 这些更新针对群集的 Kubernetes 版本进行过测试。 此层的版本更改在节点池级别应用，并且不会影响 Kubernetes 版本。

  • 操作系统的原生更新过程，如 Windows Update 或 apt。 操作系统供应商会直接提供这些更新，但不会针对群集的 Kubernetes 版本进行测试。 此层的版本更改会影响单个节点，但不会影响 Kubernetes 版本。

每一层都可独立控制。 可以决定如何处理工作负荷群集的每一层。 选择每个 AKS 群集、节点池或节点更新的频率（ 节奏）。 此外，请选择应用更新的天数或时间（ 维护时段）。 选择更新是手动安装还是自动安装，或者根本不安装。 就像在群集上运行的工作负载需要采用安全部署实践一样，群集的更新也需要这样。

有关修补程序和升级的全面视角，请参阅 AKS 修补和升级指南，在 AKS 第 2 天操作指南中。 使用以下信息来获取与该体系结构相关的基线建议。

不可变基础结构

将 AKS 群集作为不可变基础结构运行的工作负荷不会自动或手动更新其群集。 将 node 映像升级设置为 none，并将 集群自动升级设置为 none。 在此配置中，你全权负责所有层的所有升级。

当所需的更新可用时，必须执行以下步骤：

  1. 在预生产环境中测试更新，并评估其在新群集上的兼容性。

  2. 部署包含更新的 AKS 版本和节点池 VHD 的生产副本环境。

  3. 新生产群集准备就绪后，请清空旧群集，并最终将其停用。

只有在不可变基础结构定期部署新基础结构的情况下，生产群集才不应采用就地升级策略。 所有其他群集都应具有就地升级策略。

就地升级

不以不可变基础结构身份运行 AKS 群集的工作负荷应定期更新其正在运行的群集，以解决所有三个层的问题。 使更新过程符合工作负荷的要求。 使用以下建议作为起点来设计例程更新过程。

  • 计划 AKS 的 计划维护 功能，以便在群集上进行升级管理。 此功能可在可控的时间内执行更新这一固有风险的操作，以减少意外故障的影响。

  • 配置 Pod 中断预算，以便应用程序在滚动升级期间保持稳定。 但是，不要将预算配置得过于严格，以免阻碍节点升级，因为大多数升级需要在每个节点上进行隔离和清空过程。

  • 确认Azure资源配额和资源可用性。 在删除旧节点之前，进行就地升级时会部署新实例节点，称为扩展节点。 这意味着Azure配额和 IP 地址空间必须可用于新节点。 surge 值为 33% 是大多数工作负荷的良好起点。

  • 测试与增添到集群中的技术工具（如服务网格或安全代理）的兼容性。 此外，测试工作负荷组件，例如入口控制器、服务网格和工作负荷 Pod。 在预生产环境中运行测试。

节点就地升级

使用 NodeImage 自动升级渠道进行节点 OS 映像升级。 通过此通道配置群集，以便在每个节点上进行节点级 VHD 更新。 Microsoft 会根据 AKS 版本来测试更新。 对于 Windows 节点，更新大约每月进行一次。 对于 Linux 节点，更新每周大约发生一次。

  • 升级不会改变 AKS 或 Kubernetes 版本，所以不用担心 Kubernetes API 的兼容性问题。

  • 当使用 NodeImage 作为升级通道时，它会遵循计划内维护时段，应将其设置为至少每周一次。 无论使用哪个节点映像操作系统，都应进行设置以帮助确保及时应用更新。

  • 这些更新包括 OS 级安全性、兼容性和功能更新、操作系统配置设置以及 AKS 组件更新。

  • 使用 AKS 发布跟踪器跟踪映像版本及其包含的组件版本号。

如果群集的安全要求需要更积极的修补节奏，并且群集可以容忍潜在的中断，则改用 SecurityPatch 升级渠道。 Microsoft 也会对这些更新进行测试。 仅当有安全升级被Microsoft认为重要到足以在下次计划的节点映像升级之前发布时，才会发布更新。 使用 SecurityPatch 渠道时，还会获得 NodeImage 渠道收到的更新。 通道 SecurityPatch 选项仍然遵循您的维护时段，因此请确保您的维护时段有更频繁的间隙（例如每天或隔天），以支持这些突如其来的安全更新。

大多数进行就地升级的群集应避免 None 和 Unmanaged 节点映像升级渠道选项。

群集就地更新

Kubernetes 是一个快速发展的平台，定期更新会带来重要的安全修补程序以及新功能。 请务必与 Kubernetes 更新保持同步。 您应停留在 最新的两个版本（N-2）之内。 升级到 Kubernetes 的最新版本至关重要，因为新版本经常发布。

大多数群集应能够非常谨慎和严格地执行就地 AKS 版本更新。 执行就地 AKS 版本升级的风险主要可以通过足够的预生产测试、配额验证和 Pod 中断预算配置来缓解。 但任何就地升级都可能导致不可预见的行为。 如果就地升级被认为对工作负荷太有风险，建议使用 AKS 群集的 蓝绿色部署方法，而不是遵循剩余的建议。

建议在首次部署 Kubernetes 群集时避免 cluster 自动升级功能。 使用手动方法，这样你就有时间在更新进入生产环境之前在预生产环境中测试新的 AKS 群集版本。 此方法还实现了最高程度的可预测性和控制。 但是，必须努力监控 Kubernetes 平台的新更新，并在新版本发布时快速采用新版本。 最好采用“保持最新”的思维模式，而不是长期支持的方法。

Warning

我们建议不要自动修补或更新生产 AKS 群集，即使有次要版本更新也不例外，除非这些更新已首先在较低环境中进行了测试。 有关详细信息，请参阅 定期更新到最新版本的Kubernetes 和 升级AKS集群。

可以使用适用于 Azure 事件网格的 AKS 系统，在你的群集有新 AKS 版本可用时收到通知。 参考实现部署此事件网格系统，以便您可以从事件流通知解决方案中订阅 Microsoft.ContainerService.NewKubernetesVersionAvailable 事件。 有关特定兼容性问题、行为更改或功能弃用，请查看 AKS 发行说明。

你最终可能会对 Kubernetes 版本、AKS 版本、群集、群集级别组件和工作负荷达到自信的程度，从而探索自动升级功能。 对于生产系统，很少超越 patch。 此外，当你自动升级 AKS 版本时，请检查你在代码化基础设施（IaC）中的 AKS 版本设置，以确保它们保持同步。配置计划维护窗口以支持自动升级操作。

安全监视

监控容器基础结构，了解主动威胁和潜在安全风险。 有关详细信息，请参阅以下资源：

集群和工作负载操作

有关群集和工作负荷操作（DevOps）考量事项，请参阅卓越运营设计原则一栏。

集群引导

设置群集后，这时它是一个可工作的群集，然而，在部署工作负载之前，可能还需要进一步的设置。 准备群集的过程称为 引导。 启动过程通常包括将必备镜像部署到群集节点上、创建命名空间以及执行满足组织用例要求的其他任务。

若要加快从新设置的群集到正确配置的群集的转换，必须定义唯一的引导过程，并提前准备相关资产。 例如，如果使用 Linkerd 或 Consul Connect 等服务网格，通常会在计划应用程序工作负荷之前部署网格。 在设置群集之前，必须验证服务网格的映像是否存在于以前创建的容器注册表中。 此验证有助于防止部署延迟或失败。

可以使用以下方法之一来配置引导过程：

Note

这些方法中的任何一种都适用于任何群集拓扑，但推荐 GitOps Flux v2 群集扩展用于机群，因为它具有统一性，更易于大规模治理。 如果只运行几个群集，GitOps 可能会过于复杂。 可以选择将流程集成到一个或多个部署管道中，以确保引导过程的进行。 使用最符合组织和团队目标的方法。

使用适用于 AKS 的 GitOps Flux v2 群集扩展的主要优势之一是预配群集和引导群集之间实际上没有差距。 它为未来的环境管理奠定了坚实的基础，并支持将引导过程作为资源模板来与基础设施即代码 (IaC) 策略保持一致。

最后，使用 GitOps Flux v2 群集扩展时，引导过程的任何部分都不需要 kubectl。 可以为紧急故障修复情况保留基于 kubectl 的访问。 在用于Azure资源定义的模板和通过 GitOps 扩展启动清单之间，无需使用 kubectl 即可执行所有常规配置活动。

区分工作负载责任

按团队和资源类型划分工作负荷，以单独管理每个部分。

从包含基本组件的基本工作负荷开始，并以此为基础进行构建。 初始任务是配置网络。 为中心和辐射节点设置虚拟网络，并且在这些网络中设置子网。 例如，spoke 为系统节点池和用户节点池、入口资源和专用 AKS API 服务器提供了独立的子网。 在中心部署Azure Firewall的子网。

另一项任务是将基本工作负荷与Microsoft Entra ID集成。

使用 IaC

尽可能选择幂等声明式方法而不是命令式方法。 与其编写指定配置选项的命令序列，不如使用描述资源及其属性的声明性语法。 引用实现使用 Bicep，但可以选择改用 Terraform 或 Azure Resource Manager 模板（ARM 模板）。

请务必根据管理策略设置资源。 例如，在选择 VM 规格时，应在成本限制和可用性区域选项的范围内进行选择，以符合应用程序的需求。 还可以使用 Azure Policy 强制实施组织对这些决策的策略。

如果需要编写一系列命令，请使用 Azure CLI。 这些命令涵盖一系列Azure服务，你可以通过脚本自动执行这些服务。 Windows 和 Linux 支持Azure CLI。 另一个跨平台选项是Azure PowerShell。 选择取决于偏好的技能组。

在源代码管理系统中存储脚本和模板文件并进行版本控制。

工作负荷 CI/CD

工作流和部署管道必须能够持续地构建和部署应用程序。 更新必须安全、快速地部署，并在出现问题时进行回滚。

部署策略需要包括可靠的自动持续交付管道。 将工作负载容器镜像中的更改自动部署到群集。

在此体系结构中，GitHub Actions管理工作流和部署。 其他常用选项包括 Azure DevOps Services 和 Jenkins。

集群 CI/CD

显示工作负载CI/CD的图表。

下载此架构的 Visio 文件

不使用 kubectl 等命令性方法，而是使用自动同步群集和存储库更改的工具。 若要在部署到生产环境之前管理工作流，例如新版本的发布和该版本的验证，请考虑 GitOps 流。

CI/CD 流程的一个重要部分是启动新配置的集群。 GitOps 方法非常有用，因为它可以让操作员以声明方式定义引导过程，将其作为 IaC 战略的一部分，并在群集中自动反映配置。

在使用 GitOps 时，会在群集中部署一个代理，以确保群集的状态与存储在专用 Git 存储库中的配置相协调。 其中一个代理是 Flux，它使用群集中的一个或多个运算符来触发 Kubernetes 中的部署。 Flux 执行以下任务：

  • 监视所有配置的存储库
  • 检测新的配置更改
  • 触发器部署
  • 根据这些更改更新所需的运行配置

还可以设置治理这些更改的部署方式的策略。

以下示例图显示了如何使用 GitOps 和 Flux 自动执行群集配置。

该图展示了 GitOps 流程。

下载此架构的 Visio 文件

  1. 开发人员将更改提交到源代码，例如存储在 Git 存储库中的配置 YAML 文件。 然后将更改推送到 Git 服务器。

  2. Flux 与工作负荷一起在 Pod 中运行。 Flux 对 Git 存储库具有只读access，以确保 Flux 仅按开发人员的要求应用更改。

  3. Flux 可识别配置中的更改并通过使用 kubectl 命令来应用这些更改。

  4. 开发人员无法通过 kubectl 直接访问 Kubernetes API。

可以在 Git 服务器上设置分支策略，这样多个开发人员就可以通过拉取请求批准变更，然后再将变更应用到生产中。

虽然可以手动配置 GitOps 和 Flux，但我们建议使用适用于 AKS 的 Flux v2 群集扩展的 GitOps。

工作负荷和群集部署策略

将任何更改（如体系结构组件、工作负载和群集配置）部署到至少一个预生产 AKS 群集。 此过程模拟这些更改，可能在问题被部署到生产环境之前识别出来。

在继续下一阶段之前，在每个阶段运行测试和验证。 它有助于确保以高度受控的方式向生产环境推送更新，并最大限度地减少意外部署问题造成的中断。 部署应遵循与生产类似的模式，方法是使用相同的GitHub Actions管道或 Flux 运算符。

高级部署技术（如 蓝绿部署、A/B 测试和 Canary 版本）需要额外的流程和潜在的额外工具。 Flagger是一种常用的开源解决方案，可帮助解决高级部署方案。

成本管理

首先查看成本优化设计清单以及Well-Architected Framework for AKS中概述的建议列表。 有关常规工作负荷建议，请参阅 成本优化审核清单。

可以在 Azure 定价计算器0 中找到此基线体系结构中使用的组件的成本估算值。 修改估算值以包含用例所需的组件。

请考虑使用 AKS 成本分析进行 Kubernetes 特定构造的精细群集基础结构成本分配。

Provision

  • 了解成本的来源。 AKS 在部署、管理和运营 Kubernetes 群集方面的成本极低。 影响成本的是群集消耗的 VM 实例、storage、日志数据和网络资源。 考虑为系统节点池选择更便宜的 VM。 Ddv5 系列是系统节点池的典型 VM 类型，引用实现使用 Standard_D2d_v5 SKU。

  • 不要对开发/测试和生产环境使用相同的配置。 生产工作负荷对高可用性有额外的要求，而且通常成本更高。 开发/测试环境中不需要此配置。

  • 为生产工作负荷添加正常运行时间 SLA。 但是，为不需要保证可用性的开发/测试或试验工作负荷设计的群集可以节省成本。 例如，SLO 可能已足够。 此外，如果工作负荷支持它，请考虑使用运行 spot VM 的专用现成节点池。

    对于作为 AKS 工作负荷体系结构的一部分包括Azure SQL Database或Azure App Service的非生产工作负荷，请评估是否有资格使用 Azure 开发/测试订阅并接收服务折扣。

  • 以最少的节点数配置群集，并启用群集自动缩放程序来监控和决定规模，而不是一开始就使用过大的群集来满足缩放需求。

  • 设置 Pod 请求和限制，让 Kubernetes 分配密度更高的节点资源，以便使用节点的完整容量。

  • 考虑在群集上启用诊断功能会增加成本。

  • 承诺选择一年或三年期限的Azure预留虚拟机实例，以便在工作负荷必须长期存在时降低节点成本。 有关详细信息，请参阅使用 Azure 虚拟机预留实例节省成本。

  • 创建节点池时使用标记。 标记有助于创建自定义报告，跟踪发生的成本。 可以使用标记来跟踪总费用，并将任何费用映射到特定资源或团队。 如果群集在团队之间共享，请为每个使用者生成费用分摊报告，以确定共享云服务的按流量计费成本。 有关更多信息，请参阅 为节点池指定污点、标签或标记。

  • 如果工作负荷是多区域的，并且在区域间复制数据，则需要额外的带宽成本。 有关详细信息，请参阅 带宽定价。

  • 制定预算，使其不超出组织确定的成本限制。 可以通过 Microsoft 成本管理来创建预算。 还可以创建警报，以在超出特定阈值时获取通知。 有关详细信息，请参阅使用模板创建预算。

Monitor

可以监视整个群集以及计算成本、storage、带宽、日志和防火墙。 Azure提供以下选项来监视和分析成本：

实时或定期监视成本，以便在已计算成本时，可以在月底之前采取措施。 监视一段时间内的每月趋势，以保持在预算范围内。

要做出以数据为导向的决策，就必须精确定位哪种资源的成本最高。 此外，还要充分了解计算资源使用情况的指标。 例如，通过分析指标，可以确定平台是否过大。 可以在Azure监视指标中查看使用情况计量。

Optimize

按照 Azure Advisor 的建议进行执行。 探索其他优化方法：

  • 启用群集自动缩放程序，以检测并删除节点池中使用不足的节点。

    Important

    快速或频繁地更改群集自动缩放程序设置（例如节点池的最小和最大节点计数），以控制成本可能会导致意外或适得其反的结果。 例如，如果 scale-down-unneeded-time 设置为 10 分钟，并且根据工作负荷特征每五分钟修改一次最小和最大节点设置，则节点数永远不会减少。 这是因为每个节点的未使用时间计算在刷新群集自动缩放程序设置时会被重置。

  • 如果工作负荷支持，请为节点池选择较低的 SKU。

  • 如果应用程序不需要突发性扩展，请考虑通过分析一段时间内的性能指标来调整集群规模。

  • 如果工作负载允许，在没有运行期望时将用户节点池缩放到零节点。 如果群集中没有计划运行的工作负荷，请考虑使用 AKS 启动/停止功能关闭所有计算，其中包括系统节点池和 AKS 控制平面。

有关详细信息，请参阅 AKS 定价。

后续步骤