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

此参考体系结构提供一个推荐的基线基础体系结构，用于在 Azure 上部署 Azure Kubernetes 服务 (AKS) 群集。 它采用我们的设计原则，并基于 Azure 良好架构的框架中的体系结构最佳做法，通过部署此常规用途基础结构向跨学科团队或多个不同的团队（例如网络、安全性和标识）提供指导。

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

目标体系结构受业务要求的影响，因此，它在不同的应用程序上下文中可能有所不同。 它应被视为预生产阶段和生产阶段的起点。

有关此体系结构的实现，还可以查看 GitHub：Azure Kubernetes 服务 (AKS) 基线参考实现。 可以使用它作为替代起点，并根据需要进行配置。

网络配置

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

群集计算

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

身份管理

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

保护数据流

保护网络流
添加机密管理

业务连续性

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

Operations

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

网络拓扑

此体系结构使用中心辐射型网络拓扑。 中心和分支部署在通过对等互连连接的单独虚拟网络中。 此拓扑的一些优点包括：

• 分开管理。 实现一种方法来应用治理，并遵循最小特权原则。 它还支持职责分离的 Azure 登陆区域概念。

• 最大限度地减少 Azure 资源直接暴露于公共 Internet。

• 组织通常运营区域中心辐射型拓扑。 中心辐射型网络拓扑以后可以扩展，并提供工作负载隔离。

• 所有 Web 应用程序都应该需要 Web 应用程序防火墙 (WAF) 服务来帮助管理 HTTP 流量流。

• 跨多个订阅自然选择工作负载。

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

• 某些资源（例如防火墙和 DNS）可以跨网络共享。

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

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

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

要查看 AKS 上的 Windows 容器基线参考体系结构中包含的网络设计更改，请参阅配套文章。

集线器

中心虚拟网络是连接性和可观察性的中心点。 中心始终包含一个 Azure 防火墙，它具有中心 IT 团队定义的全局防火墙策略来强制实施组织范围的防火墙策略、Azure Bastion、网关子网（用于实现 VPN 连接）和 Azure Monitor（用于实现网络可观测性）。

在网络中，部署了三个子网。

用于托管 Azure 防火墙的子网

Azure 防火墙是一种防火墙即服务。 防火墙实例保护出站网络流量。 如果没有此安全层，此流量可能会与恶意第三方服务通信，因此可能泄露敏感的公司数据。 通过 Azure 防火墙管理器，可集中部署和配置多个 Azure 防火墙实例，并管理“中心虚拟网络”这一网络体系结构类型的 Azure 防火墙策略。

用于托管网关的子网

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

用于托管 Azure Bastion 的子网

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

分支

分支虚拟网络包含 AKS 群集和其他相关资源。 辐射网络有四个子网：

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

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

用于托管入口资源的子网

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

用于托管群集节点的子网

AKS 维护两组单独的节点（或节点池）。 系统节点池托管运行核心群集服务的 Pod。 用户节点池会运行你的工作负载和入口控制器，来实现与工作负载的入站通信。

用于托管专用链接终结点的子网

Azure 专用链接连接是为 Azure 容器注册表和 Azure Key Vault 创建的，因此可使用分支虚拟网络中的专用终结点访问这些服务。 专用终结点不需要专用子网，它们也可放置在中心虚拟网络中。 在基准实现中，它们部署到辐射虚拟网络中的专用子网。 这种方法减少了通过对等互连网络连接的流量，将属于群集的资源保留在同一虚拟网络中，并使你能够使用网络安全组在子网级别应用精细的安全规则。

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

规划 IP 地址

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

虚拟网络的地址空间应该足够大以容纳所有子网。 请考虑将接收流量的所有实体。 这些实体的 IP 地址将从子网地址空间分配。 请考虑以下几点。

• 升级

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

  对于 Pod，可能需要其他地址，具体取决于策略。 对于滚动更新，需要在更新实际 Pod 时提供运行工作负载的临时 Pod 的地址。 如果使用替换策略，则会删除 Pod，并创建新的 Pod。 因此，会重复使用与旧 Pod 关联的地址。

• 可伸缩性

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

  在此体系结构中，可以直接联系每个 Pod。 因此，每个 Pod 都需要一个单独的地址。 Pod 可伸缩性会影响地址计算。 该决定将取决于你对要增长的 Pod 数量的选择。

