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

　　去年过年时，运维群里突然炸锅——某边缘网关项目组说要在嵌入式设备上跑K8s，我叼着饺子差点笑出声。这帮人怕是没见过资源受限的场面：那台设备内存才2G，CPU是ARMv7架构的，连个正经的SSD都没有，跑个Docker都够呛，还K8s？结果老张甩过来个测试视频，我筷子都掉了——丫真跑起来了，用的还是K3s的裁剪版，资源占用比预期低一半。

文章配图，仅供参考

　　但最让我懵的是资源占用。他们用cgroup把每个Pod的CPU限制在500m，内存锁死256M，连etcd都跑在单独的namespace里。我盯着监控图看了半天，CPU峰值没超过30%，内存稳在1.2G左右——这比我们之前在x86服务器上跑的K8s还省资源。老张在群里补刀：“我们测了三天，崩溃次数比你们生产环境的K8s还少。”

　　这时候运维总监老李突然插话：“这方案能上生产吗？”群里瞬间安静。我咬了口饺子，心想这货肯定又要拍脑袋。结果老张回：“得改两处——etcd的持久化存储得换，现在用的SD卡扛不住高频写入；还有kubelet的日志级别得调低，不然磁盘空间不够。”老李秒回：“行，下周前出PRD。”我差点把饺子汤喷屏幕上——这决策速度，比我们需求评审快十倍。

　　后来我私下问老张：“你们怎么想到这方案的？”他叼着烟，电脑屏幕反射着蓝光：“去年双十一，我们有个智能电表项目，设备内存才1G，客户非要跑容器。当时试了MicroK8s，结果卡得死机。后来我们自己改K3s，把不必要的组件全删了，连kube-proxy都换成了用户态实现。”他顿了顿，“其实最坑的是ARM架构的二进制兼容性，我们花了半个月才搞定glibc的版本问题。”

　　这时候我妈喊我收衣服，我应了一声，转头继续问：“那现在这方案有啥缺点？”老张吐了个烟圈：“调度策略太简单，不支持亲和性/反亲和性；还有扩容得手动，没有自动伸缩。不过客户说他们设备本来就不需要这些。”我愣了下——这不就是“优胜劣汰”吗？把K8s里用不到的功能全砍掉，只留最核心的，反而跑得更稳。

　　上周我去他们机房转了一圈，那台嵌入式设备就摆在角落里，风扇声比旁边的服务器小多了。老张指着屏幕说：“现在跑着三个Pod，一个日志收集，一个规则引擎，一个API网关，CPU占用才15%。”我凑近看了眼，监控图上三条线稳得像心电图——要不是知道这是嵌入式设备，我还以为是台虚拟机。

　　回来后我跟团队说：“咱们也得学学这种思路，别总想着上全套K8s，有时候裁剪版更实用。”结果小王嘀咕：“那以后客户要功能怎么办？”我拍了拍他肩膀：“先问清楚他们到底要不要——就像老张说的，很多功能客户根本用不上，上了反而添麻烦。”

　　现在我最关心的是，这方案能不能推广到其他资源受限的场景，比如工业网关、车载设备。老张说他们正在测，但遇到个问题：某些设备的内核版本太老，不支持cgroup v2，得回退到v1。我原以为这会影响性能，结果他说“影响不大，就是日志多了点”——这货对细节的把握，比我强多了。

　　说到底，嵌入式容器化这事儿，我之前觉得是异想天开，现在看反而是条路子。优胜劣汰的道理谁都懂，但真能下狠手砍功能的，没几个。老张他们这波操作，算是给我上了一课——有时候，少即是多。

（编辑：站长网）

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