引言：管一百台工控机，比管一百台服务器难多了。

服务器都在恒温恒湿的机房里，网络稳定、电源可靠、有人值守。工控机呢?有的在高温车间，有的在户外机柜，有的在振动的产线上。当边缘节点从几台扩展到几十上百台时，单机部署的路子就走不通了——每个节点都得单独管、单独升级、单独排查故障，运维团队就算天天加班也忙不过来。K3s的出现，让Kubernetes在资源受限的边缘设备上真正扎下了根。

一、为什么原生K8s在边缘场景“水土不服”?

在受限网络中，原生Kubernetes往往扛不住。K3s的精髓就在于“做减法”，把K8s里那些在边缘用不上的组件统统裁剪掉。K3s默认使用嵌入式SQLite替代etcd，大幅降低内存占用;单二进制部署，将Kubelet、API Server等多个组件集成到一个文件中;无需外部依赖，Agent节点最低只需512MB内存即可运行。

通过结合坚固的硬件(如联想ThinkEdge服务器)与SUSE Edge的自动化能力，已经能够实现几乎零人工干预的RKE2/K3s集群部署蓝图。K3s单命令即可一键部署，自动集成容器运行时(containerd)和网络插件(flannel)等核心组件，无需外部etcd集群(默认使用嵌入式SQLite数据库，支持etcd/PostgreSQL集群化部署)。

二、从零搭建多节点K3s集群：Server节点与Agent节点的分工配置

部署K3s集群需要合理规划硬件资源：Server节点建议2-4核CPU、4GB内存以上，Agent节点1-2核CPU、2GB内存基本够用。存储介质务必使用SSD，以加速镜像拉取和容器启动。网络环境要求所有节点在同一二层网络内互通，开放API Server的6443端口和Kubelet的10250端口，产线工控机建议分配固定IP。

搭建步骤包括：在Server节点安装并配置K3s、获取节点Token、在各Agent节点上加入集群、验证集群状态并部署测试Pod。针对Arm64架构的边缘场景，利用RK3399等开发板和K3s构建低成本Arm64边缘集群是一种可行路线。在离线环境下，提前构建私有镜像仓库、预拉取K3s组件是关键一步。

三、节点标签、资源配额与调度策略：让每台工控机物尽其用

在边缘集群中，工控机的硬件配置参差不齐。通过kubectl label nodes给节点打上业务标签和位置标签，利用nodeSelector或affinity规则精准调度。同时，利用ResourceQuota和LimitRange为每个命名空间设置资源上限，防止某个业务容器耗尽整台边缘主机的内存。在K3s环境中，还可以结合Pod的priorityClassName和topologySpreadConstraints要求同服务的Pod尽量分散在不同节点，确保资源紧张时优先保障关键业务。

四、典型案例：跨园区多产线容器集群管理

案例名称：某电子制造企业跨园区边缘计算集群建设

需求痛点：三个园区、几十条产线，每台工控设备分别负责质检、数采和设备控制，版本五花八门，升级一拖就是一整天。一个新模型发布，得派人到三个园区的几十台设备上一台台手动更新，耗时费力的同时，版本一致性也根本没法保障。

解决方案：在每个园区内部署由3-5台 N-BOX-S7 -工业主机组成的K3s集群。搭载 Intel Alder Lake-N系列处理器，全金属无风扇机壳适应产线车间环境。多Server节点高可用架构实现控制平面冗余，AI推理应用以Deployment形式部署，集群自动处理Pod调度和故障自愈。采用Rancher统一管理全部边缘集群，实现跨园区的集中管控。

应用效果：所有产线容器化应用通过Rancher管理界面统一管控，无需登录每台设备手动操作。新版本发布实现滚动更新，生产不停机;节点故障后Pod自动迁移至健康节点，整体系统可用性提升至99.95%。运维人力成本降低约40%。

写在最后~~~

K3s边缘集群是否适合您的产线规模?欢迎留言分享您的想法。您目前管理多少台边缘工控机?是否已经用上K8s/K3s?留下您的需求和联系方式，技术团队将为您规划集群架构。