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

　　去年过年那会儿，我原以为能躺平几天，结果大年三十晚上十点，后端老张在群里@我，说边缘网关的埋点数据全丢了——那批设备跑的是K8s的“精简版”，说是精简，其实是我们自己砍了八成功能，结果砍到核心调度模块出问题，容器说挂就挂，跟闹着玩似的。

　　当时我在老家，窗外下着雪，手机屏幕都快贴脸上了。群里产品还在催：“埋点必须今天恢复，明天要给客户演示！”我盯着日志里“insufficient memory”的报错，心里直骂娘——那批设备内存才2G，K8s的kubelet自己就要占300M，再加上我们塞进去的监控、日志、埋点收集器，不爆才怪。老张在群里补刀：“要不把埋点容器停了吧？”产品直接炸毛：“停了你给我写周报解释？”

　　这时候设计小李突然发了个表情包，是只猫举着“躺平”的牌子——我差点把手机摔了。后来熬到凌晨两点，临时把kubelet的日志级别调到“error”，砍了所有非必要探针，又把埋点容器的资源限制从512M压到256M，才算勉强跑起来。但第二天客户演示时，还是白屏了两次——后来查出来是容器重启时，埋点收集器的缓存没持久化，数据丢了。

　　这事儿让我琢磨了挺久：嵌入式设备搞容器化，到底图啥？我们当时选轻量级K8s，是觉得能统一管理，结果为了适配资源受限的设备，改得面目全非——kubelet的调度逻辑被我们魔改了三版，每次升级都要重新适配，编译进度条能卡半小时，旁边工位的风扇声吵得我头疼。

文章配图，仅供参考

　　这时候外卖到了，我边吃边刷技术群，看到有人提“MicroK8s”——说是Ubuntu出的，专为边缘设备设计。我下载了记不清哪个版，部署到测试机上，发现它居然内置了存储插件，能直接挂载本地磁盘，不用我们自己写Volume驱动。但用着用着又发现，MicroK8s的API Server和Controller Manager是耦合的，我们想自定义调度策略，根本没法改，只能等官方更新。

　　折腾了快一个月，我算明白了：嵌入式容器化这事儿，没有“完美方案”，只有“优胜劣汰”。我们最后选了K3s，但把调度模块彻底换了——自己写了个基于优先级队列的调度器，把硬实时任务的权重拉满，软实时任务按资源占用动态调整。虽然代码丑得像补丁摞补丁，但至少跑起来稳了，客户演示时再没白屏过。

　　现在回头看，我原以为轻量级K8s能“开箱即用”，结果每个设备都得魔改——内存小的砍功能，CPU弱的换调度，网络差的改CNI。上周招聘面了个候选人，他说在原公司用K8s管IoT设备，我直接问：“你们设备内存多大？”他说“1G”，我笑了：“那你们kubelet的日志级别调的是‘fatal’吧？”他愣了下，说“还真是”。

　　最近又在看KubeEdge，说是能解决边缘设备的网络问题，但看了文档发现，它得依赖云端K8s集群，我们设备经常离线，这方案估计悬。老张说：“要不直接上虚拟机？至少隔离性好。”我摇摇头——虚拟机太重，我们设备连hypervisor都跑不动。现在只能继续魔改K3s，等哪天实在改不动了，再考虑换方案——反正嵌入式这行，没有“一劳永逸”，只有“今天能跑就行”。

（编辑：我爱资讯网）

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