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

Azure Kubernetes 服务 (AKS) 群集的基线体系结构

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

本文提供了部署 Azure Kubernetes 服务 (AKS) 群集的推荐基线基础体系结构。 它采用了我们的设计原则，并基于 Azure Well-Architected Framework 中的 AKS 体系结构最佳做法。 本文有助于指导多个不同的跨学科小组（如网络、安全和身份识别团队）部署这种通用基础结构。

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

业务需求会影响目标体系结构，而且不同的应用环境也会有所不同。 将体系结构作为预生产和生产阶段的起点。

Kubernetes 是一个强大的生态系统，可扩展到 Azure 和 Microsoft 技术之外。 部署 AKS 群集时，你需要负责做出有关如何设计和操作群集的许多决策。 运行 AKS 群集涉及混用来自各种供应商（包括 Microsoft）的闭源组件，以及 Kubernetes 生态系统中的开源组件。 环境经常发生更改，可能需要定期重新访问决策。 采用 Kubernetes 即表示你确认工作负荷需要其功能，并且工作负荷团队已准备好持续投资。

可以在 GitHub：AKS 基线参考实现上使用此体系结构的实现。 将其作为另一个起点，并根据自己的需求配置参考体系结构。

注意

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

网络配置

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

群集计算

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

身份管理

为群集集成 Microsoft Entra ID
为工作负荷集成 Microsoft Entra ID

保护数据流

保护网络流
添加机密管理

业务连续性

伸缩性
群集和节点可用性
可用性和多地区支持

Operations

群集和工作负荷 CI/CD 管道
群集运行状况和指标
成本管理和报告

网络拓扑

此体系结构使用中心辐射型网络拓扑。 在通过虚拟网络对等互连连接的独立虚拟网络中部署中心和分支。 此拓扑结构具有多种优点。 使用此拓扑结构可以：

  • 实现分开管理。 可以实行治理，并遵循最小特权原则。 它还支持职责分离的 Azure 登陆区域概念。

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

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

  • 使用 Web 应用程序防火墙服务，帮助检查所有 Web 应用程序的 HTTP 流量流。

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

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

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

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

体系结构示意图显示中心辐射型网络拓扑。

下载此体系结构的 Visio 文件。

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

有关 AKS 基线参考体系结构上的 Windows 容器所包含的网络设计变更的详细信息，请参阅 AKS 上的 Windows 容器。

中心虚拟网络

中心虚拟网络是连接性和可观测性的中心点。 在此体系结构中，中心包含：

  • Azure 防火墙具有由中央 IT 团队定义的全局防火墙策略，可在整个组织范围内执行防火墙策略。
  • 用于远程访问虚拟机 (VM) 的 Azure Bastion。
  • 用于 VPN 连接的网关子网。
  • 用于网络可观测性的 Azure Monitor。

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

用于托管 Azure 防火墙的子网

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

用于托管网关的子网

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

用于托管 Azure Bastion 的子网

此子网是 Azure Bastion 的占位符。 可以使用 Azure Bastion 安全地访问 Azure 资源，而无需将资源暴露于 Internet。 此子网仅供管理和操作使用。

辐射虚拟网络

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

用于托管 Azure 应用程序网关的子网

应用程序网关是在第 7 层运行的 Web 流量负载均衡器。 参考实现使用了启用 Azure Web 应用程序防火墙的应用程序网关 v2 SKU。 Web 应用程序防火墙可确保传入流量免受常见 Web 流量攻击，包括机器人攻击。 该实例具有接收用户请求的公共前端 IP 配置。 根据设计，应用程序网关需要专用子网。

用于托管入口资源的子网

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

用于托管群集节点的子网

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

为 Azure 容器注册表和 Azure Key Vault 创建专用链接连接，以便用户可以通过分支虚拟网络中的专用终结点来访问这些服务。 专用终结点不需要专用子网。 还可以在中心虚拟网络中放置专用终结点。 在基准实现中，终结点会被部署到分支虚拟网络中的专用子网。 这种方法可减少通过对等网络连接的流量。 它将属于群集的资源保存在同一个虚拟网络中。 还可以使用网络安全组在子网级别应用精细的安全规则。

有关详细信息，请参阅专用链接部署选项。

规划 IP 地址

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

下载此体系结构的 Visio 文件。

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

  • Azure 虚拟网络，用于群集节点、专用终结点和应用程序网关等资源。
  • 群集使用 Azure CNI 覆盖，此覆盖会将 Pod IP 地址从单独的地址空间分配到 Azure 虚拟网络。

虚拟网络 IP 地址空间

