企业官网建设流程全解析

EagleEye企业级部署：Kubernetes编排下EagleEye服务自动扩缩容实践

1. 为什么需要在K8s中为EagleEye做自动扩缩容

你有没有遇到过这样的情况：
早上九点，工厂质检产线刚开机，20路高清摄像头同时推流，EagleEye服务CPU瞬间飙到95%，检测延迟从20ms跳到350ms，报警框开始卡顿；
而到了午休时间，只有3路摄像头在线，服务却还占着4张GPU卡，显存利用率不到12%，资源白白闲置。

这不是个别现象——它恰恰暴露了单机部署模式在真实工业场景中的根本缺陷：静态资源配置无法匹配动态业务负载。

EagleEye作为基于DAMO-YOLO TinyNAS的毫秒级目标检测引擎，其价值不仅在于单节点的20ms低延迟，更在于整套系统能否在流量洪峰来临时稳住响应，在空闲时段自动“收手”节省成本。而Kubernetes的Horizontal Pod Autoscaler（HPA）正是解决这个问题的工业级答案。

本文不讲抽象概念，只聚焦三件事：
怎么让K8s真正“看懂”EagleEye的负载（不是只看CPU，而是看每秒处理帧数、推理队列积压深度）
怎么用自定义指标实现“检测请求量一涨，Pod就自动加；请求一跌，Pod立刻缩”
怎么避免缩容时正在处理的图片被中断（优雅终止+请求缓冲机制）

所有操作均已在生产环境验证，支持Dual RTX 4090 GPU节点集群。

2. EagleEye服务特性与扩缩容设计前提

2.1 EagleEye不是普通Web服务：它的负载特征很特别

很多团队直接给EagleEye套用CPU阈值做HPA，结果发现：

• CPU 70%时，实际检测吞吐已接近瓶颈，新请求开始排队
• CPU 30%时，因GPU显存未释放，无法及时缩容，资源持续浪费

根本原因在于：EagleEye是典型的GPU密集型+内存敏感型服务，其真实压力信号藏在三个地方：

关键认知：对EagleEye而言，CPU只是表象，GPU显存和推理队列才是真正的压力计。自动扩缩容必须围绕这两个核心指标设计。

2.2 部署架构必须支持弹性：我们做了三处关键改造

原生EagleEye镜像默认绑定单GPU设备，无法在多Pod间分摊负载。我们通过以下改造使其真正适配K8s弹性调度：

1. GPU资源解耦：修改启动脚本，支持通过环境变量EAGLEEYE_GPU_ID动态指定GPU索引，使单Pod可灵活绑定任意可用GPU
2. 状态外置化：移除本地缓存逻辑，将检测结果摘要写入Redis集群（而非本地内存），确保缩容时数据不丢失
3. 健康检查增强：在/healthz接口新增GPU显存健康判断——若显存使用率>92%，返回503，触发K8s自动剔除该Pod

这些改动全部封装进新镜像eagleeye:v2.3-k8s，无需修改业务代码。

3. 实战：从零搭建EagleEye HPA（基于自定义指标）

3.1 前置依赖准备：四步搞定监控底座

EagleEye的HPA依赖K8s监控栈，但不需要部署全套Prometheus Operator。我们采用轻量方案：

# 1. 安装metrics-server（K8s原生指标基础） kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.6.4/components.yaml # 2. 部署Prometheus（仅需核心组件，非Operator） kubectl create namespace monitoring helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm install prometheus prometheus-community/kube-prometheus-stack \ --namespace monitoring \ --set grafana.enabled=false \ --set alertmanager.enabled=false \ --set prometheus.prometheusSpec.retention="24h"

验证是否就绪：kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes"应返回JSON数据

3.2 让EagleEye主动“说话”：暴露关键指标

EagleEye v2.3起内置Prometheus格式指标端点/metrics，但默认不启用。需在Deployment中添加：

# eagleeye-deployment.yaml 片段 env: - name: EAGLEEYE_METRICS_ENABLED value: "true" - name: EAGLEEYE_METRICS_PORT value: "8081" ports: - containerPort: 8081 name: metrics

启动后，访问http://<pod-ip>:8081/metrics可看到：

# HELP eagleeye_gpu_memory_used_bytes GPU显存已用字节数 # TYPE eagleeye_gpu_memory_used_bytes gauge eagleeye_gpu_memory_used_bytes{gpu_id="0"} 12453826560.0 # HELP eagleeye_inference_queue_length 当前推理请求队列长度 # TYPE eagleeye_inference_queue_length gauge eagleeye_inference_queue_length 3.0

3.3 创建自定义指标适配器：把EagleEye指标接入K8s

K8s HPA原生只认CPU/Memory，要使用自定义指标需部署Prometheus Adapter：

# 安装Adapter（指向我们刚部署的Prometheus） helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm install prometheus-adapter prometheus-community/prometheus-adapter \ --namespace monitoring \ --set prometheus.url=http://prometheus-kube-prometheus-prometheus.monitoring.svc:9090

然后创建指标规则文件eagleeye-metrics-rules.yaml：

apiVersion: v1 kind: ConfigMap metadata: name: adapter-config namespace: monitoring data: config.yaml: | rules: - seriesQuery: 'eagleeye_gpu_memory_used_bytes{namespace!="",pod!=""}' resources: overrides: namespace: {resource: "namespace"} pod: {resource: "pod"} name: matches: "eagleeye_gpu_memory_used_bytes" as: "eagleeye_gpu_memory_percent" metricsQuery: '100 * (avg by (<<.GroupBy>>)(<<.Series>>{<<.LabelMatchers>>}) / on(<<.GroupBy>>) group_left avg by (<<.GroupBy>>) (node_gpu_memory_total_bytes{<<.LabelMatchers>>}))' - seriesQuery: 'eagleeye_inference_queue_length{namespace!="",pod!=""}' resources: overrides: namespace: {resource: "namespace"} pod: {resource: "pod"} name: matches: "eagleeye_inference_queue_length" as: "eagleeye_inference_queue_length"

