一句话简介

K3S：一个轻量级的 K8s 发行版，与其关系为“替换关系”。适用于资源比较紧张的“边缘设备云”。K3s还需要一个多集群管理方案，目前极为不成熟，只有偏商业的Rancher。

KubeEdge：华为开源。一个K8s 的插件，补充了K8s没有完成的事情。连接了边缘、设备和云，主打边缘自洽和云边协同方面。

openyurt：阿里开源。与KubeEdge很类似，兼容K8s，可以很方便的让K8s具备边缘计算能力。当前处于沙箱状态，未孵化。

主要特征

K3S：

  • 轻量。打包为单个二进制文件，大小50M左右，内存消耗500M左右、支持sqlite轻量级数据库
  • 单进程模型，master，kubelet，containerd都包含在一个进程中
  • 移除了很多非必要代码，减少了资源占用

KubeEdge：

  • 云边协同。支持标准K8s API、优化消息通路支持大规模接入、定制的云端组件。
  • 边缘离线自洽。重新设计消息总线、元数据本地存储等。
  • 设备管理。可插拔式的设备统一管理框架

openyurt：

  • K8s完全兼容。
  • 边缘自治。
  • 边缘运维通道。
  • 集群转换。可以一键将集群转换为openyurt

那云边协同主要解决的问题是什么呢？

  1. 网络断连时，节点异常或重启时，内存数据丢失，业务容器无法恢复；
  2. 网络长时间断连，云端控制器对业务容器进行驱逐；
  3. 长时间断连后网络恢复时，边缘和云端数据的一致性保障。
  4. 网络不稳定下，K8S client ListWatch机制下为保证数据一致性，在每次重连时都需要同步ReList一次，较大规模的边缘节点数量加以较不稳定的网络，将造成巨大的网络开销和API Server的cpu负担，特别是不可靠的远距离跨公网场景。

部署架构

K3s：

k3s部署架构

K3s需要在边缘云中运行完整的集群，集群之前互不相通。多集群时，需要额外工具纳管。

KubeEdge：

KubeEdge部署架构

KubeEdge是一种去中心化部署，管理端（K8s）需要部署在云端，这也意味着必须有一个资源充足的云端。而边缘节点则无需太多资源，只运行一个K8s集群的agent即可。

openyurt：

与上KubeEdge相同，也是去中心化的。

软件架构图

K3S：

image-20220928175203340

事实上，K3S就是基于一个特定版本Kubernetes直接做了代码修改。

K3S分Server和Agent，Server就是Kubernetes管理面组件 + SQLite和Tunnel Proxy，Agent即Kubernetes的数据面 + Tunnel Proxy。 为了减少运行Kubernetes所需的资源，K3S对原生Kubernetes代码做了以下几个方面的修改： 1、删除旧的、非必须的代码。K3S不包括任何非默认的、Alpha或者过时的Kubernetes功能。除此之外，K3S还删除了所有非默认的Admission Controller，in-tree的cloud provider和存储插件； 2、整合打包进程。为了节省内存，K3S将原本以多进程方式运行的Kubernetes管理面和数据面的多个进程分别合并成一个来运行； 3、使用containderd替换Docker，显著减少运行时占用空间； 4、引入SQLite代替etcd作为管理面数据存储，并用SQLite实现了list/watch接口，即Tunnel Proxy； 5、加了一个简单的安装程序。K3S的所有组件（包括Server和Agent）都运行在边缘，因此不涉及云边协同。如果K3S要落到生产，在K3S之上应该还有一个集群管理方案负责跨集群的应用管理、监控、告警、日志、安全和策略等

KubeEdge：

KubeEdge 架构

KubeEdge架构上清晰地分为三层，分别是：云端、边缘和设备层。

云端 KubeEdge的云端进程包含以下2个组件： 1、cloudhub部署在云端，接收edgehub同步到云端的信息； 2、edgecontroller部署在云端，用于控制Kubernetes API Server与边缘的节点、应用和配置的状态同步。

边缘 KubeEdge的边缘进程包含以下5个组件： 1、edged是个重新开发的轻量化Kubelet，实现Pod，Volume，Node等Kubernetes资源对象的生命周期管理； 2、metamanager负责本地元数据的持久化，是边缘节点自治能力的关键； 3、edgehub是多路复用的消息通道，提供可靠和高效的云边信息同步； 4、devicetwin用于抽象物理设备并在云端生成一个设备状态的映射； 5、eventbus订阅来自于MQTT Broker的设备数据。

openyurt：

image

