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

　　车间那台风扇一直在响，老张抖着腿把K3s的二进制包往板子上刷，手机在铁台上震了一下——是测试组发来的崩溃日志。近两个月我盯着这堆ARMv7的破设备，最头疼的就是“轻量级K8s”这五个字。上周把K3s的etcd换成SQLite，内存省了30%，结果第二天发现Pod调度卡死在“Pending”，日志里全是“no space left on device”——敢情SQLite的WAL文件把/var卷撑爆了，这破玩意儿连tmpfs都没配全。

　　老李叼着烟凑过来：“要不试试MicroK8s？”我甩给他一块沾着胶的手套：“你当这是Ubuntu服务器呢？这板子就512MB RAM，MicroK8s的API server一起，直接吃掉400MB，剩下的连sidecar都跑不动。”他吐了个烟圈：“那K3s总行吧？”我指着屏幕上跳动的“OOMKilled”：“K3s是省，但你见过哪个轻量级K8s敢把kubelet和containerd捆一起跑的？上次我试着拆开，结果containerd的storage driver跟kubelet的cgroup配置掐起来了，直接把系统进程树搅成麻花。”

　　中午盒饭里有块姜，我挑出来扔在桌上。小王抱着笔记本冲进来：“哥，我按你说的把K3s的kube-proxy关了，用eBPF替代，结果网络包全丢！”我接过他的板子，发现网卡驱动是3.10内核的老版本，根本不支持BPF MAP的直接访问。“这破驱动，”我敲了敲屏幕，“就像给夏利装F1引擎——硬件不支持，软件再怎么优化都是白搭。”小王挠头：“那咋办？”我叹了口气：“要么换驱动，要么滚回iptables——后者虽然慢，但至少稳定。”

　　其实我也没拆到底。上周试了把K3s的etcd换成Badger（一个嵌入式的KV库），内存占用确实降了，但写入延迟比etcd高了20%。我原以为Badger的LSM树结构在嵌入式设备上能占优势，结果发现这板子的SSD是eMMC 4.5，随机写入性能烂得离谱——Badger的compaction一开，直接把I/O队列堵死。老张在旁边补刀：“我早说过，嵌入式设备上别碰LSM树，RocksDB在这上面都跪过。”我瞪他：“那你说用啥？”他耸肩：“BoltDB呗，虽然并发差，但至少没compaction。”

　　下午测试组又报了个诡异问题：K3s的Pod偶尔会“失联”，kubelet日志里显示“ContainerStatus unknown”。我扒了半天代码，发现是containerd的snapshotter在低内存时会把部分层卸载，结果kubelet的缓存没同步，以为容器还在跑。修这个bug时，我把containerd的snapshotter从overlayfs换成fuse-overlayfs，内存占用又涨了10%。老李在旁边抖腿：“这不就是拆东墙补西墙？”我摔了扳手（掉地上一声闷响）：“那也比墙塌了强！”

　　说到拆东墙补西墙，我想起去年在另一个项目里踩的坑。那会儿用Docker Swarm跑嵌入式设备，结果发现Swarm的overlay网络在ARM上性能差得离谱——MTU设大了丢包，设小了吞吐上不去。后来改用Flannel的host-gw模式，结果又因为内核版本太老，不支持iptables的“mark”匹配，流量路由全乱套。最后没办法，只能自己写了个简单的CNI插件，绕过iptables直接改路由表。那会儿我天天骂：“这帮内核开发者就不能把API做稳定点？”现在想想，嵌入式设备上的网络，本来就是个“能用就行”的买卖——你指望它跟数据中心一样稳定？做梦。

文章配图，仅供参考

　　不过话说回来，这个型号我只在别人那儿见过——我们自己的设备，内存从来没超过1GB。修完最后一台板子，我自己都没底：K3s在这上面能跑多久？会不会下周又冒出个OOM？老张拍了拍我肩膀：“走一步看一步呗，嵌入式设备上的K8s，本来就是摸着石头过河。”我点头，把扳手收进工具箱——明天还得继续试Badger+eMMC的组合，说不定能找到个平衡点。这个我说不准，要看运气。

（编辑：应用网_常德站长网）

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