嵌入式容器化：资源受限设备上的轻量K8s集群

　　去年四月份那会儿，开发突然甩过来个需求——要在资源卡得死死的嵌入式设备上跑轻量K8s集群，说是要“容器化改造”，我原以为又是哪个领导拍脑袋的决定，结果人家甩出一份竞品分析，说隔壁组用这玩意儿扛住了三倍流量，优胜劣汰，不跟就得被淘汰。

　　那设备啥配置？CPU比树莓派还抠搜，内存就俩G，存储更绝，闪存芯片还是二手拆机的，风扇一直在转，嗡嗡的，吵得我头疼。开发说“我们优化过镜像了，每个容器就几十兆”，我盯着屏幕上的行数一直在跳——他们所谓的“优化”是把依赖全塞进基础镜像，结果拉镜像的时候卡了二十分钟，外卖都凉了。

　　第一版方案用的k3s，号称“轻量级K8s”，结果装完发现etcd占了一半内存，剩下的被kubelet和dockerd抢得你死我活。开发还怪我没调好参数，我直接把监控截图甩群里：“看，CPU使用率98%，你们写的业务代码连个心跳包都发不出去，还怪我？”运维老张路过问了句“好了没”，我头都没抬：“等设备炸了再说。”

　　后来咬着牙砍功能——etcd换成sqlite，docker换成containerd，kube-proxy直接禁用，服务发现改用DNS轮询。开发跳脚说“这不符合K8s规范”，我怼回去：“规范是给人看的，你这设备连人都算不上，要规范有个屁用！”结果还真跑起来了，三个节点扛了五十个容器，CPU稳在60%，就是偶尔会丢几个心跳包——开发说“不影响业务”，我信了，毕竟他们连日志都没开全。

　　最扯的是存储，设备自带的闪存写寿命就几千次，K8s的默认配置是每小时写一次状态，我算了下，三个月就能把存储写废。开发说“我们备份到云端”，我冷笑：“云端备份要网络，网络断了怎么办？设备重启后K8s状态丢了怎么办？”他们不说话了，最后我偷偷改了crictl的配置，把状态文件存到tmpfs里，重启就丢，反正业务代码有重试机制——我原以为这是妥协，结果运行了俩月，还真没出过因为状态丢失导致的故障。

　　说到这儿突然想起上周的值班，凌晨三点被警报吵醒，说是某个节点的kubelet挂了。我远程登录一看，内存溢出——开发新上线的服务有个内存泄漏，平时在小集群里看不出来，跑到轻量K8s上直接把节点干崩了。我一边重启一边骂：“你们写代码能不能有点数？这设备内存就俩G，你们一个容器就敢申请五百兆？”开发在群里回：“我们测试环境是8G内存的服务器，没想过会跑在嵌入式设备上……”我直接关了警报，心想：测试环境跟生产环境能一样吗？你们要是能想到，我还用在这儿熬夜？

　　现在这轻量K8s集群已经跑了半年，除了偶尔丢心跳包和内存泄漏，基本算稳。开发开始吹“我们实现了嵌入式设备的容器化革命”，我听着想笑——革命个屁，就是被逼到墙角后的妥协而已。要我说，这方案能站住脚，全靠“优胜劣汰”四个字：竞品用了，我们不用就得死；设备资源少，我们就得砍功能；开发写烂代码，我们就得偷偷打补丁。哪有什么技术高下，都是被逼出来的生存法则。

文章配图，仅供参考

　　下一步打算试试把kubelet也换成静态Pod跑，省得它自己把自己搞崩。不过开发那边又在提新需求——要在设备上跑AI模型推理，我看了看那抠搜的CPU，心想：你们要是能搞定，我直播吃键盘。

（编辑：站长网）

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