高级 Azure Kubernetes 服务 (AKS) 微服务体系结构

此参考体系结构介绍了在 Azure Kubernetes 服务（AKS）上运行微服务时要考虑的多个配置。 本文讨论基于微服务的应用程序的网络策略配置、Pod 自动缩放和分布式跟踪。

此 体系结构基于 AKS 基线体系结构构建，该体系结构充当 AKS 基础结构的起点。 AKS 基线描述了基础结构功能，例如Microsoft Entra 工作负荷 ID、入口和出口限制、资源限制和其他安全的 AKS 基础结构配置。 本文未介绍这些功能。 建议先熟悉 AKS 基线体系结构，然后再继续学习微服务内容。

体系结构

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

如果想要从 AKS 上更基本的微服务示例开始，请参阅 AKS 上的微服务体系结构。

Workflow

此请求流实现发布者-订阅者、竞争使用者和网关路由云设计模式。

以下工作流与上图相对应：

1. 提交 HTTPS 请求以安排无人机取件。 请求通过 Azure 应用程序网关传递到引入 Web 应用程序，该应用程序在 AKS 中作为群集内微服务运行。

2. 引入 Web 应用程序生成消息并将其发送到 Azure 服务总线消息队列。

3. 后端系统分配无人机并通知用户。 工作流微服务执行以下任务：

   • 从服务总线消息队列中读取消息。

   • 向传递微服务发送 HTTPS 请求，该微服务将数据传递到 Azure 托管 Redis 外部数据存储。

   • 向无人机计划程序微服务发送 HTTPS 请求。

   • 向包微服务发送 HTTPS 请求，该请求将数据传递到 Azure DocumentDB 外部数据存储。

   • 高级容器网络服务策略（Cilium NetworkPolicy）管理群集内的服务到服务流量，数据平面以透明方式强制实施可选的节点间 Pod 加密（WireGuard）。 默认情况下未启用高级容器网络服务。 它提取节点级和 Pod 级数据，并将其引入 Azure Monitor 以获取端到端可见性。

4. 体系结构使用 HTTPS GET 请求返回传递状态。 此请求通过应用程序网关传递到传递微服务。

5. 传递微服务从 Azure 托管 Redis 读取数据。

组件

• AKS 是一个托管 Kubernetes 平台，提供托管群集用于部署和缩放容器化应用程序。 使用 AKS 时，Azure 管理 Kubernetes API 服务器。 群集作员可以访问和管理 Kubernetes 节点或节点池。 此体系结构使用以下 AKS 基础结构功能：

  • AKS 管理的 Microsoft Entra ID 用于 Azure 基于角色的访问控制（Azure RBAC） 是一种将 Microsoft Entra ID 与 AKS 集成以实施基于身份的访问控制的功能。 在此体系结构中，它确保群集用户和工作负载的安全、集中身份验证和授权。

  • 由 Cilium 提供支持的 Azure CNI 是用于直接连接到 Azure 虚拟网络的建议网络解决方案。 在该架构中，它将虚拟网络中的 IP 地址分配给 Pod，同时提供内置的网络策略功能和流量监控。

  • 高级容器网络服务 是 AKS 的托管网络功能套件，可提供网络可观测性和增强群集内安全性：

    • 容器网络可观测性使用基于扩展的 Berkeley 数据包筛选器（eBPF）工具（如 Hubble 和 Retina）收集域名系统（DNS）查询、Pod 到 Pod 和 Pod 到服务流、数据包丢弃和其他指标。 它适用于 Cilium 和非 Cilium Linux 数据平面。 它还与 Prometheus 的 Azure Monitor 托管服务集成，以及用于可视化和警报的 Azure Managed Grafana。 在此体系结构中，容器网络可观测性可诊断策略配置错误、DNS 延迟或错误，以及微服务之间的流量不平衡。

    • 容器网络安全适用于使用由 Cilium 提供支持的 Azure CNI 的群集。 它执行 Cilium NetworkPolicy 资源（包括基于完全限定域名（FQDN）的出口筛选），实现零信任网络分段，并减少运维开销。 在此体系结构中，群集内 FQDN 策略适用于 Azure 防火墙或 Azure NAT 网关，以在简化策略维护的同时强制实施最低特权出口。

  • 适用于 AKS 的 Azure Policy 加载项 是一个内置扩展，用于将治理和合规性控制直接引入 AKS 群集。 它使用 Azure Policy 跨 AKS 资源应用治理规则。 在此体系结构中，它通过验证配置并限制未经授权的部署来强制实施符合性。

  • 使用应用程序路由加载项的托管 NGINX 入口 是 AKS 中的一项功能，可帮助你使用 HTTP 或 HTTPS 流量向 Internet 公开应用程序。 它为 AKS 提供预配置的 NGINX 入口控制器。 在此架构中，它负责将流量路由到服务，并使 Pod 可供应用程序网关使用。

  • 系统和用户节点池分离 是一种体系结构做法，可将群集节点划分为两种不同的节点池，并将 AKS 基础结构组件与应用程序工作负荷隔离。 在此体系结构中，通过将节点池专用于特定的作角色来增强安全性和资源效率。

  • 工作负荷 ID 是 Kubernetes 工作负载使用 Microsoft Entra ID 访问 Azure 资源的安全且可缩放的方式，无需在群集中存储机密或凭据。 使用工作负荷 ID，AKS 工作负载可以使用联合标识安全地访问 Azure 资源。 在此体系结构中，它无需机密，并通过基于标识的访问改善安全状况。

