深度解密：OpenYurt边缘容器架构与原理

Posted 2023-04-05 巨子嘉

OpenYurt边缘容器架构与原理

        在中心云，Kubernetes容器平台已经成为容器编排和调度的事实标准，但是在边缘计算领域，涉及范围较大且场景复杂，缺乏统一的标准；当前Kubernetes开源社区的主线版本，并没适配边缘场景的计划。

        目前国内各个公有云厂商，都开源了各自基于Kubernetes的边缘计算云原生项目，主要有华为的KubeEdge，阿里的OpenYurt，腾讯的SuperEdge，百度的Baetyl等，碎片化严重，短时间很难有大一统的开源产品。

        长远来看，建议通过标准的Kubernetes API来集成，这种兼容所有边缘容器的中庸方案。如果非要择其一，建议是OpenYurt，非侵入式设计，整体技术架构及实现更加优雅。本篇主要是通过OpenYurt架构与原理分析，深入浅出的了解边缘容器的技术详情。

1.1.OpenYurt产品理念及特性

        OpenYurt以上游开源项目Kubernetes为基础，针对边缘场景适配的发行版。是业界首个依托云原生技术体系、“零”侵入实现的智能边缘计算平台。具备全方位的“云、边、端一体化”能力，能够快速实现海量边缘计算业务和异构算力的高效交付、运维及管理。

1.1.1.OpenYurt产品理念

        OpenYurt采用当前业界主流的“中心管控、边缘运行”的云边分布式协同技术架构，始终贯彻“Extending your native Kubernetes to Edge”产品理念，同时遵守以下设计原则：

        “云边一体化”原则：保证与中心云一致的用户体验及产品能力的基础上，通过云边管控通道将云原生能力下沉至边缘，实现海量的智能边缘节点及业务应用，基础架构提升至业界领的云原生架构的重大突破。

        “零侵入”原则：确保面向用户开放的API与原生Kubernetes完全一致。通过节点网络流量代理方式（proxy node network traffic），对Worker工作节点应用生命周期管理新增一层封装抽象，实现分散式工作节点资源及应用统一管理及调度。同时遵循“UpStream First”开源法则；

        “低负载”原则：在保障平台功能特性及可靠性的基础上，兼顾平台的通用性，严格限制所有组件的资源，遵循最小化，最简化的设计理念，以此实现最大化覆盖边缘设备及场景。

        “一栈式”原则：OpenYurt不仅实现了边缘运行及管理的增强功能，还提供了配套的运维管理工具，实现将原生Kubernetes与支持边缘计算能力的Kubernetes集群的相互一键高效转换；

