AKS GPU集群：Azure推理部署实践

CH-21-01-022·约 16 分钟·云计算与AI基础设施·更新 2026-08-12

想象你受邀管理一座智慧物流分拣中心。每天几十万件包裹涌入，普通包裹由常规分拣员处理，而需要 AI 识别的特殊包裹——比如危险品检测、人脸比对——要交给配备顶级扫描仪的高级工位。这座中心没有固定的排班表，而是根据门口传送带的实时流量，自动增开或关闭工位；所有包裹都按统一标准打包贴码，任何一件都能被全程追踪。这正是 AKS GPU 集群的运作蓝图。在微软 Azure 云上，AKS（Azure Kubernetes Service）就是这座“分拣中心”的总承包商。它把训练好的 AI 模型装进标准化的容器“包裹”，调度到带 GPU 的“高级工位”上持续运行，为线上用户提供推理服务——识别图片、理解语音、生成推荐结果。这篇文章将像参观分拣中心一样，带你从大厅（集群基础）走到设备区（GPU 配置），见到包装线（容器化部署），直面弹性调度（自动伸缩），掌握提速技巧（推理优化），最后进入中央控制室（监控与日志）。读完你就能理解：把 AI 模型从“实验室玩具”变成“生产流水线”，到底要做哪些事。

岗位关联

对云平台工程师和学习者而言，AKS GPU 集群是 AI 推理服务上云的标准路径。掌握这套部署实践，意味着你不仅能训练模型，更能让模型在真实业务中稳定、省钱、大规模地对外服务。

可视化演示
1. 集群基础——认识分拣中心
2. GPU 节点配置——为工位装备利器
3. 容器化部署——把模型打包上岗
4. 自动伸缩——高峰多开台，闲时少开台
5. 推理优化——让每个工位干得更快
6. 监控与日志——中央控制室
AI 应用场景
Python 演示
常见误区
面试题

可视化演示

展示Azure AKS GPU集群推理部署三大核心：集群架构（ACR镜像仓库+AKS集群+GPU节点池+Pod部署+负载均衡+Azure监控）、KEDA事件驱动自动伸缩（队列深度+GPU利用率→HPA→Pod数量动态扩缩）、动态批处理性能优化（请求缓冲→批次聚合→GPU并行处理→吞吐量提升对比）。

本节配有交互动效（进入视口后自动加载，约 3KB）。

GPU集群架构 ACR存储推理镜像，AKS从ACR拉取镜像部署Pod GPU节点池运行推理Pod，CPU节点处理辅助任务负载均衡分发推理请求，Azure Monitor监控GPU利用率 ACR → AKS → GPU Node → Pod → LB → Monitor AKS GPU集群是云上AI推理的标准架构。

1. 集群基础——认识分拣中心

我们的故事从分拣中心的“园区规划”说起。你作为物流园区经理，接到任务：为电商公司搭建一座专攻 AI 识别的分拣中心。你关心的是园区多大、厂房几间、怎么分区，而不是自己去砌墙拉电线。AKS 正是这样一座由 Azure 代建的“园区”——它把 Kubernetes 集群的复杂建设打包成服务，让你开箱即用。Kubernetes 是容器编排领域的“园区管理操作系统”，而 AKS 是它在 Azure 上的托管版本。在 AKS 中，“园区”就是集群（Cluster），“厂房”是节点（Node），“厂房的班组”是 Pod。集群逻辑上分为控制平面和数据平面：控制平面如同总调度室，由 Azure 自动托管，负责 API 服务、调度决策；数据平面则是真正跑模型推理的一组虚拟机。虚拟机按“节点池”（Node Pool）分组管理。普通 CPU 节点池处理常规任务，而 GPU 节点池使用 NC、ND 系列等配置了 NVIDIA 显卡的 VM，专攻深度学习推理。命名空间（Namespace）则像给不同客户划出的独立仓储区：各租户的配置、权限、资源配额完全隔离，互不干扰。宏观认识了园区，下一步要走进设备区：怎样才能让 GPU 工位真正火力全开？

\displaystyle R_{\text{total}} = N_{\text{nodes}} \times R_{\text{per node}}

节点池的总资源量等于节点数量乘以每台节点的资源规格，就像整个作业区的工位总数是工位数乘以每工位配备的设备数。

