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

　　去年5月，我在上海临港某工业网关项目上硬塞进一个 k3s 1.26.4 + containerd 的组合——设备是 NXP i.MX8MQ，2GB RAM，eMMC 8GB。实测启动耗时 14.7 秒（含 initramfs 解压、cgroup v2 挂载、k3s server 初始化），比用 Yocto 构建的传统 systemd 服务多花 3.2 秒，但热更新部署时间从平均 92 秒压到 17 秒。这个数字不是理论值，是我拿逻辑分析仪抓的 bootup 时间线。

　　k3s 的 kubelet 默认开 20 个 concurrent-sync，而我们那个边缘摄像头模块只跑一个 gstreamer 推流 Pod——结果 CPU 调度器疯狂抖动，top 显示 kubelet 占用 42% CPU（ARM Cortex-A53 @1.5GHz）。砍到 3 个 sync 后回落至 9%，但 Pod 驱逐延迟飙升到 8.3 秒——这直接导致断网重连时漏推 2～3 帧关键图像。你敢信？官方文档压根没提这个阈值敏感性。

　　试过 microk8s —— Ubuntu Core 那套 snap 隔离机制在 eMMC 上写放大严重，连续 OTA 3 次后擦写计数跳升 117%；换成 k3s 自带的 sqlite3 backend，相同操作只涨 4.2%。不过 sqlite 在并发写入 >12 QPS 时会报 “database is locked” 错误——这是我自己加日志埋点、在 /var/log/k3s-server.log 里 grep 出来的错误链，别人写的教程从不提 sqlite 和 journalctl 冲突这件事。

　　去年5月调试期间，我们曾把 k3s node 静态编译进 uImage 镜像，试图实现“内核级容器运行时”。结果发现 Linux 6.1 的 cgroup controller 支持有残缺：memory.low 在低内存下完全不生效，memcg 子系统把 128MB 硬限制当摆设，Pod OOM kill 触发点漂移到 214MB——实测值。最后只能退回 cgroup v1，代价是丧失对 io.weight 的细粒度控制。说真的，这不是 bug，是内核配置裁剪留下的黑洞。

文章配图，仅供参考

　　用 Flannel host-gw 模式比 vxlan 快 1.8 倍，但必须手工改 iptables 规则绕过 conntrack —— 因为 conntrack 在 512MB RAM 设备上吃掉 137MB 内存，且 k3s 默认不关它。我翻了 12 个 issue 才找到 patch commit 8a1f4d3，在 build.sh 里加了 --disable-agent=false --flannel-backend=host-gw --disable=traefik,servicelb --no-deploy=metrics-server 这串参数组合，现在烧录镜像脚本第 7 行固定写着它。顺带一提，--disable-agent=false 这个反直觉开关，是让 agent 不接管主机 network namespace 的唯一办法，否则 eth0 会莫名其妙消失。

　　失败最狠的一次是尝试 runC 替换 containerd：自研精简版 runC 二进制 1.8MB，比 containerd 小 6.3MB，但启动一个 Alpine Pod 多耗 410ms ——因为 musl libc 的 getaddrinfo 在 DNS 轮询超时时卡死整整 387ms，strace 一看就明白。这事没人写，文档全在 Docker 社区一个关闭的 PR 里，编号 #42778，2022 年 9 月提交，被标记为“won't fix”，理由是“embedded isn’t a supported platform”。呵。

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

　　新技术

　　目前我把 cert-manager 降级到 v1.8.2，因为 v1.11+ 用了动态 client-go discovery，初始化要读 11 个 apiGroups 列表——在 100Mbps LAN 下耗时 3.1 秒，而我们网关经常只有 30Mbps 实际吞吐。现在改用手动生成 CA+ static secret 注入，部署快了但失去自动轮转能力。接下来想试 k0s 的 lite 模式，不过它要求 kernel >=5.10，我们的产线芯片 SDK 锁死在 5.4.70……先等 NXP 下季度补丁包吧。

（编辑：站长网）

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