OpenYurt的架构设计比较简洁，采用的是无侵入式对Kubernetes进行增强。在云端(K8s Master)上增加Yurt Controller Manager, Yurt App Manager以及Tunnel Server组件。而在边缘端(K8s Worker)上增加了YurtHub和Tunnel Agent组件。从架构上看主要增加了如下能力来适配边缘场景： 1、YurtHub: 代理各个边缘组件到K8s Master的通信请求，同时把请求返回的元数据持久化在节点磁盘。当云边网络不稳定时，则利用本地磁盘数据来用于边缘业务的生命周期管控。同时云端的Yurt Controller Manager会管控边缘业务Pod的驱逐策略。 2、Tunnel Server/Tunnel Agent: 每个边缘节点上的Tunnel Agent将主动与云端Tunnel Server建立双向认证的加密的gRPC连接，同时云端将通过此连接访问到边缘节点及其资源。 3、Yurt App Manager：引入的两个CRD资源: NodePool 和 UnitedDeployment. 前者为位于同一区域的节点提供批量管理方法。后者定义了一种新的边缘应用模型以节点池维度来管理工作负载。

生产落地

案例一：

自己云端业务系统中部署了Rancher和Harbor，边缘端有一个性能比较好的server，部署了K3S server，其他小型设备，部署了K3S agent。通过rancher统一管理k3s集群

image-20220928162611589

案例二：

除了网络复杂外，架构类似。

image-20220928162520597

Rancher本身运行在K3s集群。

案例三：

中国移动，10086客服云边协同平台，选型KubeEdge，比较看重其云边协同和离线自治。结合自身需求，做了一定改造。

KubeEdge案例 10086客服

案例四：

忽米网，5G工业互联网平台。选型KubeEdge。只是用KubeEdge的节点纳管和应用管理相关的边缘计算能力，没有使用其IoT能力。

  • 海量设备信息存储到ETCD对k8s形成压力
  • 应用管理和设备管理共享云边通信，设备数据高频率采集时的性能瓶颈
  • 设备信息和设备模型数据以CRD资源存储到ETCD，如何与已有自研平台打通？

image-20221013161417652

image-20221013161524036

案例5:

中国移动视频智能分析平台。没有找到更详细的系统框架和介绍。

image-20221013165959465

image-20221013165756886

案例6:

申通快递云边端DevOps协同。Openyurt承载了边缘侧资源托管，应用管理，云管边端的云边协同的职责

architecture

社区发展

Start趋势对比：

star-history-2022928

Commit提交：

commit对比

运维安装

K3S：

安装命令：

1

curl -sfL https://get.k3s.io | sh -

有组件AutoK3s可以通过API、CLI、UI快速创建K3S集群

KubeEdge:

首先，你需要先自行搭建一个K8s集群（需要考虑跟KubeEdge的兼容）。可以使用Keadm工具安装KubeEdge，整体过程比较繁琐。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

#CloudCore安装

#由于下载时网络连接不上，需要提前下载好安装包，放在/etc/kubeedge目录
# kubeedge-v1.10.3-linux-amd64.tar.gz
# checksum_kubeedge-v1.10.3-linux-amd64.tar.gz.txt
# keadm-v1.10.3-linux-amd64.tar.gz
# crds
keadm init --advertise-address=192.168.40.165 --kubeedge-version=1.10.3

#获取token
keadm gettoken


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

#EdgeCore安装

# 1、安装mqtt
yum -y install mqtt

# 2、修改docker的cg为cgroupfs
vi /usr/lib/systemd/system/docker.service
--exec-opt native.cgroupdriver=systemd 修改为 --exec-opt native.cgroupdriver=cgroupfs

# 3、由于下载时网络连接不上，需要提前下载好安装包，放在/etc/kubeedge目录
# kubeedge-v1.10.3-linux-amd64.tar.gz
# checksum_kubeedge-v1.10.3-linux-amd64.tar.gz.txt
# keadm-v1.10.3-linux-amd64.tar.gz
keadm join --cloudcore-ipport=192.168.40.165:10000 --token=ffe063a81b39ea99fcc6047d3ce5f2056778635e192c76a227235f0cca4dfab0.eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2NjUyMzkzNzN9.xTNql0tXptM8-01NDZ9jrriF7q6_9MHO9sZTU7Lc-PY --kubeedge-version=1.10.3

openyurt：

生产环境需要先自行搭建一个K8s集群，然后安装Openyurt管控组件，最后进行节点接入。

测试环境可以相对方便的一键从0到1。

硬件需求：

K3s：

部署规模 节点 VCPUS 内存
Small Up to 10 2 4 GB
Medium Up to 100 4 8 GB
Large Up to 250 8 16 GB
X-Large Up to 500 16 32 GB
XX-Large 500+ 32 64 GB

磁盘建议SSD

KubeEdge：

官方无建议配置，master节点、CLoud Core节点，参考K8s需求。

EdgeCore节点磁盘占用60M，运行时内存小于30M。