Azure 虚拟网络的地址空间应该足够大以容纳所有子网。 请考虑接收流量的所有实体。 Kubernetes 从子网地址空间为这些实体分配 IP 地址。 规划 Azure 虚拟网络的 IP 地址时，请考虑这些要点。

  • 升级：AKS 定期更新节点，以确保基础 VM 的安全功能和其他系统补丁是最新的。 在升级过程中，AKS 会创建一个临时托管 Pod 的节点，同时对升级节点进行封锁和清空。 该临时节点被分配了来自群集子网的 IP 地址。 确保有足够的地址空间容纳这些临时节点 IP 地址。

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

  • 可伸缩性：考虑所有系统和用户节点的节点数及其最大可伸缩性限制。 假设你想要横向扩展 400%。 对于所有这些横向扩展的节点，将需要四倍的地址数量。

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

  • 专用链接地址：考虑通过专用链接与其他 Azure 服务通信所需的地址。 此体系结构为连接容器注册表和密钥保管库分配了两个地址。

  • 保留 IP 地址：Azure 会保留某些地址供其使用。 这些地址不能分配。

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

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

Pod IP 地址空间

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

每个节点都会为其 Pod 分配一个 /24 地址空间，因此务必确保 Pod 地址空间足够大，以便允许任意数量的 /24 块，从而满足群集中节点数的需要。 请记住，包括升级或横向扩展操作期间创建的任何临时节点。 例如，如果将 /16 地址空间用于 CIDR 范围，则群集最多可以增长到大约 250 个节点。

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

有关详细信息，请参阅有关 Azure CNI 覆盖的 IP 地址规划指南

其他 IP 地址空间注意事项

有关此体系结构的完整网络注意事项，请参阅 AKS 基准网络拓扑。 有关为 AKS 群集规划 IP 寻址的信息，请参阅为群集规划 IP 寻址。

有关 AKS 基线参考体系结构上的 Windows 容器中包含的 IP 地址规划注意事项的详细信息，请参阅 AKS 上的 Windows 容器。

加载项和预览功能

Kubernetes 和 AKS 会不断发展，其发布周期比企业内部环境的软件更快。 此基线体系结构由特选 AKS 预览功能和 AKS 加载项决定。 以下是两者之间的区别：

  • AKS 团队将预览功能描述为已交付和正在改进，因为许多预览功能在进入一般可用性 (GA) 阶段之前，只会在这种状态下停留几个月。

  • AKS 加载项和扩展提供了受支持的额外功能。 AKS 负责管理它们的安装、配置和生命周期。

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

容器映像参考

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

  • 对群集进行身份验证以拉取映像。

  • 如果使用公共映像，将与服务级别目标 (SLO) 一致的公共映像导入容器注册表。 否则，映像可能会出现意外的可用性问题。 如果在需要时无法使用映像，就会造成运行问题。 以下是使用专用容器注册表（如 Azure 容器注册表）而不是公共注册表的一些好处：

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

  • 从授权的注册表中拉取映像。 可以通过 Azure Policy 强制实施此限制。 在此参考实现中，群集只从部署的容器注册表实例中拉取映像。

为基础群集配置计算

在 AKS 中，每个节点池都映射到一个虚拟机规模集。 节点是每个节点池中的 VM。 请考虑为系统节点池使用较小的 VM 大小以最大限度地降低成本。 此参考实现部署了具有三个 DS2_v2 节点的系统节点池。 该大小足以满足系统 Pod 的预期负载。 操作系统磁盘为 512 GB。

对于用户节点池，下面是一些注意事项：

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

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

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

  • 根据设计团队确定的要求，规划工作负荷的实际节点大小。 根据业务需求，此体系结构使用 DS4_v2 处理生产工作负荷。 为降低成本，可以将大小降至 DS3_v2，这是最低建议值。

  • 在规划群集容量时，假定每个节点的工作负荷消耗最高 80%。 其余的 20%留给 AKS 服务。

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

选择操作系统

大多数 AKS 群集使用 Linux 作为节点池的操作系统。 在此参考实现中，我们使用 Azure Linux，这是针对 Azure 进行过优化的轻型强化 Linux 分发版。 如果需要，或者满足 Azure Linux 无法满足的要求，可以选择使用另一个 Linux 分发版（如 Ubuntu）。

AKS 还支持运行 Windows Server 操作系统的节点池。 运行 Windows 的群集的某些方面有特殊要求。 若要了解有关 Windows 节点池体系结构的详细信息，请参阅在 AKS 上运行 Windows 容器。

如果工作负荷由各种技术组成，则可以在不同的节点池中使用不同的操作系统。 但是，如果工作负荷不需要不同的操作系统，我们建议对工作负荷的所有节点池使用单个操作系统。

为群集集成 Microsoft Entra ID

保护对群集的访问和来自群集的访问至关重要。 在做出安全选择时，请从群集的角度考虑：

  • 由内向外的访问。 考虑通过 AKS 访问 Azure 组件，如网络基础结构、容器注册表和密钥保管库。 只授权允许群集访问的资源。
  • 由外向内的访问。 提供对 Kubernetes 群集的标识访问。 仅授权允许访问 Kubernetes API 服务器和 Azure 资源管理器的外部实体。

AKS 对 Azure 的访问

通过 Microsoft Entra ID 管理 AKS 对 Azure 的访问有两种方法：服务主体或 Azure 资源的托管标识。

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

建议启用并使用托管标识，以便群集可以通过 Microsoft Entra ID 与外部 Azure 资源进行交互。 即使不立即使用 Microsoft Entra ID 集成，也可以稍后再使用。

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