1.1.2.OpenYurt功能特性

        借助Kubernetes强大的容器编排、调度能力，针对边缘资源有限，网络受限不稳定等情况适配增强；将中心云原生能力拓展至分散式边缘节点，实现面向边缘业务就近低延迟服务；同时打通反向安全控制运维链路，提供便捷高效的，云端集中式边缘设备及应用的统一运维管理能力。其核心功能特性如下：

        1．边缘节点自治：在边缘计算场景，云边管控网络无法保证持续稳定，通过增强适配解决原生Worker工作节点无状态数据，强依赖Master管控节点数据且状态强一致机制，这些在边缘场景不适配的问题。从而实现在云边网络不畅的情况下，边缘工作负载不被驱逐，业务持续正常服务；即使断网时边缘节点重启，业务依然能恢复正常；即边缘节点临时自治能力。

        2．协同运维通道：在边缘计算场景，云边网络不在同一网络平面，边缘节点也不会暴露在公网之上，中心管控无法与边缘节点建立有效的网络链路通道，导致所有原生的Kubernetes运维APIs（logs/exec/metrics）失效。适配增强Kubernetes能力，在边缘点初始化时，在中心管控与边缘节点之间建立反向通道，承接原生的Kubernetes运维APIs（logs/exec/metrics）流量，实现中心化统一运维；

        3．边缘单元化负载：在边缘计算场景，面向业务一般都是“集中式管控，分散式运行”这种云边协同分布式架构；对于管理端，需要将相同的业务同时部署到不同地域节点;对于边缘端，Worker工作节是一般是分散在广域空间，并且具有较强的地域性，跨地域的节点之间网络不互通、资源不共享、资源异构等明显的隔离属性。适配增强Kubernetes能力，基于资源，应用及流量三层实现对边缘负载进行单元化管理调度。

        通过OpenYurt开源社区，引入更多的参与方，通过联合研发方式提供更多的可选的专业功能，丰富OpenYurt特性，扩大产品覆盖能力：

        1．边缘设备管理：在边缘计算场景，端侧设备才是平台真正的服务对象；基于云原生理念，抽象非侵入、可扩展的设备管理标准模型，无缝融合Kubernetes工作负载模型与IoT设备管理模型，实现平台赋能业务的最后一公里。目前，通过标准模型完成EdgeX Foundry开源项目的集成，极大的提升了边缘设备的管理效率。

        2．本地资源管理：在边缘计算场景，将边缘节点上已有的块设备或者持久化内存设备，初始化成云原生便捷使用的容器存储，支持两种本地存储设备：（一）基于块设备或者是持久化内存设备创建的LVM；（二）基于块设备或者是持久化内存设备创建的 QuotaPath

1.2.OpenYurt设计架构及原理

1.2.1.OpenYurt设计架构

        原生Kubernetes是一个中心式的分布式架构，Master控制节点负责管理调度及控制集群运行状态；Worker工作节点负责运行容器（Container）及监控/上报运行状态；

        OpenYurt以原生Kubernetes为基础,针对边缘场景,将中心式分布式架构（Cloud Master，Cloud Worker），解耦适配为中心化管控分散式边缘运行（Cloud Master,Edge Worker），形成一个中心式大脑，多个分散式小脑的章鱼式云边协同分布式架构；其主要核心点是：

        （一）将元数据集中式且强一致的状态存储，分散至边缘节点，并且调整原生Kubernetes调度机制，实现自治节点状态异常不触发重新调度，以此实现边缘节点临时自治能力；

        （二）保证Kubernetes能力完整一致，同时兼容现有的云原生生态体系的同时，尽最大肯能将云原生体系下沉至边缘；

        （三）将中心大规模资源池化，多应用委托调度共享资源的模式，适配为面向地域小规模甚至单节点资源，实现边缘场景下，更精细化的单元化工作负载编排管理；

        （四）面向边缘实际业务场景需求，通过开放式社区，无缝集成设备管理，边缘AI，流式数据等，面向边缘实际业务场景的开箱的通用平台能力，赋能更多的边缘应用场景。

1.2.2.OpenYurt实现原理

        OpenYurt践行云原生架构理念，深刻理解Kubernetes实现机制，创新性的采用非侵入式架构设计，面向边缘计算场景实现云边协同分布式架构及中心管控边缘运行的能力：

        针对边缘节点自治能力，一方面，通过新增YurtHub组件实现边缘向中心管控请求（Edge To Cloud Request）代理，并缓存机制将最新的元数据持久化在边缘节点；另一方面新增YurtControllerManager组件接管原生Kubernetes调度，实现边缘自治节点状态异常不触发重新调度；

        针对Kubernetes能力完整及生态兼容，通过新增YurtTunnel组件，构建云边（Cloud To Edge Request）反向通道，保证Kubectl，Promethus等中心运维管控产品一致能力及用户体验；同时将中心其他能力下沉至边缘，包含各不同的工作负载及Ingress路由等。

        针对边缘单元化管理能力，通过新增YurtAppManager组件，同时搭配NodePool,YurtAppSet（原UnitedDeployment），YurtAppDaemon，ServiceTopology等实现边缘资源，工作负载及流量三层单元化管理；

        针对赋能边缘实际业务平台能力，通过新增NodeResourceManager实现边缘存储便捷使用，通过引入YurtEdgeXManager/YurtDeviceController实现通过云原生模式管理边缘设备。