节点数量N_{\text{nodes}} 是节点池中虚拟机的台数，相当于分拣中心里工位的数量。
$N_{\text{nodes}}$
单节点规格R_{\text{per node}} 是每台节点的 CPU、内存、GPU 资源上限，如同每个工位标配的设备清单。
$R_{\text{per node}}$
乘法关系总容量 = 工位数 × 单价位容量。扩容时以节点为单位成倍增加，像园区整排加建工位。
$N_{\text{nodes}} \times R_{\text{per node}}$

2. GPU 节点配置——为工位装备利器

分拣中心最贵的资产是配备顶级 AI 扫描仪的工位。作为采购经理，你要依次完成四件事：选设备型号、接通电源、安装驱动、把设备录入中控系统。AKS 中创建 GPU 节点池也是同样的流程。

第一步选型号：Azure 提供 NC v4、NC A100 v4、ND 系列等带 NVIDIA GPU 的虚拟机。这一步决定了算力天花板，好比决定买台式扫描仪还是手持扫码枪。第二步在节点系统镜像中安装 NVIDIA 驱动：驱动是 GPU 与操作系统之间的“翻译官”，没有它，显卡只是块发热的电路板。

第三步部署 NVIDIA Device Plugin（设备插件）。它是 Kubernetes 与 GPU 硬件之间的“登记员”，负责把每张显卡的型号、显存、数量上报给调度器，让调度器知道何时能把一整张 GPU 分配给某个 Pod。第四步在部署清单中声明 resources.limits，明确请求一块 GPU，并设置合理的 Request 与 Limit，防止单个模型吞掉整卡显存，挤压其他推理任务。

设备到位后，下一步是把模型这位“员工”装进工位。下节演示如何把模型打包成标准化作业单元。

\displaystyle A_{\text{GPU}} = G_{\text{total}} - G_{\text{allocated}}

可用 GPU 数等于总量减去已占用数。就像高级扫描仪一共 10 台，5 台正执行任务，剩余可接新活的就是 5 台。

GPU 总量G_{\text{total}} 是节点池中所有 GPU 的数量，对应仓库里扫描仪的总台数。
$G_{\text{total}}$
已分配量G_{\text{allocated}} 是被 Pod 以 nvidia.com/gpu 声明占用的数量，对应正在扫描中的设备。
$G_{\text{allocated}}$
相减取差A_{\text{GPU}} 表示当前还能接新任务的 GPU 数量，调度器依据它决定能否再塞进一个推理 Pod。
$G_{\text{total}} - G_{\text{allocated}}$

3. 容器化部署——把模型打包上岗

分拣中心有条铁律：任何模型供应商送的“员工”都必须装进标准作业箱才能送上工位。Docker 镜像就是这个作业箱——它把模型权重、运行环境、依赖库全部打包，让模型在任何节点上即插即用。

构建推理镜像时，通常选定一个轻量基础镜像，加入训练好的模型权重和推理服务框架。推理服务框架如 TensorFlow Serving、NVIDIA Triton 相当于“作业手册”：它定义了模型如何接收 HTTP 请求、如何把图片文本转成张量、如何返回预测结果。Triton 还支持多模型调度、动态批处理，是生产部署的首选之一。

镜像要跑起来，还需一份 YAML“布置图”。这份 Kubernetes Deployment 清单描述副本数、容器镜像、GPU/CPU 资源申请、服务端口，以及两类健康探针：livenessProbe 存活探针检车容器有没有“猝死”，失败则自动重启；readinessProbe 就绪探针检车模型是否已加载完毕、能否接流量，失败则暂时从负载均衡摘除。它们相当于工位的“开机自检”流程。

箱子备好了，可遇到高峰包裹潮怎么办？让我们走进调度室，看看弹性伸缩如何随需编排。

\displaystyle T_{\text{cold}} = T_{\text{pull}} + T_{\text{load}}

冷启动总耗时等于镜像拉取时间加模型加载时间。它决定新扩容的 Pod 从开始创建到真正接客需要等待多久。

拉取时间T_{\text{pull}} 是把镜像从 Azure Container Registry 拉到节点并解压的时间，堪比把作业箱从仓库运到工位。
$T_{\text{pull}}$
加载时间T_{\text{load}} 是推理框架把模型权重读入显存的时间，好比工人把工具摆上操作台。
$T_{\text{load}}$
求和T_{\text{cold}} 是两者相加，直接影响自动伸缩的响应速度。镜像越小、模型加载越快，扩容越从容。
$T_{\text{pull}} + T_{\text{load}}$