• Azure 专用链接地址

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

• 某些 IP 地址预留供 Azure 使用。 这些地址不能分配。

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

此体系结构专为单个工作负载设计。 对于多个工作负载，你可能希望将用户节点池彼此隔离，并与系统节点池隔离。 这种选择会导致更多规模更小的子网。 此外，入口资源可能更为复杂，因此，可能需要多个需要额外 IP 地址的入口控制器。

有关此体系结构的完整注意事项，请参阅 AKS 基准网络拓扑。

有关为 AKS 群集规划 IP 的信息，请参阅为群集规划 IP 寻址。

要查看 AKS 上的 Windows 容器基线参考体系结构中包含的 IP 地址规划注意事项，请参阅配套文章。

加载项和预览功能

Kubernetes 和 AKS 是不断发展的产品，发布周期比本地环境的软件要快。 此基线体系结构由特选 AKS 预览功能和 AKS 加载项决定。 两者之间的差异如下：

• AKS 团队将预览功能描述为“已交付且正在改进”。 其背后的原因是，许多预览功能仅停留在此状态几个月，然后就会移到正式发布 (GA) 阶段。
• AKS 加载项和扩展提供了其他受支持的功能。 加载项的安装、配置和生命周期由 AKS 进行管理。

此基线体系结构并未包含每个预览功能和加载项，而是只包括为常规用途群集增添重要价值的预览功能和加载项。 由于这些功能来自于预览版，因此将相应地修改此基线体系结构。 你可能希望在预生产群集中评估其他一些预览功能或 AKS 加载项，这些群集可增强安全性、可管理性或其他要求。 使用第三方加载项时，需要安装和维护它们，包括跟踪可用版本并在升级群集的 Kubernetes 版本后安装更新。

容器映像参考

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

• 群集经过身份验证才能拉取映像。

• 如果使用的是公共映像，请考虑将其导入与 SLO 一致的容器注册表。 否则，映像可能会遇到意外的可用性问题。 如果映像在需要时不可用，这些问题可能会导致操作问题。 使用容器注册表而不是公共注册表有以下好处：

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

  一个选项是 Azure 容器注册表 (ACR)。

• 从授权的注册表中拉取映像。 可以通过 Azure Policy 强制实施此限制。 在此参考实现中，群集仅从作为体系结构一部分部署的 ACR 中拉取映像。

为基础群集配置计算

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

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

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

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

• 工作负载的实际节点大小取决于设计团队确定的要求。 根据业务需求，我们已为生产工作负载选择DS4_v2。 为了降低成本，可以将大小降低到 DS3_v2，这是最低建议。

• 为群集规划容量时，假设工作负载最多可以消耗每个节点的 80%；剩余的 20% 保留供 AKS 服务使用。

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

为群集集成 Microsoft Entra ID

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

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

AKS 对 Azure 的访问

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

在这两种方法中，推荐使用托管标识。 使用服务主体时，你负责手动或以编程方式管理和轮换机密。 使用托管标识时，Microsoft Entra ID 会为你管理和执行身份验证并及时轮换机密。

建议启用托管标识，以便群集可通过 Microsoft Entra ID 与外部 Azure 资源进行交互。 只能在创建群集期间启用此设置。 即使未立即使用 Microsoft Entra ID，也可以稍后将其合并。

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

例如，对于由内向外的情况，我们来研究当群集需要从容器注册表拉取映像时托管标识的使用。 此操作需要群集获取注册表的凭据。 一种方法是以 Kubernetes 机密对象的形式存储该信息并使用 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 托管标识的形式对自身进行身份验证。

在此参考实现中，Pod 的托管标识通过 AKS 上的 Microsoft Entra 工作负载 ID 提供。 这与 Kubernetes 本机功能集成，以便与外部标识提供者联合。 有关 Microsoft Entra 工作负载 ID 联合身份验证的详细信息，请参阅以下概述。

部署入口资源

Kubernetes 入口资源路由传入流量并将其分发到群集。 入口资源有两部分：

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

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

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

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

• 作为设计决策的一部分，请选择允许入口控制器运行的范围。 例如，可以允许控制器仅与运行特定工作负载的 Pod 进行交互。

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

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

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

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

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

要查看 AKS 上的 Windows 容器基线参考体系结构中使用的入口设计，请参阅配套文章。

路由器设置

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

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