当群集需要从容器注册表中拉取映像时，应该使用托管标识。 此操作需要群集获取注册表的凭据。 如果不使用托管身份，则可以按照 Kubernetes Secrets 对象的形式来存储该信息，并使用 imagePullSecrets 来检索机密。 由于安全方面的复杂性，我们不建议采用这种方法。 你不仅需要事先了解机密，还需要在 DevOps 管道中存储该机密。 我们不建议采用这种方法的另一个原因是，管理机密的轮换会增加运行开销。 而是向注册表授予 AcrPull 对群集的 kubelet 托管标识的访问权限。 这种方法解决了这些关注的问题。

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

  • “网络参与者”角色。 管理群集控制分支虚拟网络的能力。 通过此角色分配，AKS 群集系统分配的标识就可以与内部入口控制器服务的专用子网一起使用。

  • “监控指标发布者”角色。 管理群集将指标发送到 Azure Monitor 的能力。

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

群集访问

Microsoft Entra 集成还简化了由外向内访问的安全性。 例如，在以下情况下可能需要使用 kubectl。 第一步，运行 az aks get-credentials 命令来获取群集的凭据。 Microsoft Entra ID 会根据允许获取群集凭据的 Azure 角色对你的标识进行身份验证。 有关详细信息，请参阅可用群集角色权限。

AKS 支持通过两种方式使用 Microsoft Entra ID 来访问 Kubernetes。 第一种方法是使用 Microsoft Entra ID 作为标识提供程序，与本地 Kubernetes RBAC 系统集成。 另一种方法是使用本地 Azure RBAC 来控制群集访问。 下文将详细介绍这两种方法。

将 Kubernetes RBAC 与 Microsoft Entra ID 相关联

Kubernetes 通过以下方式支持 RBAC：

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

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

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

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

使用 Azure RBAC 进行 Kubernetes 授权

建议使用 Azure RBAC 和 Azure 角色分配，而不是使用 Kubernetes 本地 RBAC、ClusterRoleBindings 和 RoleBindings 进行集成 Microsoft Entra 身份验证的授权。 这种方法可对群集进行授权检查。 甚至可以在管理组、订阅或资源组范围内分配这些角色。 然后，该范围下的所有群集都会继承一套一致的角色分配，即谁有权访问 Kubernetes 群集上的对象。

有关详细信息，请参阅用于 Kubernetes 授权的 Azure RBAC。

本地帐户

AKS 支持原生 Kubernetes 用户身份验证。 不建议使用这种方法来为用户提供访问群集的权限。 这种方法以证书为基础，在主标识提供程序外部执行，这给集中式用户访问控制和治理带来了困难。 始终通过使用 Microsoft Entra ID 来管理对群集的访问，并将群集配置为显式禁用本地帐户访问。

在此参考实现中，系统部署群集时会显式禁用本地群集帐户访问。

为工作负荷集成 Microsoft Entra ID

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

在此参考实现中，AKS 上的 Microsoft Entra 工作负荷 ID 为 Pod 提供托管标识。 这种方法与 Kubernetes 本地功能集成，可与外部身份提供程序联合。 有关 Microsoft Entra Workload ID 联合的详细信息，请参阅工作负载标识联合。

选择网络模型

AKS 支持多种网络模型，包括 kubenet、CNI 和 Azure CNI 覆盖。 CNI 模型是更高级的模型，具有很高的性能。 在 Pod 之间通信时，CNI 的性能类似于虚拟网络中 VM 的性能。 CNI 还能使用 Azure 网络策略，从而增强安全控制。 建议使用基于 CNI 的网络模型。

在非覆盖 CNI 模型中，每个 Pod 从子网地址空间中获取一个 IP 地址。 同一网络中的资源（或对等互连资源）可以通过其 IP 地址直接访问 Pod。 网络地址转换 (NAT) 无需用于路由该流量。

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

有关模型的信息，请参阅选择要使用的容器网络接口网络模型和比较 kubenet 和 Azure 容器网络接口网络模型。

部署入口资源

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

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

    此体系结构使用 Azure 负载均衡器。 负载均衡器位于群集外部专用于入口资源的子网中。 它接收来自应用程序网关的流量，并且通过传输层安全 (TLS) 进行通信。 有关入站流量的 TLS 加密的详细信息，请参阅入口流量流。

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

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

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

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

  • 使用 nodeSelectors 将 Pod 限制为仅在用户节点池上计划。 此设置可隔离工作负荷和系统 Pod。

  • 打开让特定实体向入口控制器发送流量的端口和协议。 在此体系结构中，Traefik 只接收来自应用程序网关的流量。

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

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

注意

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

Traefik 是 Kubernetes 群集的开源选项，此体系结构中的 Traefik 仅用于说明。 它显示了非 Microsoft 产品与 Azure 服务的集成。 例如，该实现展示了如何将 Traefik 与 Microsoft Entra 工作负荷 ID 和密钥保管库集成。