1.2.3.OpenYurt核心组件

        OpenYurt所有新增功能及组件，均是通过Addon与Controller方式来实现其核心必选与可选组件如下：

        1．YurtHub(必选)：有边缘(edge)和云中心(cloud)两种运行模式；以Static Pod形态运行在云边所有节点上,作为节点流量的SideCar，代理节点上组件和kube-apiserver的访问流量，其中边缘YurtHub会缓存的数据，实现临时边缘节点自治能力。

        2．YurtTunnel(必选)：由Server服务端与Agent客户端组成，构建双向认证加密的云边反向隧道，转发云中心(cloud)到边缘(edge)原生的Kubernetes运维APIs（logs/exec/metrics）请求流量。其中Server以Deployment工作负载部署在云中心，Agent以DaemonSet工作负载部署在边缘节点。

        3．YurtControllerManager(必选)：云中心控制器，接管原生Kubernetes的NodeLifeCycle Controller，实现在云边网络异常时，不驱逐自治边缘节点的Pod应用；还有YurtCSRController，用以审批边缘节点的证书申请。

        4．YurtAppManager(必选)：实现对边缘负载进行单元化管理调度，包括NodePool：节点池管理；YurtAppSet：原UnitedDeployment，节点池维度的业务负载；YurtAppDaemon：节点池维度的Daemonset工作负载。以Deploymen工作负载部署在云中心。

        5．NodeResourceManager(可选)：边缘节点本地存储资源的管理组件，通过修改ConfigMap来动态配置宿主机本地资源。以DaemonSet工作负载部署在边缘节点。

        6．YurtEdgeXManager/YurtDeviceController(可选):通过云原生模式管控边缘设备，当前支持EdgeX Foundry的集成。YurtEdgeXManager以Deployment工作负载署在云中心，YurtDeviceController以YurtAppSet工作负载署部署在边缘节点，并且以节点池NodePool为单位部署一套YurtDeviceController即可。

        7．运维管理组件(可选)：为了标准化集群管理，OpenYurt社区推出YurtCluster Operator组件，提供云原生声名式Cluster API及配置，基于标准Kubernetes自动化部署及配置OpenYurt相关组件，实现OpenYurt集群的全生命周期。旧Yurtctl工具建议只在测试环境使用。

        除了核心功能及可选的专业功能外，OpenYurt持续贯彻云边一体化理念，将云原生丰富的生态能力最大程度推向边缘，已经实现了边缘容器存储，边缘守护工作负载 DaemonSet，边缘网络接入Ingress Controller等，还有规划中的有Service Mesh，Kubeflow，Serverless等功能，拭目以待。

1.3.OpenYurt认知误区

1.3.1.云边网络差，不稳定

        对于云边网络差的认知误区，在边缘计算场景中，被提到最多的就是云边网络差且不稳定；其实国内基础网络在2015年开始全面升级；尤其是在“雪亮工程”全面完成之后，基础网络有一个很大的提升；上图摘自《第 48 次中国互联网络发展状况》报告，固网100Mbps接入占比已达91.5%；无线网络接入已经都是4G，5G的优质网络。

        真的挑战在云边网络组网，对于使用公有云的场景：公有云屏蔽数据中心网络，只提供了互联网出口带宽，通过互联网打通云边，通常只需要解决数据安全传输即可，接入不复杂。对于私有自建的IDC场景：打通云边网络并不容易，主要是运营商网络没有完全产品化，同时私有IDC层层防火墙等其他复杂产品，需要专业的网络人员才能完成实施工作。

