读完前面的系列文章，你可能会问一个问题：“你花了这么大篇幅讲自建边缘平台，但社区已经有 KubeEdge、K3s、Baetyl 这些云原生边缘方案了。我到底该自建还是直接用现成的？” 本文不站队，只做客观对比——帮你做出符合自己场景的选择。

---

一、开篇场景：两封邮件

周一早上，你收到了两封邮件。

第一封：“工厂 1~5 号产线的边缘网关已经部署完成，现在需要快速接入 300 台设备、配置本地数据清洗规则、对接 MES 系统。运维团队只有 2 个人，而且都是搞 PLC 出身的，不太懂 K8s。”

第二封：“公司战略决定统一技术栈为 Kubernetes。20 个数据中心集群已经跑在 K8s 上了，边缘节点也要纳入统一管理。我们有专业的 SRE 团队。”

同一个边缘计算方向，两个完全不同的约束条件。你的选型决策会是什么？

---

前置知识：如果你不熟悉 Kubernetes

这篇文章会频繁提到 K8s（Kubernetes）的概念。如果你来自嵌入式/IoT 背景而非云原生背景，这里是最精简的速览：

概念	一句话解释
Pod	K8s 的最小调度单元——一个或多个容器共享网络和存储，一起部署、一起销毁。可以粗暴理解为"一组打包好的容器"。
etcd	K8s 的"大脑数据库"——用 Raft 协议保证分布式一致性，存储集群所有配置和状态。边缘场景下它的内存占用和网络敏感度是问题。
Controller 模式	K8s 控制面的核心设计模式：你声明期望状态（我要 3 个 Pod），Controller 持续对比期望 vs 实际，不一致就纠偏。这就是我们第 10 篇 Reconciliation Loop 的思想来源。
kubectl apply	K8s 的命令行工具。“kubectl apply -f app.yaml” 就是把一个 YAML 描述的期望状态提交给集群。
Helm Chart	K8s 的包管理器——把多个 YAML 文件打包成可配置、可版本化的安装包，类似 apt/brew。

你不需精通 K8s 才能读懂本文——我们的目的恰恰是帮你判断什么情况下值得引入 K8s 的复杂性。

---

二、三个主流方案速览

2.1 KubeEdge——K8s 原生的边缘扩展

KubeEdge 是 CNCF 沙箱项目（华为开源），核心思路是把 K8s 的控制能力延伸到边缘：

云端                           边缘
┌──────────────┐          ┌──────────────┐
│  K8s Master  │          │  EdgeCore    │
│  - CloudCore │◄─MQTT───►│  - EdgeHub   │  设备
│  - API Server│  WebSocket│  - MetaMgr   │◄─MQTT
│  - etcd      │          │  - DeviceTwin│  协议适配
└──────────────┘          └──────────────┘

KubeEdge 的核心价值：

• 用 kubectl apply -f 管理边缘应用（熟悉的 K8s 体验）
• 边云通道走 WebSocket/MQTT，自动应对 NAT/防火墙
• 边缘节点离线后本地自治（Edged 管理 Pod 生命周期）
• 内置设备孪生（Device Twin），不用自己实现设备影子

关键认知：KubeEdge 的"自治"是有限的——离线后 Edged 可以保持已有 Pod 继续运行，但无法创建新 Pod、无法调度新应用。因为创建 Pod 需要 API Server（在云端），而边缘和云端之间的网络断了。如果你的场景是"边缘节点可能要断网 30 天，并且期间可能需要部署新应用"，KubeEdge 做不到。往下看 K3s。

2.2 K3s——完整的 K8s，全部在边缘

K3s 和 KubeEdge 有一个本质区别——K3s 的 Master 就在你的边缘盒子上，不在云端：

K3s 是 Rancher 开源的轻量 K8s（CNCF 沙箱项目），核心思路是把完整的 K8s 塞进 512MB 内存，全部跑在边缘盒子上：

┌─────────────────────────────────────────────┐
│  边缘节点（K3s 全栈运行在此盒子上）            │
│                                             │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐       │
│  │ Pod A   │ │ Pod B   │ │ Pod C   │       │
│  │ 采集模块│ │ AI 模块 │ │ 清洗模块│       │
│  └─────────┘ └─────────┘ └─────────┘       │
│                                             │
│  K3s Server（kube-apiserver + scheduler     │
│     + controller-manager 全在本地）          │
│  SQLite 替代 etcd（无网络分区问题）           │
│  containerd（替代 Docker 作为运行时）         │
│  flannel / traefik / coredns               │
│                                             │
│  ★ 不依赖云端，断网后完全自治                 │
└─────────────────────────────────────────────┘