根据官方10W边缘节点，100W Pod的测试实践：

  • Master节点：128核，256G，SSD
  • CloudCore节点*5：12核，48G，SSD

Openyurt：

worker节点最少2核4G。

UI表现：

K3S：

没有独立UI，可以使用K8S dashboard，但体验不佳。官方推荐Rancher纳管，但能力不开源。

KubeEdge：

依然是K8S dashboard

Openyurt：

Yurt Dashboard，一个类似于 kubernetes dashboard 的 Web 控制台，包含完整的前后端的 Web 应用。前端提供一个简单直观的操作界面，后端负责与集群的 API Server 通信

文档资源：

K3S：

文档比较规整完备，网上资料较多。

KubeEdge：

文档稀烂，资料较少。

OpenYurt：

文档比较规整，网上资料不太多。

对比总结：

KubeEdge K3S OpenYurt
安装部署 安装部署较为复杂，安装工具社区持续更新中。 安装过程极大简化，自带kubectl工具，省去了kubelet、flanne等繁琐的安装操作。 安装部署较为简单。
社区活跃 GitHub的Commit提交较多，持续更新。 GitHub的Commit提交较少。 GitHub的Commit提交较少。
部署模型 KubeEdge是一种完全去中心化的部署模式，管理面部署在云端，边缘节点无需太多资源就能运行KubeEdge的agent，云边通过消息协同。 K3S会在边缘运行完整的Kubernetes集群，因此K3S并不是一个去中心化的部署模型，每个边缘都需要额外部署Kubernetes管理面。这种部署模型带来的问题有： (1)在边缘安装Kubernetes管理面将消耗较多资源，因此该部署模型只适合资源充足的"基础设施边缘"场景，并不适用于资源较少的"设备边缘"的场景； (2)集群之间网络需要打通； (3)为了管理边缘 Kubernetes 集群还需要在上面叠加一层多集群管理组件。 去中心化的部署模式。
云边协同 云边协同是KubeEdge的一大亮点。KubeEdge通过Kubernetes标准API在云端管理边缘节点、设备和工作负载的增删改查。边缘节点的系统升级和应用程序更新都可以直接从云端下发，提升边缘的运维效率。另外，KubeEdge底层优化的多路复用消息通道相对于Kubernetes基于HTTP长连接的list/watch机制扩展性更好，允许海量边缘节点和设备的接入。KubeEdge云端组件完全开源，用户可以在任何公有云/私有云上部署KubeEdge而不用担心厂商锁定，并且自由集成公有云的其他服务。 K3S不提供云边协同的能力。 支持云边协同。
边缘节点离线自治 与Kubernetes集群的节点不同，边缘节点需要在完全断开连接的模式下自主工作，并不会定期进行状态同步，只有在重连时才会与控制面通信。 KubeEdge通过消息总线和元数据本地存储实现了节点的离线自治。用户期望的控制面配置和设备实时状态更新都通过消息同步到本地存储，这样节点在离线情况下即使重启也不会丢失管理元数据，并保持对本节点设备和应用的管理能力。 K3S不涉及这方面能力。 支持边缘自治。
设备管理 KubeEdge提供了可插拔式的设备统一管理框架，允许用户在此框架上根据不同的协议或实际需求开发设备接入驱动。当前已经支持和计划支持的协议有：MQTT，BlueTooth，OPCUA，Modbus等，随着越来越多社区合作伙伴的加入，KubeEdge未来会支持更多的设备通信协议。KubeEdge通过devicetwins/digitaltwins实现设备状态的更新和同步，并在云端提供Kubernetes的扩展API抽象设备对象，用户可以在云端使用kubectl操作Kubernetes资源对象的方式管理边缘设备。 K3S不涉及这方面能力。 不支持。
轻量化 KubeEdge完整地保留了Kubernetes管理面，重新开发了节点agent，优化runtime资源消耗，节点agent内存占用约70mb。 k3s的server大概只占用200M左右的内存，agent只占用几十兆内存。 agent端占用几十兆内存。
大规模 Kubernetes原生的可扩展性受制于list/watch的长连接消耗，生产环境能够稳定支持的节点规模是1000左右。KubeEdge作为华为云智能边缘服务IEF的内核，通过多路复用的消息通道优化了云边的通信的性能，压测发现可以轻松支持5000+节点。 未知。 未知。

最后做个总结，从功能、社区、成熟度等层面，KubeEdge都有很大优势。K3s重点放在了对K8s的减肥，但没有针对云边协同做太多工作。OpenYurt是一个更轻量化的实现方案，但目前成熟度太低，可以暂时保持关注。KubeEdge的风险也是存在的，就是华为对社区的规划和影响，目前来看政治背书做的很足，但是回归到技术响应和周边建设还有挺长路要走。