4. 自动伸缩——高峰多开台，闲时少开台

分拣中心最怕“双十一”的突发包裹潮。班组长盯着一块仪表：每个工位排队变长、设备利用接近饱和，就立即呼叫预备工位；工位闲得发慌，则果断减员。AKS 中负责这项工作的叫 HPA（Horizontal Pod Autoscaler，水平 Pod 自动伸缩器）。

HPA 像班组长一样按固定周期采集 Pod 的资源指标——可以是 CPU、GPU 利用率，也可以是自定义指标（如每秒推理请求数）。它把实际值与你设定的目标值进行比较，然后按比例调整 Deployment 的副本数。核心公式如下：

不过 HPA 只能增减“工位内的人手”。如果整个园区的工位（节点）都满了，新 Pod 只能卡在 Pending 状态干等。这时需要 cluster-autoscaler（集群自动缩放器）登场：它发现 Pod 因资源不足无法调度，就自动向 Azure 申请新的虚拟机节点；当节点长期空闲，则回收节点。HPA 管 Pod，cluster-autoscaler 管节点，内外配合，奏出完整的弹性交响曲。

弹性有了，但流量依旧汹涌。一味的加机器不是最优解，还有哪些“提效妙招”？请看下节。

\displaystyle \text{desired} = \left\lceil \text{current} \times \frac{\text{metric}}{\text{target}} \right\rceil

期望副本数 = 当前副本数 ×（当前指标 ÷ 目标指标），最后向上取整。负载是目标的两倍，副本数就翻倍；负载降一半，副本数也减半。

当前指标\text{metric} 是最近一次采样到的实际负载值，如 GPU 利用率 95%，对应工位繁忙度数值。
$\text{metric}$
目标指标\text{target} 是你希望维持的负载水位，通常设 60%~70%，如目标利用率 60%。
$\text{target}$
比例放大\text{current} \times \frac{\text{metric}}{\text{target}} 将现有副本数等比缩放。繁忙两倍就多开两倍工位，清闲一半就撤掉一半人手。
$\text{current} \times \frac{\text{metric}}{\text{target}}$
向上取整\left\lceil \cdot \right\rceil 保证副本数始终是整数，且宁可多开一个也不让请求排长队。
$\left\lceil \text{current} \times \frac{\text{metric}}{\text{target}} \right\rceil$

5. 推理优化——让每个工位干得更快

工位上，扫描仪识别一件包裹耗时 1 秒。工程师试验发现：让 8 件包裹排成一列同时过机，总耗时只增加了 60%，单位时间处理的包裹却涨了好几倍。这就是批处理的魔力。

在 GPU 推理中，动态批处理（Dynamic Batching）让推理服务把短时间窗口内到达的请求攒成一捆，一次喂给 GPU 并行计算。GPU 擅长并行而非串行——单个请求无法喂饱所有计算单元，批处理能把 GPU 的每一寸算力榨干。与此同时，模型量化（Quantization）把权重从 FP32 降到 FP16 甚至 INT8：精度略降，但显存占用减半、计算速度大幅提升。这好比把笨重的大礼盒换成小巧的简装盒，单位运输成本更低。

第三个法宝是结果缓存：如果大量用户问同一个问题，系统直接把上次的答案存进缓存，命中即可返回，完全不再触碰模型，响应近乎零延迟。第四个是并发控制：给每个模型设置最大并发数，超出部分排队等待，防止突发流量瞬间把 GPU 显存打爆、引发 OOM 崩溃——如同给传送带设置最大包裹间距，避免通道堵塞。

机器全速运转时，最怕异常悄然发生。让我们进入中央控制室，学习如何盯住整座园区。

\displaystyle \text{TPT} = \frac{B}{T_{\text{batch}}}

吞吐量 = 批大小 ÷ 单批处理耗时。每批装的请求越多、单批耗时越短，单位时间完成的推理就越多。

批大小B 是每个批次包含的请求数。批越大，并行度越高，但超过一定值后延迟反而恶化。
$B$
批耗时T_{\text{batch}} 是 GPU 处理完整一批请求的秒数。批量增大时它只缓慢增长，所以吞吐上升。
$T_{\text{batch}}$
相除求吞吐\frac{B}{T_{\text{batch}}} 得到每秒可处理的批请求数。优化目标就是让 B 尽量大、T 尽量小。
$\frac{B}{T_{\text{batch}}}$