Traefik 使用 Kubernetes 提供程序配置路由。 annotations、tls 和 entrypoints 指示将通过 HTTPS 提供路由。 middlewares 指定只允许来自 Azure 应用程序网关子网的流量。 如果客户端接受，响应将使用 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 证书在应用程序网关设置，如此图所示。

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

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

2. 应用程序网关有一个集成的 Web 应用程序防火墙 (WAF) 并为 bike.contoso.com 协商 TLS 握手，以只允许安全密码。 应用程序网关是 TLS 终止点，因为需要它才能处理 WAF 检查规则，并执行将流量转发到所配置后端的路由规则。 TLS 证书存储在 Azure 密钥保管库中。 它使用与应用程序网关集成的用户分配托管标识进行访问。 有关该功能的信息，请参阅使用密钥保管库证书实现 TLS 终止。

3. 如果流量从应用程序网关移动到后端，则它在转发到内部负载均衡器时使用另一个 TLS 证书（*.aks-ingress.contoso.com 的通配符）再次加密。 这种重新加密可确保不安全的流量不会流入群集子网。

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

可以在到达工作负载 Pod 的每一跳中实现端到端 TLS 流量。 在决定保护 Pod 到 Pod 流量时，请务必衡量性能、延迟和操作影响。 对于大多数单租户群集，具有适当的控制平面 RBAC 和成熟的软件开发生命周期做法，TLS 加密到入口控制器并使用 Web 应用程序防火墙 (WAF) 进行保护就足够了。 这将最大限度地减少工作负载管理和网络性能影响的开销。 工作负载和合规性要求将决定执行 TLS 终止的位置。

出口流量流

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

可利用 AKS 的 HTTP 代理功能，而不是使用 Azure 防火墙。 来自群集的所有出口流量首先设置为 HTTP 代理的 IP 地址，由该地址决定转发流量还是将其丢弃。

使用任一方法查看 AKS 所需的出口网络规则。

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

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

要查看 AKS 上的 Windows 容器基线参考体系结构中使用的特定于 Windows 的出口注意事项，请参阅配套文章。

Pod 到 Pod 流量

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

请在预配群集时启用网络策略，因为以后无法添加。 实现 NetworkPolicy 的技术有几种。 建议使用 Azure 网络策略，它需要 Azure 容器网络接口 (CNI)，请参阅下面的注释。 其他选项包括 Calico 网络策略，这是一种著名的开源选项。 如果需要管理群集范围的网络策略，请考虑使用 Calico。 Calico 不在标准 Azure 支持范围内。

有关详细信息，请参阅 Azure 网络策略与 Calico 策略之间的差异及其功能。

管理流量

作为运行群集的一部分，Kubernetes API 服务器将从要对群集执行管理操作的资源接收流量，例如创建资源或缩放群集的请求。 这些资源的示例包括 DevOps 管道中的构建代理池、Bastion 子网和节点池本身。 不要接受来自所有 IP 地址的此管理流量，而是使用 AKS 的授权 IP 范围功能仅允许来自授权 IP 范围的流量流到 API 服务器。

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

可预配专用 AKS 群集来获得额外的控制层，代价是增加了复杂性。 通过使用专用群集，可确保 API 服务器与节点池之间的网络流量仅保留在专用网络上，而不公开到 Internet。 有关详细信息，请参阅 AKS 专用群集。

添加机密管理

将机密存储在托管密钥存储中，例如 Azure 密钥保管库。 优点是托管存储处理机密轮换、提供强加密、提供访问审核日志，并将核心机密排除在部署管道之外。 在此体系结构中，已启用 Azure Key Vault 防火墙，并配置了专用链接连接来连接到 Azure 中需要访问机密和证书的资源。

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

借助 Key Vault 的 Azure RBAC 权限模型，可将工作负载标识分配给 Key Vault 机密用户或 Key Vault 读取者角色分配，并访问机密。 有关详细信息，请参阅使用 RBAC 访问 Azure Key Vault。

访问群集机密

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

CSI 驱动程序有许多提供程序来支持各种托管存储。 在此实现中，我们使用加载项选择了带机密存储 CSI 驱动程序的 Azure Key Vault 来从 Azure Key Vault 检索 TLS 证书，并将其加载到运行入口控制器的 Pod 中。 它在 Pod 创建期间完成，并且卷存储公钥和私钥。

