【Azure AKS】高级Azure Kubernetes服务（AKS）微服务架构

此参考架构详细说明了在Azure Kubernetes Services上运行微服务时需要考虑的几个配置。主题包括配置网络策略、pod自动缩放和跨基于微服务的应用程序的分布式跟踪。

该架构建立在微软推荐的Azure Kubernetes Service（AKS）基础设施起点AKS基线架构之上。AKS基线详细说明了基础设施功能，如Microsoft Entra工作负载ID、入口和出口限制、资源限制以及其他安全的AKS基础设施配置。本文档未涵盖这些基础设施细节。建议您在继续使用微服务内容之前熟悉AKS基线。

GitHub徽标此架构的参考实现可在GitHub.上获得。

架构

网络图显示了具有两个对等虚拟网络的中心辐射网络以及此实现使用的Azure资源。

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

如果您希望从AKS上更基本的微服务示例开始，请参阅AKS上的微服务架构(Microservices architecture on AKS.)。

通信流

此请求流实现了发布者-订阅者、竞争消费者和网关路由云设计模式。消息传递流程如下：

• 提交HTTPS请求以安排无人机接送(drone pickup)。请求通过Azure应用程序网关传递到摄入web应用程序，该应用程序在AKS中作为集群内微服务运行。
• 摄取web应用程序生成一条消息并将其发送到Service Bus消息队列。
• 后端系统分配无人机并通知用户。工作流程：
  • 使用Service Bus消息队列中的消息信息。
  • 向Delivery微服务发送HTTPS请求，该微服务将数据传递给Azure Cache for Redis外部数据存储。
  • 向Drone Scheduler微服务发送HTTPS请求。
  • 向Package微服务发送HTTPS请求，后者将数据传递给MongoDB外部数据存储。
• HTTPS GET请求用于返回传递状态。此请求通过应用程序网关传递到Delivery微服务。
• 交付微服务从Azure Cache for Redis读取数据。

组件

此架构使用以下Azure组件：

Azure Kubernetes Service是一个Azure产品，提供托管的Kubernetes集群。使用AKS时，Kubernetes API服务器由Azure管理。Kubernetes节点或节点池是可访问的，可以由集群操作员管理。

此架构中使用的AKS基础设施功能包括：

• System and user node pool separation
• AKS-managed Microsoft Entra ID for role-based access control (RBAC)
• Microsoft Entra Workload ID
• Azure Policy Add-on for AKS
• Azure Container Networking Interface (CNI)
• Azure Monitor container insights

Azure虚拟网络是用于运行虚拟机（VM）和应用程序的隔离且高度安全的环境。此参考架构使用对等中心辐射虚拟网络拓扑[peered hub-spoke ]。集线器虚拟网络包含Azure防火墙和Azure Bastion子网。辐条虚拟网络包含AKS系统和用户节点池子网以及Azure应用程序网关子网。

• Azure Private Link分配特定的私有IP地址，以便从AKS系统和用户节点池子网内的私有端点访问Azure容器注册表和密钥库。

具有web应用程序防火墙（WAF）的Azure应用程序网关将HTTP（S）路由暴露给AKS集群，并对web应用程序的web流量进行负载平衡。此架构使用Azure应用程序网关入口控制器（AGIC）作为Kubernetes入口控制器。

• Azure Bastion通过使用安全套接字层（SSL）为虚拟网络中的VM提供安全的远程桌面协议（RDP）和安全shell（SSH）访问，而无需通过公共IP地址暴露VM。
• Azure防火墙是一种保护所有Azure虚拟网络资源的网络安全服务。防火墙只允许批准的服务和完全限定的域名（FQDN）作为出口流量。

外部存储和其他组件：

• Azure密钥库存储和管理AKS服务的安全密钥。
• Azure容器注册表存储可以在AKS集群中运行的私有容器映像。AKS使用其Microsoft Entra管理的身份向容器注册表进行身份验证。您还可以使用其他容器注册表，如Docker Hub。
• Azure Cosmos DB使用开源的Azure Cosmos DB for MongoDB存储数据。微服务通常是无状态的，并将其状态写入外部数据存储。Azure Cosmos DB是一个NoSQL数据库，具有MongoDB和Cassandra的开源API。
• Azure Service Bus提供可靠的云消息即服务和简单的混合集成。Service Bus支持微服务应用程序中常见的异步消息传递模式。
• Azure Cache for Redis在应用程序架构中添加了一个缓存层，以提高高流量负载的速度和性能。
• Azure Monitor收集和存储指标和日志，包括应用程序遥测和Azure平台和服务指标。您可以使用这些数据来监控应用程序，设置警报和仪表板，并对故障进行根本原因分析。