6. 监控与日志——中央控制室

控制室的墙壁上是一面巨型监控屏：每条传送带的流速、每台 GPU 的温度、每个工位的排队长度实时跳动。这就是 Azure Monitor 的 Container Insights 带给 AKS 的河景视角。

数据从哪来？Prometheus 这类指标采集器像埋在设备里的传感器，周期性抓取 CPU 利用率、GPU 利用率、显存占用、推理延迟、QPS 等指标。日志系统则记录每件“包裹”的完整流转轨迹——谁在何时调用了哪个模型，返回成功还是超时，耗时多少毫秒。在 Azure 中，这些日志汇入 Log Analytics 工作区，可用 KQL（Kusto 查询语言）灵活检索，例如筛选 5xx 错误码、计算 P99 延迟。

光有数据还不够，必须配置告警规则。GPU 利用率超过 90%、错误率超过 5%、P99 延迟超过 300 毫秒……这些阀值一旦被触发，Azure Monitor 立即通过邮件、短信或 Webhook 通知值班人员。告警正如包裹线卡壳时自动响起的呼叫铃声——问题还在萌芽，班长已经出现在故障工位前。

从大厅走到设备区，从包装线上回到调度室，最后落座中央控制室——你已经完整地参观了这座 AKS GPU“分拣中心”。上述六块拼图合起来，就是生产级 AI 推理服务的落地全景。

\displaystyle \text{Availability} = \frac{\text{Success}}{\text{Total}} = 1 - \frac{\text{Failed}}{\text{Total}}

服务可用性 = 成功请求数 ÷ 总请求数，也等于 1 减去失败率。99.9% 可用性意味着每 1000 个请求中最多 1 个失败。

成功请求\text{Success} 是统计周期内正常返回结果的请求数，相当于准时送达的包裹量。
$\text{Success}$
总请求\text{Total} 是所有进入系统的请求总数，包含成功与失败，对应包裹总量。
$\text{Total}$
可用率\frac{\text{Success}}{\text{Total}} 或 1 - \frac{\text{Failed}}{\text{Total}} 给出服务可靠度，是 SLO/SLA 的核心口径。
$1 - \frac{\text{Failed}}{\text{Total}}$

AI 应用场景

电商大促的推荐模型弹性伸缩

阶段：模型部署与自动伸缩

解决的问题：大促期间流量暴涨，传统固定 GPU 集群要么按峰值采购浪费预算，要么限流伤害用户体验。AKS 利用 HPA 与 cluster-autoscaler 组合，让资源精准跟随流量曲线。

具体案例：某电商平台在双十一期间，HPA 检测到推荐模型 GPU 利用率超过 60% 目标值且 P99 延迟上升，自动将副本数从 3 个扩容到 12 个；cluster-autoscaler 同步把 GPU 节点从 5 台加到 18 台。大促结束后 20 分钟，负载回落，系统自动缩容，该月 GPU 成本下降约 70%。

多租户大模型 API 网关

阶段：推理服务治理与可观测性

解决的问题：创业公司同时服务多个客户，每个客户调用量、预算、权限都不同。用普通裸机部署很难隔离故障、分区计费和审计追踪。

具体案例：一家人工智能公司把 Llama 与 Stable Diffusion 两套模型分别部署在两个命名空间中，为每个客户分配资源配额与调用密钥。Prometheus 按租户标签统计调用量，KQL 日志查询还原每笔调用详情，Azure Monitor 告警在某个租户异常刷量时及时拦截。

Python 演示

python34 行

# 模拟 HPA 自动伸缩：根据负载指标动态调整副本数import math  class HorizontalPodAutoscaler:    def __init__(self, initial_replicas, target_utilization):        self.replicas = initial_replicas        self.target = target_utilization     def desired_replicas(self, current_metric):        ratio = current_metric / self.target        result = math.ceil(self.replicas * ratio)        return max(1, result)     def scale(self, current_metric):        desired = self.desired_replicas(current_metric)        # 限幅：一次最多变化 2 倍，防止抖动        if desired > self.replicas * 2:            desired = self.replicas * 2        self.replicas = desired        return self.replicas  def simulate():    hpa = HorizontalPodAutoscaler(initial_replicas=2, target_utilization=60)    loads = [25, 40, 70, 95, 110, 80, 45, 30]    print("load%  replicas")    for load in loads:        replicas = hpa.scale(load)        print(f"{load:6.1f}  {replicas:4d}")  if __name__ == "__main__":    simulate()