工作负载存储

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

若要了解有关存储选项的详细信息，请参阅 Azure Kubernetes 服务 (AKS) 中应用程序的存储选项。

策略管理

管理 AKS 群集的一种有效方法是通过策略强制执行治理。 Kubernetes 通过 OPA Gatekeeper 实现策略。 对于 AKS，策略通过 Azure Policy 交付。 每个策略都应用于其范围内的所有群集。 Azure Policy 强制最终由群集中的 OPA Gatekeeper 处理，并记录所有策略检查。 策略更改不会立即反映在群集中，预期会出现一些延迟。

Azure Policy 提供了两种不同的方案来管理 AKS 群集：

• 通过评估组织标准来阻止或限制资源组或订阅中的 AKS 群集部署。 例如，遵循命名约定、指定标记等。
• 通过 Azure Policy for Kubernetes 保护 AKS 群集。

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

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

• 要审核还是拒绝该操作？ 在“审核”模式下，该操作是允许的，但它被标记为“不合规”。 具有定期检查不合规状态并采取必要措施的流程。 在“拒绝”模式下，该操作因违反策略而被阻止。 选择此模式时要小心，因为它可能过于严格，导致工作负载无法正常工作。

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

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

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

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

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

该实现还设置了不属于任何内置计划的其他策略。 这些策略设置为“拒绝”模式。 例如，有一个策略可确保仅从已部署的 ACR 中拉取映像。 请考虑创建自己的自定义计划。 将适用于工作负载的策略组合到一个分配中。

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

要查看 AKS 上的 Windows 容器基线参考体系结构中包含的特定于 Windows 的 Azure Policy 注意事项，请参阅配套文章。

节点和 Pod 可伸缩性

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

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

手动或编程方式需要监视和设置有关 CPU 利用率或自定义指标的警报。 对于 Pod 缩放，应用程序操作员可以通过 Kubernetes API 调整 ReplicaSet 来增加或减少 Pod 副本的数量。 对于群集缩放，一种方法是在 Kubernetes 计划程序失败时收到通知。 另一种方法是随着时间的推移观察待处理的 Pod。 可以通过 Azure CLI 或门户调整节点数。

自动缩放是推荐的方法，因为一些手动机制已内置于自动缩放程序中。

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

水平 Pod 自动缩放程序

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

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

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

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

如果工作负载是事件驱动型的，则常用的开源选项是 KEDA。 如果工作负载由事件源（例如消息队列）驱动，而不受 CPU 或内存限制，请考虑使用 KEDA。 KEDA 支持许多事件源（或缩放程序）。 可以在此处找到支持的 KEDA 缩放程序列表，包括 Azure Monitor 缩放程序；通过它，可以基于 Azure Monitor 指标便捷地扩展 KEDA 工作负载。

群集自动缩放程序

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

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

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

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

要查看 AKS 上的 Windows 容器基线参考体系结构中包含的缩放注意事项，请参阅配套文章。

业务连续性决策

若要保持业务连续性，请为基础结构和应用程序定义服务级别协议。 有关每月正常运行时间计算的信息，请参阅 Azure Kubernetes 服务 (AKS) 的 SLA。

群集节点

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