还可以使用与 AKS 良好集成的应用程序网关入口控制器。 除了作为入口控制器的功能外，它还提供其他好处。 例如，应用程序网关充当群集的虚拟网络入口点。 它可以观察进入群集的流量。 如果应用程序需要 Web 应用程序防火墙，请使用应用程序网关。 此外，应用程序网关还允许执行 TLS 终止。

有关基线参考体系结构中 AKS 上 Windows 容器的入口设计的详细信息，请参阅 AKS 上的 Windows 容器。

路由器设置

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

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

Traefik 使用 Kubernetes 提供程序配置路由。 annotations、tls 和 entrypoints 选项表示路由通过 HTTPS 提供。 middlewares 选项指定只允许来自应用程序网关子网的流量。 如果客户端接受，则响应将使用 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 到 Pod 流量。 此流量包括入口控制器和工作负荷之间的通信。 如果工作负荷由部署到群集的多个应用程序组成，那么这些应用程序之间的通信也属于此类别。

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

显示群集流量流的示意图。

下载此体系结构的 Visio 文件。

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

入口流量流

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

示意图显示 TLS 终止。

下载此体系结构的 Visio 文件。

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

  2. 应用程序网关有一个集成的 Web 应用程序防火墙并为 bicycle.contoso.com 协商 TLS 握手，以只允许安全密码。 应用程序网关是 TLS 终止点，这一点很重要，因为应用程序网关的 Web 应用程序防火墙需要检查明文响应。 密钥保管库可存储 TLS 证书。 群集通过与应用程序网关集成的用户分配的托管标识进行访问。 有关详细信息，请参阅使用 Key Vault 证书实现 TLS 终止。

    应用程序网关处理 Web 应用程序防火墙检查规则，并运行路由规则以便将流量转发到配置的后端。

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

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

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

出口流量流

在此体系结构中，建议来自群集的所有出口流量都通过 Azure 防火墙进行通信。 也可以使用自己的类似网络虚拟设备。 不建议使用其他出口选项，如 Azure NAT 网关 或 HTTP 代理，因为它们不提供网络流量检查功能。 对于零信任控制和检查流量的能力，来自群集的所有出口流量都通过防火墙。 可以使用用户自定义路由 (UDR) 来实现这一配置。 路由的下一个跃点是 Azure 防火墙的专用 IP 地址。 Azure 防火墙决定是阻止还是允许出口流量。 这一决定基于 Azure 防火墙中定义的特定规则或内置威胁情报规则。

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

无论使用哪种方法，都要查看 AKS 所需的出口网络流量规则。

注意

如果使用公共负载均衡器作为公共点，使用 UDR 通过防火墙传输入口流量和出口流量，则可能会出现非对称路由情况。 此体系结构在应用程序网关后面的专用入口子网中使用内部负载均衡器。 这种设计选择不仅增强了安全性，而且消除了不对称路由问题。 也可以在应用程序网关之前或之后通过防火墙路由入口流量，但这种方法在大多数情况下并无必要，我们也不推荐使用。 有关非对称路由的详细信息，请参阅将防火墙与 Azure 标准负载均衡器集成。

零信任控制的一个例外是群集需要与其他 Azure 资源进行通信。 例如，群集可能需要从容器注册表中拉取更新的映像，或从密钥保管库中拉取机密。 在这些情况下，建议使用专用链接。 这样做的好处是，特定子网可以直接到达服务，而群集与服务之间的流量不需要通过 Internet。 而缺点再有，专用链接需要额外的配置，而不是通过其公共终结点使用目标服务。 此外，并非所有 Azure 服务或产品都支持专用链接。 对于这些情况，请考虑在子网上启用虚拟网络服务终结点来访问服务。

如果不能选择专用链接或服务终结点，可以通过其公共终结点访问其他服务，并通过 Azure 防火墙规则和目标服务中内置的防火墙控制访问。 由于这些流量会通过防火墙的静态 IP 地址，因此可以将这些地址添加到服务的 IP 允许列表中。 这样做的一个缺点是，Azure 防火墙需要更多规则来确保只允许来自特定子网的流量。 在使用 Azure 防火墙为出口流量规划多个 IP 地址时，请将这些地址考虑在内。 否则，可能会耗尽端口。 有关规划多个 IP 地址的详细信息，请参阅创建具有多个 IP 地址的 Azure 防火墙。

有关 AKS 基线参考体系结构中的 Windows 容器中特定于 Windows 的出口注意事项的信息，请参阅 AKS 上的 Windows 容器。

Pod 到 Pod 流量

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

在配置群集时启用网络策略，因为以后将无法添加。 对于实现 NetworkPolicy 的技术，有几种选择。 建议使用 Azure 网络策略，它需要 Azure 容器网络接口 (CNI)。 有关详细信息，请参阅以下说明。 其他选项包括 Calico 网络策略，这是一种广为人知的开源选项。 如果需要管理群集范围的网络策略，请考虑使用 Calico。 Calico 不在标准 Azure 支持范围内。

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

管理流量

