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

　　去年九月那波轻量K8s上设备，我原以为老板是拍脑袋决策，结果他甩给我三台断货半年的旧网关——内存4G，CPU比树莓派还弱，说「要么让这些废物跑起来，要么你跟它们一起滚」。风扇在旁边嗡嗡转，饮水机咕嘟咕嘟响，我盯着那堆生锈的螺丝孔，突然想起上个月工厂那边说「这批设备连Docker都跑不动」，现在倒好，直接上K8s？

　　可老板不管这些。他只说「类目里那几个头部都在搞边缘计算，咱们小类排名掉到200开外，再不折腾就真死了」。我摸出U盘插进设备，鼠标垫卷边的地方卡着半根头发——这破玩意儿还是三年前测评剩下的。安装过程比预期顺利，K3s的二进制包才40M，比完整版K8s小了一个数量级，可等真正跑Pod的时候，问题全来了：资源监控显示CPU占用率卡在99%，日志里全是「OOMKilled」，打包台上横着的那卷胶带突然滚到地上，惊得我手一抖，把终端窗口给关了。

　　最离谱的是网络插件。我原以为Flannel这种轻量级方案肯定能跑，结果设备启动后连API Server都连不上——后来查日志才发现，那批旧网关的网卡驱动有问题，某些数据包会被直接丢弃。仓库卷帘门「哗啦」一声响，送快递的小哥探头问「有没有要发的件？」，我头都没抬，指着地上那堆设备说「先把这些搬出去扔了」。可老板不让，说「扔了就真没机会了」，逼着我改CNI配置，把默认的Flannel换成Calico，结果Calico的IPAM模块又因为内存不足疯狂崩溃。

　　那段时间我天天泡在工厂。车间里机器轰鸣，有人在旁边点外卖，塑料袋的沙沙声混着设备报警的蜂鸣，吵得我头疼。有天半夜，我盯着监控大屏突然发现，某台设备的Pod居然稳定跑了24小时——资源占用率从99%掉到了60%，CPU温度也降了10度。翻日志才发现，是某个开发偷偷把Pod的requests/limits调成了「0.1/0.2」，原本要1G内存的应用，现在硬挤在200M里跑。我原以为这会导致频繁OOM，结果它反而更稳了——因为资源争抢少了，调度器不用频繁杀进程重建。

　　这事儿后来成了我们内部的「反常识案例」。按K8s官方文档，requests/limits必须合理设置，否则系统会崩溃；可实际在资源受限的设备上，「过度压缩」反而成了优胜劣汰的机制——那些真正能跑的应用，会自己优化内存使用；而那些占着资源不做事的，直接被OOMKilled，连救的机会都没有。有个开发跟我争，说「这不符合最佳实践」，我指着监控大屏说「最佳实践是给16G内存的服务器写的，咱们这4G的设备，活下来才是硬道理」。

　　可也不是所有应用都能这么搞。有次我们试着把一个老旧的Java服务迁到设备上，结果它启动就要500M内存，运行起来直接飙到1G——K3s的调度器当场崩溃，整个节点变成「NotReady」状态。工厂那边急得跳脚，说「这批设备本来是用来做实时监控的，现在连数据都传不回来」。最后没办法，只能把Java服务拆成三个微服务，每个控制在200M以内，再通过Sidecar模式跑——虽然延迟高了点，但至少能稳定运行了。饮水机又开始咕嘟响，我摸出手机看了眼时间，凌晨三点，车间里还有两个开发在改代码。

　　现在回头看，那波轻量K8s的实战，最成功的不是技术本身，而是逼着所有人重新思考「资源」的定义。以前我们总觉得「资源越多越好」，可当设备内存只有4G时，「够用」比「完美」更重要。那些能自动压缩内存、降低CPU占用的应用，活了下来；而那些死守「最佳实践」的，要么被淘汰，要么被迫改造——这就是我说的「优胜劣汰」，不是靠市场，是靠设备本身的资源限制。

　　不过这事儿也有局限。比如我们到现在都没搞定GPU的调度——那批旧网关的GPU驱动太老，K8s的Device Plugin根本识别不了。有次老板问「能不能在设备上跑AI模型？」，我指着监控大屏说「连Java服务都跑得费劲，AI？等明年换设备再说吧」。他没说话，低头刷了会手机，突然说「那批新设备到货了，内存8G，CPU是ARM的，你试试能不能跑K8s」。我愣了下，鼠标垫卷边的地方又卡了根头发——这破玩意儿，看来还得继续用。

文章配图，仅供参考

（编辑：航空爱好网）

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