K8S低成本AI推理方案测评 2024

针对深度学习推理成本优化，一款开源工具近期展现出极高的实用价值，值得深入评估。

Karpenter 是面向 Kubernetes 集群的节点弹性供给工具，藉由 AKS Karpenter Provider 在 Azure Kubernetes Service 中实现节点生命周期自动化。其运作机制直截了当：持续监听调度器标记为“不可调度”的 Pod，解析这些 Pod 的资源请求、节点选择器、亲和性规则、容忍度以及拓扑扩散约束，按需创建最优匹配的节点，并在节点闲置时自动回收。更进一步，它还能将现有节点合并到成本更低、资源利用率更优的实例上。

这种能力最适合应用于工作负载剧烈波动、需频繁适配节点配置的场景。例如，深度学习推理任务常伴随突发性请求峰值，手工扩缩不仅效率低下，还极易导致资源过度预留或不足。Karpenter 能够将这一过程彻底自动化，精准匹配瞬时需求。

在 AKS 的 GPU 推理实践中，一个直观的策略是将 Azure Spot VM 用作工作节点。Spot 实例价格远低于按需虚拟机，但面临被回收的风险。依托 Karpenter 的自动重调度机制，该风险可有效对冲。业界主要采用两种实施方案。

策略一：多副本部署与 Spot 实例搭配

配置多个 Spot VM 作为 AKS 工作节点，并为 GPU 推理服务创建多个 Pod 副本，通过 Service 与 Ingress 实现流量负载均衡。即便单个节点被 Azure 回收，其余节点上的副本仍可继续响应请求。若业务可容忍短暂中断，仅运行单个 Pod 亦可——Karpenter 会在节点被驱逐后自动在可用节点上重建 Pod。

策略二：多节点池与权重分配

另一种做法是设立多个节点池，一个池采用 Spot 实例，另一个池使用标准 GPU 虚拟机。为各池赋予差异化的调度权重，使 GPU Pod 的 Deployment 优先调度至高权重池。这种方式能实现资源分配的精细调控，在成本与可靠性间取得平衡。

按照微软官方文档完成支持 Karpenter 的 AKS 集群部署后，进入实际验证阶段。首先创建一个 GPU Pod 的 Deployment，初始副本数设置为 1。

检查 Deployment 状态时，Pod 仍处于 0/1 未就绪状态：

kubectl get deployment
NAME          READY   UP-TO-DATE   A VAILABLE   AGE
samples-gpu   0/1     1            0           2m24s

此时 Azure 自动启动 Spot GPU 虚拟机的创建流程。通过 Karpenter 的 NodeClaims 资源可清晰追踪该过程：

kubectl get nodeclaims.karpenter.sh
NAME              TYPE                       ZONE            READY   AGE
gpu-spot-57p8w    Standard_NC24ads_A100_v4   southeastasia-2 False   2m18s

查看 Deployment 详细信息，可发现它正等待节点就绪：

kubectl describe deployment samples-gpu
...
Replicas: 1 desired | 1 updated | 1 total | 0 a vailable | 1 una vailable
...

等待约 2-3 分钟后，AKS 集群的节点列表中新增加一台 GPU 虚拟机：

kubectl get nodes
NAME                        STATUS   ROLES   AGE   VERSION
aks-gpu-spot-57p8w          Ready    agent   33s   v1.27.9
aks-nodepool1-34768744-...  Ready    agent   54m   v1.27.9
aks-nodepool1-34768744-...  Ready    agent   54m   v1.27.9
aks-nodepool1-34768744-...  Ready    agent   54m   v1.27.9

Pod 随即进入 Running 状态：

kubectl get pods
NAME                              READY   STATUS    RESTARTS   AGE
samples-gpu-95b9c58b6-nbg8g       1/1     Running   0          4m10s

登录 Pod 确认，GPU 型号确为 A100。

接下来测试横向伸缩。将 GPU Pod 的副本数增至 2：

kubectl scale deployment samples-gpu --replicas=2
kubectl get deployment
NAME          READY   UP-TO-DATE   A VAILABLE   AGE
samples-gpu   1/2     2            1           7m28s

约 1-2 分钟后，两个副本均进入就绪状态：

kubectl get deployment
NAME          READY   UP-TO-DATE   A VAILABLE   AGE
samples-gpu   2/2     2            2           11m

查看节点列表，Karpenter 自动添加了第二台 GPU 虚拟机：

kubectl get nodes
NAME                        STATUS   ROLES   AGE   VERSION
aks-gpu-spot-57p8w          Ready    agent   10m   v1.27.9
aks-gpu-spot-p9vh8          Ready    agent   3m1s  v1.27.9
aks-nodepool1-34768744-...  Ready    agent   63m   v1.27.9
aks-nodepool1-34768744-...  Ready    agent   63m   v1.27.9
aks-nodepool1-34768744-...  Ready    agent   63m   v1.27.9

检查 Karpenter 自定义资源定义，三个核心资源对象均已成功注册：

kubectl get crd | grep -i kar
aksnodeclasses.karpenter.azure.com   2024-03-24T01:18:01Z
nodeclaims.karpenter.sh              2024-03-24T01:18:01Z
nodepools.karpenter.sh               2024-03-24T01:18:01Z

此时查询 NodeClaims，两台 GPU Spot 虚拟机均显示 Ready：

kubectl get nodeclaims.karpenter.sh
NAME              TYPE                       ZONE            NODE                     READY   AGE
gpu-spot-57p8w    Standard_NC24ads_A100_v4   southeastasia-2 aks-gpu-spot-57p8w       True    15m
gpu-spot-p9vh8    Standard_NC24ads_A100_v4   southeastasia-2 aks-gpu-spot-p9vh8       True    8m11s

Azure 门户中可看到这两台 Spot 实例处于运行状态。

最后进行资源回收测试，将 Deployment 副本数直接降至 0：

kubectl scale deployment samples-gpu --replicas=0
kubectl get deployment
NAME          READY   UP-TO-DATE   A VAILABLE   AGE
samples-gpu   0/0     0            0           26m

Pod 清零后，Karpenter 自动移除对应的 GPU 节点，Azure 上的 Spot 虚拟机随之被回收。整个流程完全自动化、闭环，无需人工干预。