1.3.2.list-watch机制，云边流量大

        对于list-watch机制，云边流量大的认知误区，List-Watch机制是Kubernetes的设计精华，通过主动监听机制获取相关的事件及数据，从而保证所有组件松耦合相互独立，逻辑上又浑然一体。List请求返回是全量的数据，一旦Watch失败，就需要重新Relist。但是Kubernetes有考虑管理数据同步优化，节点的kubelet只监听本节点数据，kube-proxy会监听所有的Service数据，数据量相对可控；同时采用gRPC协议，文本报文数据相比业务数据非常小。上图是在节点1200节点的集群规模，做的压测数据监控图表。

        真的挑战在基础镜像及应用镜像下发，当前的基础镜像及业务镜像，即使在中心云，依然在探索各种技术来优化镜像快速分发的瓶颈；尤其是边缘的AI应用，一般都是由推送应用+模型库构成，推算应用的镜像相对较小，模型库的体积就非常，同时模型库随着自学习还需要频繁的更新，如果更高效的更新模型库，需要更多技术及方案来应对。

1.3.3.边缘资源少，算力不足

        对于边缘资源少的认知误区，边缘的资源情况是需要再细分场景，针对运营商网络边缘，面向消费者的边缘计算，资源相对比较充足，最大的挑战是资源共享及隔离；针对实体产业的边缘，都会有不小的IDC支持，边缘资源非常充足，足以将整个云原生体系下沉。针对智能设备边缘，资源相对比较稀缺，但是一般都都会通过一个智能边缘盒子，一端连接设备，一端连接中心管控服务，从上图的AI边缘盒子来看，整体配置提升速度较快，长期来看，边缘的算力快速增强以此来满足更复杂更智能化的场景需求。

1.3.4.Kubelet比较重，运行占用资源多

        对于Kubelet比较重，运行占用资源多的认知误区，是需要深入的了解节点资源分配及使用情况，通常节点的资源自下而上分为四层：

        1.运行操作系统和系统守护进程（如 SSH、systemd等）所需的资源。

        2.运行Kubernetes代理所需的资源，如 Kubelet、容器运行时、节点问题检测器等。

        3.Pod可用的资源。

        4.保留到驱逐阈值的资源。

        对于各层的资源分配设置的没有标准，需要根据集群的情况来权衡配置，Amazon Kubernetes对Kubelet资源配置算法是Reserved memory = 255MiB + 11MiB * MAX_POD_PER_INSTANCE；假设运行32 Pods，高达90%的内存都可以分配给业务使用，相对来说Kubelet资源占用并不高。

        同时也要结合业务对高可用的要求,做响应的调整。针对边缘场景，一般不建议在一个节点上运行大量的Pods，稳定为大。

1.4.总结

        边缘计算平台的建设，以Kubernetes为核心的云原生技术体系，无疑是当前最佳的选择与建设路径；但是云原生体系庞大，组件复杂，将体系下沉至边缘，不仅存在很大的挑战与困难，同时充满巨大的机遇及想象空间；

        当前边缘容器产品碎片化严重，短时间很难有大一统的开源产品；其中阿里开源的OpenYurt边缘容器产品，采用非侵入式设计，整体技术架构及实现更加优雅实用；虽然还有一些不足，大部分的边缘场景都能覆盖；简约至上，实用为大；

关注“巨子嘉”，巨子出品，必属精品 

参考资料：

1.第 48 次中国互联网络发展状况

2.Allocatable memory and CPU in Kubernetes Nodes

3.OpenYurt官方文档

4.nvidia开发者官网

深度解读 OpenYurt：从边缘自治看 YurtHub 的扩展能力

作者 | 新胜 ?阿里云技术专家

导读：OpenYurt 开源两周以来，以非侵入式的架构设计融合云原生和边缘计算两大领域，引起了不少行业内同学的关注。阿里云推出开源项目 OpenYurt，一方面是把阿里云在云原生边缘计算领域的经验回馈给开源社区，另一方面也希望加速云计算向边缘延伸的进程，并和社区共同探讨未来云原生边缘计算架构的统一标准。为了更好地向社区和用户介绍 OpenYurt，我们特地推出【深度解读OpenYurt】系列文章，本文为系列文章的第三篇，一一介绍了 OpenYurt 中组件?YurtHub?的扩展能力。

