K3s轻量级Kubernetes实战：边缘计算场景下的部署与优化

K3s轻量级Kubernetes实战：边缘计算场景下的部署与优化

发布时间：2026/10/8 2:31:05
K3s轻量级Kubernetes实战：边缘计算场景下的部署与优化 1. 为什么完整版Kubernetes在边缘场景经常跑不动1.1 边缘节点和云端节点在资源禀赋上的落差先说个我实际遇过的场景。工厂车间一台4G内存的工控机原来跑着一个单机版监控服务后来业务要上容器编排我照着云上的习惯直接上了标准Kubernetes。装完那一刻内存还剩不到2.5Gkubelet、etcd、kube-apiserver这几个组件在系统里互相抢CPU机器温度都上去了。运行了大概一周节点开始随机NotReady查日志发现是etcd的磁盘IO和内存压力在折腾维护成本比业务本身还高。这不是个例。边缘计算节点的硬件配置通常就是树莓派44G或8G内存、工业网关2~4G内存、嵌入式工控机、车载计算单元这些东西。而标准Kubernetes的控制面光etcd在三节点集群里就要占掉相当可观的内存和磁盘写入带宽单控制面节点跑起来至少需要2G内存才敢说从容。再加上网络插件、DNS、Ingress Controller、监控组件一台边缘小机器还没跑业务就先被基础设施压垮了。所以问题从来不是Kubernetes不好用而是在错误的场景里用了完整版。边缘节点要的是能跑容器、能调度、能自愈、能离线存活而且最好只占用很小一块资源的编排系统。轻量级Kubernetes就是为这种需求出生的而K3s是目前这个生态里用得最多、社区迭代最活跃的那个发行版。1.2 资源和运维之外还有网络这道坎边缘场景还有另外两个容易被云原生老手忽略的痛点。第一是运维半径。云端集群一般有专职平台团队升级、证书轮换、故障恢复都可以由专门的人来处理。但边缘站点往往上百个散布在各地每个站点可能只有一台设备没有专职运维。如果每台设备都跑一套完整Kubernetes光是证书过期、组件升级、etcd压缩策略这些问题就够运维团队喝一壶的。K3s把控制面压成单进程、把证书轮换做成自动化就是为了让没有专职运维的环境也能跑得起Kubernetes。第二是网络隔离。很多工业现场、野外基站、海上平台压根没有稳定的公网连接甚至完全离线。标准Kubernetes的部署和升级高度依赖从镜像仓库拉取组件离线环境下操作成本极高。K3s的安装包可以整体搬运到内网支持完全离线的air-gap部署这一点在边缘场景里是刚需中的刚需。2. K3s轻量化的核心设计一个集群是怎么被塞进小机器的2.1 Kine用SQL把etcd换掉这是最狠的一刀K3s最激进的改动是默认不跑etcd。Kubernetes的kube-apiserver把集群状态存在etcd里而etcd本质上是为分布式一致性设计的强一致KV存储内存和磁盘开销都不小。K3s用了一个叫Kine的项目在API Server和存储之间做了一个翻译层把etcd风格的watch、事务操作翻译成普通SQL语句默认落到节点上的SQLite里。如果你读过《深入理解Kubernetes源码》里关于存储层的那部分就会明白Kine本质上是在重新实现etcd存储插件需要满足的那套接口Watch、Create、Update、Delete、List。SQLite充当后端时每次watch到变更都会变成一轮SQL查询事件的推送粒度从etcd底层的流式通知降级成了轮询加比对。这对边缘集群来说完全够用因为边缘节点上的对象数量通常很少几百个Pod、几十个ConfigMapSQLite承载这种量级的读写毫无压力但省下的内存和进程数却是实打实的。代价也在这里埋下了SQLite的写入锁粒度粗不支持高并发写而且Kine这种翻译层天生就不适合大量高频状态变更的场景。你的业务如果频繁创建/更新大量CRD对象API Server的写请求会直接打在存储层上SQLite这时候会成为明显的瓶颈。后面我会专门讲什么时候该换回etcd。2.2 单二进制架构一个进程干完控制面的活K3s第二个关键设计是单二进制。标准Kubernetes的控制面由kube-apiserver、kube-controller-manager、kube-scheduler、kube-proxy、etcd这些独立进程组成每个进程都要单独维护、单独监控、单独升级。K3s把这些组件全部编译进一个二进制文件里安装后在系统里看到的就是一个叫k3s的进程。这个设计带来的好处是运维模型被彻底简化了。节点上只要确保一个二进制文件版本正确升级就是换文件、重启服务这两步。进程数量减少直接带来内存占用下降这也是K3s敢说512M内存可以跑起来的主要原因之一。对比一下完整版K8s控制面空载状态轻轻松松吃掉1.5G以上内存K3s空载时通常可以控制在几百MB级别中间差出来的资源就是业务容器的空间。这里补充一个细节K3s默认使用内嵌的containerd作为容器运行时不再额外装Docker。对边缘设备来说少一个Docker守护进程也是实打实的资源节省。当然它也保留了docker作为CRI的兼容选项但默认路径就是最省资源的那条。2.3 内置的组件策略开箱即用而不是开箱选型完整版Kubernetes装完只是个空壳后面的CNI、Ingress、StorageClass、DNS、监控指标全都要你自己选型安装。K3s的策略反着来把边缘场景最常见的一批组件直接内置。Ingress默认装好Traefik一条Ingress规则就能把流量打进来。Service LoadBalancerK3s自带klipper-lb在裸金属和边缘节点上能给Service分配一个本机端口模拟LoadBalancer语义。本地存储内置local-path-provisionerPod声明PVC时自动在节点磁盘上创建目录对单机边缘场景非常实用。DNS集群内解析CoreDNS直接配好Pod之间用服务名互相访问开箱即用。Helm控制器用HelmChart定义的方式维护集群内置组件省去手动helm install一堆杂事。这套全家桶策略在云端可能会被吐槽不够定制化但在边缘场景里非常合理。边缘工程师往往不是专职K8s运维他们要的是装完就能跑业务K3s默认给他们一套可用的最小可用集群。大部分组件都可以通过--disable参数关掉需要自定义的时候再换成自己的方案。2.4 轻量化不是白来的缩水项必须心里有数K3s做减法的同时有些能力是明确被舍弃或弱化的。我之前踩过坑才意识到这些不是K3s的bug而是设计取舍存储能力默认是单机磁盘local-path没有副本概念磁盘坏了数据就没了。边缘单机接受这个风险但数据库类任务不能这么干。SQLite不是网络存储多节点共用一个数据目录的那套玩法不存在高可用必须另配存储后端后面细说。内置的Traefik版本和社区最新版可能有差异部分高级路由注解不生效。去掉了一些云厂商相关的provider代码公共云上想用云盘、云LB要么开外挂配置要么换标准K8s。我的经验是把K3s当成为边缘和受限环境定制的Kubernetes而不是功能残缺的Kubernetes用它的默认能力去匹配业务需求踩坑概率会小很多。3. 实操演示三行命令拉起K3s集群并部署Nginx3.1 安装前的环境准备与自检我在实验室里用两台虚拟机演示一台作为server节点2C4GUbuntu 20.04一台作为agent工作节点2C2G。先把系统基础环境准备好sudo apt update sudo apt install -y curl df -h /var/lib/rancher # K3s数据默认放在这里确保有5G以上空闲然后是K3s提供的一个体检工具安装前看当前环境是否满足运行条件sudo k3s check-config这个命令会检查内核模块、cgroup配置、iptables、swap等一堆项。如果输出里有标红的Warning先处理掉再装。最常见的是swap没关或者overlay内核模块没加载装完才发现的坑比提前发现要难处理得多。3.2 Server节点安装官方安装脚本一行搞定curl -sfL https://get.k3s.io | sh -s - --write-kubeconfig-mode 644--write-kubeconfig-mode 644是为了让当前用户直接读kubeconfig不需要每次操作都sudo。安装脚本做完的事情包括把k3s二进制放到/usr/local/bin、创建/etc/rancher/k3s/k3s.yaml、注册systemd服务并启动。装完后验证export KUBECONFIG/etc/rancher/k3s/k3s.yaml k3s kubectl get nodes这时候应该看到server节点状态为Ready。注意这里用的是k3s kubectl因为K3s把kubectl客户端也打包进同一个二进制里了不用另外装kubectl。如果你本机已经有kubectl直接用kubectl --kubeconfig /etc/rancher/k3s/k3s.yaml也可以。3.3 加入Worker节点在边缘场景里一个站点往往是1台server 若干台agent的形态。在server节点上先拿到tokensudo cat /var/lib/rancher/k3s/server/node-token然后到agent节点上执行curl -sfL https://get.k3s.io | K3S_URLhttps://192.168.1.10:6443 K3S_TOKEN你的token sh -等一两分钟回到server节点验证k3s kubectl get nodes -o wide两个节点都应该Ready。这里说个经验边缘agent节点和server之间的网络质量往往不好如果加入失败先别急着重装仔细看journalctl -u k3s-agent的日志十次里有八次是6443端口没通或者token抄错了。3.4 部署第一个工作负载Nginx集群起来了最快验证业务跑通的方式就是部署一个Nginx并暴露端口kubectl create deployment nginx-demo --imagenginx:alpine --replicas2 kubectl expose deployment nginx-demo --port80 --typeNodePort kubectl get svc nginx-demoNodePort默认分配的是30000以上的端口拿到端口号后直接访问curl http://192.168.1.11:307xx能看到Nginx默认首页就说明整个链路通了。如果想让入口更优雅一点可以用K3s自带Traefik因为默认装好了直接建一条Ingress以外的方式其实很多kubectl create ingress nginx-demo --rulenginx.demo.local/*nginx-demo:80然后在访问端把域名解析到任意节点IP或者加hosts记录就能通过Traefik访问服务了。4. 边缘场景里的真实形态边缘智能、实训设备与轻量工作流4.1 边缘智能把AI推理从云端搬到现场边缘智能这个词这几年很热核心逻辑很简单如果所有计算都在云端完成数据来回传输的延迟可能几百毫秒工业质检、AGV调度、视频安防这类实时性要求高的场景根本等不起。所以AI模型不能只放在云端服务器上必须下沉到靠近数据源头的地方让推理在本地完成云端只承担训练和下发模型的工作。K3s在这种架构里扮演的角色是现场的运行时和调度器。一套典型的边缘智能部署大概是这样的K3s节点上跑着模型推理容器通过设备插件把GPU、NPU或VPU算力挂载进容器输入侧有摄像头或传感器容器通过RTSP或者MQTT把数据流喂给推理服务输出侧接本地告警或断点续传把关键结果异步回传云端。模型更新时云端推送新镜像K3s完成滚动更新。算力敏感型任务通常用工业PC或带GPU的边缘盒子这类设备的内存虽然比树莓派大但和云服务器还是没法比。K3s在这个位置的优势是占资源少多出来的算力可以给推理模型节点自治能力强断网的时候本地容器继续跑网络恢复后再同步状态。4.2 工业互联网边缘计算实训箱教学设备里的隐藏主角我接触过不少做工业互联网实训设备的厂商他们的产品形态是边缘计算实训箱一个加固机箱里装着一块边缘计算板卡、若干工业传感器接口模块和一套预装好的软件环境用来给高职院校和企业培训用。这类设备有个共性——配置不高无法承载完整K8s但教学大纲里又必须涉及容器编排、微服务部署、工业协议转换这些云原生概念。K3s几乎成了这类实训箱的默认基础设施。原因很简单实训箱是让学生反复折腾的经常被玩坏、被重置K3s的单二进制安装和卸载都很干净重装一套只要几分钟。而且课堂上通常跑的是Modbus采集、OPC-UA网关、边缘算法等轻量容器K3s完全撑得住。如果你做类似设备把K3s预装进镜像里让学生从kubectl基础命令开始学比让他们先折腾etcd集群友好太多。4.3 轻量级工作流和开源边缘平台边缘站点也需要自动化。很多团队用K3s承载轻量级工作流引擎比如把Tekton、Argo Workflows这类流水线框架跑在单节点的K3s上实现边缘侧的定时任务、模型更新流水线、数据清洗作业。这些工作流调度框架在完整K8s上很重但在K3s上跑反而刚刚好——低资源、秒级调度、够用的持久化。另外边缘计算开源平台这个方向上K3s也经常充当底层底座。像OpenYurt、SuperEdge这类面向边缘的Kubernetes增强项目它们关注的是边缘自治、云边协同、单元化部署这些上层能力而不是重造一个容器编排内核。在这些项目的部署拓扑里边缘侧节点往往就用K3s充当轻量级Kubernetes发行版云端保留完整K8s控制面。5. 同类轻量级方案横向对比K3s、k0s、microk8s、minikube怎么选5.1 主要候选方案特点我这些年把市面上的轻量级方案基本都用过一轮整理了一张对比表供参考方案维护方安装方式组件策略最适合的场景K3sSUSE/Rancher生态脚本或二进制支持离线包内置Traefik、ServiceLB、local-path等边缘生产、资源受限设备、Rancher托管k0sk0s开源社区单二进制极简默认只带containerd其余自己装需要高度定制、合规要求严的运维团队microk8sCanonicalsnap命令安装插件式按需enable/disableUbuntu生态下的开发测试、小团队预生产minikubeKubernetes社区二进制或包管理器默认最小集插件丰富本机开发、学习kubectlkindKubernetes社区Docker容器模拟节点无内置附加件本地CI、测试Kubernetes版本兼容性这里多说一句k0s。它和K3s在很多方面很像也是单二进制搞定控制面也支持外部存储后端做高可用。但k0s默认不给你内置任何Ingress、存储、负载均衡这意味着你要从头选型安装。对喜欢掌控一切的标准化团队这是一个优点对想尽快跑业务的边缘工程师K3s的开箱即用更实在。K3s名字的由来也是个有意思的梗K8s砍掉5个字母变成K3s意思是比Kubernetes轻一半还多。5.2 按场景给出选型思路我给周围朋友的建议一向很直接边缘生产设备、需要长期无人值守运维的优先K3s。组件齐全、升级路径成熟、出问题能搜到大量实践案例这是其他轻量级方案比不了的生态优势。公司内部对组件选型卡得非常死、所有组件都要自己定制的看k0s。它天生就是干净的Kubernetes不带任何偏见。纯粹自己电脑上学习、练手或者CI里快速起集群验证代码用minikube或kind别占着边缘设备折腾。如果整个公司已经在用Rancher管理集群那边缘侧无脑K3sRancher对K3s的支持深度是原生级别的。补充一个容易被忽略的点K3s现在也是CNCF生态里的重要项目这意味着它不是某个公司的闭源玩具而是有独立治理和大量社区贡献的开源项目。选型时这一条可以减少很多会不会突然没人维护的顾虑。6. 生产环境里的坑与调优清单写在最后面的干货6.1 SQLite写入瓶颈和正确的高可用姿势K3s默认用SQLite看似省事但一旦业务对API Server的写请求密集起来问题就来了。我遇到过调度大量Job的场景每分钟要创建几百个Pod对象控制面CPU没爆但K3s的API响应开始变慢Pod创建时间明显拉长。最后查下来瓶颈就是Kine把高频写操作翻译成SQLite的串行写入事务排队严重。如果你的边缘业务也存在类似的高频状态变更或者你想构建一个多server的高可用集群建议直接用内置的嵌入式etcd模式。在第一个server节点上初始化curl -sfL https://get.k3s.io | sh -s - server --cluster-init后面的server节点按普通server方式加入但要把--server指向第一个节点并带上集群token。三台server组成嵌入式etcd的高可用集群后控制面具备多数派容错能力存储层也从SQLite换成了真正的etcd。代价是多占一些内存和磁盘但换取的是稳定性和容错能力这笔账在关键业务上很划算。6.2 证书轮换和升级路径别拖到过期才发现K3s默认签发的证书有效期是一年。虽然它内部做了自动轮换逻辑但我在早期版本上遇到过kubeconfig里admin证书过期导致无法访问集群的情况。遇到这类问题别慌两个处理思路一是手动轮换执行下面命令后重启服务sudo k3s certificate rotate sudo systemctl restart k3s第二个思路是直接升级到新版本。K3s的升级模型很简单重新跑一遍安装脚本并指定版本号curl -sfL https://get.k3s.io | INSTALL_K3S_VERSIONv1.28.5k3s1 sh -脚本会把新版二进制放到/usr/local/bin并重启服务。我要强调的教训是边缘节点没有专职运维盯着证书过期这种事最容易发生最好在监控里设置一个证书剩余有效期60天的告警别等到Kubectl连不上再排查。6.3 小内存小磁盘设备的资源规划经验K3s虽然轻也不是无底洞。在我那些4G内存、32G硬盘的设备上长期稳定运行靠的是这几个参数curl -sfL https://get.k3s.io | sh -s - \ --write-kubeconfig-mode 644 \ --disable traefik \ --kubelet-arg system-reservedcpu200m,memory200Mi \ --kubelet-arg eviction-hardmemory.available300Mi--disable traefik这一步很多人不理解做边缘业务时我经常不想要默认的Ingress因为边缘侧流量入口往往是MQTT或私有协议用不到HTTP路由关掉能省几十MB内存。system-reserved和eviction-hard是给kubelet划定底线防止业务容器无限吃内存把系统拖死。还有一个容易忽略的local-path的PV默认落在/var/lib/rancher/k3s/storage小硬盘设备上跑日志容器或者模型文件缓存很容易把根分区写满建议提前把这个目录挪到大容量分区或者单独挂载。6.4 离线部署边缘场景里最实用的技能最后讲离线部署这是边缘项目和云端项目最大的差异点。很多边缘现场没有公网或者只有极差的窄带网络安装脚本远程拉包这条路直接堵死。K3s支持完整离线安装我常用的流程是在一台能上网的机器上下载离线镜像和二进制# 从GitHub Release拿到k3s二进制和k3s-airgap-images-amd64.tar把文件拷到目标节点后镜像放到指定目录sudo mkdir -p /var/lib/rancher/k3s/agent/images/ sudo cp k3s-airgap-images-amd64.tar /var/lib/rancher/k3s/agent/images/然后跳过下载直接本地安装sudo cp k3s /usr/local/bin/ sudo chmod x /usr/local/bin/k3s INSTALL_K3S_SKIP_DOWNLOADtrue ./install.sh安装脚本和二进制、镜像包一起打包整套东西几百MB左右用U盘或者内网共享盘就能分发到所有边缘站点。我现在的习惯是每次升级都在本地准备一套离线包不管现场有没有网先保证能装、能升、能救急。最后说点个人的体会。K3s解决了我很大一部分边缘上也想用Kubernetes的诉求但它不是银弹。我现在的选型原则很朴素节点的资源越紧张、站点数量越多、专职运维越少就越优先考虑K3s凡是核心数据库、强一致缓存这类需要高写入性能的场景就不要指望默认的SQLite扛着动手换上嵌入式etcd或者干脆用完整版。理解了它做的每一个取舍你就不容易在边缘场景里翻车。