14年码农亲测：嵌入式设备跑K8s集群

2025年9月，我蹲在实验室角落，对着三台树莓派5B和一块自制的ARM开发板折腾了整整两周——这堆总价不到2000块的设备，最终跑通了K8s集群。别笑，这不是玩具项目——某工业物联网厂商找我做POC（概念验证），要求用嵌入式设备替代传统x86服务器管理2000+个传感器节点。当时他们技术总监拍着桌子说："要是能成，我们每年硬件成本能砍掉70%。"

先说硬件配置：树莓派5B（4GB内存）+ 64GB TF卡，开发板是全志H616（双核A53，1GB内存），系统全刷成Ubuntu Server 24.04 LTS。K8s版本选的是1.32——不是最新版，但经过测试，这个版本对ARM架构的内存占用优化最好。最扯的是网络方案——原本想用USB转千兆网卡，结果发现驱动在K8s的Calico网络插件里会崩溃，最后被迫用树莓派自带的WiFi模块组网，延迟比有线高了30ms，但勉强能用。

第一次部署时，我直接照搬x86服务器的配置——结果kubelet进程刚启动就OOM（内存不足），开发板直接卡死。查日志发现，K8s默认的cgroup配置对低内存设备极不友好，光是etcd就占了300MB内存。后来手动调了kubelet的--kube-reserved参数，把内存预留从256MB砍到64MB，才让开发板能喘口气。但新问题又来了：当集群负载超过50个Pod时，树莓派的CPU温度直接飙到85℃，散热片烫得能煎鸡蛋——最后不得不给每台设备加了小风扇，噪音比服务器机房还大。

——但这些坑，恰恰证明了嵌入式设备跑K8s的可行性。

说个冷门细节：K8s的Ingress Controller在ARM设备上跑特别坑。我试过Nginx、Traefik，最后发现只有K3s自带的Traefik v2.10能稳定运行——更高版本会因为Go的GC（垃圾回收）机制触发OOM。还有存储卷，原本想用Ceph，结果发现Ceph的OSD进程在1GB内存的设备上根本跑不起来，最后改用Local Volume，把每个传感器的数据直接存到设备本地TF卡里，通过K8s的DaemonSet同步到主节点。这方案虽然土，但实测吞吐量能达到每秒2000条数据，足够工业场景用了。

最让我意外的是资源利用率。传统x86服务器跑200个Pod，CPU占用率轻松到60%；而三台树莓派组成的集群跑50个Pod，CPU占用率才30%——不是因为ARM更强，而是K8s在低配设备上会自动限制资源调度。比如我故意把某个Pod的CPU请求设成2核，K8s直接拒绝调度，说"节点资源不足"，但实际树莓派还有1.5核空闲。这种"强制节制"的机制，反而让集群更稳定——不像x86服务器，经常因为某个Pod抢资源导致整节点崩溃。

当然，失败案例也不少。有次我试图在开发板上跑K8s的Dashboard，结果UI加载花了5分钟，浏览器直接卡死——后来查日志，发现Dashboard的前端依赖太多，光是Node.js就占了400MB内存。还有次升级K8s版本，新版本的kube-proxy和旧版的Calico冲突，导致所有Pod的网络中断，花了整整两天才回滚成功。这些坑让我明白：嵌入式设备跑K8s，不是"能不能"的问题，而是"值不值得"——如果场景对延迟不敏感（比如传感器数据采集），对可靠性要求不高（允许偶尔重启），那绝对值得试；但如果是金融交易、自动驾驶这种场景，还是老老实实用x86服务器吧。

现在这项目还在跑，客户已经把方案推广到了5个工厂，总共部署了200+台嵌入式设备。他们反馈说，硬件成本确实降了，但运维成本涨了——因为嵌入式设备的故障率比x86服务器高3倍，经常需要现场更换设备。不过这也在意料之中——毕竟用200块的设备干2000块设备的活，总得付出点代价。

文章配图，仅供参考

（编辑：站长网）

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