嵌入式容器化：资源受限设备轻量级K8s实践

去年四月份，我接手了一个工业物联网项目——在某汽车零部件工厂的2000台老旧PLC设备上部署轻量级K8s集群。这些设备内存仅512MB，CPU是ARM Cortex-A7架构，传统K8s的kubelet进程直接吃掉300MB内存，剩下200MB连基础业务容器都跑不起来。当时团队都摇头："这条件玩K8s？开玩笑吧。"但甲方坚持要新技术——他们想用K8s的滚动更新和健康检查解决设备固件升级总宕机的问题。

我翻遍GitHub，找到k3s——Rancher的轻量版，官方说单节点内存占用能压到50MB。但实测发现，k3s的etcd组件在ARM架构下会莫名崩溃，连续三天凌晨两点蹲在车间调试，最后发现是ARM的浮点运算单元和x86有差异，导致etcd的WAL日志写入时数据错乱。这算不算新技术踩的第一个坑？

后来改用k3s的SQLite替代etcd，内存占用降到80MB，但新问题又来了——SQLite的并发写入锁会卡住kubelet的调度循环。某次升级时，200台设备同时卡在"ContainerCreating"状态，监控显示kubelet的CPU占用飙到90%，而业务容器一个都没启动。那天甲方技术总监在视频会议里拍桌子："你们说的新技术，就是让我们生产线停摆？"

转机出现在第五次迭代——我们彻底砍掉k3s的server组件，只保留agent，用外部的MySQL集群存储状态，kubelet的日志级别调到"Warning"减少IO。最终方案：每个设备跑3个容器——kubelet（40MB）、flannel（10MB）、业务容器（动态分配剩余内存）。实测数据：2000台设备集群，滚动升级时平均宕机时间从30分钟压到90秒，固件升级失败率从12%降到0.3%。

文章配图，仅供参考

现在回头看，我主观判断：轻量级K8s在嵌入式场景的"新技术"光环下，藏着大量未被文档化的坑——比如ARM架构的浮点运算差异、SQLite的并发锁、containerd的内存碎片。但这些坑踩过后，确实解决了传统方案（如Ansible+Cron）无法实现的滚动更新和自愈能力。上周甲方还发来数据：过去一年靠K8s的健康检查，避免了7次因固件bug导致的生产线停机，按每小时损失50万算，省了3500万。

下一步？我正研究把k3s的kubelet替换成更轻量的nri-kubernetes（Node Resource Interface），据说能省20MB内存。但ARM设备的浮点运算问题会不会又冒出来？谁知道呢——新技术嘛，不就是一边踩坑一边往前拱？

（编辑：91站长网）

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