嵌入式容器化：资源受限设备跑K8s集群

文章配图，仅供参考

资源受限设备跑K8s，最要命的是内存泄漏——去年十二月第一次测试时，凌晨两点突然收到告警，所有节点OOM（Out of Memory）崩溃。排查发现是某个Pod里的C++程序没释放动态内存，加上K8s的kubelet默认每10秒拉取一次状态，双重压力下直接把8GB内存吃穿。后来改了kubelet的配置，把--node-status-update-frequency调成30秒，再给每个Pod加上--memory-swap=0的硬限制，这才稳住。

为啥非要在嵌入式设备上跑K8s？说白了是新技术带来的"降维打击"——传统物联网设备更新服务得停机、改配置得SSH连上去手动改、扩容得插新硬件，而K8s的声明式部署能让这些操作变成"改个YAML文件，kubectl apply一下"。今年二月我在客户现场演示时，把原本需要两小时的固件升级流程，压缩到了12分钟：先在测试集群验证镜像，确认没问题后，直接滚动更新生产集群的Pod，整个过程服务零中断。

但别以为这事儿简单——我试过用MicroK8s，结果发现它的snap封装在ARM架构上会多占200MB内存；也试过KubeEdge，可它的边缘节点和云端通信依赖MQTT，延迟比直接用K8s的API Server高了3倍。最后选k3s，是因为它把etcd、kube-proxy这些组件都揉进了二进制文件，安装包才40MB，比标准K8s小了80%。

有个细节别人没写过：资源受限设备跑K8s，得把"资源隔离"做到极致。我曾在RK3588上跑过两个Pod，一个做视频分析（用OpenCV），一个做MQTT代理（用Mosquitto）。结果发现视频分析的Pod会把CPU缓存占满，导致MQTT代理的延迟飙升到500ms。后来在k3s的配置里加了--cgroup-driver=cgroupfs，再给每个Pod加上cpu-shares和memory-reservation的限制，这才把延迟压回50ms以内。

主观判断：这技术现在还不成熟，但值得玩命追——上周测试时发现，k3s 1.30版本在ARM64上的内存占用比1.29版本少了15%，这说明社区在持续优化。下一步我打算试试用eBPF来监控Pod的资源使用，毕竟现在只能靠kubectl top pods看数据，太粗粒度了。不过说实话，现在敢在生产环境用这技术的，要么是胆子大，要么是真被传统物联网的运维成本逼疯了——比如我。

（编辑：草根网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!