嵌入式容器化：资源受限设备轻松运行K8s

　　去年四月被客户按着头搞“嵌入式容器化在K8s上的落地”，我原以为又是那种“老板拍脑袋，开发背黑锅”的活儿——毕竟那会儿连K3s的文档都没翻全，更别说要在4GB内存的工业网关上跑K8s了。结果客户甩过来一句：“你们不是总说‘优胜劣汰’吗？现在市面上能同时满足低功耗和容器编排的方案，就你们这波能试出来。” 我盯着屏幕上的K8s集群监控图，突然觉得这活儿可能真有点意思——毕竟谁不想在资源受限的设备上把K8s玩出花来？

　　群里老张前天贴了张图，说他们团队在某IoT网关上跑K8s，结果内存占用直接飙到80%，调度器卡得连Pod都拉不起来。我一边啃着凉透的外卖，一边翻他的日志——好家伙，kubelet的日志里全是“OOM Killed”的报错，连etcd的副本都因为资源不足挂了一半。老张在群里吐槽：“这哪是容器化？这是给设备上刑啊！” 我回他：“你试试把kubelet的--kube-reserved和--system-reserved参数调小点？我们之前在3GB内存的设备上，硬是把这两个值从512m砍到了256m，结果调度器反而跑顺了。” 他回了个“？”，然后说：“我试试，要是再崩，明天去你工位堵你。”

文章配图，仅供参考

　　窗外在下雨，浏览器开了二十多个标签，全是K8s的文档和嵌入式设备的资料。我原以为“资源受限设备跑K8s”最大的挑战是性能，结果试下来发现，真正的坑是“兼容性”。比如某款工业网关的CPU是ARMv7架构，而K8s官方镜像大多是x86的，直接拉下来根本跑不了。有次为了适配一个ARM设备，我熬到凌晨两点，把kubelet、kube-proxy、containerd全重新编译了一遍，结果第二天测试的时候，设备直接蓝屏了。客户在电话里吼：“你们不是说能适配吗？这怎么解释？” 我一边擦汗一边说：“您别急，我们再试试——可能是编译参数没调对。” 挂了电话后，我翻出之前的编译日志，发现是GCC版本不对，换了个旧版本重新编译，设备居然真的启动了。客户后来在验收报告里写了句：“虽然过程曲折，但结果还算满意。” 我看着这句话，突然觉得“优胜劣汰”这四个字，在嵌入式容器化里，可能真的不是说说而已。

　　跟客户吵过一架，起因是他们要求在2GB内存的设备上跑K8s集群。我说这不可能，他们说：“你们不是总说‘没有做不到，只有想不到’吗？” 我回：“那是吹牛的，2GB内存连etcd都跑不起来，更别说kubelet和调度器了。” 他们不依不饶：“那你们之前怎么在4GB设备上跑起来的？” 我说：“4GB是极限，2GB是自杀——您要真想试，我们可以用K3s，但功能会阉割很多。” 他们沉默了半分钟，然后说：“行吧，那先试K3s。” 结果试下来发现，K3s虽然轻量，但扩展性差，很多K8s的API都不支持。客户又来找我：“你们之前说的‘优胜劣汰’，现在怎么不行了？” 我回：“优胜劣汰不是万能药，得看场景——2GB内存的设备，现阶段可能真的不适合跑完整的K8s。” 他们没说话，但我知道，这波他们可能真的信了。

　　其实嵌入式容器化在K8s上的落地，最让我意外的是“生态”。之前总以为K8s的生态只在大服务器上玩得转，结果试下来发现，很多开源工具在嵌入式设备上也能跑。比如我们用的Prometheus监控，原本以为会因为资源不足挂掉，结果通过调整采样间隔和存储周期，居然在4GB设备上稳稳跑了三个月。还有Fluentd的日志收集，原本担心会占用太多CPU，结果通过限制并发数和缓冲大小，设备也没崩。群里小李昨天说：“你们这波算是把K8s的生态玩明白了——原来不是只有大服务器才能用，小设备也能蹭点光。” 我回他：“蹭光？我们是把光掰碎了，往小设备里塞。”

　　现在回头看，“嵌入式容器化：资源受限设备轻松运行K8s”这事儿，它站得住的地方确实是“优胜劣汰”——不是所有设备都适合跑K8s，但能在资源受限的环境里跑起来的，一定是经过反复优化和适配的。就像我们之前试过的某个方案，因为内存占用太高被客户否了，后来换了轻量级的容器运行时，反而成了他们的首选。但话说回来，这波到底能走多远，我现在也看不准——毕竟嵌入式设备的硬件更新慢，而K8s的版本迭代快，说不定哪天新的特性出来，老设备又得重新适配。不过管他呢，先试了再说——优胜劣汰嘛，总得有人先跳进坑里，才能知道能不能爬出来。

（编辑：站长网）

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