K3s 的核心价值：

• 单二进制部署（< 100MB），一条命令启动完整 K8s
• 替换 etcd 为 SQLite，内存占用大幅下降，且无网络分区担忧
• 离线后完全自治——可以创建/删除 Pod、调度资源，不依赖任何云端服务
• 与标准 K8s API 完全兼容，Helm Chart、kubectl、Prometheus Operator 全部可用

2.3 本系列的自建方案

┌─────────────────────────────────────────────┐
│  边缘节点（自建平台）                         │
│                                             │
│  ┌─────────────────────────────────────┐   │
│  │ DeployMaster  │清单管理+状态机+协调  │   │
│  ├─────────────────────────────────────┤   │
│  │ MessageHub    │MQTT Broker+路由+缓存 │   │
│  ├─────────────────────────────────────┤   │
│  │ NodeCore      │模块生命周期+安全     │   │
│  ├─────────────────────────────────────┤   │
│  │ 业务模块      │EdgeRuntimeSDK 接入   │   │
│  └─────────────────────────────────────┘   │
│  基于 Go 微服务，进程/容器混合部署            │
└─────────────────────────────────────────────┘

2.4 Baetyl——AI 原生的边缘计算框架

Baetyl 是百度开源的边缘计算框架（LF Edge 项目），核心思路是把边缘做成一个"云端训练的模型、边缘推理执行"的一体化管道：

云端                             边缘
┌─────────────┐             ┌──────────────────────┐
│ 管理控制台   │             │  Baetyl Core         │
│ - 模块管理  │◄─MQTT/HTTPS─│  - Agent（守护进程）   │
│ - 模型下发  │             │  - Engine（编排引擎）   │
│ - 影子同步  │             │  - 函数计算运行时       │
└─────────────┘             │                       │
                            │  业务模块：            │
                            │  ┌─────────────────┐ │
                            │  │ 视频分析模块     │ │
                            │  │ (AI 推理管道)    │ │
                            │  ├─────────────────┤ │
                            │  │ 数据采集模块     │ │
                            │  └─────────────────┘ │
                            └──────────────────────┘

Baetyl 的核心价值：

• AI 推理原生——不是"你能跑镜像所以能跑 AI"，而是内置视频/图像处理管道、模型热更新、推理结果流转，百度 AI 的工业经验沉淀
• 函数计算——支持 Python/Node.js 脚本直接运行，不需要打包容器，适合快速原型和简单数据处理
• 模块影子——和本系列第 18 篇的设备影子同源，云边双向同步期望/实际状态
• 同时支持进程模式（Native）和容器模式（Docker/K3s），与你的策略模式思路一致
• 完全开源，不绑定百度云（可以接任何 MQTT Broker），Go 语言实现

Baetyl 和本系列方案最像的地方：都是用 Go 写的、都内嵌 MQTT、都支持多运行时、都有消息路由和模块管理。它的独特优势在于AI 场景的开箱即用——如果你的边缘业务以视频分析、图像检测为主，Baetyl 的 AI 管道比你自己从零搭建省几个月。

---

三、多维度对比

3.1 资源消耗

维度	KubeEdge	K3s	Baetyl	自建方案
最小内存	~256MB（EdgeCore 在边缘）	~512MB（Server 在边缘）	~128MB（Core）	~128MB（全部核心）
磁盘占用	~200MB	~1GB（全部 K8s 组件在边缘）	~100MB	~50MB
CPU 空闲负载	~5%	~8%	~3%	~2%
运行时依赖	containerd/Docker	containerd	Docker（可选）	无（可选 Docker）

Baetyl 和自建方案并列最轻——都基于 Go 静态编译，都可以纯进程模式运行。K3s 资源消耗最高，适合不敏感的高配节点。

3.2 学习曲线

角色	KubeEdge	K3s	Baetyl	自建方案
运维人员	需懂 K8s	需懂 K8s	懂 Docker + MQTT 即可	只需填 Web 表单
开发者	Dockerfile + K8s YAML	Dockerfile + K8s YAML	Python/Go 脚本或 Dockerfile	实现 EdgeRuntimeSDK 接口
调试	kubectl logs/exec	同 K8s 生态	内置日志 + 管理控制台	自建 Web 界面
社区支持	CNCF 沙箱，文档丰富	CNCF 沙箱，文档丰富	LF Edge 项目，中文文档多	无社区

