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

　　去年一月份接手那个边缘节点集群的时候，我原以为轻量K8s就是给K3s套个壳，结果第一周就被CPU占用率打脸——那台ARM板子跑三个Pod，kubelet直接飙到90%，风扇转得跟直升机似的。当时运维群里有人说“资源受限设备就该用静态编排”，我差点把键盘摔了——静态编排？那跟用Excel管服务器有什么区别？

文章配图，仅供参考

　　机房的空调最近总抽风，昨天下午温度飙到45度，我蹲在机柜前看监控的时候，老张端着泡面过来凑热闹：“你这轻量版K8s，不会热崩溃吧？”我白他一眼，指着屏幕上的资源曲线：“看见没？CPU调度周期比标准版短了40%，热插拔Pod的时候连心跳都没断。”他嗦了口面，突然说：“我闺女昨天问我‘爸爸为什么总看绿色代码’，我说那是爸爸的电子盆栽。”

　　但有些事真说不准。上周五测试镜像拉取，发现K3s自带的containerd在弱网环境下会卡死。我原以为换个镜像仓库就能解决，结果换了三个，问题依旧——最后发现是底层TCP栈的拥塞控制算法在搞鬼。改成BBR之后，三百多M的镜像两分钟拉完，比标准K8s还快。这时候隔壁工位的小王接了个电话，是媳妇催他回家修水管，他对着手机喊：“我在给设备‘修水管’呢！”

　　最离谱的是资源隔离。有次业务方非要跑一个Java服务，我警告他们“这机器总共才1G内存”，他们拍着胸脯说“优化过了”。结果第二天早上，整个节点的Pod全OOM——那Java进程直接吃了800M，连kubelet都被挤死了。后来我们定了死规矩：边缘设备只跑Go/Rust写的服务，Java？去云上跑吧。这事儿让我明白，所谓“轻量”不是靠削功能，是靠把不适合的玩家淘汰出局。

　　昨天下班前，测试组又来搞事，说要在边缘设备上跑AI推理。我盯着他们递来的需求单，上面写着“需要支持GPU调度”——那台设备连HDMI接口都没有！我指着单子上的“NVIDIA T4”说：“你们是打算把显卡插在USB口上？”他们愣了两秒，突然笑了：“我们就试试，不行再改。”我叹了口气，心想：这大概就是运维的宿命吧——永远在给不可能的需求找解法。

　　现在集群已经跑了三个月，除了那次CNI插件的幺蛾子，基本没出过大问题。上周巡检的时候，我发现某台设备的kubelet日志里有个奇怪的错误——每分钟报一次“failed to get node info”，但节点状态正常。我查了半天，最后发现是监控脚本里的一个拼写错误。改完之后，我盯着屏幕发了五分钟呆：原来最危险的不是资源受限，是人的疏忽。

　　下一步打算试试把边缘设备的日志直接灌到Loki里，省得每次查日志都要登录设备。不过老张说：“别整那些花里胡哨的，能稳住就谢天谢地了。”我想想也是——在边缘计算这行，能活下来的方案，从来不是最完美的，而是最能扛揍的。就像K3s，它不完美，但它能在256M内存的设备上跑起来，这就够了。

（编辑：站长网）

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