其他运营支持系统（OSS）组件：

• Helm，Kubernetes的包管理器，将Kubernetes对象捆绑到一个单元中，您可以发布、部署、版本和更新。
• Azure Key Vault Secret Store CSI提供程序获取存储在Azure Key Vault中的密钥，并使用Secret Store的CSI驱动程序接口将其挂载到Kubernetes Pod中。
• Flux是Kubernetes的一个开放且可扩展的持续交付解决方案，由GitOps Toolkit提供支持。

场景详细信息

上图中显示的示例STATEDrone Delivery Shipping App实现了本文中讨论的架构组件和实践。在这个例子中，Fabrikam，股份有限公司，一家虚构的公司，管理着一支无人机机队。企业在该服务上注册，用户可以请求无人机提货。当客户安排取货时，后端系统会分配一架无人机，并通知用户估计的交货时间。在交付过程中，客户可以通过不断更新的预计到达时间跟踪无人机的位置。

潜在用例

该解决方案非常适合飞机、航空航天和航空工业。

建议

在部署高级AKS微服务架构时实施这些建议。

应用网关入口控制器（AGIC）

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

将客户端请求路由到正确的后端服务为客户端提供了一个端点，并有助于将客户端与服务解耦。

• 将多个请求聚合为一个请求，以减少客户端和后端之间的聊天。
• 从后端服务卸载SSL终止、身份验证、IP限制和客户端速率限制或节流等功能。

AKS集群的状态被转换为特定于应用程序网关的配置，并通过Azure资源管理器应用。

外部入口控制器简化了进入AKS集群的流量摄入，提高了安全性和性能，并节省了资源。此架构使用Azure应用程序网关入口控制器（AGIC）[Azure Application Gateway Ingress Controller (AGIC) ]进行入口控制。使用Application Gateway处理所有流量，无需额外的负载均衡器。由于Pod与Application Gateway建立了直接连接，因此减少了所需的跳数，从而提高了性能。

Application Gateway具有内置的自动缩放功能，这与集群中的入口控制器不同，如果它们消耗了不希望的计算资源，则必须向外扩展。Application Gateway可以执行第7层路由和SSL终止，并具有与内置web应用程序防火墙（WAF）集成的端到端传输层安全性（TLS）。

对于AGIC ingress选项，在配置AKS集群时必须启用CNI网络，因为Application Gateway部署在AKS虚拟网络的子网中。多租户工作负载或支持开发和测试环境的单个集群可能需要更多的ingress控制器。

零信任网络策略

网络策略指定了如何允许AKS Pod相互通信以及与其他网络端点通信。默认情况下，允许所有入口和出口流量进出Pod。在设计微服务之间以及与其他端点的通信方式时，请考虑遵循零信任原则，即访问任何服务、设备、应用程序或数据存储库都需要显式配置。

实现零信任策略的一种策略是创建一个网络策略，拒绝目标命名空间内所有Pod的所有入口和出口流量。以下示例显示了一个“拒绝所有策略”，该策略将应用于位于后端开发命名空间中的所有Pod。

YAML

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: default-deny-all
 namespace: backend-dev
spec:
 podSelector: {}
 policyTypes:
 - Ingress
 - Egress

一旦限制性策略到位，就开始定义特定的网络规则，以允许流量进出微服务中的每个pod。在下面的示例中，网络策略应用于后端开发命名空间中的任何pod，其标签与app.kubernetes.io/component:backend匹配。该策略拒绝任何流量，除非来自标签与app.kubernetes.io/part-of:dronedelivery匹配的pod。

YAML

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: package-v010-dev-np-allow-ingress-traffic
 namespace: backend-dev
spec:
 podSelector:
   matchLabels:
     app.kubernetes.io/component: backend
 ingress:
 - from:
   - podSelector:
       matchLabels:
         app.kubernetes.io/part-of: dronedelivery
   ports:
   - port: 80
     protocol: TCP

有关Kubernetes网络策略的更多信息和潜在默认策略的其他示例，请参阅Kubernetes文档中的网络策略。

资源配额

