先说个结论视频AI中台这事儿真正难的从来不是AI模型本身而是视频接入、算力调度、镜像交付这一整条链路怎么拧成一股绳。我这大半年都泡在一个基于GB28181/RTSP接入的视频AI中台项目里从最开始用脚本硬怼10路摄像头到最后在K8s集群上跑几十路视频流加上多套AI算子中间踩过的坑、推翻的方案足够写满好几页笔记。这篇文章我就以亲历者的身份把整个项目的架构演进过程掰开揉碎了讲。内容包括为什么一定要上Docker多架构镜像、GB28181和RTSP两种接入方式在真实项目里怎么取舍、K8s弹性调度到底怎么设计才不会被流量打崩以及监控告警体系怎么搭才不变成摆设。同时会把埋点、镜像构建、调度参数、告警规则这些具体的实操细节一并放出来给正在做同类项目或者准备入坑的朋友一些参考。1. 项目背景与整体思路为什么是“Docker K8s GB28181/RTSP AI”这套组合1.1 项目的真实痛点视频接入冷启动与算力碎片化先说背景。我所在的团队接到的任务是把公司分散在不同业务里的视频能力收拢成一个统一的中台。这个中台要能做到三件事对接不同厂商的摄像头和NVR把视频流统一汇聚起来再叠加AI分析能力比如人脸、车辆、行为识别输出结构化结果。听起来挺常规的但真正动手调研才发现问题比想象的多。第一设备接入协议极其混杂。手头有海康威视的摄像头支持GB28181国标注册也用RTSP拉流有第三方厂商的设备只给了RTSP地址但地址里带了一串动态token过期就失效还有一部分老旧的NVR只能通过GB28181被动注册等待设备主动上报。接入层如果做不好后面AI分析就是空谈。第二算力碎片化严重。公司内部既有x86服务器也有刚采购的ARM架构机器还有几块GPU卡插在旧机器上。不同架构、不同指令集、不同加速卡导致同一份代码打包成镜像后并不能在所有机器上跑。第三流量峰值难预测。视频AI中台的特点是平时业务量平稳但一旦某个客户搞大型活动或者某个区域发生异常事件视频路数会瞬间暴涨。如果按照峰值去采购服务器平时资源就白白浪费了如果不按峰值设计临时扩容又跟不上。这三个痛点叠加在一起决定了我们最终的技术选型用Docker解决镜像交付的一致性用K8s解决算力调度和弹性伸缩用GB28181/RTSP双协议解决设备接入的兼容性。1.2 技术选型的三个关键决策先说Docker。为什么不是虚拟机不是裸机部署核心原因是交付物的一致性。视频接入服务和AI推理服务依赖的环境很复杂FFmpeg的版本、OpenCV的依赖、GPU驱动、CUDA版本任何一个不对劲都可能导致服务起不来。用Docker把整个运行环境固化到镜像里开发、测试、生产环境保持完全一致这是我们最快能见效的决策。接着是K8s。说实话小规模项目直接docker-compose就够了。但视频AI中台一旦上了规模就需要自动伸缩、故障转移、滚动更新这些能力。K8s的调度模型天然适合这种场景把视频接入服务、AI推理服务、流媒体网关全都声明成Pod交给调度器去分配资源。最后是GB28181和RTSP两条腿走路。很多项目一开始只想支持RTSP因为拉流简单一个URL就能搞定。但实际对接中就发现国标设备尤其是海康那种大厂设备在跨网段、跨平台对接时GB28181注册模式要比RTSP稳定得多。反过来一些私有化部署的客户又只愿意给RTSP地址。所以接入层必须同时支持两种协议不能押宝在单一方案上。1.3 中台总体架构的演进路线整个中台分成四层接入层负责GB28181注册和RTSP拉流统一把视频流转成内部格式这个环节我们用ZLMediaKit做核心流媒体网关配合FFmpeg做转封装和拉流兜底。推理层负责跑AI算子人脸检测、车牌识别、行为分析等。每个算子被封装成独立的推理服务通过消息队列订阅视频帧或视频片段。调度层K8s集群统一管理所有服务的生命周期通过HPAHorizontalPodAutoscaler做弹性伸缩通过节点亲和性调度把推理任务分配到带GPU的节点上。监控层Prometheus负责采集指标Grafana做可视化Alertmanager负责告警。不把监控做好弹性调度和故障排查都是盲人摸象。下面我会按照从镜像到接入、再从调度到监控的顺序把每一层的落地细节都讲清楚。2. 多架构镜像构建Docker作为交付基座的技术细节2.1 为什么必须搞定多架构镜像先说说多架构镜像这个问题是怎么冒出来的。项目里有一批ARM架构的服务器主要用于边缘节点部署低功耗、机架密度高。但是AI算子里有一部分依赖的第三方库只发布了x86版本导致同一份Dockerfile在x86上构建没问题到了ARM上就报错。反过来有些跑在ARM上的轻量级服务放到x86上虽然也能跑却会白白浪费性能。如果在部署时手动区分架构逐个节点去构建镜像那运维成本就失控了。我们急需一套机制构建一次镜像推到镜像仓库后K8s节点拉取时能自动匹配本机架构。这个机制在Docker里叫做多架构镜像multi-arch image本质是利用manifest list在镜像名后面关联多个不同平台的镜像变体。打个比方平时我们下载安装包时会看到“Windows版”“macOS版”“Linux版”的区分多架构镜像就像把这三个安装包装进一个下载入口下载时自动识别你的系统给你分发对应的版本。K8s节点在拉取镜像时就是这么干的根据节点的操作系统和CPU架构自动选择对应的镜像变体。2.2 用buildx一次构建多平台镜像构建多架构镜像用得最多的工具是Docker Buildx它是Docker官方提供的构建插件底层用BuildKit完成构建。关键命令如下# 创建多架构构建器 docker buildx create --name multiarch-builder --driver docker-container --use # 查看可用的构建器 docker buildx ls # 构建并推送多架构镜像 docker buildx build --platform linux/amd64,linux/arm64 \ -t registry.example.com/video-ai-middleware:1.2.0 \ --push .这里有个注意点普通的Docker构建器只能构建当前宿主机架构的镜像必须使用docker-container驱动模式才能跨架构构建。而且构建过程中如果镜像里有RUN指令执行编译操作比如编译FFmpeg构建器需要能模拟目标架构的执行环境QEMU是默认的模拟方案。构建时如果发现某些平台失败先检查是不是QEMU没有注册到位# 注册binfmt模拟器 docker run --privileged --rm tonistiigi/binfmt --install all实际项目中我们的AI推理镜像因为要装CUDA和OpenCV单次构建可能要跑十几分钟。为了提速BuildKit的缓存机制要好好用起来。比如把包安装、依赖下载这些不经常变的步骤放在Dockerfile的前面保证缓存命中把代码COPY放在后面这样代码每次更新时不需要重装依赖。2.3 Dockerfile优化减少镜像体积与构建时间多架构镜像每多一个平台镜像仓库里就会多一份变体如果镜像本身体积很大拉取时间会严重影响Pod冷启动速度。我们在优化镜像体积上做了三件事第一尽量用精简基础镜像。能选alpine就不用ubuntu能选slim版本就不用完整版。对于视频流处理和AI推理alpine有时候会缺底层库用debian:slim会更稳妥但体积也比完整版小很多。第二使用多阶段构建。编译阶段用带完整工具链的镜像运行阶段只拷贝编译产物和必要依赖。# 编译阶段 FROM golang:1.20 AS builder WORKDIR /app COPY . . RUN CGO_ENABLED0 GOOSlinux go build -o stream-gateway . # 运行阶段 FROM alpine:3.18 RUN apk add --no-cache ca-certificates tzdata COPY --frombuilder /app/stream-gateway /usr/local/bin/stream-gateway ENTRYPOINT [stream-gateway]第三不要把所有工具都装进同一个镜像。流媒体网关和AI推理服务拆开部署各用各的镜像而不是打一个大而全的“全家桶”镜像。2.4 镜像仓库与拉取策略的配置多架构镜像推送到镜像仓库后K8s节点侧需要启用正确的拉取策略。我们用的是阿里云ACR作为镜像仓库支持多架构manifest拉取时Docker会自动按节点架构选择对应变体。在K8s的Deployment中可以不指定具体的架构但建议加上镜像拉取策略containers: - name: stream-gateway image: registry.example.com/video-ai-middleware:1.2.0 imagePullPolicy: IfNotPresent如果镜像版本更新频繁建议把imagePullPolicy设为Always否则节点可能复用本地缓存的旧镜像。我踩过这个坑改了镜像tag但忘了改部署配置结果新代码没生效排查了半天才发现是拉取策略的问题。3. GB28181与RTSP接入让每一路视频都进得来、出得去3.1 GB28181协议与RTSP协议的定位差异接入层是整个视频AI中台的咽喉但很多人对GB28181和RTSP的关系搞不清楚。这里我用自己的经验捋一下。RTSPReal Time Streaming Protocol是一种流媒体控制协议负责建立和控制流媒体会话底层一般跑RTP传输音视频数据。可以理解成“你给播放器一个URL播放器发起请求服务器回传一路流”适合点对点拉流。很多摄像头和NVR都支持RTSP但它的问题是需要知道设备的IP、端口、用户名、密码而且设备主动推流的能力不太强。GB28181是国内安防行业的标准协议定位和RTSP不一样。GB28181定义了设备如何注册到平台、平台如何向设备发起邀请取流、设备如何主动推送告警信息等完整流程。它更像一个“注册-邀请-取流”的会话体系摄像头主动向SIP服务器注册平台收到注册后下发指令设备再通过RTP把视频流推到指定端口。在项目里这两种协议是并存的使用场景也分得很清楚维度GB28181RTSP设备发现设备主动注册平台被动接收需要手动获取URL无法自动发现跨网段支持很好适合跨公网对接受端口映射、NAT影响较大语音对讲通过SIP信令实现比较成熟实现需要额外的RTSP扩展支持拉流稳定性高设备注册后平台可以反复邀请取流相对简单但token过期或密码变动容易断流适用厂商海康、大华等国内厂商普遍支持几乎所有厂商都支持举个具体的例子我们对接海康威视摄像头时如果走GB28181接入只需要在摄像头管理界面配置SIP服务器地址和设备编号摄像头注册上来之后平台就可以维护一个稳定的设备列表。但如果是通过海康的RTSP地址拉流地址里通常带用户名密码如果摄像头密码改了RTSP流就会断排查起来非常麻烦。3.2 流媒体网关选型ZLMediaKit还是Mediamtx接入层需要有流媒体网关来接收、转发视频流。市面常见的开源方案有ZLMediaKit和Mediamtx原RTSP-Simple-Server。我们最终选了ZLMediaKit作为主力原因有几个第一GB28181支持成熟。ZLMediaKit原生支持GB28181协议的SIP信令处理设备注册、邀请取流、语音广播和对讲都有对应的接口。对比之下Mediamtx更偏向RTSP/RTMP/WebRTC这些常见的流媒体协议对GB28181没有内置支持需要额外开发信令模块。第二ZLM的RTP被动接收能力强。GB28181设备在收到平台的INVITE指令后会把RTP流推到平台指定的端口ZLM对TCP/UDP两种RTP传输模式都支持得很好。我们在实际压测中发现ZLM同时接收几十路不同设备的RTP推流稳定性和丢包率都控制得不错。第三HLS/WebRTC输出能力完善。AI分析后的视频结果需要给前端平台展示ZLM可以直接把内部流转成HLS或WebRTC流前端网页不用安装插件就能播放。Mediamtx也不是一无是处。它部署极其轻量一个二进制文件搞定非常适合边缘节点。我们在某些边缘场景下用Mediamtx做RTSP拉流再转WebRTC输出配合FFmpeg拉流兜底效率很高。但作为GB28181的核心网关它扛不起来。3.3 GB28181接入的完整流程GB28181接入流程分成几步SIP服务启动监听埠和端口。ZLM会启动一个SIP UDP服务默认监听5060端口。设备侧配置SIP服务器IP、端口、设备ID。我们在海康摄像头的配置页面填入平台侧的SIP信息摄像头会主动发送REGISTER请求。平台侧收到REGISTER请求后返回200 OK设备显示已注册。此时设备处于“在线待命”状态。平台需要取流时向设备发送INVITE请求携带媒体描述session description告诉设备把流推到哪个IP的哪个端口。设备回复200 OK并发送RTP流到指定端口ZLM开始收流。平台可以对这个通道进行播放、录制、AI分析。整个流程里最容易出问题的是SIP端口和设备编号配置。SIP协议用UDP传输如果设备所在网络对UDP有限制注册就会失败。另外设备编号20位数字有严格的编码规则中心编码、行业编码、类型编码、序号编码都不能乱填填错了摄像头注册时会返回错误码。3.4 RTSP拉流与推流用ffmpeg处理不规范的流虽然GB28181是主流但总有客户不按套路出牌。有些第三方设备只提供RTSP地址有些地址有效期很短需要定时拉取。这时我们就要做RTSP接入。我们的接入策略很简单先用Mediamtx或ZLM内置的拉流代理去拉取RTSP源再把流统一转换成内部格式。如果设备地址非常规比如需要携带自定义请求头或者加密认证就写一个专用的FFmpeg拉流脚本把流推送回ZLM。实际项目里RTSP地址的场景比想象中多设备地址rtsp://user:pass192.168.1.64:554/Streaming/Channels/101这是海康最经典的地址格式101代表主码流通道1。云服务地址rtsp://domain:554/openurl/xxxx这种带token的地址必须按客户提供的有效期定时刷新。本地文件很多测试场景直接拿一个MP4文件当成RTSP源用FFmpeg循环推流方便验证AI算法。涉及RTSP拉流必须注意一个点拉流拉不动时不要盲目重试。持续重试会给设备造成额外压力有些设备还会主动锁定IP。建议设计退避机制拉流失败后等待几秒再重试连续失败多次就告警让人工介入。3.5 语音对讲、浏览器播放等实战问题GB28181除了视频还支持语音对讲这个在安防场景里是刚需。比如门岗看到一个陌生人在大门外需要远程喊话。ZLM支持GB28181的语音广播和语音对讲平台拿到设备的音频RTP流之后可以播放同时麦克风采集的音频可以推给设备。具体实现时会遇到音频编码格式不一致的问题。有些设备只支持G.711A有些支持G.711U还有的支持AAC。ZLM内部一般能自动转码但如果前端页面需要播放对讲声音还要把音频转成WebRTC兼容的格式这中间涉及音频转码和混音处理起来比较费劲。浏览器播放是另一个高频需求。RTSP协议本身浏览器不支持直接播放所以必须借助流媒体中转。我们的方案是让ZLM把RTSP/GB28181流转成HLS或WebRTC。HLS延迟高但兼容性好适合监控回放WebRTC延迟低适合实时预览和语音对讲场景。4. K8s弹性调度算力分配的核心机制4.1 集群节点规划与部署要点视频AI中台的K8s集群分为控制面和数据面我用三台机器做控制面二十多台机器做数据面。节点类型上进行了区隔通用计算节点跑接入服务、流媒体网关、业务后端CPU密集。GPU节点跑AI推理服务必须带NVIDIA GPU。边缘节点有些ARM机器部署在客户机房跑轻量接入和部分推理算子。K8s集群的安装部署这里不展开讲但几个容易忽略的点值得提一下第一容器运行时选型。我们用的containerd因为K8s从1.24之后默认就移除了dockershim虽然Docker镜像格式还能兼容但没必要额外加一层shim。第二网络插件选择。视频流服务对网络带宽和延迟很敏感我们选了Calico的BGP模式避免VXLAN封装带来的性能损耗。如果节点跨网段通信不多Flannel也够用但如果视频流跨节点转发频繁Calico BGP模式的优势非常明显。第三存储规划。视频AI中台一般需要两块存储一个是NFS或云盘用于持久化业务数据比如设备列表、告警记录另一个是大容量存储用于录像文件。4.2 弹性伸缩HPA与CPU Throttling弹性伸缩是K8s最大的优势之一。我们对接入服务和AI推理服务做HPA核心指标是CPU利用率和QPS。apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: ai-inference-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: ai-inference minReplicas: 3 maxReplicas: 20 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70但HPA不是万能的这里最大的坑是CPU Throttling。K8s默认用CFSCompletely Fair Scheduler来做CPU配额限制。当一个Pod设置了CPU limit比如2核K8s会在每个CFS周期内限制Pod最多只能使用2核的时间片。如果Pod的CPU实际使用量超过了limitPod里的进程会被强制节流导致线程被迫暂停。这时候从外部看CPU利用率不高但服务响应变慢了这就是典型的CPU Throttling。我们在AI推理服务上遇到过开了HPACPU利用率还没触发扩容但推理延迟已经飙升。排查后发现是CPU limit太小导致Pod内的进程被持续节流。解决办法有两个调高CPU limit或者直接不设limit让Pod在节点空闲时可以用满节点CPU。不设limit有风险一个异常Pod可能把整台机器的CPU打满但对内部集群来说可以通过命名空间资源配额来兜底。适当调整K8s的CFS周期参数。默认CFS周期是100ms如果Pod每周期只能跑5ms持续节流是必然的。调大周期到200ms或者500ms能让Pod在单周期内跑更久减少节流频率。实测下来对推理服务不设CPU limit改用节点级别的资源配额做软限制反而比硬limit节流更稳定。但前提是你需要监控配合不然一个跑飞的任务会拖垮整个节点。4.3 节点亲和性、污点与GPU调度视频AI中台的调度策略必须精细控制不能全靠K8s默认调度器随机分配。首先AI推理服务必须固定调度到GPU节点。实现方式有两种给GPU节点打标签然后利用nodeSelector。更推荐用nodeAffinity支持更灵活的匹配规则。其次GPU节点的调度需要用设备插件机制。NVIDIA官方提供了nvidia-device-plugin安装后节点会暴露nvidia.com/gpu这个资源你可以像申请CPU、内存一样在Pod里声明GPU数量。resources: limits: nvidia.com/gpu: 1还有污点Taint与容忍Toleration的配合。GPU节点打上污点只允许带容忍度的推理Pod调度上去防止普通业务Pod把GPU节点CPU占满影响推理。kubectl taint nodes gpu-node-01 gputrue:NoSchedule然后在推理服务的Deployment中加入toleration这样只有推理Pod能调度到GPU节点上。4.4 多架构节点的统一调度策略我们的集群里同时有x86和ARM节点K8s版本从1.25开始支持基于节点的架构标签匹配镜像。在Deployment里可以声明spec: template: spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/arch operator: In values: - arm64如果某个服务只支持ARM架构比如某些在ARM上做过指令集优化的视频编码库就给它加NodeAffinity只允许调度到ARM节点。反过来如果某个服务两架构都支持不必加亲和性多架构镜像就能自动选择。但这里有个管理上的风险如果同一套服务的多架构镜像在x86和ARM上表现得不太一样比如推理精度或性能差异建议用两套Deployment分别管理而不是共用一套Deployment。否则滚动更新时会同时更新两个架构的实例出了问题很难定位。5. 监控与告警体系让K8s集群“有话好好说”5.1 Prometheus Grafana node-exporter三件套没有监控的K8s集群是聋子和瞎子。我们的监控体系是基于Prometheus Grafana node-exporter搭起来的。node-exporter在每个节点上以DaemonSet方式运行采集节点级别的CPU、内存、磁盘、网络指标。Prometheus负责抓取和存储指标支持K8s的服务发现能自动发现新增的Pod并抓取指标。Grafana负责可视化展示直接用Prometheus作为数据源配好看板。AlertmanagerPrometheus的告警组件负责把告警推送到钉钉、企业微信或者邮件。部署方式很简单用Helm一键安装helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack --namespace monitoring这个chart会顺手把node-exporter、Alertmanager、Grafana一并装上省去手工配置的时间。5.2 磁盘告警规则配置视频AI中台最容易爆的就是磁盘因为视频录像是存储大杀器。摄像头如果7x24小时录一个码率4Mbps的画面一天就要占掉约43GB几十路视频一个月就是几TB的量级。我们的磁盘告警规则分三级磁盘使用率超过70%发出警告通知运维关注。磁盘使用率超过85%发出严重告警需要在24小时内清理或扩容。磁盘使用率超过95%发出紧急告警立刻干预否则服务可能写入失败。在Prometheus中配置告警规则groups: - name: node-disk-alerts rules: - alert: DiskUsageWarning expr: (1 - (node_filesystem_avail_bytes / node_filesystem_size_bytes)) * 100 70 for: 5m labels: severity: warning annotations: summary: {{ $labels.instance }} 磁盘使用率超过70% - alert: DiskUsageCritical expr: (1 - (node_filesystem_avail_bytes / node_filesystem_size_bytes)) * 100 85 for: 10m labels: severity: critical annotations: summary: {{ $labels.instance }} 磁盘使用率超过85%注意添加for: 5m或10m是为了避免磁盘短时抖动导致误报。磁盘在写满前阶段经常有波动比如日志轮转、录像文件切换会瞬间释放很多空间。如果一超过70%就告警告警风暴能把人烦死。5.3 监控告警之外的进阶经验监控系统本身也会成为瓶颈。Prometheus默认的本地TSDB存储不擅长长期保存大量历史数据如果视频中台的监控指标太多建议启用远程存储Thanos或VictoriaMetrics。另外告警规则的阈值不是一成不变的。视频AI中台在业务高峰期CPU和内存指标会普遍偏高如果告警阈值定得太死会频繁误报。我建议先跑两周基线数据根据业务实际表现动态调整告警阈值再逐渐收窄告警范围。6. 实操踩坑与排查速查我踩过的那些雷6.1 GB28181注册失败、403等问题的排查思路GB28181接入调试是视频项目中最耗时、最崩溃的环节。这里整理几个高频问题的排查思路现象一设备注册不上抓包看到SIP 403 Forbidden。403在GB28181里通常表示认证失败。排查思路确认设备侧注册密码与平台侧一致。GB28181采用Digest认证密码错一个字符都不行。确认设备编码和平台侧配置的设备列表匹配。如果平台没有预先录入设备编码认证通过后也可能被拒绝。确认SIP服务器的realm配置和设备侧一致。有的设备对realm字段很敏感。现象二设备显示已注册但邀请取流时设备没有响应。大概率是平台侧RTP接收端口没开放或者设备无法访问该端口。GB28181取流时平台在INVITE的SDP里会告诉设备往哪个IP:端口推流。如果该端口被防火墙拦截或者网络NAT有问题设备推不出流。排查时需要抓包确认INVITE和200 OK的交互过程。现象三取流后视频花屏或卡顿。可能是RTP传输模式不匹配。GB28181支持TCP和UDP两种RTP传输模式如果设备默认发送UDP但平台只监听了TCP端口就会丢包。配置ZLM时建议把TCP和UDP两个端口都监听并做好兼容。6.2 RTSP拉流、浏览器播放的常见坑RTSP拉流最常见的坑是源地址有效但FFmpeg拉不起来或者拉起来之后延迟越来越大。第一确认RTSP传输协议。有些设备默认用UDP传输RTP但UDP在弱网环境下丢包严重导致花屏。FFmpeg可以强制走TCPffmpeg -rtsp_transport tcp -i rtsp://xxx -c copy output.mp4第二确认解码格式兼容。FFmpeg版本过旧可能导致某些新设备的H.265流解不出来。保持FFmpeg版本更新必要时升级到最新稳定版。第三浏览器播放RTSP没有直接方案必须转成浏览器支持的协议。我们的做法是在接入层就统一把RTSP流转成HLS或WebRTC通过ZLM或Mediamtx做协议转换前端用video.js播放HLS或直接用WebRTC连接。6.3 Docker Desktop启动失败、K8s集群中Pod卡在ContainerCreating等Docker Desktop在Windows上经常报“virtualization support not detected”这个报错一般是因为没有开启Windows的Hyper-V或WSL2虚拟化。解决办法是在“控制面板 - 程序 - 启用或关闭Windows功能”里勾选“Hyper-V”和“适用于Linux的Windows子系统”然后重启电脑。如果还是不行检查BIOS里是否开启了虚拟化Intel VT-x或AMD-V。K8s集群中Pod卡在ContainerCreating的原因很多但视频中台最常见的两个原因镜像拉取失败。多架构镜像在节点上找不到对应架构或者镜像仓库认证失败。存储卷挂载失败。Pod需要挂载NFS存储但NFS服务未启动或者挂载点权限不对。排查方法kubectl describe pod pod-name kubectl logs pod-name --previousdescribe能看到Event里的失败原因logs能看程序启动日志。多数问题在这两步就能定位。7. 个人实操经验总结与后续演进方向项目做到现在最大的体会是视频AI中台本质上是一个工程问题而不是算法问题。算法模型再强大如果接入层撑不住几十路视频流调度层扛不住峰值流量监控层看不到风险整个系统就像一座地基不牢的高楼盖得越高越危险。从Docker多架构镜像到K8s弹性调度从GB28181/RTSP接入到Prometheus监控告警这是一整套体系每个环节都必须打通缺一环就掉链子。如果让我给刚开始做类似项目的朋友一个建议我会说不要一上来就追求大而全的中台先从一条链路跑通开始。比如先接好一路视频走完“摄像头 - GB28181/RTSP接入 - 流媒体网关 - AI推理 - 监控呈现”这条完整链路再逐步横向扩展。链路跑通了扩容只是增加资源的问题链路没跑通堆再多机器也白搭。还有一个很实用的建议所有配置、脚本、规则都要版本化管理。Dockerfile、K8s YAML、Prometheus告警规则全部放进Git仓库。我们有过一次教训某台GPU节点的驱动升级后AI推理Pod起不来查了半天发现是部署时的镜像tag和当前环境的CUDA版本不匹配。因为镜像tag没有及时更新到脚本里才导致了这个低级问题。后来我们把所有部署配置纳入代码评审和自动化发布这类问题就少了很多。后续这个中台还有几个方向可以继续演进把AI算子标准化成可以通过消息队列异步调用的服务进一步降低算子之间的耦合探索在ARM边缘节点上运行更轻量的推理模型把一部分AI计算下沉到边缘再就是完善告警自愈能力让K8s在出现异常时能自动处理一部分故障而不是每次都要人工介入。做这种级别的项目没有什么一步到位的银弹靠的是把每一层的基础都打好然后一层层往上搭。希望这篇文章里那些实操细节和踩过的坑能让你少走一些弯路。