资讯详情

深入了解 · 专业解读

AIBrix PodAutoscaler 实战教程：基于 HPA / KPA / APA 三种策略的动态扩缩容

发布时间：2026/9/18 13:29:01
AIBrix PodAutoscaler 实战教程：基于 HPA / KPA / APA 三种策略的动态扩缩容 AIBrix PodAutoscaler 实战教程基于 HPA / KPA / APA 三种策略的动态扩缩容【免费下载链接】aibrixCost-efficient and pluggable Infrastructure components for GenAI inference项目地址: https://gitcode.com/GitHub_Trending/ai/aibrix导读本文是 AIBrix 项目官方教程 development/tutorials/podautoscaler/README.md 的完整实战讲解。AIBrix 通过自定义资源PodAutoscaler缩写 AIBrix-pa为 Kubernetes 工作负载提供统一的自适应扩缩容入口支持三种策略HPA封装 Kubernetes 原生 HorizontalPodAutoscaler、KPAKnative 风格 Pod 自动缩放含 stable/panic 双窗口与APAAIBrix 自研应用感知算法。读完本文你将掌握如何构建并运行 AIBrix Manager、如何用 CPU 指标让 Nginx 服务自动扩容、如何用 KPA/APA 基于 vLLM 模拟服务的 Prometheus 吞吐指标avg_prompt_throughput_toks_per_s驱动副本伸缩以及如何清理全部实验资源。前置准备构建 CRD 并运行 Manager教程假设你已经在本地准备好 Kubernetes 集群如 kind并完成了 AIBrix 的基础构建与安装详细步骤见根目录 README.md。进入仓库根目录cd $AIBrix_HOME安装完成后验证PodAutoscaler对应的 CRD 是否已注册kubectl get crds | grep podautoscalers预期输出# podautoscalers.autoscaling.aibrix.ai该 CRD 由 api/autoscaling/v1alpha1/podautoscaler_types.go 定义apiVersion为autoscaling.aibrix.ai/v1alpha1。从源码可见其Spec核心字段包括scaleTargetRef指向可伸缩目标如 Deployment、minReplicas/maxReplicas、metricsSources指标源列表、observeWindowSeconds/panicWindowSecondsKPA 稳定/恐慌窗口、以及枚举约束为{HPA,KPA,APA}的scalingStrategy。CRD 清单位于 config/crd/autoscaling/autoscaling.aibrix.ai_podautoscalers.yaml。方式一本地运行 Managermake run打开一个独立终端以同步方式启动 AIBrix Managermake runmake run定义在 Makefile作用是从宿主机直接运行 controller。启动成功后应看到如下日志2024-07-29T11:37:4008:00 INFO setup starting manager 2024-07-29T11:37:4008:00 INFO starting server {kind: health probe, addr: [::]:8081} 2024-07-29T11:37:4008:00 INFO controller-runtime.metrics Starting metrics server ... Starting workers {controller: podautoscaler, controllerGroup: autoscaling.aibrix.ai, controllerKind: PodAutoscaler, worker count: 1} ...调试阶段如需把集群内的服务端口暴露到本地可使用kubectl port-forward svc/llama2-70b 8000:8000 -n aibrix-system方式二构建并部署 Manager镜像方式与make run不同make deploy会把 Manager 以 Pod 形式部署进集群因而能够暴露 Manager 在 watch HPA 时可能存在的 RBAC 权限问题更接近生产形态make docker-build-controller-manager AIBRIX_CONTAINER_REGISTRY_NAMESPACEaibrix make deploy AIBRIX_CONTAINER_REGISTRY_NAMESPACEaibrix查看已部署 Manager 的日志kubectl get pods -n aibrix-system -o name | grep aibrix-controller-manager | head -n 1 | xargs -I {} kubectl logs {} -n aibrix-system如需持续跟踪日志加上-fkubectl get pods -n aibrix-system -o name | grep aibrix-controller-manager | head -n 1 | xargs -I {} kubectl logs -f {} -n aibrix-system预期输出无 warning、无 error2024-08-05T10:20:03Z INFO Starting EventSource {controller: podautoscaler, controllerGroup: autoscaling.aibrix.ai, controllerKind: PodAutoscaler, source: kind source: *v1alpha1.PodAutoscaler} 2024-08-05T10:20:03Z INFO Starting EventSource {controller: podautoscaler, controllerGroup: autoscaling.aibrix.ai, controllerKind: PodAutoscaler, source: kind source: *v2.HorizontalPodAutoscaler} 2024-08-05T10:20:03Z INFO Starting Controller {controller: podautoscaler, controllerGroup: autoscaling.aibrix.ai, controllerKind: PodAutoscaler} 2024-08-05T10:20:03Z INFO Starting EventSource {controller: modeladapter, controllerGroup: model.aibrix.ai, controllerKind: ModelAdapter, source: kind source: *v1alpha1.ModelAdapter} ... 2024-08-05T10:20:03Z INFO Starting workers {controller: podautoscaler, controllerGroup: autoscaling.aibrix.ai, controllerKind: PodAutoscaler, worker count: 1}注意日志中podautoscaler同时监听了*v1alpha1.PodAutoscaler与*v2.HorizontalPodAutoscaler两类事件源这印证了 HPA 策略的本质AIBrix 负责创建并托管原生 HPA 资源。对应的控制器入口实现位于 pkg/controller/podautoscaler/podautoscaler_controller.go其包注释明确描述了三种策略的架构HPA 为KEDA 式封装KPA/APA 则由控制器直接计算并施加缩放决策。指标源与策略模型源码视角在进入四个用例之前先补充理解PodAutoscaler的指标模型这有助于解释后面每个示例的 YAML 含义。在 podautoscaler_types.go 中定义了四类metricSourceTypepod直接从每个 Pod 的 HTTP(S) 端点抓取指标http[s]://pod_ip:port/path是模拟 Llama 用例采用的方式resource走 Kubernetes Resource Metrics API 获取 CPU、内存等资源指标custom走 Kubernetes Custom Metrics APIexternal从外部服务如gpu-optimizer获取指标。每个MetricSource还包含protocolTypehttp/https、endpoint、path、port、targetMetric与targetValue。需要留意的是GetPaMetricSources当前只支持单个指标源多于一个会返回错误。三种ScalingStrategyType常量定义于同一文件HPAKubernetes 原生 HPA、KPAKnative Pod Autoscaling 算法、APAAIBrix 自研算法。算法实现分别位于 pkg/controller/podautoscaler/algorithm/hpa.go、kpa.go 与 apa.go。Case 1基于 HPA 策略用 CPU 指标扩容 Nginx本用例部署一个 Nginx 应用并创建一个目标为Nginx Pod CPU 使用率保持在 10% 以下的 AIBrix-pa该 AIBrix-pa 会自动创建对应的原生 HPA 来完成缩放。# 创建 nginx kubectl apply -f config/samples/autoscaling_v1alpha1_demo_nginx.yaml # 创建 AIBrix-pa kubectl apply -f config/samples/autoscaling_v1alpha1_podautoscaler.yaml其中 autoscaling_v1alpha1_demo_nginx.yaml 定义了一个 1 副本的 Nginx Deploymentcpu requests: 200m、cpu limits: 500m及一个 NodePort 类型的nginx-service宿主机端口 30001。而 autoscaling_v1alpha1_podautoscaler.yaml 的核心字段为apiVersion: autoscaling.aibrix.ai/v1alpha1 kind: PodAutoscaler metadata: name: podautoscaler-example namespace: default spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: nginx-deployment minReplicas: 1 maxReplicas: 10 targetMetric: CPU targetValue: 10 scalingStrategy: HPA应用后检查资源状态kubectl get podautoscalers --all-namespaces预期输出 NAMESPACE NAME AGE default podautoscaler-example 24s kubectl get deployments.apps NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 1/1 1 1 8s由 AIBrix 级联创建的原生 HPA 也会出现kubectl get hpa预期输出 NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE podautoscaler-example-hpa Deployment/nginx-deployment 0%/10% 1 10 1 2m28s从TARGETS列为0%/10%、REPLICAS为 1 可以看出HPA 已经接管了 nginx-deployment目标就是维持 CPU 不超过 10%。HPA 资源的创建与同步逻辑可参见 pkg/controller/podautoscaler/hpa_resources.go。施压观察扩容效果使用一个简单的负载生成器持续请求 Nginx 服务kubectl run load-generator --imagebusybox -- /bin/sh -c while true; do wget -q -O- http://nginx-service.default.svc.cluster.local; doneNginx 的 CPU 使用率会随之升到 40% 以上。大约 30 秒后观察副本数增长kubectl get pods预期输出 NAME READY STATUS RESTARTS AGE load-generator 1/1 Running 0 86s nginx-deployment-5b85cc87b7-gr94j 1/1 Running 0 56s nginx-deployment-5b85cc87b7-lwqqk 1/1 Running 0 56s nginx-deployment-5b85cc87b7-q2gmp 1/1 Running 0 4m33s注意原生 HPA 的响应速度有限受其默认同步周期与稳定窗口限制AIBrix 官方计划在后续版本中对此进行优化。如果对响应速度敏感可以考虑 KPA/APA 策略。Case 2创建 KPA 策略的 AIBrix-pa已废弃该用例中 KPA 在 Nginx 上的用法已被标记为 Deprecated仅用于演示 KPA 算法的缩放行为当前推荐的 KPA/APA 场景是面向模型服务的 Case 3 / Case 4。先创建默认 1 副本的演示 Deploymentkubectl apply -f config/samples/autoscaling_v1alpha1_demo_nginx.yaml kubectl get deployments -n defaultNAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 1/1 1 1 24s创建scalingStrategy: KPA的自动缩放器kubectl apply -f config/samples/autoscaling_v1alpha1_kpa.yamlautoscaling_v1alpha1_kpa.yaml 展示了 KPA 特有的窗口参数与指标源写法apiVersion: autoscaling.aibrix.ai/v1alpha1 kind: PodAutoscaler metadata: name: podautoscaler-example-kpa namespace: default spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: nginx-deployment minReplicas: 1 maxReplicas: 10 observeWindowSeconds: 600 panicWindowSeconds: 60 metricsSources: - metricSourceType: resource targetMetric: cpu targetValue: 10 scalingStrategy: KPA确认 KPA 缩放器已创建kubectl get podautoscalers --all-namespaces NAMESPACE NAME AGE default podautoscaler-example-kpa 5m1s关键行为提示由于这里把 CPU 目标值设为 0KPA 会尝试把 Pod 缩容到 0。查看aibrix-controller-manager中KPA algorithm run...相关日志kubectl get pods -n aibrix-system -o name | grep aibrix-controller-manager | head -n 1 | xargs -I {} kubectl logs {} -n aibrix-system2024-08-28T03:52:01Z INFO Obtained selector and get ReadyPodsCount {controller: podautoscaler, ..., selector: appnginx, originalReadyPodsCount: 1} I0828 03:52:01.735190 1 kpa.go:245] Operating in stable mode. 2024-08-28T03:52:01Z INFO Successfully called Scale Algorithm {..., scaleResult: {DesiredPodCount:0,ExcessBurstCapacity:98,ScaleValid:true}} 2024-08-28T03:52:01Z INFO Proposing desired replicas {..., desiredReplicas: 0, metric: , scaleTarget: Deployment/default/nginx-deployment} 2024-08-28T03:52:01Z DEBUG events KPA algorithm run. desiredReplicas: 0, currentReplicas: 1 {..., reason: KPAAlgorithmRun} 2024-08-28T03:52:01Z INFO Successfully rescaled {..., currentReplicas: 1, desiredReplicas: 0, reason: All metrics below target} 2024-08-28T03:52:01Z DEBUG events New size: 0; reason: All metrics below target {..., reason: SuccessfulRescale}podautoscaler-example-kpa的事件kubectl describe podautoscalers podautoscaler-example-kpa会显示 KPA 成功将 Pod 缩到 0Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal KPAAlgorithmRun 2m23s PodAutoscaler KPA algorithm run. desiredReplicas: 0, currentReplicas: 1 Normal SuccessfulRescale 2m23s PodAutoscaler New size: 0; reason: All metrics below target Normal KPAAlgorithmRun 2m23s PodAutoscaler KPA algorithm run. desiredReplicas: 0, currentReplicas: 0从源码 kpa.go 可以看到 KPA 的双模式机制控制器根据最近一个短窗口panic 窗口内的指标波动决定是否进入panic modepanic 模式下只允许扩容、不允许缩容We do not scale down while in panic mode而平稳期则以stable mode运行——日志中的Operating in stable mode.正是这一逻辑的体现。observeWindowSeconds稳定窗口默认上限 3600与panicWindowSeconds恐慌窗口在 podautoscaler_types.go 中均有1~3600的校验约束。Case 3在模拟 Llama 上使用 KPA 策略启动模拟 LlamaMocked Llama 是对 vLLM 版 Llama 部署的模拟实现用于为缩放提供符合标准 Prometheus 协议的模拟指标。详细介绍见 development/app/README.md。在 Kubernetes 上部署kubectl create -k development/app/config/simulator kubectl get deployments --all-namespaces |grep llama2预期看到 3 副本就绪NAME READY UP-TO-DATE AVAILABLE AGE llama2-70b 3/3 3 3 16s本地调试时可将服务端口转发出来kubectl port-forward svc/llama2-70b 8000:8000关于模拟指标development/app/README.md 给出了一个便于测试自动缩放的设计模拟指标值与副本数成反比。1 副本时vllm:avg_prompt_throughput_toks_per_s为 100.0扩容到 5 副本后总量变为100 / 5 20这正是本用例中每个 Pod 指标维持在 20这个目标值的来源。你还可以通过/set_metrics端点动态覆盖gpu_cache_usage_perc、running、waiting等指标值方便制造不同缩放场景。创建 KPA 自动缩放器kubectl apply -f config/samples/autoscaling_v1alpha1_mock_llama.yaml kubectl get podautoscalers --all-namespacesNAMESPACE NAME AGE default podautoscaler-example-mock-llama 10s该示例的 YAML autoscaling_v1alpha1_mock_llama.yaml 引入了几个值得关注的字段apiVersion: autoscaling.aibrix.ai/v1alpha1 kind: PodAutoscaler metadata: name: podautoscaler-example-mock-llama annotations: autoscaling.aibrix.ai/max-scale-up-rate: 2 autoscaling.aibrix.ai/max-scale-down-rate: 2 autoscaling.aibrix.ai/scale-down-cooldown-window: 60s namespace: aibrix-system spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: llama2-70b minReplicas: 1 maxReplicas: 10 observeWindowSeconds: 600 panicWindowSeconds: 60 metricsSources: - metricSourceType: pod protocolType: http port: 8000 path: /metrics targetMetric: avg_prompt_throughput_toks_per_s targetValue: 20 scalingStrategy: KPA三个 annotation 分别约束最大扩容速率、最大缩容速率与缩容冷却窗口避免副本在短时间内剧烈抖动。缩放结果、日志与事件kubectl get deployments --all-namespaces |grep llama2Deployment 已被缩放到 5 副本NAME READY UP-TO-DATE AVAILABLE AGE llama2-70b 5/5 5 5 9m47s过滤 Manager 日志中的KPA关键字kubectl get pods -n aibrix-system -o name | grep aibrix-controller-manager | head -n 1 | xargs -I {} kubectl logs {} -n aibrix-system |grep KPA2024-09-04T05:58:32Z DEBUG events KPA algorithm run. currentReplicas: 5, desiredReplicas: 3, rescale: true {type: Normal, ..., reason: KPAAlgorithmRun} 2024-09-04T05:58:32Z DEBUG events KPA algorithm run. currentReplicas: 5, desiredReplicas: 5, rescale: false {type: Normal, ..., reason: KPAAlgorithmRun}缩放分析模拟 Llama 的平均 Prefill 吞吐为每秒 100 tokensavg_prompt_throughput_toks_per_s自动缩放器要维持每个 Pod 的该指标为 20。由事件可见KPA 将副本从 3 调整到 5随后在 5 副本下指标稳定rescale: false表示无需再调。这正是指标值与副本数成反比这一模拟设计驱动的典型收敛过程3 副本时单 Pod 指标约 100/3 ≈ 33.3 20需要扩容扩容到 5 副本后单 Pod 指标恰好为 20达到目标。Case 4在模拟 Llama 上使用 APA 策略启动模拟 Llama与 Case 3 相同kubectl create -k development/app/config/simulator kubectl get deployments --all-namespaces |grep llama2NAME READY UP-TO-DATE AVAILABLE AGE llama2-70b 3/3 3 3 16s创建 APA 自动缩放器如果此前已在该模拟 Deployment 上创建过其他自动缩放器先删除避免同一目标上多个自动缩放器互相干扰kubectl delete podautoscalers.autoscaling.aibrix.ai podautoscaler-example-mock-llama -n aibrix-system kubectl delete podautoscalers.autoscaling.aibrix.ai podautoscaler-example-mock-llama-apa -n aibrix-system创建scalingStrategy: APA的自动缩放器kubectl apply -f config/samples/autoscaling_v1alpha1_mock_llama_apa.yaml kubectl get podautoscalers --all-namespacesNAMESPACE NAME AGE aibrix-system podautoscaler-example-mock-llama-apa 65mautoscaling_v1alpha1_mock_llama_apa.yaml 与 KPA 版本的主要区别仅在于scalingStrategy: APA以及去掉了panicWindowSecondsAPA 不依赖 panic 窗口apiVersion: autoscaling.aibrix.ai/v1alpha1 kind: PodAutoscaler metadata: name: podautoscaler-example-mock-llama-apa namespace: aibrix-system spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: llama2-70b minReplicas: 1 maxReplicas: 10 observeWindowSeconds: 600 metricsSources: - metricSourceType: pod protocolType: http port: 8000 path: /metrics targetMetric: avg_prompt_throughput_toks_per_s targetValue: 20 scalingStrategy: APA缩放结果、日志与事件kubectl get deployments --all-namespaces |grep llama2Deployment 已被缩放到 5 副本aibrix-system llama2-70b 5/5 5 5 65m查看 APA 自动缩放器的事件可以看到完整的缩放细节kubectl describe podautoscalers podautoscaler-example-mock-llama-apa -n aibrix-systemEvents: Type Reason Age From Message ---- ------ ---- ---- ------- Normal AlgorithmRun 78s PodAutoscaler APA algorithm run. currentReplicas: 3, desiredReplicas: 5, rescale: true Normal SuccessfulRescale 78s PodAutoscaler New size: 5; reason: avg_prompt_throughput_toks_per_s above target Normal AlgorithmRun 77s PodAutoscaler APA algorithm run. currentReplicas: 5, desiredReplicas: 5, rescale: false事件中的reason: avg_prompt_throughput_toks_per_s above target表明当前单 Pod 的 Prefill 吞吐高于目标值 20因此需要扩容缩放到 5 副本后指标回落至目标附近rescale: false表示进入稳态。与 HPA 的整体比例调节不同APA 直接基于应用级指标如吞吐、KV Cache 利用率做决策其实现见 pkg/controller/podautoscaler/algorithm/apa.go并配套 apa_test.go 等单元测试保障算法正确性。清理环境卸载 AIBrix 的完整步骤请参考根目录 README.md。本教程额外创建的资源按以下命令清理# 删除 AIBrix 资源 kubectl delete podautoscalers.autoscaling.aibrix.ai podautoscaler-example kubectl delete podautoscalers.autoscaling.aibrix.ai podautoscaler-example-mock-llama -n aibrix-system kubectl delete podautoscalers.autoscaling.aibrix.ai podautoscaler-example-mock-llama-apa -n aibrix-system make uninstall make undeploy # 删除级联创建的 HPA kubectl delete hpa podautoscaler-example-hpa # 删除演示用的 Nginx Deployment 与负载生成器 kubectl delete deployment nginx-deployment kubectl delete pod load-generator kubectl delete deployment llama2-70b -n aibrix-system小结通过四个递进的用例本文完整演示了 AIBrix PodAutoscaler 的实战路径先是 HPA 策略——AIBrix 替你封装并托管原生 HPA适合快速复用 Kubernetes 既有生态再是 KPA 策略——借助 stable/panic 双窗口算法在模拟 Llama 上基于avg_prompt_throughput_toks_per_s从 3 副本收敛到 5 副本最后是 APA 策略——由 AIBrix 自研算法直接消费 Pod 级 Prometheus 指标完成应用感知的缩放。三个策略共享同一套 CRD 与控制器框架pkg/controller/podautoscaler切换只需修改scalingStrategy与metricsSources这使 AIBrix 能同时覆盖传统资源指标扩容与模型服务自定义指标扩容两类场景为 GenAI 推理服务的弹性伸缩提供了统一入口。【免费下载链接】aibrixCost-efficient and pluggable Infrastructure components for GenAI inference项目地址: https://gitcode.com/GitHub_Trending/ai/aibrix创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

相关新闻