资源配额是管理员在开发团队或项目中保留和限制资源的一种方式。您可以在命名空间上设置资源配额，并使用它们来设置以下限制：

• 计算资源，如CPU和内存，或GPU。
• 存储资源，包括给定存储类的卷数或磁盘空间量。
• 对象计数，例如可以创建的机密、服务或作业的最大数量。

一旦资源请求或限制的累积总数超过分配的配额，就不会成功进行进一步的部署。

资源配额确保分配给命名空间的Pod总数不能超过命名空间的资源配额。前端不能耗尽后端服务的资源，反之亦然。

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

以下示例显示了设置资源配额请求和限制的pod规范：

yml

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

有关资源配额的更多信息，请参阅：

• Enforce resource quotas
• Resource quotas

自动缩放

Kubernetes支持自动缩放以增加分配给部署的Pod数量，或增加集群中的节点以增加可用的总计算资源。自动缩放是一种自校正的自主反馈系统。虽然您可以手动扩展Pod和节点，但自动扩展可以最大限度地减少服务在高负载下资源短缺的可能性。自动缩放策略必须同时考虑Pod和节点。

集群自动缩放

集群自动缩放器（CA）可缩放节点数量。假设由于资源限制而无法调度Pod；集群自动伸缩器提供更多节点。您可以定义最小数量的节点以保持AKS集群和工作负载的运行，并定义最大数量的节点用于高流量。CA每隔几秒钟检查一次挂起的Pod或空节点，并适当地扩展AKS集群。

以下示例显示了ARM模板中的CA配置：

JSON

"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"
},

ARM模板中的以下行为CA设置了示例最小和最大节点：

JSON

"minCount": 2,
"maxCount": 5,

Pod自动缩放

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

CA和HPA配合得很好，因此在您的AKS集群中启用这两个自动缩放器选项。HPA扩展应用程序，而CA扩展基础设施。

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

YAML

apiVersion: autoscaling/v2beta2
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
       targetAverageUtilization: 60

HPA查看实际消耗的资源或运行Pod的其他指标，但CA为尚未调度的Pod提供节点。因此，CA会查看pod规范中指定的请求资源。使用负载测试来微调这些值。

健康探测器

Kubernetes负载平衡了与服务标签选择器匹配的Pod的流量。只有成功启动且健康的Pod才能接收流量。如果容器崩溃，Kubernetes会删除pod并安排更换。

在Kubernetes中，pod可以暴露两种类型的健康探测：

• 活跃度探测器告诉Kubernetes吊舱是否成功启动并且健康。
• 就绪探测器告诉Kubernetes pod是否准备好接受请求。

活性探针处理仍在运行但不健康的Pod，应该回收利用。例如，如果为HTTP请求提供服务的容器挂起，则容器不会崩溃，但会停止为请求提供服务。HTTP活性探测停止响应，通知Kubernetes重新启动pod。

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

微服务应在其代码中公开端点，以促进健康探测，并根据其执行的检查专门定制延迟和超时。HPA公式几乎完全在pod的Ready阶段关闭，因此健康探测的存在和准确性至关重要。

监测

在微服务应用程序中，应用程序性能管理（APM）监控对于检测异常、诊断问题和快速了解服务之间的依赖关系至关重要。Application Insights是Azure Monitor的一部分，为用编写的实时应用程序提供APM监控。NET Core、Node.js、Java和许多其他应用程序语言。

应用洞察：

• 记录HTTP请求，包括延迟和结果代码。
• 默认情况下启用分布式跟踪。
• 在跟踪中包含操作ID，以便您可以匹配特定操作的所有跟踪。
• 通常在跟踪中包含其他上下文信息。

要将服务遥测与Kubernetes世界结合起来，请将Azure Monitor遥测与AKS集成，以从控制器、节点和容器以及容器和节点日志中收集指标。如果你正在使用。NET，Kubernetes的Application Insights库通过图像、容器、节点、pod、标签和副本集信息丰富了Application Insights遥测。

下图显示了application Insights为AKS微服务遥测跟踪生成的应用程序依赖关系图的示例：

AKS微服务应用程序的Application Insights依赖关系图示例。

有关检测通用语言以实现应用程序洞察集成的选项的更多信息，请参阅Kubernetes的应用程序监控。

注意事项

这些考虑实现了Azure良好架构框架的支柱，这是一组可用于提高工作负载质量的指导原则。有关更多信息，请参阅Microsoft Azure架构良好的框架。