作为群集运行的一部分，Kubernetes API 服务器会接收来自想要对群集进行管理操作的资源的流量，例如创建资源以扩展群集的请求。 这些资源的示例包括 DevOps 管道中的构建代理池、Azure Bastion 子网中的 Azure Bastion 实例以及节点池本身。 与其接受来自所有 IP 地址的管理流量，不如使用 AKS 授权 IP 范围功能，只允许来自授权 IP 范围的流量访问 API 服务器

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

为了实现另一层控制，可以配置一个专用 AKS 群集，但代价是额外的复杂性。 通过使用专用群集，可以帮助确保 API 服务器和节点池之间的网络流量仅保留在专用网络上，而绝不会公开到 Internet。 有关详细信息，请参阅 AKS 专用群集。

添加机密管理

将机密存储在托管密钥存储中，例如密钥保管库。 这样做的好处是，托管密钥存储库可以处理机密的轮换。 它提供强大的加密功能和访问审核日志。 它还能将核心机密保留在部署管道之外。 在此体系结构中，启用并配置了密钥保管库防火墙，并在从 Azure 中需要访问机密和证书的资源进行连接时使用专用链接。

密钥保管库与其他 Azure 服务很好地集成在一起。 使用这些服务的内置功能来访问机密。 有关 Azure 应用程序网关如何访问入口流的 TLS 证书的详细信息，请参阅入口流量流部分。

通过密钥保管库的 Azure RBAC 权限模型，可以将工作负载标识分配给密钥保管库机密用户或密钥保管库阅读器角色分配，并访问机密。 有关详细信息，请参阅通过使用 RBAC 来访问密钥保管库。

访问群集机密

需要使用工作负载标识来允许 Pod 访问来自特定存储的机密。 为了便于检索过程，请使用机密存储 CSI 驱动程序。 当 Pod 需要机密时，驱动程序会连接到指定的存储，检索卷上的机密，并在群集中装载该卷。 然后，Pod 可以从卷文件系统获取机密。

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

工作负荷存储

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

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

策略管理

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

要管理 AKS 群集，可以使用 Azure Policy：

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

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

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

  • 要审核还是拒绝该操作？ 在审核模式下，该操作是允许的，但会被标记为不合规。 具有定期检查不合规状态并采取必要措施的流程。 在拒绝模式下，该操作因违反策略而被阻止。 选择此模式时要小心，因为它可能会对工作负荷的运行造成过多限制。

  • 工作负荷中是否存在设计上不合规的领域？ Azure Policy 能够指定不受策略强制影响的 Kubernetes 命名空间。 建议仍在审核模式下应用策略，以便了解这些实例。

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

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

  • 是否将 Azure 策略分配给特定范围？ 确保还针对预生产环境验证生产策略。 否则，在部署到生产环境时，可能会遇到预生产时没有考虑到的意外额外限制。

此参考实现可在创建 AKS 群集时启用 Azure Policy。 在审核模式下分配限制性举措，以了解不合规情况。

该实现还设置了不属于任何内置计划的额外策略。 这些策略设置为拒绝模式。 例如，有一种策略可以确保只从已部署的容器注册表实例中拉取映像。 请考虑创建自己的自定义计划。 将适用于工作负荷的策略组合到一个分配中。

要观察 Azure Policy 在群集中的运行情况，可以访问 gatekeeper-system 命名空间中所有 Pod 的 Pod 日志，以及 kube-system 命名空间中 azure-policy 和 azure-policy-webhook Pod 的日志。

有关特定于 Windows 的 Azure Policy 注意事项的详细信息，请参阅 AKS 策略管理上的 Windows 容器一文。

节点和 Pod 可伸缩性

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

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

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

推荐使用自动缩放方法，因为其中一些手动机制已内置在自动缩放程序中。

作为一般方法，首先使用最少数量的 Pod 和节点进行性能测试。 使用这些值可以建立基准预期。 然后，使用性能指标和手动缩放的组合来查找瓶颈并了解应用程序对缩放的响应。 最后，利用此数据来设置参数以实现自动缩放。 有关使用 AKS 的性能优化方案的详细信息，请参阅性能优化方案：分布式业务事务。

水平 Pod 自动缩放程序

水平 Pod 自动缩放程序 (HPA) 是可缩放 Pod 数的 Kubernetes 资源。

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

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

可能存在竞争条件，在缩放操作完成之前 HPA 会检查该条件。 结果可能是比率计算错误。 有关详细信息，请参阅缩放事件的冷却。

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

群集自动缩放程序

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

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

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

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

有关此基线参考体系结构中包含的 Windows 特定缩放考虑因素的信息，请参阅 AKS 上的 Windows 容器一文。

业务连续性决策

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

群集节点

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

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

对群集进行定期维护（如及时更新）对提高可靠性至关重要。 此外，建议通过探测来监控 Pod 的运行状况。

Pod 可用性

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

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

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

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

注意

如果在群集级别设置资源配额，在部署没有适当请求和限制的第三方工作负荷时可能会出现问题。

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

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

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