• 应用程序网关 是一种 Azure 托管服务，提供第 7 层负载均衡和 Web 应用程序防火墙（WAF）功能。 在此体系结构中，它将引入微服务公开为公共终结点，并平衡传入到应用程序的 Web 流量。

• Azure 防火墙 是一种 Azure 托管服务，可提供智能的云原生网络安全和威胁防护。 在此体系结构中，它控制从微服务到外部资源的出站通信，仅允许已批准的 FQDN 作为出口流量。

• Azure 专用链接 是一种 Azure 托管服务，通过 Microsoft 主干网络实现与 Azure 平台即服务（PaaS）服务的专用连接。 在此体系结构中，它分配专用 IP 地址，以通过专用终结点从 AKS 节点池访问 Azure 容器注册表和 Azure Key Vault。

• Azure 虚拟网络 是一项 Azure 托管服务，它提供独立且安全的环境来运行应用程序和虚拟机（VM）。 在此体系结构中，它使用对等互连的中心辐射型拓扑。 中心网络托管 Azure 防火墙和 Azure Bastion。 辐射状网络包含 AKS 系统和用户节点池子网，以及应用程序网关子网。

外部存储和其他组件

• Azure 托管 Redis 是一项 Azure 托管服务，它提供高性能的内存中数据存储，用于缓存、会话存储和实时数据访问。 除了传统缓存，它还支持高级数据类型和功能，如 JSON 文档存储、全文搜索和矢量搜索以及流处理。 这些功能非常适合加速微服务和为新式 AI 方案提供支持，例如检索扩充生成（RAG）、智能助手、实时建议、AI 代理和异常情况检测。 在此体系结构中，交付微服务使用 Azure 托管 Redis 作为状态存储和 侧缓存 ，以提高流量过大期间的速度和响应能力。

• 容器注册表 是一种 Azure 托管服务，用于存储专用容器映像以在 AKS 中部署。 在此体系结构中，它保存微服务的容器映像，AKS 使用其Microsoft Entra 托管标识对其进行身份验证。 还可以使用其他注册表，例如 Docker 中心。

• Azure Cosmos DB 是 Azure 托管的全局分布式 NoSQL、关系数据库和矢量数据库服务。 在此体系结构中，Azure Cosmos DB 和 Azure DocumentDB 充当每个微服务的外部数据存储。

• Key Vault 是一种 Azure 托管服务，可安全地存储和管理机密、密钥和证书。 在此体系结构中，Key Vault 存储微服务用于访问 Azure Cosmos DB 和 Azure 托管 Redis 的凭据。

• Azure Monitor 是一个 Azure 托管的可观测性平台，可跨服务收集指标、日志和遥测数据。 在此体系结构中，实现监控，包括针对应用程序跨 AKS 和集成服务的故障的警报、仪表盘展示和根本原因分析。

  容器网络可观测性用于先进的容器网络服务，使用 Hubble 实现流可视化，使用 Retina 提供精心挑选的网络遥测信息。 这些工具与托管可观测性后端（例如 Prometheus 的 Azure Monitor 托管服务和 Azure Managed Grafana）集成，用于故障排除和服务级别目标（SLO）报告。