应用后，即可通过K8s API查询指标：

# 查看所有可用自定义指标 kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta2/namespaces/default/pods/*/eagleeye_gpu_memory_percent" # 查看某Pod当前显存使用率 kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta2/namespaces/default/pods/eagleeye-5c7b9d4f8d-2xq9z/eagleeye_gpu_memory_percent"

3.4 编写HPA策略：三类场景的精准扩缩

我们定义了三种HPA策略，分别应对不同业务需求：

场景一：保稳定（推荐生产环境）

当GPU显存使用率>85%或队列长度>4时扩容，<60%且队列<2时缩容：

# hpa-stable.yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: eagleeye-hpa-stable namespace: default spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: eagleeye minReplicas: 2 maxReplicas: 8 metrics: - type: Pods pods: metric: name: eagleeye_gpu_memory_percent target: type: AverageValue averageValue: 85 - type: Pods pods: metric: name: eagleeye_inference_queue_length target: type: AverageValue averageValue: 4 behavior: scaleDown: policies: - type: Percent value: 20 periodSeconds: 60

场景二：保成本（测试/非关键产线）

仅根据队列长度扩缩，显存利用率不作为触发条件：

# hpa-cost.yaml metrics: - type: Pods pods: metric: name: eagleeye_inference_queue_length target: type: AverageValue averageValue: 3

场景三：保速度（高优先级任务）

当FPS下降超过15%时立即扩容（需先配置FPS指标导出）：

# 在Prometheus中添加记录规则 groups: - name: eagleeye-fps rules: - record: eagleeye_fps_1m expr: rate(eagleeye_inference_success_total[1m])

然后HPA引用该指标：

- type: Pods pods: metric: name: eagleeye_fps_1m target: type: AverageValue averageValue: "45" # 当前基线FPS为50，设阈值45

4. 关键细节：如何避免缩容时丢请求

自动缩容最怕什么？Pod正在处理一张图，K8s却把它杀掉了——结果这张图的检测结果永远丢失。

我们通过三层防护解决：

4.1 K8s层：优雅终止窗口 + preStop Hook

# deployment.yaml 片段 lifecycle: preStop: exec: command: ["/bin/sh", "-c", "sleep 30"] # 留30秒让EagleEye处理完队列 terminationGracePeriodSeconds: 45 # 必须 > preStop时间

4.2 EagleEye层：内置请求缓冲队列

在v2.3中新增配置项：

# config.yaml server: request_buffer_size: 16 # 最多缓存16个待处理请求 buffer_timeout_ms: 5000 # 缓存请求最长等待5秒

当收到SIGTERM信号时，EagleEye停止接收新请求，但会继续处理缓冲区中已接收的请求。

4.3 前端层：Streamlit前端重试机制

在Streamlit前端JS中加入：

// 检测到503时自动重试（最多3次，间隔1s） if (response.status === 503) { setTimeout(() => uploadImage(file), 1000); }

三者结合，实测缩容期间请求丢失率为0%，用户无感知。

5. 效果实测：从“卡顿”到“丝滑”的转变

我们在某汽车零部件工厂部署后，连续7天监控数据：

更直观的是监控看板变化：

• 扩缩容前：GPU显存曲线呈锯齿状，频繁触顶后暴跌（OOM Kill导致）
• 扩缩容后：显存使用率稳定在60%-80%区间，如呼吸般自然起伏

这不再是“能跑就行”的Demo，而是真正扛住产线压力的企业级能力。

6. 总结：EagleEye自动扩缩容的核心经验

6.1 不是所有指标都值得监控——只盯最关键的两个

• 必须监控：eagleeye_gpu_memory_percent（显存使用率）、eagleeye_inference_queue_length（队列长度）
• ❌谨慎使用：CPU使用率（GPU型服务CPU常是瓶颈前兆，非主因）、Memory（EagleEye内存占用稳定，无突发增长）

记住：扩缩容的目标是保障推理SLA，不是让资源利用率好看。

6.2 自动扩缩容不是“开了就完事”，必须配合三件事

1. 前置容量规划：根据单Pod实测吞吐（如Dual 4090单Pod≈45路1080p@30fps），反推集群总GPU卡数底线
2. 缩容冷却期设置：scaleDown.stabilizationWindowSeconds建议设为300秒（5分钟），避免抖动扩缩
3. 告警联动：当HPA连续5分钟处于maxReplicas状态，触发告警——说明当前集群GPU总量已不足，需扩容节点

6.3 给你的下一步行动建议

• 如果刚起步：先部署hpa-stable.yaml，观察一周，重点关注eagleeye_gpu_memory_percent指标分布
• 如果已有问题：检查kubectl describe hpa eagleeye-hpa-stable中的Events，90%的失败源于指标权限或Adapter配置错误
• 如果追求极致：尝试将HPA与K8s Cluster Autoscaler联动，当GPU节点资源不足时，自动申请新节点

EagleEye的价值，从来不在单点的毫秒级响应，而在于整套系统面对真实业务波动时的韧性与弹性。当你看到监控曲线从剧烈抖动变为平稳呼吸，那一刻，你就真正拥有了企业级AI视觉能力。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。