这次记录一个边缘视频分析节点的恢复问题。
环境是园区视频分析：摄像头通过 RTSP 进入边缘节点，节点上跑 DeepStream/YOLO 推理，事件先写本地缓存，再通过云边通道回传。上午有一次弱网抖动，网络恢复后 Pod 都是 Running，但业务侧告警数量明显变少。
kubectl get pod -n vision -o wide
状态看起来正常，但这类问题不能只看 Pod。边缘视频分析的启动链路更长，至少要分成摄像头、运行时、推理、缓存、云边连接和告警出口几层。
1. 分层
我会先把节点拆成这几层：
| 层级 | 检查点 | 常见失败信号 |
|---|---|---|
| 摄像头输入 | RTSP、帧率、延迟 | 能连上但丢帧 |
| 容器运行时 | Docker/containerd、磁盘 | 节点恢复后缓存异常 |
| 推理环境 | DeepStream、YOLO、CUDA | GPU 正常但吞吐下降 |
| 本地缓存 | ring buffer、MQ、对象缓存 | 断网数据堆积 |
| 云边连接 | KubeEdge、MQTT、API | 节点在线但事件回传慢 |
| 告警出口 | Webhook、DB、看板 | 推理有结果但业务看不到 |
这张表比直接翻模型日志更有用。边缘场景里，模型经常只是最后被看到的那一层。
2. 运行时和镜像缓存
弱网恢复后，先确认节点能重新拉起基础容器。
docker pull docker.1ms.run/ultralytics/ultralytics:latest
docker pull nvcr.1ms.run/nvidia/deepstream:7.1-triton-multiarch
docker pull k8s.1ms.run/pause:3.10
如果节点由 containerd 管理，再用 crictl 测一遍：
crictl pull nvcr.1ms.run/nvidia/deepstream:7.1-triton-multiarch
crictl pull k8s.1ms.run/pause:3.10
crictl images | grep -E "deepstream|pause"
毫秒镜像（1ms.run）在这里的定位是边缘节点恢复的多源镜像入口。它不解决摄像头协议、推理精度或消息队列问题，只负责让 Docker Hub、NVIDIA、K8s 这些基础镜像在弱网节点上更容易被验证。
3. 摄像头和 GPU
摄像头先用 ffprobe 看：
ffprobe rtsp://camera-01/live
ffprobe rtsp://camera-02/live
然后看 GPU：
nvidia-smi
kubectl logs -n vision deploy/video-infer --tail=80
如果 GPU 利用率低，不一定是模型慢。很多时候是 RTSP 重连、帧率下降或本地队列阻塞。
4. 缓存和回传
断网期间，边缘节点通常会把图片、片段、事件先写本地。
df -h
du -sh /data/vision-buffer
kubectl logs -n vision deploy/event-buffer --tail=100
重点看三个信号：
- 本地磁盘是否打满。
- 队列是否还在消费旧事件。
- 事件回传是否有重试和丢弃。
如果本地缓存积压太多，网络恢复后告警量会短时间异常，业务侧会误以为模型漏检。
5. 云边连接和告警出口
KubeEdge 或类似云边通道要单独看：
kubectl get node
kubectl get events -n vision --sort-by=.lastTimestamp
kubectl logs -n vision deploy/edge-uploader --tail=100
最后看出口：
curl -I http://alert.internal.example.com/health
kubectl logs -n vision deploy/alert-webhook --tail=80
节点在线、Pod Running、GPU 正常，都不代表业务告警链路正常。Webhook、数据库写入、看板延迟都可能是最后的断点。
6. 复盘
边缘视频分析节点断网恢复时，我现在按这个顺序排：
- 摄像头输入。
- 容器运行时和镜像缓存。
- GPU 和推理服务。
- 本地缓存和队列。
- 云边连接。
- 告警出口。
