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

　　走廊尽头那台监护仪一直在响，我摘了口罩灌了口凉水——去年搞嵌入式K8s那会儿，比这还闹心。当时运维组非说资源受限设备跑不了集群，我原以为他们就是嫌麻烦，结果在边缘网关上部署第一版时，etcd直接把内存吃满，设备直接变砖，重启都救不回来。

　　那会儿我们用的还是标准K8s组件，光kubelet就占了40%内存。老张蹲在机房地上拆设备，白大褂口袋里半块饼干掉出来，沾了灰也没顾上捡。他说“要不试试k3s？”我当场怼回去：“轻量版能扛生产流量？”现在想想，那会儿真是轴——k3s的etcd换成了SQLite，内存占用直接砍到三分之一，但当时谁信啊？

　　转机是夜里送来那个设备——某工业现场的PLC网关，内存只有512M。我们硬塞了标准K8s进去，结果第二天现场反馈“设备间歇性失联”。排查时发现，kube-proxy的iptables规则把网络栈撑爆了。小李蹲在工位前改代码，打印机卡纸的声音都没盖住他的咒骂：“这他妈哪是容器化，这是往火坑里推！”

文章配图，仅供参考

　　真正让我服气的是一次复盘。那天护士站有人在剥橘子，香味飘进值班室，我盯着监控屏突然愣住：之前总抱怨“资源不够”的设备，换用精简版K8s后，故障率反而比全量版低了15%。后来查日志才发现，全量版的kubelet每隔5分钟就扫一次节点状态，精简版改成事件驱动后，CPU占用直接降了40%。这哪是“资源不够”，分明是“资源没用对”。

　　现在回头看，这事儿能成，优胜劣汰的逻辑太明显了。标准K8s组件就像“全能选手”，啥都能干但啥都不精；嵌入式场景需要的是“专项运动员”，只保留最核心的功能。比如我们后来把kubelet的“Volume管理”模块单独拆出来，用轻量级存储驱动替代，内存占用又降了20%。老张现在逢人就说：“早该这么干，之前白折腾半年。”

　　但我也栽过跟头。有次为了进一步压缩内存，把CNI插件换成了更轻量的版本，结果网络隔离出了问题——两个Pod居然能互相访问生产数据库。那天我蹲在机房改配置，走廊那盏灯闪了一下，突然想起之前删掉的kube-proxy代码里，好像有段关于网络策略的逻辑。后来把那段代码加回去，问题才解决。现在想想，轻量不是目的，稳定才是——为了省那点资源，把核心功能砍了，才是真傻。

　　上周跟运维组吵架，他们还在纠结“标准K8s才是正道”，我直接甩了组数据：过去三个月，嵌入式集群的故障率比全量版低30%，资源利用率高50%。老张在旁边补刀：“现在谁还跟资源过不去？”他们不说话了——这个我不讲了，反正最后他们也开始研究精简版了。

　　现在值班时，我偶尔会盯着监控屏发呆。那些曾经“跑不动”的设备，现在稳稳地跑着K8s集群，像一群精瘦的运动员，在资源有限的赛道上，跑得比谁都快。优胜劣汰的道理，在技术圈也一样——不是谁声大谁对，是谁能活下来，谁才是对的。

（编辑：站长网）

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