• 服务总线 是一种 Azure 托管的消息传送服务，支持分布式应用程序之间的可靠和异步通信。 在此体系结构中，服务总线充当引入和工作流微服务之间的排队层，这可实现分离和可缩放的消息交换。

其他作支持系统组件

• Flux 是适用于 Kubernetes 的受 Azure 支持、开源且可扩展的持续交付解决方案，可在 AKS 中启用 GitOps。 在此体系结构中，Flux 通过从 Git 存储库同步应用程序清单文件来自动执行部署，这可确保将微服务一致且声明性地传送到 AKS 群集。

• Helm 是 Kubernetes 本机包管理器，将 Kubernetes 对象捆绑到单个单元中，用于发布、部署、版本控制及更新。 在此体系结构中，Helm 用于打包微服务并将其部署到 AKS 群集。

• Key Vault 机密存储 CSI 驱动程序提供程序 是一个 Azure 集成的驱动程序，它使 AKS 群集能够使用 CSI 卷从 Key Vault 装载机密。 在此体系结构中，机密直接装载到微服务容器中，这样就可以安全地检索 Azure Cosmos DB 和 Azure 托管 Redis 的凭据。

替代方案

可以使用 适用于容器的应用程序网关 和 Istio 网关加载项等替代方法，而不是使用应用程序路由加载项。 有关 AKS 中的入口选项的比较，请参阅 AKS 中的入口。 用于容器的应用程序网关是应用程序网关入口控制器的演变，提供流量拆分和加权轮循机制负载均衡等额外功能。

可以使用 ArgoCD 作为 GitOps 工具，而不是 Flux。 Flux 和 ArgoCD 都可用作群集扩展。

建议不要在密钥保管库中存储 Azure Cosmos DB 和 Azure 托管 Redis 的凭据，而是使用托管标识进行身份验证，因为无密码身份验证机制更安全。 有关详细信息，请参阅 使用托管标识从 Azure VM 连接到 Azure Cosmos DB ， 并使用 Microsoft Entra ID 访问服务总线资源对托管标识进行身份验证。 Azure 托管 Redis 还支持 使用托管标识进行身份验证。

方案详细信息

在此示例中，虚构公司 Fabrikam Inc. 管理一个无人机群。 商家可以注册该服务，用户可以请求无人机收取要交付的商品。 当客户安排取件时，后端系统会分配无人机，并通知用户估计的交付时间。 客户可以跟踪无人机的位置，并在交付正在进行时查看持续更新的到达估计时间。

建议

您可以将以下建议应用于大多数场景。 除非有优先于这些建议的特定要求，否则请遵循这些建议。

使用应用程序路由加载项的托管 NGINX 入口

API 网关路由是一种常规微服务设计模式。 API 网关充当反向代理，用于将请求从客户端路由到微服务。 Kubernetes 入口 资源和 入口控制器 通过执行以下作来处理大多数 API 网关功能：

• 将客户端请求路由到正确的后端服务，以便为客户端提供单个终结点，并帮助将客户端与服务分离

• 将多个请求聚合到单个请求，以减少客户端和后端之间的聊天

• 卸载安全套接字层（SSL）终止、身份验证、IP 地址限制以及后端服务中的客户端速率限制或限制等功能

入口控制器简化了 AKS 群集的流量引入，提高了安全性和性能，并节省资源。 此体系结构使用 托管 NGINX 入口和应用程序路由加载项 进行入口控制。

建议将 入口控制器与内部（专用）IP 地址 和内部负载均衡器配合使用，并集成到 Azure 专用 DNS 区域，以解析微服务的主机名。 将入口控制器的专用 IP 地址或主机名配置为应用程序网关中的后端池地址。 应用程序网关接收公共终结点上的流量，执行 WAF 检查，并将流量路由到入口专用 IP 地址。

使用 自定义域名和 SSL 证书 配置入口控制器，以便对流量进行端到端加密。 应用程序网关接收 HTTPS 侦听器上的流量。 WAF 检查后，应用程序网关会将流量路由到入口控制器的 HTTPS 终结点。 将所有微服务配置为使用自定义域名和 SSL 证书，该证书可保护 AKS 群集中的微服务间通信。

多租户工作负荷或支持开发和测试环境的单个群集可能需要更多入口控制器。 应用程序路由加载项支持高级配置和自定义，包括 同一 AKS 群集中的多个入口控制器 ，并使用注释配置入口资源。