可扩展性

在规划可扩展性时，请考虑以下几点。

• 不要将自动缩放和副本数量的命令式或声明式管理结合起来。用户和自动缩放器都试图修改副本数量，这可能会导致意外行为。启用HPA后，将副本数量减少到要部署的最小数量。
• pod自动缩放的一个副作用是，随着事件的发生，pod可能会被频繁创建或驱逐。为了减轻这些影响：
• 使用就绪性探测器让Kubernetes知道新pod何时准备好接受流量。
  使用pod中断预算来限制一次可以从服务中驱逐的pod数量。
• 创建集群后无法更改VM大小，因此请在创建集群时进行初始容量规划，为代理节点选择合适的VM大小。

多租户或其他高级工作负载可能具有节点池隔离要求，需要更多且可能更小的子网。有关创建具有唯一子网的节点池的详细信息，请参阅添加具有唯一子网络的节点池。组织对其中心辐射式实施有不同的标准。一定要遵循你的组织指导方针。

可管理性

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

• 通过自动化部署管道管理AKS集群基础架构。此架构的参考实现提供了一个GitHub Actions工作流，您可以在构建管道时参考。
• 工作流文件仅将基础架构而非工作负载部署到现有的虚拟网络和Microsoft Entra配置中。分别部署基础架构和工作负载可以让您解决不同的生命周期和操作问题。
• 将您的工作流视为在发生区域故障时部署到另一个区域的机制。构建管道，以便您可以在具有参数和输入更改的新区域中部署新集群。

安全

安全性提供了防止蓄意攻击和滥用您宝贵数据和系统的保证。有关更多信息，请参阅安全柱概述。

在规划安全时，请考虑以下几点。

• AKS pod通过使用存储在Microsoft Entra ID中的工作负载标识进行身份验证。最好使用工作负载标识，因为它不需要客户端密钥。
• 使用托管身份，执行进程可以快速获得Azure资源管理器OAuth 2.0令牌；不需要密码或连接字符串。在AKS中，您可以使用Microsoft Entra Workload ID为单个Pod分配标识。
• 微服务应用程序中的每个服务都应该被分配一个唯一的工作负载标识，以促进最低权限的RBAC分配。您应该只为需要标识的服务分配标识。
• 在应用程序组件需要访问Kubernetes API的情况下，请确保将应用程序pods配置为使用具有适当范围的API访问权限的服务帐户。有关配置和管理Kubernetes服务帐户的更多信息，请参阅管理Kubernetes服务账户。
• 并非所有Azure服务都支持使用Microsoft Entra ID进行数据平面身份验证。若要存储这些服务、第三方服务或API密钥的凭据或应用程序机密，请使用Azure密钥保管库。Azure密钥库提供集中管理、访问控制、静态加密以及对所有密钥和秘密的审计。
• 在AKS中，您可以将密钥库中的一个或多个密钥挂载为卷。然后，该吊舱可以像普通卷一样读取密钥库秘密。有关更多信息，请参阅GitHub上的secrets store csi驱动程序提供程序azure项目。

成本优化

成本优化是指寻找减少不必要费用和提高运营效率的方法。有关更多信息，请参阅成本优化支柱概述。

• Microsoft Azure良好架构框架中的成本部分描述了成本考虑因素。使用Azure定价计算器估算特定场景的成本。
• AKS没有与Kubernetes集群的部署、管理和操作相关的成本。您只需为集群消耗的VM实例、存储和网络资源付费。集群自动缩放可以通过删除空或未使用的节点来显著降低集群的成本。
• 要估算所需资源的成本，请参阅容器服务计算器。
• 考虑通过Kubernetes特定的构造为粒度集群基础设施成本分配启用AKS成本分析。

下一步

• Introduction to Azure Kubernetes Service
• What is Azure Virtual Networks?
• What is Azure Private Link?
• What is Azure Application Gateway?
• What is Azure Bastion?
• About Azure Key Vault
• Introduction to Azure Container Registry
• Welcome to Azure Cosmos DB
• Azure Monitor overview

• Baseline architecture for an Azure Kubernetes Service (AKS) cluster
• Design, build, and operate microservices on Azure with Kubernetes
• Microservices architecture on AKS
• Monitor a microservices architecture in AKS
• Performance tuning scenario: Distributed business transactions
• Building a CI/CD pipeline for microservices on Kubernetes