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

　　去年四月份那会儿，我跟团队接了个活儿——给某工业设备厂商的边缘计算盒子做容器化改造。甲方要求用K8s，可那盒子内存才两G，CPU还是ARM架构的，跑原生K8s？我第一反应是“这帮人是不是疯了”。但销售拍着胸脯说“能搞”，转头就把合同签了，留我们对着文档发呆。

　　当时我原以为，轻量级K8s无非是砍点功能，比如把etcd换成SQLite，把kubelet精简成单进程。结果折腾了两周，发现根本不是这么回事。那设备跑着实时操作系统，内核连cgroups v2都不支持，Docker根本装不上。后来试了K3s，结果启动时内存直接飙到1.8G，剩下两百兆连个日志文件都打不开——甲方当场就炸了，说“你们这比裸机还重”。

　　办公室空调太冷，我裹着外套盯着屏幕，突然想起之前看过MicroK8s的文档。这玩意儿号称“单节点K8s”，但官方说最低要求4G内存，我们设备才一半。可死马当活马医吧，我熬了三个夜，把kube-proxy、kube-dns这些组件全拆了，用iptables直接写规则，连dashboard都砍了——反正甲方只要API和调度功能。结果你猜怎么着？启动后内存占用才六百兆，CPU空闲率90%以上。甲方测试时盯着监控页面，半天憋出一句“这数据是不是假的？”

文章配图，仅供参考

　　说到这儿，我想起上周跟一个做IoT的同行吃饭。他吐槽说，他们团队用K8s管智能路灯，结果一场暴雨把部分节点淹了，恢复后发现etcd集群分裂，数据冲突搞了两天才修好。我听了直乐——这不就是“功能优先”的代价吗？要是在设计时就考虑“部分节点离线”的场景，用SQLite当存储，或者把调度逻辑下放到节点本地，哪会出这种幺蛾子？

　　手机快没电了，我插着充电器继续唠。其实嵌入式容器化这事儿，最坑的不是技术，是“惯性思维”。很多人觉得K8s就得是“标准版”，组件一个都不能少，可资源受限的设备根本不吃这套。我们后来给甲方写方案时，特意加了句“所有组件需支持动态降级”——比如内存不够时自动关闭非核心Pod，CPU过载时暂停调度新任务。甲方一开始还嫌“不够优雅”，结果跑了三个月后，主动要求把这套逻辑做成标准功能。

　　窗外天黑了，我合上笔记本，突然想起个细节。去年测试MicroK8s时，有次因为内核版本太低，kubelet启动后一直报“unsupported kernel”。我翻遍文档没找到解决办法，最后在GitHub的issue里看到个冷门回复——把/proc/sys/kernel/osrelease的文件内容改成“5.4.0”（实际是4.19），居然就过了。这种“野路子”在传统K8s里绝对算bug，可在资源受限的场景里，能跑起来比“正确”重要多了。

　　下一步我们打算试试K0s——听说这玩意儿连API server都能拆成单进程，内存占用能压到三百兆以内。不过销售已经在担心了：“甲方要是问‘为什么不用K3s’，我怎么解释？”我笑了笑说：“你就说‘K3s是给树莓派用的，咱们这是工业设备，得用更狠的’。”其实我心里也没底，但反正优胜劣汰嘛——能活下来的方案，才是好方案。

（编辑：站长网）

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