网络和网络策略

使用由 Cilium 提供支持的 Azure CNI。 eBPF 数据平面具有合适的路由性能，并支持任何大小的群集。 Cilium 原生支持 Kubernetes NetworkPolicy 并提供流量可观测性功能丰富。 有关详细信息，请参阅 在 AKS 中配置由 Cilium 提供支持的 Azure CNI。

对于特定的 IP 地址管理需求，由 Cilium 提供支持的 Azure CNI 支持虚拟网络路由和覆盖 Pod IP 模型。 有关详细信息，请参阅 由 Cilium 提供支持的 Azure CNI。

零信任网络策略

网络策略指定 AKS Pod 如何相互通信和其他网络终结点。 默认情况下，允许传入和传出 pod 的所有入口和出口流量。 设计微服务如何相互通信和其他终结点时，请考虑遵循 零信任原则，其中访问任何服务、设备、应用程序或数据存储库需要显式配置。 定义并强制实施 Kubernetes NetworkPolicy（由高级容器网络服务/Cilium 实现），以分隔微服务的流量，并将出站流量限制到仅允许的完全限定域名（FQDN）。

实现零信任策略的一种策略是创建一个网络策略，该策略拒绝目标命名空间中所有 Pod 的所有入口和出口流量。 以下示例显示了 一个拒绝所有 策略，该策略适用于命名空间中的所有 backend-dev Pod。

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: deny-all
  namespace: backend-dev
spec:
  endpointSelector: {}  # Applies to all pods in the namespace
  ingress:
  - fromEntities: []
  egress:
  - toEntities: []

实施限制性策略后，开始定义特定的网络规则，以允许流量传入和传出微服务中的每个 Pod。 在以下示例中，Cilium 网络策略应用于 backend-dev 命名空间中标签符合 app.kubernetes.io/component: backend 条件的所有 Pod。 除非该策略源自具有匹配 app.kubernetes.io/part-of: dronedelivery标签的 Pod，否则该策略将拒绝任何流量。

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: package-v010-dev-np-allow-ingress-traffic
  namespace: backend-dev
spec:
  endpointSelector:
    matchLabels:
      app.kubernetes.io/component: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app.kubernetes.io/part-of: dronedelivery
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP

有关 Kubernetes 网络策略和潜在默认策略的更多示例的详细信息，请参阅 Kubernetes 文档中的网络策略。 有关 AKS 中的网络策略的最佳做法，请参阅 AKS 中的网络策略。

使用 由 Cilium 提供支持的 Azure CNI 时，Kubernetes NetworkPolicy 由 Cilium 强制实施。 出于特殊要求，Azure 提供其他网络策略引擎，包括 Azure 网络策略管理器和 Calico。 建议 Cilium 作为默认网络策略引擎。

资源配额

管理员使用资源配额来保留和限制开发团队或项目中的资源。 可以在命名空间上设置资源配额，并使用这些配额来设置以下资源的限制：

• 计算资源，如中央处理单元（CPU）、内存和图形处理单元（GPU）

• 存储资源，包括特定存储类的卷数或磁盘空间量

• 对象计数，例如可以创建的机密、服务或任务的最大数量

在累计资源请求或限制通过分配的配额后，不会再成功部署。

资源配额确保分配给命名空间的 pod 总数不能超过命名空间的资源配额。 前端不能对后端服务使用所有资源，后端不能对前端服务使用所有资源。

定义资源配额时，命名空间中创建的所有 pod 必须在其 pod 规范中提供限制或请求。 如果它们未提供这些值，则会拒绝部署。

以下示例演示一个 Pod 规范，用于设置资源配额请求和限制：

requests:
  cpu: 100m
  memory: 350Mi
limits:
  cpu: 200m
  memory: 500Mi

有关资源配额的详细信息，请参阅以下文章：

• 强制实施资源配额
• 资源配额

自动缩放

Kubernetes 支持 自动缩放 ，以增加分配给部署的 Pod 数或增加群集中的节点数，以增加可用计算资源总数。 自动缩放是一种自我纠正的自治反馈系统。 可以手动缩放 Pod 和节点，但自动缩放可最大程度地减少服务在高负载时达到资源限制的可能性。 自动缩放策略必须同时考虑 Pod 和节点。

群集自动缩放

