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

　　去年十一月那会儿，业务方突然拍脑袋说要搞“嵌入式容器化”，说要把K8s塞进资源受限的设备里。我原以为他们疯了——那些设备内存才512M，CPU是十年前的低功耗型号，连个正经的SSD都没有，跑个轻量级OS都吃力，现在要上K8s？运维老王当时就拍桌子：“你们这是要逼死我们！”可业务方那头拍着胸脯说“优胜劣汰，不搞就落后”，最后还是硬上了。

　　第一周就炸了。我蹲在机房里盯着监控，设备内存占用像坐火箭一样往上涨，K8s的kubelet和docker-daemon疯狂吃资源，没两小时就OOM（内存不足）了。业务方还嘴硬：“肯定是你们配置没调好！”我调了三天参数，把kubelet的内存限制砍到128M，docker的存储驱动换成overlay2，甚至把日志级别从info调到error——结果还是撑不过半天。手机一直在震，业务方的电话一个接一个，问“为什么设备又挂了”，我一边回“在查”一边盯着屏幕上的“Out of memory”日志，泡面凉了都没顾上吃。

　　其实最气人的是，业务方根本不听劝。他们说“嵌入式设备就是要跑容器化，这是趋势”，可他们连设备实际负载都没测过。我翻出设备的历史监控数据，发现平均内存占用才300M，K8s一上来直接翻倍。运维老王冷笑：“趋势？趋势就是让设备死机？”业务方那头的小张还反驳：“你们技术不行别怪趋势。”我差点摔键盘——这哪是技术问题？这是物理限制啊！

　　后来没办法，只能上“土办法”。我把K8s的组件拆得七零八落，kubelet、kube-proxy、docker全拆成单独的进程，用systemd的cgroup手动限制资源。还把设备的存储从ext4换成btrfs，就为了支持docker的snapshot功能——结果btrfs在低性能设备上卡得要死，读写延迟飙到几百毫秒。业务方又开始催：“怎么还没好？”我盯着屏幕上卡死的btrfs命令，心想：“你们要是早点听劝，至于这样？”

文章配图，仅供参考

　　其实那段时间，我半夜经常被电话吵醒。业务方说设备又挂了，我爬起来远程登录，发现又是OOM。有一次，我盯着日志看了半小时，发现kubelet在疯狂重启容器——因为内存不足，容器被kill，kubelet又尝试重启，结果更耗内存，形成死循环。我原以为K8s的调度机制能自动处理资源不足，结果发现它根本不管设备死活，只管“尽力而为”。

　　后来实在没办法，我写了个脚本，每隔十分钟检查一次内存，如果超过400M就手动kill掉最耗内存的pod。业务方知道后，又跳出来说：“这不符合K8s的设计理念！”我怼回去：“设计理念能当饭吃？设备不死机才是硬道理！”他们不说话了，但我知道他们心里不服——可不服也没办法，设备要是再挂，用户该骂了。

　　现在回头看，这事儿能成，其实靠的就是“优胜劣汰”——那些扛不住K8s的设备，早就被淘汰了。剩下的设备，要么是业务方妥协，降低了K8s的功能需求（比如不用动态扩缩容），要么是我硬着头皮优化，把资源占用压到极限。运维老王说：“这叫‘用脚投票’——设备用不起来，自然没人用。”我点头：“可苦的是我们这些搞技术的。”

　　窗外天亮了，我揉了揉眼睛，发现手机又在震——业务方又来催新需求了。我叹了口气，心想：“这活儿，防不住啊。”

（编辑：站长网）

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