可用性区域和多地区支持

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

  • 整个基础结构：选择支持可用性区域的区域。 有关详细信息，请参阅限制。 要获得正常运行时间 SLA，则需要选择标准层或高级层。 使用可用性区域时，正常运行时间 SLA 会更大。

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

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

  • 依赖资源：为获得完全的区域优势，所有服务依赖项还必须支持区域。 如果依赖服务不支持区域，则区域故障会导致该服务失败。

    例如，托管磁盘可在配置磁盘的区域内使用。 如果发生故障，节点可能会移动到另一个区域，但托管磁盘不会随节点移动到该区域。

为简化此体系结构，AKS 部署在单一区域，节点池跨越可用性区域 1、2 和 3。 基础结构的其他资源，如 Azure 防火墙和应用程序网关，也部署在同一区域，并支持多个区域。 为容器注册表启用异地复制。

多个区域

启用可用性区域后，万一整个区域发生故障，覆盖范围也不够大。 要获得更高的可用性，请在不同的地区运行多个 AKS 群集。

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

  • 如果 Azure 资源支持异地冗余，请提供冗余服务的辅助实例所在位置。 例如，通过启用容器注册表的异地复制功能，它可以自动将映像复制到选定的 Azure 区域。 即使主要区域发生故障，也能继续访问映像。

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

注意

AKS 基线多区域群集参考体系结构扩展了本文中的体系结构，以包括主动/主动和高可用配置中的多个区域。

将多区域体系结构的实现作为起点，并根据自己的需要进行配置。

灾难恢复

如果主要区域中发生故障，最好能在另一个区域快速创建一个新的实例。 以下是一些建议：

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

  • 使用可以有效复制的非状态工作负荷。 如果需要在群集中存储状态（不建议这样做），请确保经常在其他区域备份数据。

  • 作为 DevOps 管道的一部分整合恢复策略（如复制到另一个区域），以满足 SLO 的要求。

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

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

群集备份

对于许多体系结构而言，可以通过基于 Git 操作的群集启动来配置新群集并使其恢复运行状态，然后再部署应用程序。 但是，如果关键资源状态（如配置映射、作业和机密）无法在启动过程中捕获，则需要考虑恢复策略。 建议在 Kubernetes 中运行无状态工作负荷。 如果体系结构涉及基于磁盘的状态，则还必须考虑该内容的恢复策略。

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

VMware Velero 便是一个可直接安装和管理的常见 Kubernetes 备份解决方案。 或者，可以使用 AKS 备份扩展来提供托管的 Velero 实现。 AKS 备份扩展支持备份 Kubernetes 资源和永久性卷，其时间安排和备份范围将在 Azure 备份中表现为保管库配置。

参考实现没有实现备份，这需要额外的 Azure 资源来管理、监控、购买和保护。 这些资源可能包括 Azure 存储帐户、Azure 备份保管库和配置以及受信任访问功能。 相反，Git 操作与运行无状态工作负荷的意图相结合，才是恢复解决方案。

选择并验证符合业务目标（包括已定义的恢复点目标和恢复时间目标）的备份解决方案。 在团队 runbook 中定义恢复过程，并针对所有业务关键型工作负荷练习此恢复过程。

Kubernetes API 服务器 SLA

可以将 AKS 用作免费服务，但该层不提供财务支持的 SLA。 要获得 SLA，必须选择标准层。 建议所有生产群集都使用标准层。 将免费层保留给生产前群集，而高级层仅保留给关键任务工作负荷。 使用 Azure 可用性区域时，Kubernetes API 服务器 SLA 会更高。 节点池和其他资源都有自己的 SLA。 有关各项服务的具体 SLA 的详细信息，请参阅适用于联机服务的 SLA。

权衡

跨区域，尤其是跨地区部署体系结构需要权衡成本与可用性。 高级 SKU 中提供了一些复制功能，例如容器注册表中的异地复制，但价格更高。 对于多区域部署，成本也会增加，因为流量跨区域传输时需要支付带宽费用。

此外，预计区域或地区之间的节点通信会出现额外网络延迟。 衡量此体系结构决策对工作负荷的影响。

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

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

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

监控和收集指标

建议使用 Azure Monitor 容器见解来监控容器工作负荷的性能，因为可以实时查看事件。 它从正在运行的 Pod 捕获容器日志，并聚合它们以供查看。 它还从指标 API 收集有关内存和 CPU 使用率的信息，以监控正在运行的资源和工作负荷的运行状况。 还可以使用容器见解来监控 Pod 缩放时的性能。 它包括对所收集数据的监控、分析和可视化至关重要的遥测技术。 容器见解可识别趋势，并让你能够配置警报功能，以便主动接收有关关键问题的通知。

Pod 中托管的大多数工作负荷都会发出 Prometheus 指标。 容器见解可与 Prometheus 集成。 可以查看从节点和 Kubernetes 收集到的应用程序和工作负荷指标。

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

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

  • ClusterAutoscaler：通过日志记录获得缩放操作的可观测性。 有关详细信息，请参阅检索群集自动缩放程序日志和状态。
  • KubeControllerManager：获得 Kubernetes 和 Azure 控制平面之间交互的可观测性。
  • kube-audit-admin：获得对修改群集的活动的可观测性。 没有理由同时启用 kube-audit 和 kube-audit-admin。 kube-audit 是 kube-audit-admin 的超集，也包括非修改（读取）操作。
  • guard：捕获 Microsoft Entra ID 和 Azure RBAC 审核。