群集自动缩放程序（CA）可缩放节点数。 如果由于资源约束而无法计划 Pod，则 CA 会预配更多节点。 定义最少数量的节点可使 AKS 群集和工作负载保持正常运行，而定义最多数量的节点可以应对繁重的流量。 CA 每隔几秒钟检查一次挂起的 pod 或空节点，并相应地缩放 AKS 群集。

以下示例演示群集 Bicep 模板中的 CA 配置：

autoScalerProfile: {
  'scan-interval': '10s'
  'scale-down-delay-after-add': '10m'
  'scale-down-delay-after-delete': '20s'
  'scale-down-delay-after-failure': '3m'
  'scale-down-unneeded-time': '10m'
  'scale-down-unready-time': '20m'
  'scale-down-utilization-threshold': '0.5'
  'max-graceful-termination-sec': '600'
  'balance-similar-node-groups': 'false'
  expander: 'random'
  'skip-nodes-with-local-storage': 'true'
  'skip-nodes-with-system-pods': 'true'
  'max-empty-bulk-delete': '10'
  'max-total-unready-percentage': '45'
  'ok-total-unready-count': '3'
}

Bicep 模板中的以下行提供设置 CA 的最小节点和最大节点数的示例：

minCount: 2
maxCount: 5

水平 Pod 自动缩放

水平 Pod 自动缩放程序（HPA）根据观察到的 CPU、内存或自定义指标缩放 Pod。 若要配置水平 Pod 缩放，请在 Kubernetes 部署 Pod 规范中指定目标指标和最小和最大副本数。 负载测试服务以确定这些数字。

CA 和 HPA 协同工作，因此在 AKS 群集中启用两个自动扩缩选项。 HPA 可缩放应用程序，而 CA 可缩放基础结构。

以下示例设置 HPA 的资源指标：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: delivery-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: delivery
  minReplicas: 2
  maxReplicas: 5
  metrics:
  - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

HPA 查看用于运行 Pod 所消耗的实际资源或其他指标。 CA 为尚未计划的 Pod 预配节点。 因此，CA 会按照 Pod 规范中指定的请求资源来查看请求的资源。 使用负载测试微调这些值。

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

垂直 Pod 自动缩放

垂直 Pod 自动缩放程序（VPA）会自动调整 Pod 的 CPU 和内存请求，以匹配工作负荷的使用模式。 配置后，VPA 会根据过去的使用情况自动设置每个工作负荷的容器的资源请求和限制。 VPA 使 CPU 和内存可用于其他 Pod，并帮助确保有效利用 AKS 群集。

在此体系结构中，VPA 会根据微服务的过去使用情况增加 CPU 和内存请求和限制。 例如，如果工作流微服务与其他微服务相比消耗更多的 CPU，VPA 可以监视此使用情况并增加工作流微服务的 CPU 限制。

Kubernetes 事件驱动的自动缩放

Kubernetes 事件驱动自动缩放（KEDA）插件启用事件驱动的自动缩放，以可持续且经济高效的方式扩展微服务来满足需求。 例如，当服务总线队列中的消息数超过特定阈值时，KEDA 可以纵向扩展微服务。

在 Fabrikam 无人机交付方案中，KEDA 根据服务总线队列深度以及基于引入微服务输出横向扩展工作流微服务。 有关 Azure 服务的 KEDA 缩放程序列表，请参阅 AKS 上的与 KEDA 的集成。

运行状况探测

Kubernetes 对发往与服务标签选择器匹配的 pod 的流量进行负载均衡。 只有成功启动且处于正常状态的 Pod 才会接收流量。 如果某个容器崩溃，Kubernetes 会删除 pod，并计划替代的 pod。 Kubernetes 定义了 Pod 可以公开的三种类型的运行状况探测：

• 就绪情况探测告知 Kubernetes Pod 是否已准备好接受请求。

• 实时性探测告知 Kubernetes 是否应删除 Pod 并启动新实例。

• 启动探测告知 Kubernetes 是否已启动 Pod。

运行情况探测处理仍在运行但运行不正常且应回收的 pod。 例如，如果服务 HTTP 请求的容器挂起，则容器不会崩溃，但会停止处理请求。 HTTP 实时性探测停止响应，这提醒 Kubernetes 重启 Pod。

有时，即使 Pod 已成功启动，Pod 也可能无法接收流量。 例如，在容器中运行的应用程序可能正在执行初始化任务。 就绪情况探测指示 pod 是否已准备好接收流量。

