边缘云原生的技术探索(4)

云侧主要在 K8s 原生集群中部署了一个 CloudController，其中包含了 YurtControllerManager。YurtControllerManager 主要替换掉原生的 nodelifecycle 控制器来保证在自治节点离线的情况下 pod 不会从自治节点中被驱逐。
YurtAppManger 主要负责管理自定义资源 NodePool、UnitedDeployment。NodePool 主要是对自治节点分组管理，NodePool 建议以相同的属性对边缘节点进行分组，例如地理位置，操作系统，CPU 体系结构等。而 UnitedDeployment 主要提供在 NodePool 中管理 pod 的机制。
边缘侧主要采用了 K8s 原生的节点组件 (kueblet、kubeproxy 等)，但是通过 YurtHub 代理了节点组件和 apiserver 的通信，并缓存了下来，保证自治节点在重启后能从缓存恢复状态。
相对于 KubeEdge 来说，openyurt 直接采用了原生的 K8s 组件，减少了适配压力，并提供了自治节点协同的能力，极大的整合了自治节点资源的利用率。但是原生 K8s 组件对边缘设备有一定的资源压力，并且没有对 IOT 设备的原生支持。
由于边缘节点代理无轻量化设计导致不太适合在终端低功耗设备上运行，OpenYurt 主要适合运行在离云计算距离较远，但又具有一定计算资源的场景，比如 CDN、边缘设备的区域网关等。
SuperEdge
大部分开源方案都是将边缘节点以 K8s 的节点身份接入 K8s 平台，SuperEdge 也不例外，但是在具体实现思路上有一些不一样的地方。

SuperEdge 架构也分为云侧和边缘侧两部分：在云侧 application-grid controller 主要负责自定义资源 DeploymentGrid、StatefulSetGrid、ServiceGrid 的管理，这三个自定义资源主要在 Deployment、StatefulSet、Service 的基础上增加了一个 gridUniqKey 字段，通过 gridUniqKey 决定将资源应用到哪些节点上 (通过为节点打上标签进行分组)。云侧的右边有一个 edge-health admission，它综合边缘节点的状态和 edge-health 的探测结果，影响边缘负载的驱逐，从而保证弱网环境下，断网节点 workload 的正常运行。