目的：演示 HPA 的核心算法——根据当前负载与目标值的比值，按比例调整副本数并加上限幅保护。

ratio = current_metric / self.target计算当前负载与目标利用率的比值，>1 表示需要扩容，<1 表示可以缩容。
result = math.ceil(self.replicas * ratio)按比例缩放并向上取整，保证副本数是个够用的整数。
return max(1, result)副本数下限为 1，避免缩到零导致服务不可用。
if desired > self.replicas * 2:限制单次最大扩 2 倍，防止指标抖动引发副本数的剧烈震荡。
self.replicas = desired更新当前副本数，供下一轮采样继续计算。
hpa.scale(load)模拟每个采样周期触发一次伸缩计算，就像班组长每隔几秒看一眼繁忙度仪表。

常见误区

误区我在 AKS 里创建了带 GPU 的节点池，部署 Pod 时加上 `nvidia.com/gpu` 字段应该就能跑起来了。

正解节点池创建后还要安装 NVIDIA 驱动，并在集群中部署 NVIDIA Device Plugin 设备插件。驱动让操作系统认识显卡，插件则把显卡信息上报给 Kubernetes 调度器。缺了插件，调度器以为节点上没有 GPU，Pod 永远调度不上。

为何常见：Azure 创建 GPU 节点池时通常预装了驱动，容易让人误以为插件也一并配好了——实际上插件要单独部署。

误区HPA 名字叫“自动伸缩”，既然它能把副本数从 3 扩到 30，节点不够时它肯定也会顺手加几台虚拟机。

正解HPA 只调整 Deployment 的副本数，它会下达“多开几个 Pod”的指令；把这些 Pod 放到哪台机器上，是调度器的事。如果节点资源已被耗尽，新 Pod 会卡在 Pending 状态，必须由 cluster-autoscaler 检测到 Pending 后去 Azure 申请新节点加入集群。

为何常见：两个组件名称里都有"autoscaler"，且实际生产中常配合使用，让人误以为它们是同一个功能的两面。

误区所有模型都可以直接量化到 INT8，精度掉了就怪量化不好，不如加大显存堆 GPU。

正解量化效果因模型而异。稳妥路径是先用 FP16 减半显存，再用校准数据集评估 INT8 的精度损失，若在可接受范围内才上线。与此同时，动态批处理和结果缓存往往带来比量化更大的吞吐提升，应组合使用。

为何常见：量化是业界热门词汇，容易让人忽略它只是推理性价比工具箱中的一件工具，而非银弹。

误区Kubernetes 里默认的监控面板都是 CPU 和内存，GPU 使用情况看不看无所谓，反正模型能跑就行。

正解GPU 是推理集群里最贵的单点资源。必须监控 GPU 利用率、显存占用、温度、时钟频率。一个健康的推理服务应当是 GPU 几乎打满而 CPU 相对轻松——这说明算力真正被榨干了；反之则是代码或批处理策略有问题。

为何常见：对 GPU 计算不熟悉的人，容易沿用传统 CPU 监控的思维惯性，忽略“加速卡”才是价值所在。

误区为了避免资源竞争，我把 CPU、内存、GPU 的 Request 和 Limit 全都设成相同值，这样总该稳定了吧。

正解Request 是调度依据，Limit 是运行时硬上限。GPU 必须同时设置两者；CPU 设成相等可以防止超卖，但内存如果 Request 设得过大，会让调度器误以为集群很满，导致本该缩容的节点迟迟不回收。合理做法是结合真实负载画像分别设定。

为何常见：生产模板里常见 request=limit 的写法，很多人不深究其适用条件，直接照搬到 GPU 推理场景。

面试题

Q1. AKS 的 Kubernetes 控制平面由谁负责运维？

单选题 · easy

A.用户自建的虚拟机
B.Azure 托管服务← 正确答案
C.第三方监控系统
D.本地数据中心

答案：B。AKS 全称 Azure Kubernetes Service，控制平面（API Server、调度器等）由 Azure 托管，用户只需管理节点池和业务负载。其他选项描述的是自建 Kubernetes 或无关组件。

Q2. 下列哪种节点池最适合运行深度学习推理任务？

单选题 · easy