K3s/KubeEdge 胜在 K8s 生态；Baetyl 胜在中文友好——文档大部分是中文，对国内团队阅读成本更低。自建方案需要团队自己维护知识体系。

3.3 离线自治能力

这是边缘计算最关键的维度。

能力	KubeEdge	K3s	Baetyl	自建方案
断网后模块继续运行	是	是	是	是
断网后新建/更新模块	否（需云端 API Server）	是（本地 Server 独立）	是（本地 Engine 独立）	是（本地 FSM + 清单缓存）
断网恢复后数据同步	Device Twin 同步	无内置	模块影子同步	离线缓存 + 自动补传
断电后自动恢复	是（本地元数据）	是（SQLite）	是（本地存储）	是（两阶段恢复）
离线安全决策	依赖云端	本地 RBAC 有效	本地认证有效	全本地（安全中间件在节点内）

K3s、Baetyl 和自建方案离线能力最完整——都能在完全断网的情况下独立管理本地应用。KubeEdge 的 Edged 可以管理已有 Pod，但创建新 Pod 需要连接云端的 API Server——Master 在云上，这是本质限制。

3.4 运维复杂度

方面	KubeEdge	K3s	Baetyl	自建方案
版本升级	云端+边缘两端升级	kubectl apply 滚动升级	管理控制台一键下发	9 步安全 OTA（第 23 篇）
故障排查	kubectl describe + 社区经验	kubectl describe + 社区经验	内置日志 + Web 控制台	自建诊断工具
安全更新	跟随 K8s CVE 修复节奏	跟随 K8s CVE 修复节奏	跟随 Baetyl 发版节奏	自己监控依赖库漏洞
HA	云端多 Master，边缘无 HA	可配多节点（但本架构只用单节点，HA 走平台层 keepalived，第 12 篇）	无内置 HA	keepalived 主备（第 12 篇）

K3s/KubeEdge 运维成本可控——因为踩过坑的人多，搜索引擎能找到答案。Baetyl 的中文文档和内置控制台对国内小团队更友好。自建方案的坑需要自己踩、自己填。

3.5 定制化能力

能力	KubeEdge	K3s	Baetyl	自建方案
Broker 内嵌流控	不支持	不支持	不支持	令牌桶 + 背压
离线消息缓存	Device Twin（限于状态同步）	无	模块影子（限于状态）	多文件循环队列
三级可靠性	不支持	不支持	不支持	LOW/MEDIUM/HIGH 分级
工业协议（OPC UA/Modbus）	插件机制	Helm Chart 部署	插件机制	插件工厂 + 原生支持
深度安全（TPM/SQLCipher/eBPF）	依赖 K8s Secrets	依赖 K8s Secrets	依赖系统安全	原生集成（第 7 篇）
AI 推理管道	无内置	无内置	内置（核心卖点）	需从零搭建（第 25 篇）
多运行时混合部署	仅容器（OCI）	仅 Pod	容器 + 函数	进程/Docker/K3s Pod 统一接口，一份清单三种跑法

自建方案最大的差异化优势是多运行时——KubeEdge 离不开容器、K3s 离不开 Pod、Baetyl 虽然支持进程但在 AI 场景才好用。你的方案通过策略模式（第 4 篇），同一份部署清单 type: process 走原生进程、type: docker 走 Docker 容器、type: k8s 走 K3s Pod。对运维来说不需要学三套不同的部署工具，改一个字段就切换。

---

四、选型决策树

你的边缘节点内存 < 512MB？
  ├── 是 → 自建方案 或 Baetyl（KubeEdge/K3s 跑不动）
  └── 否 → 继续

你的团队有 K8s 经验吗？
  ├── 否 → 自建方案 或 Baetyl（学习 K8s 成本 > 开发成本）
  └── 是 → 继续

边缘节点需要完全离线（断网也能部署新应用）？
  ├── 是 → K3s、Baetyl 或 自建方案（KubeEdge 做不到）
  └── 否 → 继续

你的业务以视频分析/AI 推理为核心？
  ├── 是 → Baetyl（AI 管道开箱即用，省几个月开发）或 自建方案（第 25 篇 + EdgeRuntimeSDK 组合）
  └── 否 → 继续