系列文章推荐：

• OpenYurt 开箱测评 | 一键让原生 K8s 集群具备边缘计算能力
• 深度解读 OpenYurt ：边缘自治能力设计解析

OpenYurt 介绍

阿里云边缘容器服务上线 1 年后，正式开源了云原生边缘计算解决方案 OpenYurt，跟其他开源的容器化边缘计算方案的区别在于：OpenYurt 秉持 Extending your native Kubernetes to edge 的理念，对 Kubernetes 系统零修改，并提供一键式转换原生 Kubernetes 为 openyurt，让原生 K8s 集群具备边缘集群能力。

同时随着 OpenYurt 的持续演进，也一定会继续保持如下发展理念：

• 非侵入式增强 K8s
• 保持和云原生社区主流技术同步演进

YurtHub 架构说明

在上篇文章中，我们介绍了 OpenYurt 的边缘自治能力，重点解读了其中的组件 YurtHub。其架构图如下：

同时在介绍 YurtHub 的优势中我们提到 与 Kubernetes 设计理念契合，YurtHub 非常容易扩展出更多的能力。具体在 YurtHub 扩展出了什么能力呢？接下来我们将一一展开介绍。

YurtHub 的扩展能力

1. 边缘网络自治

首先介绍一下何谓边缘网络自治：即在边缘和云端网络断连时，不管时业务容器重启，或是边缘节点重启等，边缘业务的跨节点通信可以持续工作或是自动恢复。

在 OpenYurt 中，实现边缘网络自治需要解决如下的问题（以 flannel vxlan overlay 网络为例）：

• 问题 1: 节点上的网络配置可以自治，kube-proxy 的 iptables/ipvs 规则，flannel 的 fdb/arp/route 配置，coredns 的域名解析等网络配置，在节点重启后可以自动恢复，否则边缘跨节点通信将无法持续；
• 问题 2: 业务容器 IP 保持不变，因为和云端网络断连状态下容器 IP 变化将无法通知到其他节点；
• 问题 3: vtep(vxlan tunnel endpoint) 的 mac 地址保持不变，原因和容器 IP 保持不变类似。

从问题 1 可以看出，必须解决 kube-proxy/flannel/coredns 等组件的自治，才能实现网络配置的自治。如果之前边缘自治是采用重构 kubelet 来实现的话，要实现边缘网络自治就会碰到很大的麻烦，如果强行把重构的 kubelet 自治能力移植到各个网络组件 (kube-proxy/flannel/coredns)，也对整个架构将是噩梦。

在 OpenYurt 中因为 YurtHub 的独立性，kube-proxy/flannel/coredns 等网络组件轻松使用 YurtHub 来实现网络配置的自治能力。因为 YurtHub 缓存了 service 等网络配置资源在 local storage，即使断网并且节点重启，网络组件仍然可以获得断网前的 object 状态以及相应的配置信息。如下图所示:

问题 2，3 和 Kubernetes core 无关，主要涉及到 cni 插件和 flanneld 的增强，后续文章中再详细介绍。

2. 多云端地址支持

公有云上的 Kubernetes 高可用部署时，多实例 kube-apiserver 前面一般都挂了一个 SLB，但是在专有云场景下或者边缘计算场景下，节点需要通过多个云端地址来访问。比如:

• 专有云场景：因为没有 SLB 服务，用户需要需要在云端通过 VIP 方式来自行实现 kube-apiserver 的负载均衡，或者像 kubespray 那样在每个节点上部署一个 nginx 来实现多云端地址的访问；
• 边缘计算场景: 考虑到边缘和云端之间网络的稳定性和安全性要求，某些场景下用户也通过专线和公网两种方式和云端通信，比如优先采用专线，当专线故障时能自动切换到公网通信。

