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

去年11月份，我接了个活儿——帮某工业物联网厂商把K8s集群塞进他们的嵌入式网关设备。那设备啥配置？ARM Cortex-A53四核，1GB内存，32GB eMMC存储，跑着定制版Linux。厂商原话是：“我们想用K8s管设备上的微服务，但市面上没现成方案。”我翻了下他们的需求清单：要支持动态扩缩容、服务发现、健康检查，还得能跑在资源比树莓派还抠搜的设备上。

传统思路肯定不行——标准K8s节点至少得2核4GB内存，光etcd和kubelet就能把嵌入式设备的CPU榨干。我翻了三个月源码，发现K8s的“轻量化”其实是个伪命题——它的设计初衷是管理云服务器，根本没考虑过资源受限场景。但有个细节让我眼睛一亮：K8s的组件其实可以拆解——kubelet负责节点管理，kube-proxy处理网络，etcd存集群状态，这些模块未必得全装在一台设备上。

我做了个激进方案：把etcd和API Server拆到云端，设备上只跑kubelet和轻量级CNI插件（用Flannel的简化版）。但第一次测试就炸了——设备启动kubelet后，内存占用直接飙到800MB，剩下200MB连个Nginx都跑不起来。更糟的是，设备重启后，kubelet总卡在“ContainerRuntimeStatus”错误，查日志发现是Docker Daemon启动太慢，被kubelet当成了“未就绪”。

文章配图，仅供参考

但新问题又来了：设备断电重启后，kubelet偶尔会“失忆”——忘记之前部署的Pod配置。我扒了K8s源码，发现是kubelet的“Pod Manifest”文件在重启后没被正确加载。最后我在设备上加了个“启动守护进程”：每次重启后先检查/var/lib/kubelet/config.yaml是否存在，不存在就从云端重新拉取配置。这招虽然土，但实测有效——连续重启10次，Pod恢复成功率100%。

现在这方案已经跑在2000多台设备上，平均每台设备跑5-8个容器，CPU占用不超过70%，内存占用稳定在850MB以下。最让我意外的是，有台设备在-20℃的冷库里跑了3个月没重启，kubelet和容器都没挂——这比很多云服务器的稳定性还强。

有人说我这是“强行把大象塞进冰箱”——K8s本来就不是为嵌入式设计的。但我的主观判断是：在资源受限设备上跑K8s，不是“能不能”的问题，而是“怎么跑”的问题。传统嵌入式开发用静态编译+进程管理，但微服务时代需要动态调度、服务发现、自动扩缩容——这些功能，除了K8s，还有哪个开源方案能同时满足？

当然，这方案也有局限——比如设备必须联网（得连云端etcd），比如不支持复杂网络策略（只用了最简单的Flannel）。下一步我打算试试把etcd也塞进设备——用单节点模式，内存占用能压到100MB以内。要是成了，那嵌入式设备的“云原生”就真成了。

（编辑：站长网）

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