你的业务需要深度定制消息路由、可靠性、工业协议？
  ├── 是 → 自建方案（K8s 生态没有现成方案，Baetyl 在此层面也不够灵活）
  └── 否 → 继续

你的组织要求统一 K8s 技术栈？
  ├── 是 → K3s（单节点）或 KubeEdge（云边协同）
  └── 否 → 自建方案、Baetyl 或 K3s 选一个你团队擅长的

---

五、一个实际的混合架构

在本系列的实践中，我们推荐混合架构——不是四选一，而是选对场景对的技术：

云端：K8s 集群（标准 K8s + Helm）
  ├── 管理平台（Go Web 应用，部署在 K8s）
  ├── 设备影子管理服务（Go，部署在 K8s）
  ├── MQTT 接入层（EMQX，部署在 K8s）
  └── Prometheus + Grafana + Jaeger（监控 + 追踪）

边缘：
  ├── AI 视觉检测节点 → 可选 Baetyl（AI 管道开箱即用）
  │   └── 视频分析模块、图像预处理管道、模型热更新
  │
  ├── 高配节点（4核8G 以上）→ 可选 K3s 管理业务模块
  │   └── 业务模块打包为 OCI 镜像，K3s 调度管理
  │
  └── 低配节点（256M~1G）→ 自建方案
      └── NodeCore + DeployMaster + MessageHub 直接管理

统一的原则：

• 无论底层是 K3s、Baetyl 还是自建方案，模块的部署清单格式统一（JSON Schema 一致）
• 云端的管理语义统一（都是"期望状态驱动"）
• 运维通道统一（OpsAgent WebSocket，不管底层用了谁）
• 消息总线统一（全部走 MQTT，K3s Pod/Baetyl 模块通过 EdgeRuntimeSDK 连 MessageHub）

这就是第 4 篇策略模式的精髓——用统一接口适配不同底层形态。自建方案的 ProcessModuleManager 和 K3s 的 K8sModuleManager 实现同一个 ModuleManager 接口，对外无差别：

// 统一接口——所有部署形态都要实现
type ModuleManager interface {
    Create(req *DeployRequest) (*ModuleInfo, error)
    Start(moduleID string) error
    Stop(moduleID string) error
    Remove(moduleID string) error
    List() ([]*ModuleInfo, error)
}

// DeployMaster 只调接口，不关心底层是谁
func (dm *DeployMaster) DeployModule(config *ModuleConfig) error {
    mgr := dm.registry.Get(config.Runtime) // "process" / "docker" / "k3s"
    info, _ := mgr.Create(config.ToRequest())
    return mgr.Start(info.ModuleID)
}

// 注册表——同一套部署清单驱动四种运行时的模块生命周期
dm.registry.Register("process", &ProcessModuleManager{})
dm.registry.Register("docker",  &DockerModuleManager{})
dm.registry.Register("k8s",     &K8sModuleManager{clientset: k3sClient})

无论底层是自建进程、Docker 容器还是 K3s Pod，DeployMaster 的执行路径完全相同——这就是第 8 篇"期望状态驱动"和第 4 篇"策略模式"的组合威力。

---

六、小结

方案	一句话定位	最佳场景
KubeEdge	K8s 的"千里眼"——远程管理边缘 Pod	组织强依赖 K8s，边缘节点网络不稳定但不需要离线自治
K3s	最小化的完备 K8s	边缘节点资源充足，需完整 K8s 生态，团队有 K8s 经验
Baetyl	AI 原生的边缘框架——内置视频/图像处理管道	业务以视觉检测、视频分析、模型推理为核心，团队不想从零搭 AI 管道
自建方案	为边缘量身定做的极简运行时	资源极度受限、需要深度定制消息流控/安全/可靠性、团队不走 K8s 路线

没有完美的方案，只有适合你场景的方案。 本文的目标不是让你站队，而是帮你理解每个方案的设计取舍——理解了取舍，选型就不是 “拍脑袋”，而是 “有据可依”。

下一篇，我们探讨边缘计算的另一个热门方向——边缘 AI 推理：如何在资源受限的边缘网关上部署和运行 TFLite / ONNX 模型。

---

本文是《边缘平台架构沉思录：Go 架构推演与工程决策》系列的第 24 篇。