通过将应用程序放置在称为用户节点池的单独节点池中，将应用程序与系统服务隔离。 这样，Kubernetes 服务将在专用节点上运行，不会与其他工作负载竞争。 建议使用标记、标签和污点标识节点池来计划工作负载，并确保系统节点池受到 CriticalAddonsOnly [taint] (/azure/aks/use-system-pools#system-and-user-node-pools) 污染。

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

Pod 可用性

确保 Pod 资源。 强烈建议部署指定 Pod 资源要求。 然后，计划程序可以适当地计划 Pod。 如果无法计划 Pod，可靠性将大大降低。

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

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

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

设置 Pod 请求和限制。 设置这些限制后，Kubernetes 就能有效地将 CPU 和/或内存资源分配给 Pod，并在节点上具有更高的容器密度。 由于硬件得到更好的使用，所以限制还可以提高可靠性，同时降低成本。

若要估算限制，请测试和建立基准。 从请求和限制的相等值开始。 然后，逐步调整这些值，直到建立可导致群集不稳定的阈值。

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

可用性区域和多地区支持

如果 SLA 需要更高的运行时间，请使用可用性区域防范服务中断。 如果地区支持可用性区域，则可以使用。 然后，控制平面组件和节点池中的节点都能够跨区域分布。 如果整个区域不可用，则该地区内另一个区域中的节点仍然可用。 每个节点池映射到一个单独的虚拟机规模集，用于管理节点实例和可伸缩性。 规模集操作和配置由 AKS 服务管理。 启用多区域时需要注意以下事项：

• 整个基础结构。 选择支持可用性区域的地区。 有关详细信息，请参阅限制和地区可用性。 如果要购买正常运行时间 SLA，请选择支持该选项的地区。 使用可用性区域时，正常运行时间 SLA 更大。

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

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

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

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

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

多个区域

如果整个地区出现故障，则启用可用性区域是不够的。 若要获得更高的可用性，请在不同的地区运行多个 AKS 群集。

• 使用配对区域。 请考虑使用配置为使用配对地区从地区故障中恢复的 CI/CD 管道。 使用配对地区的好处是在更新期间具有可靠性。 Azure 确保一次只更新该对中的一个地区。 某些 DevOps 工具（如 Flux）可简化多区域部署。

• 如果 Azure 资源支持异地冗余，请提供冗余服务具有次要地区的位置。 例如，为 Azure 容器注册表启用异地复制会自动将映像复制到所选 Azure 地区，并且即使某个地区遇到服务中断，也将继续访问映像。

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

灾难恢复

如果主要地区中发生故障，则应能够在另一个地区中快速创建新实例。 以下是一些建议：

• 使用配对区域。

• 可以有效地复制无状态工作负载。 如果需要在群集中存储状态（不推荐），请确保在配对地区中经常备份数据。

• 将恢复策略（例如复制到另一个地区）作为 DevOps 管道的一部分，以满足服务级别目标 (SLO)。

• 预配每个 Azure 服务时，请选择支持灾难恢复的功能。 例如，在此体系结构中，启用 Azure 容器注册表以用于异地复制。 如果某个区域关闭，仍可从复制的区域拉取映像。

群集备份

对于许多体系结构，可以通过基于 GitOps 的[群集启动}(#cluster-bootstrapping)来实现对新群集的配置并使其返回到运行状态，然后便可部署应用程序。 但是，如果存在由于某种原因而无法在启动过程中捕获的关键资源状态（例如配置映射、作业和潜在机密），请考虑使用恢复策略。 通常建议在 Kubernetes 中运行无状态工作负载，但如果体系结构涉及基于磁盘的状态，则还需要考虑针对该内容的恢复策略。

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

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

参考实现不会实现备份，后者将涉及体系结构中要管理、监视、付费和保护的额外 Azure 资源；例如 Azure 存储帐户、Azure 备份保管库和配置，以及受信任的访问。 GitOps 与运行无状态工作负载的意图一起，共同组成了所实现的恢复解决方案。

选择并验证满足业务目标的解决方案，这些目标包括定义的恢复点目标 (RPO) 和恢复时间目标 (RTO)。 在团队 runbook 中定义此恢复过程，并针对所有业务关键型工作负载练习此恢复过程。

Kubernetes API 服务器 SLA

AKS 可以用作免费服务，但该层不提供财务支持的 SLA。 若要获取该 SLA，必须选择“标准层”。 建议所有生产群集都使用标准层。 为预生产群集预留免费层。 与可用性区域结合使用时，Kubernetes API 服务器 SLA 增加到 99.95%。 你的节点池和其他资源都在各自的 SLA 中涵盖。

权衡

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

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

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

通过强制故障转移测试和模拟中断来确保可靠性，例如停止节点、关闭特定区域中的所有 AKS 资源以模拟区域故障，或者调用外部依赖项失败。 Azure Chaos Studio 还可用于模拟 Azure 和群集中的各种类型的服务中断情况。

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

监视和收集指标

建议使用 Azure Monitor 容器见解工具来监视容器工作负载的性能，因为你可实时查看事件。 它从正在运行的 Pod 捕获容器日志，并聚合它们以供查看。 它还从指标 API 收集有关内存和 CPU 利用率的信息，以监视正在运行的资源和工作负载的运行状况。 可使用它来监视 Pod 缩放时的性能。 这包括收集关键的遥测数据来监视、分析和可视化所收集的数据，从而确定趋势，并配置警报以在出现严重问题时主动获得通知。

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

有一些与 Kubernetes 集成的第三方解决方案（例如 Datadog、Grafana 或 New Relic），如果你的组织已在使用这些解决方案，那么你可以使用它们。

借助 AKS，Azure 可管理一些核心 Kubernetes 服务，并且 AKS 控制平面组件的日志作为资源日志在 Azure 中实现。 建议大多数群集随时启用以下功能，因为它们可以帮助你排查群集问题，并且日志密度相对较低：

• 登录 ClusterAutoscaler 以观察缩放操作。 有关详细信息，请参阅检索群集自动缩放程序日志和状态。
• KubeControllerManager 能够观察 Kubernetes 与 Azure 控制平面之间的交互。
• KubeAuditAdmin 能够观察修改群集的活动。 没有理由同时启用 KubeAudit 和 KubeAuditAdmin，因为 KubeAudit 是 KubeAuditAdmin 的超集，还包括非修改（读取）操作。
• 临界子句可捕获 Microsoft Entra ID 和 Azure RBAC 审核。

其他日志类别（例如 KubeScheduler 或 KubeAudit）可能非常有助于在早期群集或工作负载生命周期开发期间启用，其中添加的群集自动缩放、Pod 放置和计划以及类似数据可以帮助解决群集或工作负载操作问题。 在故障排除需求结束后将扩展故障排除日志保持在全时状态可能被认为是在 Azure Monitor 中引入和存储的不必要成本。

虽然 Azure Monitor 包含一组现有的日志查询来助你入门，但你也可以它们为基础来帮助生成自己的查询。 随着库的增长，可以使用一个或多个查询包来保存和重复使用日志查询。 自定义查询库有助于提高 AKS 群集的运行状况和性能的可观测性，并支持服务级别目标 (SLA)。

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

要查看 AKS 上的 Windows 容器基线参考体系结构中包含的特定于 Windows 的监视注意事项，请参阅配套文章。

启用自我修复

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

AKS 群集更新

定义符合业务需求的更新策略至关重要。 了解 AKS 群集版本或其节点更新的日期和时间的可预测性水平，并了解所安装的特定映像或二进制文件的所需控制程度，是描述 AKS 群集更新蓝图的基本方面。 可预测性与两个主要 AKS 群集更新属性相关联，这些属性是更新频率和维护时段。 控件表示更新是手动安装还是自动安装。 拥有 AKS 群集的组织，如果没有严格的安全规定，可以考虑每周甚至每月更新一次，而其他组织必须尽快（每天）更新有安全标签的修补程序。 将 AKS 群集作为不可变基础结构进行操作的组织不会对其进行更新。 这意味着，既不进行自动更新，也不进行手动更新。 相反，当所需的更新可用时，会部署一个副本戳，只有当新的基础架构实例准备就绪时，旧的基础架构才会耗尽，从而为它们提供最高级别的控制。

一旦确定了 AKS 群集更新蓝图，就可以轻松地将其映射到 AKS 节点和 AKS 群集版本的可用更新选项中：

• AKS 节点：

  1. 无/手动更新：这适用于不可变的基础结构或手动更新是首选项时。 这实现了对 AKS 节点更新的更高级别的可预测性和控制。
  2. 自动无人参与更新：AKS 执行本机操作系统更新。 这通过配置符合业务利益的维护时段来提供可预测性。 这可能是基于高峰时段和最佳运营方式。 控制级别较低，因为不可能事先知道 AKS 节点内将具体安装什么。
  3. 自动更新节点映像：建议在新的虚拟硬盘 (VHD) 可用时自动更新 AKS 节点映像。 设计维护时段，使其尽可能与业务需求保持一致。 对于带有安全标签的 VHD 更新，建议配置可预测性最低的日常维护时段。 定期 VHD 更新可以配置为每周、每两周甚至每月维护一次。 根据是否需要安全标签 VHD 与常规 VHD 以及计划维护时段相结合，可预测性会有所波动，从而提供或多或少的灵活性来与业务需求保持一致。 虽然让这始终取决于业务需求是理想的，但现实要求组织找到临界点。 控制级别较低，因为不可能预先知道哪些特定二进制文件被包括在新 VHD 中，并且这种类型的自动更新仍然是推荐的选项，因为映像在可用之前会经过审查。

  注意

  有关如何配置自动 AKS 节点更新的更多信息，请参阅自动升级节点操作系统映像。

• AKS 群集版本：

  1. 无/手动更新：这适用于不可变的基础结构或手动更新是首选项时。 这实现了对 AKS 群集版本更新的更高级别的可预测性和控制。 建议选择加入此功能，因为这样可以完全控制，从而有机会在投入生产之前在较低的环境中测试新的 AKS 群集版本（即 1.14.x 到 1.15.x），
  2. 自动更新：不建议在未在较低环境中进行适当测试的情况下，将生产群集自动修补或以任何方式（即 1.16.x 到 1.16.y）更新为新的 AKS 群集版本。 虽然 Kubernetes 上游版本和 AKS 群集版本更新是协调一致的，提供了一个有规律的节奏，但建议在生产中使用 AKS 群集仍然是防御性的，以增加对更新过程的可预测性和控制。 相反，将低级环境的此配置作为卓越运营的一部分，支持主动的例行测试执行，以便尽早发现潜在问题。

使用支持的 N-2 版本使 Kubernetes 版本保持最新。 升级到最新版本的 Kubernetes 至关重要，因为新版本经常发布。

有关详细信息，请参阅定期更新到最新版本的 Kubernetes 并升级 Azure Kubernetes 服务 (AKS) 群集。

可以通过 Azure 事件网格的 AKS 系统主题来通知群集引发的事件，例如群集有新的 AKS 版本可用。 参考实现部署此事件网格系统主题，以便可以从事件流通知解决方案订阅 Microsoft.ContainerService.NewKubernetesVersionAvailable 事件。

每周更新

AKS 提供具有最新 OS 和运行时更新的新节点映像。 这些新映像不会自动应用。 你负责决定映像的更新频率。 建议制定每周升级节点池基础映像的流程。 有关详细信息，请参阅 Azure Kubernetes 服务 (AKS) 节点映像升级AKS 发行说明。

每日更新

在两次映像升级之间，AKS 节点单独下载并安装 OS 和运行时修补程序。 安装可能需要重新启动节点 VM。 由于挂起的更新，AKS 不会重新启动节点。 应制定一个流程来监视需要重新启动以应用更新的节点，并以受控方式执行这些节点的重新启动。 开源选项是 Kured（Kubernetes 重启守护程序）。

使节点映像与最新的每周版本保持同步将最大程度地减少这些偶尔的重新启动请求，同时保持增强的安全态势。 仅依赖节点映像升级可确保 AKS 兼容性和每周安全修补。 虽然应用每日更新可更快地解决安全问题，但它们不一定在 AKS 中进行了测试。 如果可能，请使用节点映像升级作为主要的每周安全修补策略。

安全监视

监视容器基础结构，了解主动威胁和潜在安全风险：

• 启用 Microsoft Defender for Containers 以识别和修正 Defender for Cloud 对容器映像的建议。
• Microsoft Defender for Containers 会定期扫描容器映像以查找漏洞。
• Microsoft Defender for Containers 还为可疑活动生成实时安全警报。
• 有关应用于 AKS 虚拟机主机的安全强化的信息，请参阅主机 OS 中的安全强化。

群集和工作负载操作 (DevOps)

以下是一些注意事项。 有关详细信息，请参阅卓越运营支柱。

群集引导

配置完成后，就有了一个正在工作的群集，但在部署工作负载之前可能仍需要执行一些步骤。 准备群集的过程称为引导，并且可以包括诸如将先决映像部署到群集节点、创建命名空间以及满足用例或组织要求的任何其他操作。

为了减少预配群集与正确配置的群集之间的差距，群集操作员应考虑其独特的引导过程会是什么样子，并提前准备相关资产。 例如，如果在部署应用程序工作负载之前在每个节点上运行 Kured 很重要，那么群集操作员需要确保在预配群集之前已经存在包含目标 Kured 映像的 ACR。

可以使用以下其中一种方法配置引导过程：

• 使用 Flux 或 Argo CD 等进行自我配置
• 管道
• GitOps Flux v2 群集扩展

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

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

隔离工作负载责任

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

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

另一部分可能是将基本工作负载与 Microsoft Entra ID 集成。

使用基础结构即代码 (IaC)

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

请确保根据治理策略预配资源。 例如，在选择正确的 VM 大小时，请保持在成本限制、可用性区域选项的范围内，以匹配应用程序的要求。

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

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

工作负载 CI/CD

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

部署策略必须包括可靠的自动化持续交付 (CD) 管道。 对工作负载容器映像的更改应自动部署到群集。

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

群集 CI/CD

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

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

CI/CD 流程的一个重要部分是新预配群集的引导。 为此，GitOps 方法很有用，它允许操作员以声明方式将引导过程定义为 IaC 策略的一部分，并自动查看群集中反映的配置。

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

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

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

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

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

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

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

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

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

5. 在 Git 服务器上具有分支策略。 这样，多个开发人员就可通过拉取请求批准更改，然后再将其应用于生产环境。

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

工作负载和群集部署策略

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

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

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

成本管理

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

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

要查看 AKS 上的 Windows 容器基线参考体系结构中包含的特定于基于 Windows 的工作负载的成本管理注意事项，请参阅配套文章。

预配

• 在 Kubernetes 群集的部署、管理和操作中，没有与 AKS 相关的成本。 影响成本的是群集消耗的虚拟机实例、存储、日志数据和网络资源。 考虑为系统节点池选择更便宜的 VM。 DS2_v2 SKU 是系统节点池的典型 VM 类型。

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

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

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

• 不要从一个超大群集开始以满足缩放需求，而是配置一个具有最少节点数的群集，并使群集自动缩放程序能够监视和制定规模决策。

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

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

• 如果工作负载预计会长期存在，可以承诺使用一年或三年期虚拟机预留实例以降低节点成本。 有关详细信息，请参阅预留 VM。

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

• 地区的可用性区域之间的数据传输不是免费的。 如果工作负载是多地区的或跨可用性区域进行传输，那么预计会产生额外的带宽成本。 有关详细信息，请参阅跨计费区域和地区的流量。

• 创建预算以保持在组织确定的成本限制范围内。 一种方法是通过 Azure 成本管理创建预算。 还可以创建警报，以在超过某些阈值时获取通知。 有关详细信息，请参阅使用模板创建预算。

监视

为了监控整个群集的成本以及计算成本，还会收集有关存储、带宽、防火墙和日志的成本信息。 Azure 提供各种仪表板来监视和分析成本：

• Azure 顾问

• Azure 成本管理

理想情况下，实时监视成本或至少定期监视成本，以便在已经计算成本的月底之前采取行动。 还要监视一段时间内的每月趋势以保持在预算范围内。

要做出数据驱动的决策，请确定哪个资源（粒度级别）产生的成本最高。 此外，还对用于计算每个资源的使用情况的计量有了很好的了解。 例如，通过分析指标，可以确定平台是否过大。 可以在 Azure Monitor 指标中查看使用情况计量。

优化

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

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

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

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

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

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

后续步骤

继续了解 AKS 基线体系结构：

• 若要了解如何在 AKS 基准上托管微服务，请参阅高级 Azure Kubernetes 服务 (AKS) 微服务体系结构。
• 要跨多个地区部署 AKS 基准，请参阅多地区群集的 AKS 基准。
• 要将 AKS 基准部署到 PCI-DSS 3.2.1 环境中，请参阅适用于 PCI-DSS 3.2.1 的 AKS 监管群集。
• 要了解将 Windows 容器添加到参考体系结构的注意事项，请参阅配套文章：AKS 上的 Windows 容器基线参考体系结构

详细了解 AKS

• 查看 AKS 产品路线图，请参阅 GitHub 上的 Azure Kubernetes 服务路线图。
• 如需复习 Kubernetes，请完成以下学习路径：Kubernetes 介绍和在 Kubernetes 上开发和部署应用程序。

相关资源

请参阅以下相关指南：

• Azure Kubernetes 服务 (AKS) 的 Azure 架构良好的框架评审
• AKS 登陆区域加速器，它是基于此体系结构的企业规模实现。 该加速器可帮助你使用基础结构即代码 (IaC) 为 Azure Kubernetes 服务 (AKS) 部署设置 Azure 环境一致且可重复。
• Azure Kubernetes 服务 (AKS) 第 2 天操作指南

请参阅以下相关体系结构：

• Azure Kubernetes 服务上的微服务体系结构
• 使用 Azure 防火墙帮助保护 Azure Kubernetes 服务 (AKS) 群集
• Azure Kubernetes 服务的 GitOps
• 使用 AKS 的数据流式传输