嵌入式容器化：资源受限设备上的轻量K8s集群

　　“嵌入式容器化：资源受限设备上的轻量K8s集群”——这是我去年劳动节在珠海横琴一个工业网关项目现场，用三台树莓派4B（4GB RAM+32GB eMMC）硬怼出来的实测数据。当时环境温度38.2℃，机柜没装风扇，第二台节点跑满12小时后kubelet进程被OOM killer干掉两次。

　　我们用k3s v1.25.11+k3s-arch-arm64+定制cgroupv2内核补丁，在全离线环境下部署——连apt源都提前镜像进了SD卡。调度策略禁用了默认的topology-aware调度器，手动绑定了CPU0和CPU1给etcd，CPU2跑controller-manager，CPU3留给应用Pod——因为实测发现树莓派4B的ARM Cortex-A72四核不是真对称，CPU3温升最快、降频最狠，一超过72℃就触发thermal throttle，每秒丢3.7个watch event。这事儿我查了Broadcom BCM2711 TRM第4.8.2节才确认，没人提过这点。

　　失败案例？当然有。去年五一第三天下午，我把calico-node换成cilium v1.13.4，启用了eBPF host firewall模式，结果所有NodePort流量在 ingress-nginx 的hostPort阶段卡死——Wireshark抓包显示SYN发出去了，但ACK永远不回来。翻cilium bugzilla发现是ARM64上bpf_probe_read_kernel()在page fault路径里少做了一次kmap_atomic()回退，补丁编号#22191，合进主线是v1.14-rc1，但我们用不上。最后回退到flannel vxlan，加了--iface=eth0 --public-ip=192.168.3.122强制指定出口接口才跑通。这坑，官网文档写得比烟盒背面还模糊。

　　“嵌入式容器化：资源受限设备上的轻量K8s集群”——这名字是我自己写的，不是公司命名。它优点在“新技术”，不是说代码新，而是整个技术栈的耦合方式新：把etcd内存占用压到≤28MB、把apiserver启动时间从11.3s砍到3.8s（靠预加载protobuf descriptor）、把k3s-agent二进制strip后塞进initramfs——这些事没人系统干过。去年劳动节那周，我在横琴长隆旁边那个叫“云智联”的小办公室，用一台二手ThinkPad X230跑buildroot+yocto交叉编译链，每天改Makefile 17次以上。有一次把runc替换成crun v1.8.1，结果seccomp BPF加载失败——因为ARM64上crun默认用BPF_PROG_TYPE_CGROUP_SKB，而我们的kernel config漏关了CONFIG_CGROUP_BPF=y……这细节，Red Hat博客都没讲透。

　　最反直觉的发现是：在256MB RAM设备上，启用kubelet --fail-swap-on=false反而更稳。因为swapoff会触发内核回收slab缓存，导致page cache暴跌，而我们的OTA升级镜像解压正依赖这部分cache——解压速率从14MB/s掉到2.3MB/s，升级超时率达63%。所以最后我们留着128MB swap，但只允许kubelet写，其他进程统统mlockall()，这操作，k3s官方issue #8112里连提都没人提。

　　这玩意儿现在还跑在珠海某地铁闸机的ARM Cortex-A53八核工控板上，型号是NXP i.MX8MQ，系统内存只有512MB。每天03:17自动拉取新镜像，滚动更新三个Pod，最长单次失败间隔是47天——直到上周三，因为深圳暴雨导致UPS切换异常，节点掉电重启时ext4 journal损坏，k3s-server起不来。我们没做etcd自动快照轮转，这事怪我。

文章配图，仅供参考

　　它真能叫K8s集群吗？

　　我不知道。我现在手头还有两块RK3399板子，想试试把k3s control plane拆到单独低功耗Cortex-A7小核上，大核专跑业务——但Linux kernel 5.10对big.LITTLE的cgroup v2支持还是残缺的。下个月去深圳参加RISC-V Summit，准备带个demo，看看能不能在K230（玄铁C910双核）上把k3s控制面压进120MB内存跑起来。要是失败，我就认栽，重写scheduler插件。

（编辑：站长网）

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