YurtHub 正式考虑到了上述的需求，支持多云端地址访问。云端地址的负载均衡模式可以选择：

• rr(round-robin)： 轮转模式，默认选择该模式；
• priority: 优先级模式，高优先级地址故障后才使用低优先级地址。

具体可以参照 YurtHub 的 LB 模块，如下图所示：

3. 节点维度的云端流控

对于一个分布式系统来说，流控都是一个无法回避的问题。原生 Kubernetes 从集群视角在 kube-apiserver 中以及从访问者视角在 client-go 库中封装了流量管控，在边缘计算场景下，client-go 的流量管控既分散又对业务有一定侵入，显然不能很好的解决流控问题。

YurtHub 在边缘可以接管不论是系统组件还是业务容器对云端访问的流量，可以很好的解决节点维度的云端流控问题。目前 YurtHub 的流控配置是：单节点上对云端的并发请求数超过 250 个时，将拒绝新的请求。

4. 节点证书轮换管理

Kubernetes 已经支持节点证书自动轮换，即当节点证书快过期前，kubelet 会自动向云端申请新的节点证书。但是在边缘计算场景下，很有可能因为边缘和云端网络的断连，造成 kubelet 将无法完成证书的轮换。证书过期后即使和云端网络连接恢复，节点证书也可能无法自动轮换，并造成 kubelet 的频繁重启。

YurtHub 在接管节点和云端通信流量时，同时也可以接管节点的证书管理。这样既解决了各类安装工具对节点证书的管理的不一致，也解决了证书过期后网络再恢复时的证书轮换问题。另外目前 YurtHub 还是 kubelet 共享节点证书，YurtHub 的独立节点证书管理功能将在近期开源。

5. 其他

YurtHub 除了前面介绍的扩展能力，还有很多有价值的能力，在此也简单介绍：

• 节点多租隔离管理：在具备多租隔离能力的 Kubernetes 集群中，假定节点归属于某个租户，那么 YurtHub 将可以确保节点上所有云端请求都只返回节点所属租户的资源。比如说 list service 将只返回该租户的 service。而这种多租隔离能力不需要其他组件做任何修改。当然如果要实现集群内的多租隔离，需要配合相应的多组 CRD 等，详细可以参照项目 kubernetes-sigs/multi-tenancy；
• 集群间节点迁移：某些场景下，边缘节点需要从集群 A 迁移到集群 B，常规操作是先从集群 A 下线，然后再次接入集群 B，最后在集群 B 部署节点上的应用。因为 YurtHub 对节点流量以及节点证书的接管，可以直接对 YurtHub 注入集群B的信息，让节点无损迁移到集群 B；
• 通过域名访问云端 kube-apiserver 等等一些其他功能。

总结

• 通过上述的扩展能力可以看出，YurtHub 不仅仅是边缘节点上的带有数据缓存能力的反向代理。而是对 Kubernetes 节点应用生命周期管理加了一层新的封装，提供边缘计算所需要的核心管控能力；
• YurtHub 不仅仅适用于边缘计算场景，其实可以作为节点侧的一个常备组件，适用于使用 Kubernetes 的任意场景。相信这也会驱动 YurtHub 向更高性能，更高稳定性发展。

参考链接

• kubespray: HA endpoints for K8s

OpenYurt 项目地址：https://github.com/alibaba/openyurt，欢迎大家参与共建！有疑问可加入钉钉交流群：31993519

课程推荐

为了更多开发者能够享受到 Serverless 带来的红利，这一次，我们集结了 10+ 位阿里巴巴 Serverless 领域技术专家，打造出最适合开发者入门的 Serverless 公开课，让你即学即用，轻松拥抱云计算的新范式——Serverless。

点击即可免费观看课程：https://developer.aliyun.com/learning/roadmap/serverless

“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的公众号。”