【Azure AKS】Azure Kubernetes服务（AKS）集群的基线架构

本文提供了一个推荐的基线基础架构，用于部署Azure Kubernetes Service（AKS）集群。它使用我们的设计原则，并基于Azure良好架构框架中的AKS架构最佳实践。本文有助于指导多个不同的跨学科小组，如网络、安全和身份团队，在部署这种通用基础设施时。

这种架构并不关注工作负载。它专注于AKS集群本身。此信息是大多数AKS集群的最低推荐基线。它与Azure服务集成，提供可观察性，提供支持多区域增长的网络拓扑，并确保集群内流量的安全。

您的业务需求会影响目标架构，并且在不同的应用程序上下文中可能会有所不同。将架构视为预生产和生产阶段的起点。

Kubernetes是一个强大的生态系统，它超越了Azure和微软技术。当您部署一个AKS集群时，您需要对如何设计和操作集群的许多决定负责。运行AKS集群需要混合使用来自各种供应商的闭源代码组件，包括微软；以及Kubernetes生态系统中的开源组件。环境经常变化，您可能需要定期重新审视决策。通过采用Kubernetes，您承认您的工作负载需要它的功能，并且工作负载团队准备持续投资。

您可以在GitHub上使用此架构的实现：AKS基线参考实现[GitHub: AKS baseline reference implementation】。将其用作替代起点，并根据您的需求配置参考架构。

注：

参考架构需要了解Kubernetes及其概念。如果你需要复习，请参阅Kubernetes简介，并在Kubernetes培训路径上开发和部署应用程序。

网络配置

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

集群计算

• 计算基础集群
• 容器图像参考
• 政策管理

身份管理

• 为集群集成Microsoft Entra ID
• 为工作负载集成Microsoft Entra ID

安全的数据流

• 保护网络流
• 添加秘密管理

业务连续性

• 可扩展性
• 集群和节点可用性
• 可用性和多区域支持

操作

• 集群和工作负载CI/CD管道
• 集群健康状况和指标
• 成本管理和报告

网络拓扑

该架构使用中心辐射式网络拓扑。在通过虚拟网络对等连接的单独虚拟网络中部署集线器和辐条。这种拓扑有几个优点。使用此拓扑可以：

• 启用隔离管理。您可以应用治理并遵守最小特权原则。它还支持具有职责分离的Azure着陆区的概念。
• 尽量减少Azure资源直接暴露于公共互联网。
• 提供区域中心辐射拓扑结构。您可以在未来扩展中心辐射网络拓扑，并提供工作负载隔离。
• 使用web应用程序防火墙服务来帮助检查所有web应用程序的HTTP流量。
• 为跨多个订阅的工作负载提供支持。
• 使架构可扩展。为了适应新的功能或工作负载，您可以添加新的辐条，而不是重新设计网络拓扑。
• 支持跨网络共享资源，如防火墙和域名系统（DNS）区域。
• 与Azure企业级着陆区对齐。

显示中心辐射网络拓扑的架构图。

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

有关更多信息，请参阅Azure中的中心辐射网络拓扑【Hub-spoke network topology in Azure.】。

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

集线器虚拟网络

集线器虚拟网络是连接和可观察性的中心点。在这种架构中，中心包含：

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

在网络中，该架构有三个子网。

承载Azure防火墙的子网

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

承载网关的子网

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

用于承载Azure Bastion的子网

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

辐条虚拟网络

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

承载Azure应用程序网关的子网

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

承载入口资源的子网

为了路由和分配流量，Traefik是实现Kubernetes入口资源的入口控制器。此子网中存在Azure内部负载平衡器。有关更多信息，请参阅将内部负载平衡器与AKS一起使用。

承载群集节点的子网

AKS维护两个节点池，它们是单独的节点组。系统节点池托管运行核心集群服务的Pod。用户节点池运行您的工作负载和入口控制器，以启用与工作负载的入站通信。

承载Azure专用链接终结点的子网

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

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

规划IP地址

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

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

此参考架构使用多种网络方法，每种方法都需要一个IP地址空间：

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

虚拟网络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 Overlay通过使用专用地址空间为Pod分配IP地址，该地址空间与您在虚拟网络中使用的地址空间分开。使用不与您的虚拟网络或任何对等虚拟网络重叠的IP地址空间。但是，如果您创建了多个AKS集群，则可以在每个集群上安全地使用相同的pod地址空间。

每个节点都为其pod分配了一个/24地址空间，因此确保pod地址空间足够大以允许集群中节点数量所需的/24块非常重要。记住要包括在升级或横向扩展操作期间创建的任何临时节点。例如，如果您为CIDR范围使用/16地址空间，则集群最多可以增长到约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策略强制执行此限制。在此参考实现中，集群仅从部署的容器注册表实例中提取映像。

为基础集群配置计算

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

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

• 选择较大的节点大小，以打包节点上设置的最大数量的Pod。大型节点最大限度地减少了在所有节点上运行的服务（如监控和日志记录）的占用空间。
• 如果您有特定的工作负载要求，请选择适当的VM类型。例如，您可能需要为某些工作负载提供内存优化产品，或为其他工作负载提供GPU加速产品。有关详细信息，请参阅Azure中虚拟机的大小。
• 至少部署两个节点。这样，工作负载具有两个副本的高可用性模式。使用AKS，您可以在不重新创建集群的情况下更改节点计数。
• 根据设计团队确定的要求，规划工作负载的实际节点大小。根据业务需求，该架构使用DS4_v2作为生产工作负载。为了降低成本，您可以将大小降至DS3_v2，这是最低建议。
• 假设在规划集群容量时，您的工作负载消耗了每个节点高达80%的容量。剩余的20%保留给AKS服务。
• 根据您的容量规划设置每个节点的最大Pod。如果你想建立一个容量基线，从30开始。根据工作负载、节点大小和IP约束的要求调整该值。

选择操作系统

大多数AKS集群使用Linux作为其节点池的操作系统。在这个参考实现中，我们使用Azure Linux，这是一个轻量级、强化的Linux发行版，已经针对Azure进行了调优。如果你愿意，或者如果你有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标识集成，也可以稍后将其合并。

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

当集群需要从容器注册表中提取映像时，您应该使用托管标识。此操作要求群集获取注册表的凭据。如果你不使用托管身份，那么你可能会以Kubernetes secret对象的形式存储该信息，并使用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、ClusterRoleBinding和RoleBinding进行集成Microsoft Entra身份验证的授权。这种方法强制对集群进行授权检查。您甚至可以在管理组、订阅或资源组范围内分配这些角色。然后，作用域下的所有集群都继承了一组一致的角色分配，这些分配与谁有权访问Kubernetes集群上的对象有关。

有关更多信息，请参阅Azure RBAC For Kubernetes授权。

本地帐户

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

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

为工作负载集成Microsoft Entra ID

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

在此参考实现中，AKS上的Microsoft Entra Workload ID为Pod提供了托管身份。这种方法与Kubernetes本地功能集成，以与外部身份提供者联合。有关Microsoft Entra工作负载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加密的更多信息，请参阅Ingress流量。

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

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

• 作为设计决策的一部分，将入口控制器限制在特定的操作范围内。例如，您可能只允许控制器与运行特定工作负载的Pod交互。
• 避免将副本放置在同一节点上，以分散负载，并在节点发生故障时帮助确保业务连续性。为此，请使用podAntiAffinity。
• 使用nodeSelectors将Pod限制为仅在用户节点池上调度。此设置隔离工作负载和系统Pod。
• 开放端口和协议，允许特定实体向入口控制器发送流量。在此架构中，Traefik仅接收来自应用网关的流量。
• 配置readinesProbe和livessProbe设置，以指定的时间间隔监视Pod的运行状况。入口控制器应发送指示吊舱健康状况的信号。

考虑限制入口控制器对特定资源的访问以及执行某些操作的能力。您可以通过Kubernetes RBAC权限实现该限制。例如，在这种架构中，Traefik通过使用Kubernetes ClusterRole对象中的规则被授予监视、获取和列出服务和端点的权限。

注：

根据您的要求、工作量、团队的技能组合和技术选项的可支持性选择合适的入口控制器。最重要的是，你的入口控制器必须满足你的SLO期望。

Traefik是Kubernetes集群的开源选项，在此架构中用于说明目的。它显示了非微软产品与Azure服务的集成。例如，该实现显示了如何将Traefik与Microsoft Entra工作负载ID和密钥库集成。

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

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

路由器设置

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

以下是该架构的一个示例：

Traefik使用Kubernetes提供程序来配置路由。注释、tls和入口点选项表明路由是通过HTTPS提供的。中间件选项指定只允许来自应用程序网关子网的流量。如果客户端接受，则响应将使用gzip编码。因为Traefik执行TLS终止，所以与后端服务的通信是通过HTTP进行的。

YAML

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是通过Application Gateway使用两个不同的TLS证书设置的，如下图所示。

显示TLS终止的图表。

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

• 客户端向域名bicycle.contoso.com发送HTTPS请求。该名称与应用程序网关的公共IP地址的DNS a记录相关联。此流量经过加密，以帮助确保客户端浏览器和网关之间的流量无法被检查或更改。
• Application Gateway具有集成的web应用程序防火墙，并为bicycle.contoso.com协商TLS握手，只允许使用安全密码。Application Gateway是一个TLS终止点，这一点很重要，因为Application Gateway的web应用程序防火墙需要检查明文响应。密钥库存储TLS证书。集群使用与Application Gateway集成的用户分配的托管身份访问它。有关更多信息，请参阅使用密钥保险库证书终止TLS。

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

• 当流量从Application Gateway移动到后端时，它会再次使用另一个TLS证书进行加密，该证书是*.aks-ingress.ntoso.com的通配符，因为它会被转发到内部负载均衡器。这种重新加密有助于确保不安全的流量不会流入群集子网。
• 入口控制器通过负载均衡器接收加密流量。控制器是*.aks-ingress.ntoso.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通过防火墙的入口流量和出口流量的公共点，您可能会看到不对称的路由情况。此架构在Application Gateway后面的专用入口子网中使用内部负载平衡器。这种设计选择不仅增强了安全性，还消除了不对称路由问题。或者，您可以在应用程序网关之前或之后通过防火墙路由入口流量，但这种方法在大多数情况下不是必需的，我们不建议使用。有关非对称路由的更多信息，请参阅将防火墙与Azure标准负载平衡器集成。

零信任控制的一个例外是当集群需要与其他Azure资源通信时。例如，集群可能需要从容器注册表中提取更新的映像或从密钥库中提取机密。在这些情况下，我们建议您使用Private Link。优点是特定的子网直接到达服务，集群和服务之间的流量不通过互联网。缺点是Private Link需要额外的配置，而不是在其公共端点上使用目标服务。此外，并非所有Azure服务或产品都支持Private Link。对于这些情况，考虑启用子网上的虚拟网络服务端点来访问服务。

如果不选择Private Link或服务端点，您可以通过其他服务的公共端点访问它们，并通过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服务器和节点池之间的网络流量仅保留在专用网络上，并且永远不会暴露在互联网上。有关更多信息，请参阅AKS私有集群。

添加秘密管理

将机密存储在托管密钥存储中，如密钥库。优点是托管密钥存储可以处理密钥的轮换。它提供了强大的加密和访问审计日志。它还将核心机密排除在部署管道之外。在此架构中，启用并配置了密钥保险库防火墙，当从Azure中需要访问机密和证书的资源进行连接时，使用专用链接。

Key Vault与其他Azure服务集成良好。使用这些服务的内置功能来访问机密。有关Application Gateway如何访问入口流的TLS证书的更多信息，请参阅入口流量部分。

密钥库的Azure RBAC权限模型使您能够将工作负载标识分配给密钥库密钥用户或密钥库读取器角色分配，并访问密钥。有关详细信息，请参阅使用RBAC访问密钥库。

访问群集机密

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

CSI驱动程序有许多提供商来支持各种托管商店。此实现使用密钥库和机密存储CSI驱动程序。该插件从密钥库检索TLS证书，并将驱动程序加载到运行入口控制器的pod中。此操作发生在pod创建期间，卷存储公钥和私钥。

工作负载存储

此架构中的工作负载是无状态的。如果需要存储状态，我们建议将其持久化到集群之外。工作负载状态的指导不在本文的范围内。

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

政策管理

管理AKS集群的一种有效方法是通过策略实施治理。Kubernetes通过开放策略代理（OPA）网关实现策略。对于AKS，通过Azure策略交付策略。每个策略都适用于其范围内的所有集群。OPA Gatekeeper处理集群中的策略执行，并记录所有策略检查。策略更改不会立即反映在您的集群中，因此预计会出现一些延迟。

要管理您的AKS集群，您可以使用Azure策略来：

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

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

• 您是要设置一组策略（也称为计划），还是选择单个策略？Azure策略提供了两个内置计划：基本计划和限制计划。每个倡议都是适用于AKS集群的内置策略的集合。我们建议您选择一个计划，并为集群和与集群交互的资源（如容器注册表、应用程序网关或密钥库）选择其他策略。根据组织的要求选择策略。
• 您想审核还是拒绝该操作？在审核模式下，允许该操作，但标记为不符合。制定流程，定期检查不合规状态并采取必要行动。在拒绝模式下，该操作被阻止，因为它违反了策略。选择此模式时要小心，因为它可能对工作负载的运行限制太大。
• 您的工作负载中是否有设计不符合要求的区域？Azure Policy能够指定不受策略执行约束的Kubernetes命名空间。我们建议您仍然在审核模式下应用策略，以便了解这些实例。
• 您是否有内置策略未涵盖的要求？您可以创建自定义Azure策略定义，以应用您的自定义OPA网守策略。不要将自定义策略直接应用于集群。有关详细信息，请参见创建和分配自定义策略定义。
• 您有组织范围的要求吗？如果是这样，请在管理组级别添加这些策略。即使您的组织有通用策略，您的集群也应该分配自己的特定于工作负载的策略。
• 您是否将Azure策略分配给特定范围？确保生产策略也针对您的预生产环境进行了验证。否则，在部署到生产环境时，您可能会遇到在预生产中没有考虑到的意外额外限制。

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

该实施还设置了不属于任何内置计划的额外政策。这些策略在拒绝模式下设置。例如，有一个策略可以确保只从部署的容器注册表实例中提取映像。考虑创建自己的自定义计划。将适用于您的工作负载的策略合并到一个任务中。

要从集群中观察Azure Policy的功能，您可以访问网守系统命名空间中所有pod的pod日志，以及kube-system命名空间中Azure Policy和Azure Policy webhook pod的日志。

有关Windows特定Azure策略注意事项的更多信息，请参阅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）是一种Kubernetes资源，用于缩放Pod的数量。

在HPA资源中，我们建议设置最小和最大副本计数。这些值限制了自动缩放的范围。

HPA可以根据CPU使用率、内存使用率和自定义指标进行扩展。仅提供开箱即用的CPU使用率。HorizontalPodAutoscaler定义指定了指标的目标值。例如，规范设置了目标CPU使用率。当pod运行时，HPA控制器使用Kubernetes Metrics 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请求和限制：设置请求和限制使Kubernetes能够有效地将CPU和内存资源分配给pod，并使您在节点上具有更高的容器密度。请求和限制还可以提高您的可靠性，同时由于更好的硬件使用而降低成本。

要估计工作负载的限制，请测试并建立基线。从请求和限制的相等值开始。然后，逐渐调整这些值，直到建立一个可能导致集群不稳定的阈值。

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

可用区和多区域支持

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

整个基础设施：选择一个支持可用性区域的区域。有关更多信息，请参阅限制。要获得正常运行时间SLA，您需要选择标准或高级级别。使用可用性区域时，正常运行时间SLA更大。

集群：您只能在创建节点池时设置可用区域。它们以后不能更改。所有区域都应支持节点大小，以便实现预期的分布。底层虚拟机规模集跨区域提供相同的硬件配置。

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

依赖资源：为了获得完全的区域利益，所有服务依赖关系也必须支持区域。如果依赖服务不支持区域，则区域故障可能会导致该服务失败。

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

为了简化此架构，AKS部署到单个区域，节点池跨越可用性区域一、二和三。基础架构的其他资源，如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 backup中的vault配置。

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

选择并验证一个符合您业务目标的备份解决方案，包括您定义的恢复点目标和恢复时间目标。在团队runbook中定义您的恢复过程，并针对所有关键业务工作负载进行实践。

Kubernetes API服务器SLA

您可以将AKS作为免费服务使用，但该层不提供财务支持的SLA。要获得SLA，您必须选择标准层。我们建议所有生产集群使用标准层。为预生产集群保留免费层，仅为关键任务工作负载保留高级层。当您使用Azure可用性区域时，Kubernetes API服务器SLA更高。您的节点池和其他资源受其自己的SLA保护。有关每种服务的特定SLA的更多信息，请参阅在线服务的SLA。

折衷

跨区域（尤其是区域）部署架构需要权衡成本与可用性。一些复制功能，如Container Registry中的地理复制，在高级SKU中可用，但价格更高。对于多区域部署，成本也会增加，因为当流量跨区域移动时会收取带宽费用。

此外，在区域或地区之间的节点通信中，预计会有额外的网络延迟。衡量此架构决策对工作负载的影响。

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

有关更多信息，请参见Chaos Studio。

监控和收集指标

我们建议使用Azure Monitor容器洞察来监控容器工作负载的性能，因为您可以实时查看事件。它从正在运行的Pod中捕获容器日志，并将其聚合以供查看。它还从度量API收集有关内存和CPU使用情况的信息，以监控运行资源和工作负载的运行状况。您还可以使用容器洞察来监控Pod扩展时的性能。它包括遥测技术，这对监测、分析和可视化收集的数据至关重要。容器洞察可以识别趋势，并使您能够配置警报以接收有关关键问题的主动通知。

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

一些非微软的解决方案与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指标获得。您还可以使用Network Observability插件在节点级别公开网络指标。大多数集群应该使用Network Observability插件来提供额外的网络故障排除功能，并在节点级别检测意外的网络使用或问题。

对于对传输控制协议（TCP）或用户数据报协议（UDP）丢包、延迟或DNS压力高度敏感的工作负载，吊舱级网络指标很重要。在AKS中，您可以通过高级网络观察性功能找到这种详细程度。大多数工作负载不需要这种深度的网络可观察性。除非你的Pod需要一个高度优化的网络，并且灵敏度低至数据包级别，否则你不应该安装Advanced Network Observability插件。

实现自我修复

通过设置活性和准备状态探针来监测吊舱的健康状况。如果Kubernetes检测到无响应的pod，它会重新启动pod。活性探针确定吊舱是否健康。如果Kubernetes检测到无响应的pod，它会重新启动pod。就绪探测确定吊舱是否已准备好接收请求和流量。

注：

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

AKS集群的例行更新

Kubernetes集群的第二天操作的一部分是执行例行的平台和操作系统更新。每个AKS集群上都有三层更新需要解决：

Kubernetes版本（例如，Kubernetes1.30.3至1.30.7或Kubernettes1.30.7至1.31.1），可能会随KubernetESneneneba API的更改和弃用而提供。此层的版本更改会影响整个集群。
每个节点上的虚拟硬盘（VHD）映像，它结合了操作系统更新和AKS组件更新。这些更新是针对集群的Kubernetes版本进行测试的。此层的版本更改在节点池级别应用，不会影响Kubernetes版本。
操作系统自己的本机更新过程，如Windows update或apt。操作系统供应商直接提供这些更新，并且不针对集群的Kubernetes版本进行测试。此层的版本更改会影响单个节点，但不会影响Kubernetes版本。
这些层中的每一层都是独立控制的。您可以决定如何处理工作负载集群的每一层。选择每个AKS集群、其节点池或其节点的更新频率（节奏）。此外，选择应用更新的日期或时间（您的维护窗口）。选择是否手动或自动安装更新。就像在集群上运行的工作负载需要安全的部署实践一样，对集群的更新也是如此。

有关修补和升级的全面观点，请参阅AKS第2天操作指南中的AKS修补和升级指南。使用以下信息作为与此架构相关的基线建议。

不可变的基础设施

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

具有定期部署新基础设施的不可变基础设施是生产集群不应该应用就地升级策略的唯一情况。所有其他集群都应该有就地升级策略。

就地升级

不将AKS集群作为不可变基础设施运行的工作负载应定期更新其正在运行的集群，以解决所有三个层的问题。根据工作负载的要求调整更新过程。使用以下建议作为设计日常更新过程的起点。

安排AKS的计划维护功能，以便您可以控制集群上的升级。此功能使您能够在受控时间执行更新，这是一项固有风险的操作，以减少意外故障的影响。
配置pod中断预算，以便您的应用程序在滚动升级期间保持稳定。但是，不要将预算配置得过于激进，以至于阻止节点升级，因为大多数升级都需要在每个节点上进行警戒和排水过程。
确认Azure资源配额和资源可用性。就地升级在删除旧节点之前部署新的节点实例，称为浪涌节点。这意味着Azure配额和IP地址空间必须可用于新节点。对于大多数工作负载来说，33%的激增值是一个很好的起点。
测试与工具的兼容性，例如您添加到集群中的服务网格或安全代理。并测试您的工作负载组件，如入口控制器、服务网格和工作负载Pod。在预生产环境中进行测试。
 

节点就地升级

使用NodeImage自动升级通道进行节点操作系统映像升级。此通道配置您的群集，以使用节点级更新更新每个节点上的VHD。Microsoft根据您的AKS版本测试更新。对于Windows节点，更新大约每月发生一次。对于Linux节点，这些更新大约每周发生一次。

升级永远不会改变您的AKS或Kubernetes版本，因此Kubernetesneneneba API兼容性不是问题。
当您使用NodeImage作为升级通道时，它会遵守您计划的维护窗口，您应该每周至少设置一次。无论您使用什么节点映像操作系统，都可以设置它，以帮助确保及时应用。
这些更新包括操作系统级安全性、兼容性和功能更新、操作系统配置设置和AKS组件更新。
图像发布及其包含的组件版本号通过使用AKS发布跟踪器进行跟踪。
如果集群的安全要求要求更积极的补丁节奏，并且集群可以容忍潜在的中断，请使用SecurityPatch升级通道。微软也测试了这些更新。只有当Microsoft认为安全升级足够重要，需要在下一次计划的节点映像升级之前发布时，才会发布更新。当您使用SecurityPatch通道时，您还可以获得NodeImage通道接收到的更新。SecurityPatch通道选项仍然尊重您的维护窗口，因此请确保您的维护时段有更频繁的间隔（例如每天或每隔一天）来支持这些意外的安全更新。

大多数进行就地升级的集群应避免使用“无”和“未管理”节点映像升级通道选项。

集群的就地更新

Kubernetes是一个快速发展的平台，定期更新带来了重要的安全修复和新功能。保持Kubernetes更新的最新状态很重要。您应该保持在两个最新版本或N-2内。升级到Kubernetes的最新版本至关重要，因为新版本经常发布。

大多数集群都应该能够以足够的谨慎和严谨的方式执行就地的AKS版本更新。通过充分的预生产测试、配额验证和吊舱中断预算配置，可以最大限度地降低执行就地AKS版本升级的风险。但任何就地升级都可能导致意外行为。如果认为就地升级对您的工作负载来说风险太大，我们建议您使用蓝绿色部署AKS集群的方法，而不是遵循其余的建议。

我们建议您在首次部署Kubernetes集群时避免使用集群自动升级功能。使用手动方法，在更新进入生产环境之前，您有时间在预生产环境中测试新的AKS集群版本。这种方法还实现了最大程度的可预测性和控制性。但是，您必须认真监控Kubernetes平台的新更新，并在发布时迅速采用新版本。最好采取“保持现状”的心态，而不是长期的支持方法。

警告

我们不建议自动修补或更新生产AKS集群，即使是小版本更新，除非您首先在较低的环境中测试这些更新。有关更多信息，请参阅定期更新到最新版本的Kubernetes和升级AKS集群。

当您的群集有新的AKS版本可用时，您可以使用Azure事件网格的AKS系统主题接收通知。参考实现部署了此事件网格系统主题，以便您可以订阅Microsoft。集装箱服务。NewKubernetesVersionAvailable事件来自您的事件流通知解决方案。查看AKS发行说明，了解具体的兼容性问题、行为更改或功能弃用。

您最终可能会对Kubernetes版本、AKS版本、集群、集群级组件和工作负载充满信心，以探索自动升级功能。对于生产系统来说，很少能超越补丁。此外，在自动升级AKS版本时，还要检查集群的基础架构即代码（IaC）的AKS版本设置，以免它们不同步。配置您的计划维护窗口以支持自动升级操作。

安全监控

监控您的容器基础架构，查看是否存在活动威胁和潜在安全风险。以下是一些资源：

• Microsoft Defender for Containers用于识别和修复Defender for Cloud对容器映像的建议。
• Defender for Containers会定期扫描您的容器映像以查找漏洞。
• Defender for Containers还为可疑活动生成实时安全警报。
• AKS应用程序和集群的安全概念详细介绍了容器安全如何保护从构建到在AKS中运行的应用程序工作负载的整个端到端管道。
   

集群和工作负载操作

有关集群和工作负载操作（DevOps）的考虑因素，请参阅卓越运营设计原则支柱。

集群引导

在您完成配置后，您有一个工作集群，但在部署工作负载之前，您可能还有一些必要的步骤。准备集群的过程称为引导。引导可以包括将必备映像部署到集群节点上，创建命名空间，以及执行满足组织用例要求的其他任务。

为了减少配置好的集群和正确配置的集群之间的差距，集群运营商应该考虑他们独特的引导过程是什么样子的。他们需要提前准备相关资产。例如，如果在部署应用程序工作负载之前在每个节点上运行Kured很重要，则集群操作员应在配置集群之前验证包含目标Kured映像的容器注册表实例是否已经存在。

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

• GitOps Flux v2 cluster extension
• Pipelines
• Self-configuration with Flux or Argo CD, for example

注：

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

将GitOps Flux v2集群扩展用于AKS的主要优点之一是，配置集群和引导集群之间实际上没有间隙。它为未来的环境奠定了坚实的管理基础，还支持将引导作为资源模板，以与您的IaC战略保持一致。

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

隔离工作量责任

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

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

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

使用IaC

在可能的情况下，选择幂等声明性方法而不是命令式方法。与其编写一系列指定配置选项的命令，不如使用描述资源及其属性的声明性语法。您可以使用二头肌、Azure资源管理器模板（ARM模板）或地形。

确保按照管理政策提供资源。例如，当您选择VM大小时，请保持在成本限制和可用区域选项范围内，以满足您的应用程序的要求。您还可以使用Azure策略来强制执行组织针对这些决策的策略。

如果需要编写一系列命令，请使用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文件。

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

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

Flux识别配置中的更改，并使用kubectl命令应用这些更改。

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

您可以在Git服务器上设置分支策略，以便在将更改应用于生产之前，多个开发人员可以通过拉取请求批准更改。

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

工作量和集群部署策略

将任何更改（如架构组件、工作负载和集群配置）部署到至少一个预生产的AKS集群。这样做可以模拟更改，并可能在将问题部署到生产环境之前发现问题。

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

高级部署技术，如蓝绿色部署、A/B测试和金丝雀发布，需要额外的流程和潜在的额外工具。Flagger是一种流行的开源解决方案，可帮助解决高级部署场景。

成本管理

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

考虑使用AKS成本分析，通过Kubernetes特定的构造进行粒度集群基础设施成本分配。

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

供应

• 
  了解你的成本来自哪里。在Kubernetes集群本身的部署、管理和操作中，与AKS相关的成本很低。影响成本的是集群消耗的VM实例、存储、日志数据和网络资源。考虑为系统节点池选择更便宜的虚拟机。DS2_v2系列是系统节点池的典型VM类型。
• 不要对开发/测试和生产环境进行相同的配置。生产工作负载对高可用性有额外的要求，通常更昂贵。在开发/测试环境中不需要此配置。
• 为生产工作负载添加正常运行时间SLA。但是，为不需要保证可用性的开发/测试或实验工作负载设计的集群可以节省成本。例如，SLO就足够了。此外，如果您的工作负载支持它，请考虑使用运行点虚拟机的专用点节点池。
• 对于包含Azure SQL数据库或Azure App Service作为AKS工作负载架构一部分的非生产工作负载，请评估您是否有资格使用Azure Dev/Test订阅来获得服务折扣。
• 为集群提供最少数量的节点，并启用集群自动缩放器来监控和做出规模决策，而不是从超大集群开始以满足扩展需求。
• 设置pod请求和限制，让Kubernetes以更高的密度分配节点资源，以便您使用硬件来满足容量需求。
• 考虑到当您在集群上启用诊断时，可能会增加成本。
• 如果您的工作负载必须长期存在，请承诺使用一年或三年的Azure保留虚拟机实例来降低节点成本。有关更多信息，请参阅使用Azure保留虚拟机实例节省成本。
• 创建节点池时使用标记。当您创建自定义报告以跟踪已发生的成本时，标签会有所帮助。您可以使用标签来跟踪总费用，并将任何成本映射到特定的资源或团队。此外，如果集群在团队之间共享，则为每个消费者构建计费报告，以确定共享云服务的计量成本。有关详细信息，请参见为节点池指定污点、标签或标记。
• 如果您的工作负载是多区域的，并且您在区域之间复制数据，则预计会产生额外的带宽成本。有关更多信息，请参阅带宽定价。
• 创建预算，以保持在组织确定的成本限制范围内。您可以通过Microsoft成本管理创建预算。您还可以创建警报，以便在超过某些阈值时收到通知。有关更多信息，请参见使用模板创建预算。

监视器

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

• Azure顾问
• 微软成本管理

理想情况下，实时或至少定期监控您的成本。然后，您可以在成本计算完毕的月底之前采取行动。此外，监控每月的趋势，以保持在预算范围内。

要做出数据驱动的决策，请在粒度级别上确定哪种资源的成本最高。此外，要很好地了解计算资源使用情况的仪表。例如，通过分析指标，您可以确定平台是否过大。您可以在Azure Monitor指标中看到使用量表。

优化

根据Azure Advisor提供的建议采取行动。还有其他优化方法：

• 启用群集自动缩放器以检测并删除节点池中未充分使用的节点。

重要事项

积极更改集群自动缩放器设置，如节点池的最小和最大节点设置，以影响成本，可能会产生适得其反的结果。例如，如果将不需要的时间按比例缩小设置为10分钟，并且根据工作负载特性每五分钟修改一次最小和最大节点设置，则节点数量将永远不会减少。这是因为由于集群自动缩放器设置被刷新，每个节点的不必要时间的计算都会重置。

• 如果您的工作负载支持，请为节点池选择较低的SKU。
• 如果应用程序不需要突发扩展，请考虑通过分析随时间变化的性能指标将集群调整到合适的大小。
• 如果您的工作负载支持它，请在不期望用户节点池运行时将其扩展到0个节点。此外，如果您的集群中没有计划运行的工作负载，请考虑使用AKS启动/停止功能关闭所有计算，包括您的系统节点池和AKS控制平面。

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

• Advanced AKS microservices architecture
• AKS baseline for multiregion clusters
• AKS regulated cluster for PCI-DSS 3.2.1
• Windows containers on AKS baseline reference architecture

• AKS roadmap on GitHub
• Intro to Kubernetes
• Develop and deploy applications on Kubernetes
• Well-Architected Framework review for AKS
• AKS landing zone accelerator
• AKS day-2 operations guide
• Microservices architecture on AKS
• Use Azure Firewall to help protect an AKS cluster
• Git operations for AKS
• Data streaming with AKS