微服务应在其代码中公开终结点，以便进行运行状况探测，并专门针对它们执行的检查进行延迟和超时。 HPA 公式依赖于 Pod 的就绪阶段，因此运行状况探测存在且准确至关重要。

监视

监视在微服务体系结构中至关重要，用于检测异常、诊断问题并了解服务依赖项。 Application Insights 是 Azure Monitor 的一部分，为以 .NET、Node.js、Java 和许多其他语言编写的应用程序提供应用程序性能监视（APM）。 Azure 提供了多个集成功能，用于端到端可见性：

• 适用于 Prometheus 的 Azure Monitor 托管服务 收集基础结构和工作负荷指标，并发出警报。

• 容器见解中的实时数据功能监视 AKS 群集、节点和容器，了解运行状况和资源使用情况。

• Azure 托管 Grafana 可视化群集和微服务的指标和仪表板。

高级容器网络服务 可观测性通过提供对 AKS 群集网络行为的深度、基于 eBPF 的可见性来补充这些工具。 它捕获 DNS 延迟、Pod 到 Pod 和服务流量、网络策略丢弃情况，以及 HTTP 状态代码和响应时间等第 7 层协议的指标。 此遥测集成了适用于 Prometheus 指标的 Azure Monitor 托管服务和适用于仪表板的 Azure Managed Grafana。 Cilium eBPF 数据平面提供流级可见性和故障排除。 与高级容器网络服务和 Azure Monitor 结合使用时，此功能可提供端到端网络可观测性。 此集成可检测传统 APM 可能错过的网络瓶颈、策略配置错误和通信问题。

注意事项

这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改进工作负荷质量的指导原则。 有关详细信息，请参阅 Well-Architected Framework。

安全性

安全性提供针对故意攻击和滥用宝贵数据和系统的保证。 有关详细信息，请参阅 安全的设计评审清单。

规划安全性时，请考虑以下几点：

• 在 AKS 群集中使用 部署安全措施 。 部署安全措施通过 Azure Policy 控件在 AKS 群集中强制实施 Kubernetes 最佳做法。

• 将安全扫描集成到微服务生成和部署管道中。 使用 Microsoft Defender for Cloud DevOps 安全性管理 DevOps 环境。 使用 无代理代码扫描 并运行 静态代码分析工具 作为持续集成和持续部署（CI/CD）管道的一部分，以便可以在生成和部署过程中识别和解决微服务代码漏洞。

• AKS Pod 使用存储在 Microsoft Entra ID 中的 工作负荷标识 来自行进行身份验证。 应使用工作负荷标识，因为它不需要客户端密码。

• 使用托管标识时，应用程序可以在运行时快速获取 Azure 资源管理器 OAuth 2.0 令牌。 它不需要密码或连接字符串。 在 AKS 中，可以使用 工作负荷 ID 将标识分配给各个 Pod。

• 应为微服务应用程序中的每个服务分配一个唯一的工作负荷标识，以简化最低特权的 Azure RBAC 分配。 仅向需要标识的服务分配标识。

• 如果某个应用程序组件需要 Kubernetes API 访问权限，请确保将应用程序 Pod 配置为使用具有适当范围的 API 访问权限的服务帐户。 有关详细信息，请参阅 管理 Kubernetes 服务帐户。

• 并非所有 Azure 服务都支持Microsoft Entra ID 进行数据平面身份验证。 若要存储这些服务的凭据或应用程序机密、非Microsoft服务或 API 密钥，请使用 Key Vault。 它为所有密钥和机密提供集中管理、访问控制、静态加密和审核。

• 在 AKS 中，可将 Key Vault 中的一个或多个机密装载为一个卷。 然后，pod 可以像读取普通卷一样读取密钥保管库机密。 有关详细信息，请参阅在 AKS 群集中对机密存储 CSI 驱动程序使用 Key Vault 提供程序。 建议为每个微服务维护单独的密钥保管库。

高级容器网络服务 为 AKS 群集提供群集内网络分段和零信任控制。 使用由 Cilium 提供支持的 Azure CNI 上的 Cilium 网络策略在群集中实现第 3 层和第 4 层分段。 高级容器网络服务安全性通过添加高级功能来扩展此基础：

• 基于 FQDN 的出口筛选，以将出站流量限制为已批准的域。