在早期群集或工作负荷生命周期开发过程中，启用其他日志类别（如 KubeScheduler 或 kube-audit）可能会有所帮助。 添加的群集自动缩放、Pod 放置和调度以及类似数据可帮助排除群集或工作负荷运行方面的故障。 但是，如果在故障排除需求结束后一直保持扩展的故障排除日志，则在 Azure Monitor 中引入和存储数据可能会产生不必要的成本。

虽然 Azure Monitor 包含一组现有的日志查询来助你入门，但你也可以它们为基础来帮助生成自己的查询。 随着库的增长，可以通过使用一个或多个查询包来保存和重复使用日志查询。 自定义查询库可提供更多有关 AKS 群集运行状况和性能的可观测性。 它支持实现 SLO。

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

有关 Windows 特定监控注意事项的详细信息，请参阅 AKS 上的 Windows 容器。

人际网络指标

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

对于对传输控制协议 (TCP) 或用户数据报协议 (UDP) 丢包、延迟或 DNS 压力高度敏感的工作负荷，Pod 级网络指标非常重要。 在 AKS 中，可以通过高级网络可观测性功能找到这种程度的详细信息。 大多数工作负荷并不需要这种深度的网络可观测性。 除非 Pod 需要高度优化的网络，其灵敏度可低至数据包级别，否则不应该安装高级网络可观测性插件。

启用自我修复

通过设置运行情况和就绪情况探测来监控 Pod 的运行状况。 如果 Kubernetes 检测到 Pod 无响应，它会重新启动 Pod。 运行情况探测确定 Pod 是否正常。 如果 Kubernetes 检测到 Pod 无响应，它会重新启动 Pod。 就绪情况探测确定 Pod 是否已准备好接收请求和流量。

注意

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

AKS 群集的例程更新

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

  • Kubernetes 版本（例如，Kubernetes 1.30.3 到 1.30.7 或 Kubernetes 1.30.7 到 1.31.1），此版本可能附带 Kubernetes API 更改和弃用。 此层的版本更改会影响整个群集。
  • 每个节点上的虚拟硬盘 (VHD) 映像，该映像会合并操作系统更新和 AKS 组件更新。 这些更新针对群集的 Kubernetes 版本进行过测试。 此层的版本更改在节点池级别应用，并且不会影响 Kubernetes 版本。
  • 操作系统自身的本地更新流程，如 Windows Update 或 apt。 操作系统供应商会直接提供这些更新，但不会针对群集的 Kubernetes 版本进行测试。 此层的版本更改会影响单个节点，但不会影响 Kubernetes 版本。

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

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

不可变的基础结构

将 AKS 群集作为不可变基础结构运行的工作负荷不会自动或手动更新其群集。 将节点映像升级设置为 none，并将群集自动升级设置为 none。 在此配置中，你全权负责所有层的所有升级。 当需要的更新可用时，必须在预生产环境中测试该更新，并评估其在新群集上的兼容性。 然后，部署包含更新的 AKS 版本和节点池 VHD 的生产副本戳。 当新的生产群集准备就绪时，旧群集将被耗尽并最终退役。

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

就地升级

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

  • 安排 AKS 的计划内维护功能，以便控制群集的升级。 此功能可在可控的时间内执行更新这一固有风险的操作，以减少意外故障的影响。
  • 配置 Pod 中断预算，以便应用程序在滚动升级期间保持稳定。 但是，不要将预算配置得过于严格，以免阻碍节点升级，因为大多数升级需要在每个节点上进行隔离和清空过程。
  • 确认 Azure 资源配额和资源可用性。 就地升级会在删除旧节点之前部署新的节点实例（称为激增节点）。 这意味着 Azure 配额和 IP 地址空间必须可用于新节点。 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 群集时避免使用群集自动升级功能。 使用手动方法，这样你就有时间在更新进入生产环境之前在预生产环境中测试新的 AKS 群集版本。 此方法还实现了最高程度的可预测性和控制。 但是，必须努力监控 Kubernetes 平台的新更新，并在新版本发布时快速采用新版本。 最好采用“保持最新”思维模式而不是长期支持方法。

警告

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

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

你最终可能会对 Kubernetes 版本、AKS 版本、群集、群集级别组件和工作负荷达到自信的程度，从而探索自动升级功能。 对于生产系统，超越 patch 的情况很少见。 此外，在自动升级 AKS 版本时，还要检查群集的基础结构即代码 (IaC) AKS 版本设置，以免它们不同步。配置计划内维护时段以支持自动升级操作。

安全监控

监控容器基础结构，了解主动威胁和潜在安全风险。 下面是一些资源：

群集和工作负荷操作

有关群集和工作负荷运营 (DevOps) 的注意事项，请参阅卓越运营设计原则支柱。

