K8S低成本AI推理方案

在深度学习推理的成本优化上，最近有个开源工具表现相当亮眼，值得认真关注。

Karpenter 是专为 Kubernetes 集群设计的节点自动配置工具，通过 AKS Karpenter Provider 在 Azure Kubernetes Service 上实现节点自动化管理。它的核心工作逻辑很清晰：持续监控被调度器标记为“不可调度”的 Pod，分析这些 Pod 的资源需求、节点选择器、亲和性、容忍度以及拓扑扩散约束，然后动态创建最匹配的节点，并在节点不再被需要时自动回收。更厉害的是，它还能把现有节点整合到更便宜、利用率更高的实例上。

那么，这种能力在什么场景下最能派上用场？简单来说，工作负载波动大、需要频繁调整节点配置的环境，就是 Karpenter 的主场。比如很多深度学习推理任务，实际使用量可能忽高忽低，传统手动扩缩不仅效率低，还容易造成资源浪费。Karpenter 正好可以把这个过程全自动化。

具体到 AKS 上的 GPU 推理场景，一个很自然的想法是把 Azure Spot VM 作为 AKS 的工作节点。Spot VM 的成本比常规 VM 低得多，但代价是有被驱逐的风险。有了 Karpenter 之后，这个风险完全可以被化解。目前主要有两种应对思路。

方案一：多副本 + Spot VM 组合

把多个 Spot VM 设为 AKS 的 Worker 节点，然后为 GPU 推理服务创建多个 Pod 副本，配合 Service 和 Ingress 来做流量分发。就算某个节点被 Azure 回收，其他节点上的副本依然能正常提供服务。如果业务能容忍短暂的瞬时中断，只跑一个 Pod 也问题不大——Karpenter 会在节点被驱逐后，自动在其他可用节点上把 Pod 重新拉起来。

方案二：多 Node Pool + 权重策略

另一种思路是创建多个 Node Pool。其中一个 Pool 使用 Spot VM，另一个使用常规的 GPU VM。然后给不同 Pool 设置不同的调度权重，让 GPU Pod 的 Deployment 优先选择权重高的 Pool。这样可以更精细地控制资源的分配策略，兼顾成本与稳定性。

参照微软官方文档把支持 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 VM：

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 查看一下，确认是 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 VM：

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 的 CRD 情况也很顺利，三个核心资源对象均已注册：

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 VM 都已就绪：

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 VM 正在运行。

最后做资源回收测试，将 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 VM 也随之被回收。整个过程自动化、闭环，不需要人工介入。