A.标准 CPU 节点池
B.GPU 高性能节点池← 正确答案
C.存储优化节点池
D.内存优化节点池

答案：B。GPU 高性能节点池（如 NC、ND 系列）搭载 NVIDIA 显卡，专为并行计算设计，是深度学习推理的算力基础。CPU 节点池速度太慢，存储/内存优化节点池侧重 IO 与容量而非算力。

Q3. NVIDIA Device Plugin 在 AKS 中的主要作用是什么？

单选题 · mid

A.提高 GPU 计算频率
B.感知并分配 GPU 设备← 正确答案
C.自动升级驱动版本
D.压缩模型加载时间

答案：B。Device Plugin 是 Kubernetes 与 GPU 硬件间的“登记员”，把 GPU 资源上报给调度器并支持按需分配。它不负责超频、驱动升级或模型加速，那些是其他组件的工作。

Q4. HPA 计算目标副本数的正确公式是？

单选题 · mid

A.ceil(current × target / metric)
B.ceil(current × metric / target)← 正确答案
C.floor(current × metric / target)
D.current + metric / target

答案：B。HPA 的公式是 desired = ceil（当前副本数 × 当前指标 / 目标指标）。负载是目标的 2 倍则副本翻倍；选项 A 分子分母颠倒，C 用向下取整可能缩水，D 不符合比例放大逻辑。

Q5. 以下哪些措施可以提升 AKS 上的推理吞吐量？

多选题 · mid

A.动态批处理提速← 正确答案
B.模型量化 FP16← 正确答案
C.提高 GPU 资源限额
D.推理结果缓存← 正确答案

答案：ABD。动态批处理把多个请求打包一次计算，量化减少显存和计算量，缓存直接命中返回、绕开模型，三者都能显著提升吞吐。“提高 GPU 资源限额”只是放宽上限，并不会让单次推理变快，反而可能造成资源浪费。

Q6. 当 HPA 扩容后的 Pod 一直处于 Pending 状态，最可能的原因是什么？

单选题 · hard

A.镜像拉取失败
B.节点资源不足← 正确答案
C.配额设置限制
D.探针配置错误

答案：B。Pending 表示调度器找不到满足资源需求的节点，说明节点池已满，需要 cluster-autoscaler 申请新节点。镜像失败会表现为 ImagePullBackOff，配额限制通常是创建时被拒，探针错误则表现为 CrashLoopBackOff 或未就绪。

Q7. 关于 cluster-autoscaler 与 HPA 的配合，下列说法正确的是？

多选题 · hard

A.扩缩 Pod 数量← 正确答案
B.扩缩 Node 数量← 正确答案
C.两者互不相干
D.清除 Pending 调度← 正确答案

答案：ABD。HPA 负责扩缩 Pod 副本数，cluster-autoscaler 负责扩缩节点数，且后者会通过处理 Pending Pod 来触发扩容。两者分工明确、需要协同，说“互不相干”是错误理解。

Q8. AKS 中 Namespace 的作用类似于分拣中心的？

单选题 · easy

A.流水线传送带
B.客户独立仓储区← 正确答案
C.园区内停车场
D.员工食堂餐厅

答案：B。Namespace 提供逻辑隔离，让不同团队或客户拥有独立的资源配额、权限和对象边界，形同分拣中心中为不同客户划分的独立仓储区。传送带、停车场、食堂没有隔离与配额的含义。

Q9. 若容器存活探针 livenessProbe 检查失败，Kubernetes 会怎样处理？

单选题 · mid

A.将流量从 Pod 摘除
B.自动重启故障容器← 正确答案
C.仅发出告警通知
D.将故障节点删除

答案：B。livenessProbe 判断容器是否存活，失败即认为进程卡死，Kubelet 会重启容器。而“将流量摘除”是 readinessProbe 的行为；仅告警和删除节点都不是默认处理方式。

Q10. 在 Azure 上监控 AKS GPU 集群可以使用的工具包括？

多选题 · hard

A.Azure Monitor 平台← 正确答案
B.Prometheus 与 Grafana← 正确答案
C.Log Analytics 的 KQL← 正确答案
D.Azure 镜像仓库 ACR

答案：ABC。Azure Monitor 提供容器监控看板，Prometheus + Grafana 采集可视化指标，Log Analytics 的 KQL 用于检索容器日志。ACR 是镜像仓库，负责存 Docker 镜像，不具备监控与日志分析能力。