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

　　2025年2月那会儿，我在给某工业设备厂商做边缘计算方案，对方非要上K8s——不是那种带GPU的边缘盒子，是ARM Cortex-A53、内存512M的玩意儿。我原以为他们只是说说，结果真买了二十台这种开发板，说“要跑完整的K8s集群，和云端一致”。当时机房空调坏了，我蹲在铁皮柜旁边擦汗，看他们CTO举着开发板说：“你看，这上面能跑Docker，为什么不能跑K8s？”

　　第一周踩的坑全是“常识性错误”。比如kubelet默认配置里，cgroup驱动是systemd，可这破板子连systemd都没装——我改成了cgroupfs，结果容器启动时内存泄漏，三天漏满512M直接OOM。更离谱的是etcd，官方说“最小配置需要2G内存”，他们非说“可以优化”，最后真让我用sqlite替代了etcd的存储层（别学，数据一致性全靠祈祷）。那天下午我蹲在机房地上改配置，运维小哥在旁边吃外卖，汤汁滴在开发板上，我抬头喊“小心短路”，他嚼着鸡腿说“没事，这板子防水”。

文章配图，仅供参考

　　说到代码烂，他们前端组还来凑热闹。那天我在改kube-proxy的配置，前端老张凑过来说：“我们最近在搞低代码平台，能不能用K8s调度前端构建任务？”我差点把键盘摔了：“你们构建一次要1G内存，这板子总共512M！”他挠挠头：“那...能不能分片构建？”我冷笑：“分片？你当这是分布式计算呢？这板子连多线程都跑不利索。”他哦了一声，转身走了——后来我听运维说，他们真在板子上跑了前端构建，结果把内核搞崩溃了三次。

　　不过话说回来，有些“优化”确实有用。比如我们把kubelet的日志级别从Info调到Error，内存占用直接降了40%；把docker的storage driver从overlay2换成aufs（虽然官方不推荐，但ARM板子上aufs更轻量）；甚至把kube-scheduler的选举间隔从5秒改成30秒——反正集群里就三个节点，选谁都一样。这些改动没一个在官方文档里，全是靠试错试出来的。那天我改完最后一个配置，抬头看见窗外下雨了，雨水打在机房的玻璃上，发出噼里啪啦的声音——我突然觉得，这破板子跑K8s，就像让三轮车装F1发动机，虽然能跑，但得把轮子、座椅、车壳全拆了。

　　现在这项目已经上线三个月了，运行还算稳定——当然，前提是我们禁用了所有非核心组件（比如dashboard、metrics-server），把Pod数量限制在五个以内，还写了个脚本定期清理僵尸容器。他们CTO最近又在提“扩展性”，说要在板子上跑AI模型推理。我直接回他：“先把你那心跳检测容器的CPU占用降下来再说。”他笑了笑，没说话——我猜他心里在想：“这站长怎么这么保守，优胜劣汰懂不懂？”

　　其实我也说不准这方案到底算不算成功。从技术角度，它确实在资源受限的设备上跑了K8s；但从实用角度，它牺牲了太多功能（比如监控、日志、弹性伸缩），换来的“稳定性”更像是运气。就像那天运维小哥说的：“这板子能跑K8s，不是因为它强，是因为我们把它阉割得够狠。”我琢磨着，这话虽然难听，但好像也没错。

　　下一步我打算做个对比测试：同样配置的板子，一个跑K8s，一个跑轻量级容器编排工具（比如K3s或MicroK8s），看看谁更稳。不过估计他们不会同意——毕竟“优胜劣汰”这面旗，他们已经扛了半年了。

（编辑：站长网）

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