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

　　去年八月份那会儿，运维老张在群里@我三次，说边缘网关的K8s集群又炸了——这次是内存泄漏，三百多台设备全卡成狗。我原以为又是哪个Pod的OOM Killer没调好，结果翻日志发现，这帮孙子居然在资源受限的嵌入式设备上跑标准版K8s！那堆CNI插件、kube-proxy、etcd，光启动就占了一半内存，剩下的全被Docker的storage driver吃光，设备连心跳包都发不出去，监控系统直接黑屏。

　　后来我们硬着头皮试了K3s，结果更离谱——它确实轻量，但安全模块砍得太狠。有次设备被扫出CVE-2023-28840，想打补丁才发现K3s的镜像仓库连签名验证都没开，补丁包直接被中间人替换成挖矿程序。老张蹲在机房里骂了半小时街，说这帮搞轻量化的根本不懂安全：“安全是成本不是收入，但成本砍到骨头里，设备被黑了算谁的？”

　　那天深夜十二点，群里突然@全员，说某省运营商的网关集体掉线。我翻日志看到一堆眼熟的IP——185.143.223.x，这串数字上个月刚在蜜罐里出现过，明显是同一拨人在扫。可等我们想溯源，发现设备上的审计日志全被K3s的默认配置清空了，连攻击者的UA头都没留下。老张拍桌子：“这他妈叫轻量化？这叫裸奔！”

　　后来我们自己魔改了一套方案：用MicroK8s当底座，砍掉所有非必要组件，只留kubelet和apiserver，CNI插件换成自研的，把iptables规则硬编码进内核模块。安全组那边死活不同意，说“不符合K8s官方规范”，我直接把设备内存使用截图甩他们脸上：“规范能当饭吃？这堆破铜烂铁总共才2G内存，你们的标准版K8s启动就要1.5G，剩下的500M连个Nginx都跑不起来！”

　　上周去现场调试，发现设备根目录下多了个“tmp_update.sh”的文件，权限还是777。我第一反应是又被黑了，结果老张说这是运维小哥手滑上传的补丁脚本，忘记删了。我盯着那文件看了半天，突然乐了——这要是在标准版K8s上，早被RBAC规则拦住了，可我们的轻量版连RBAC都没开，全靠iptables硬封。老张在旁边冷笑：“所以说安全是成本，但有时候没成本反而更安全——至少不会被自己人绕晕。”

　　现在最头疼的是镜像签名。标准K8s用Notary，可那玩意儿在嵌入式设备上跑起来跟蜗牛似的，我们只能自己写了个简易签名工具，用OpenSSL直接生成SHA256摘要，存到设备Flash里。安全组又跳出来说“不符合OCI规范”，我直接怼回去：“规范是给人看的，不是给设备用的。这堆网关连个正经时钟都没有，你让它们怎么验证证书有效期？”

　　昨天老张发来张照片——某运营商的机房里，三百多台设备整齐排列，每台前面都贴了张纸条：“轻量K8s试验田，非战斗人员请勿触摸”。我盯着那纸条看了半天，突然想起上个月被DDoS攻击的事：攻击者发了三百多万条伪造的kubelet请求，标准版K8s的apiserver直接被打死，而我们的轻量版因为砍掉了kube-proxy，所有请求全被丢进黑洞路由，设备连个包都没丢。老张在电话里说：“这他妈才叫安全——不是靠堆功能，是靠砍功能。”

　　现在的问题是，这种“砍功能式安全”到底算不算安全？上周安全大会上，某大厂专家说“轻量化是未来趋势”，可他展示的案例里，设备被黑后连日志都没留下，全靠外部流量分析溯源。我原以为这是技术局限，结果老张说：“人家那是故意留的——留了日志就要负责，不如直接砍掉，出了事往运营商身上一推，完美。”

文章配图，仅供参考

（编辑：站长网）

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