• HTTP 和 gRPC 远程过程调用（gRPC）等协议的级别 7 感知策略，用于验证和控制应用程序级通信。

• 使用 WireGuard 加密来保护 Pod 与 Pod 之间的流量，并保护传输中的敏感数据。

  这些功能与外围防御（如网络安全组（NSG）和 Azure 防火墙一起工作，以提供分层的安全方法，以强制从群集内部实施流量控制。

• 如果微服务需要与群集外部的外部 URL 等资源通信，请通过 Azure 防火墙控制访问。 如果微服务不需要进行任何出站调用，请使用 网络隔离群集。

• 启用 Microsoft Defender for Containers 以提供安全状况管理、微服务漏洞评估、运行时威胁防护和其他安全功能。

网络数据平面和策略引擎

AKS 上的 Cilium 目前支持 Linux 节点，并在数据平面中强制实施 NetworkPolicy。 请注意策略注意事项，例如 ipBlock 使用节点 IP 地址和 Pod IP 地址，并且主机网络 Pod 使用主机标识。 Pod 级策略不适用。 将 AKS 和 Cilium 版本与受支持的版本矩阵对齐。 有关更多信息，请参阅 Cilium 支持的 Azure CNI 限制。

成本优化

成本优化侧重于减少不必要的开支和提高运营效率的方法。 有关详细信息，请参阅 成本优化的设计评审清单。

• Well-Architected Framework 中的“成本优化”部分介绍了成本注意事项。

• 使用 Azure 定价计算器估算特定方案的成本。

• 在免费层中，AKS 不与 Kubernetes 群集的部署、管理和作相关的成本。 只需为群集使用的 VM 实例、存储和网络资源付费。 群集自动缩放可以通过删除空节点或未使用的节点来显著降低群集成本。

• 考虑将 AKS 免费层用于开发工作负荷，并将 标准层和高级层 用于生产工作负荷。

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

卓越运营

卓越运营涵盖部署应用程序并使其在生产环境中运行的运营流程。 有关详细信息，请参阅 卓越运营的设计评审清单。

规划可管理性时，请考虑以下几点：

• 通过自动化部署管道（如 GitHub Actions 工作流）管理 AKS 群集基础结构。

• 工作流文件仅将基础结构（而不会将工作负载）部署到已存在的虚拟网络和 Microsoft Entra 配置中。 通过单独部署基础结构和工作负荷，可以解决不同的生命周期和作问题。

• 如果发生区域故障，请考虑工作流作为部署到另一个区域的机制。 生成管道，以便可以在具有参数和输入更改的新区域中部署新群集。

性能效率

性能效率是指工作负荷能够高效地缩放以满足用户需求。 有关详细信息，请参阅 性能效率的设计评审清单。

规划可伸缩性时，请考虑以下几点：

• 不要将自动缩放和副本数量的命令式或声明式管理相结合。 如果用户和自动缩放程序都尝试更改副本数，则可能会出现意外行为。 启用 HPA 后，将副本数减少到要部署的最小数量。

• Pod 自动缩放的影响是，当应用程序缩容或扩容时，可能会频繁创建或逐出 Pod。若要缓解这些影响，请执行以下操作：

  • 使用就绪情况探测来让 Kubernetes 知道新 pod 已准备好接受流量。

  • 使用 pod 中断预算来限制每次可从服务中逐出的 pod 数。

• 如果微服务存在大量出站流，请考虑使用 网络地址转换（NAT）网关 以避免源网络地址转换（SNAT）端口耗尽。

• 多租户或其他高级工作负荷可能具有节点池隔离要求，这些要求需要更多和可能更小的子网。 有关详细信息，请参阅 添加具有唯一子网的节点池。 组织对其中心辐射型实现采用不同的标准。 请务必遵循组织的准则。

• 请考虑将 Azure CNI 与覆盖网络配合使用 ，以节省网络地址空间。

后续步骤

• AKS 的 简介
• 什么是虚拟网络？
• 什么是专用链接？
• 什么是应用程序网关？
• 什么是 Azure Bastion？
• Key Vault 简介
• 容器注册表简介
• Azure Monitor 概述
• 高级容器网络服务

相关资源

• AKS 群集的基线体系结构
• 使用 Kubernetes 在 Azure 上设计、生成和操作微服务
• AKS 上的微服务体系结构
• 为 Kubernetes 上的微服务生成 CI/CD 管道