群集引导

执行预配后，就会拥有一个正常运行的群集，但在部署工作负荷之前，可能还需要一些必要的步骤。 准备群集的过程被称为引导。 引导可以包括在群集节点上部署必备映像、创建命名空间，以及执行其他满足企业用例要求的任务。

为了缩小已配置群集与正确配置群集之间的差距，群集操作员应考虑其独特的启动过程。 他们需要提前准备相关资产。 例如，如果在部署应用程序工作负荷之前，每个节点上都必须运行 Kured，那么群集操作员在配置群集之前，就应该验证包含目标 Kured 映像的容器注册表实例是否已经存在。

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

注意

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

使用适用于 AKS 的 GitOps Flux v2 群集扩展的主要优势之一是预配群集和引导群集之间实际上没有差距。 它为环境建立了一个不断发展的坚实的管理基础，还支持将该引导作为资源模板包含在内，以便与 IaC 策略保持一致。

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

隔离工作负荷责任

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

从包含基本组件的基本工作负荷开始，并以此为基础进行构建。 初始任务是配置网络。 为中心和分支提供虚拟网络，并在这些网络中提供子网。 例如，一个分支具有独立的子网，用于系统和用户节点池以及入口资源。 在中心内为 Azure 防火墙部署一个子网。

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

使用 IaC

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

确保根据治理策略预配资源。 例如，在选择 VM 大小时，应在成本限制和可用性区域选项的范围内进行选择，以满足应用程序的要求。 还可以使用 Azure Policy 针对这些决定执行组织的策略。

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

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

工作负荷 CI/CD

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

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

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

群集 CI/CD

示意图显示工作负荷 CI/CD。

下载此体系结构的 Visio 文件。

不要使用像 kubectl 这样的命令式方法，而是使用自动同步群集和存储库更改的工具。 要管理工作流程，例如发布新版本并在部署到生产前对该版本进行验证，可以考虑使用 GitOps 流。

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

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

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

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

以下示例展示如何使用 GitOps 和 Flux 自动执行群集配置：

示意图显示 GitOps 流。

下载此体系结构的 Visio 文件。

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

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

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

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

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

虽然可以手动配置 GitOps 和 Flux，但我们还是建议使用带有 Flux v2 群集扩展的 GitOps 来配置 AKS。

工作负荷和群集部署策略

将任何更改（体系结构组件、工作负荷、群集配置）部署到至少一个预生产 AKS 群集。 这样做可以模拟更改，并可能在部署到生产中之前发现问题。

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

蓝绿部署、A/B 测试和 Canary 发布等高级部署技术将需要额外的流程，并可能需要额外的工具。 Flagger 是一种常用的开源解决方案，可帮助解决高级部署场景。

成本管理

首先请查看 AKS 架构良好的框架中概述的成本优化设计清单和建议列表。 使用 Azure 定价计算器估算体系结构使用的服务的成本。 有关其他最佳做法，请参阅成本优化。

考虑使用 AKS 成本分析，以便通过 Kubernetes 特定构造进行精细群集基础结构成本分配。

有关 Windows 特定成本管理注意事项的信息，请参阅 AKS 上的 Windows 容器。

预配

  • 了解成本的来源。 AKS 在部署、管理和运营 Kubernetes 群集方面的成本极低。 影响成本的是群集消耗的虚拟机实例、存储、日志数据和网络资源。 考虑为系统节点池选择更便宜的 VM。 DS2_v2 系列是系统节点池的典型 VM 类型。

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

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

    对于将 Azure SQL 数据库或 Azure 应用程序服务作为 AKS 工作负荷体系结构一部分的非生产工作负荷，请评估你是否有资格使用 Azure 开发/测试订阅来获得服务折扣。

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

  • 设置 Pod 请求和限制，让 Kubernetes 以更高密度分配节点资源，从而充分利用硬件容量。

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

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

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

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

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

监视器

可以监控整个群集以及计算、存储、带宽、日志和防火墙的成本。 Azure 提供了监控和分析成本的选项：

理想情况下，要实时或至少定期监测成本。 这样，就可以在月底计算出成本之前采取行动。 此外，还要监控每月的长期趋势，以保持在预算范围内。

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

优化

根据 Azure 顾问提供的建议进行操作。 还可以通过其他方法进行优化：

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

    重要

    轻易更改群集自动缩放程序设置（如节点池的最小和最大节点设置）以影响成本，可能会适得其反。 例如，如果将 scale-down-unneeded-time 设置为 10 分钟，并且根据工作负荷特征每五分钟修改一次最小和最大节点设置，那么节点数量将永远不会减少。 这是因为群集自动分级器设置刷新后，每个节点的不需要时间计算会重置。

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

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

  • 如果工作负荷支持，请在不期望它们运行时将用户节点池扩展到 0 个节点。 此外，如果没有计划在群集中运行的工作负荷，请考虑使用 AKS 启动/停止功能关闭所有计算，其中包括系统节点池和 AKS 控制平面。

有关其他成本相关信息，请参阅 AKS 定价。

后续步骤