上述的架构设计 , 对比Kubernetes的能力增强点主要有:
- 边缘单元化:通过Yurt App Manager组件 , 从单元化的视角 , 管理分散在不同地域的边缘资源 , 并对各地域单元内的业务提供独立的生命周期管理 , 升级 , 扩缩容 , 流量闭环等能力 。且业务无需进行任何适配或改造 。
- 边缘自治: 因为每个边缘节点增加了具备缓存能力的透明代理YurtHub , 从而可以保障云边网络断开 , 如果节点或者业务重启时 , 可以利用本地缓存数据恢复业务 。
- 云边协同(运维监控):通过Tunnel Server/Tunnel Agent的配合 , 为位于防火墙内部的边缘节点提供安全的云边双向认证的加密通道 , 即使边到云网络单向连通的边缘计算场景下 , 用户仍可运行原生kubernetes运维命令(如kubectl proxy/logs/exec/port-forward/attach等) 。同时中心式的运维监控系统(如prometheus, metrics-server等)也可以通过云边通道获取到边缘的监控数据 。
- 云原生生态兼容:
- 所有功能均是通过Addon或者controller形式来增强Kubernetes , 因此保证来对Kubernetes以及云原生社区生态的100%兼容 。
- 另外值得一提的是:OpenYurt项目还提供了一个YurtCtl工具 , 可以用于原生Kubernetes和OpenYurt集群的一键式转换 ,
- 原生Kubernetes带来的系统稳定性挑战:因为OpenYurt没有修改Kubernetes , 所以这个问题也是原生Kubernetes在边缘场景下的问题 。当云边长时间断网再次恢复时 , 边缘到云端会产生大量的全量List请求 , 从而对kube-apiserver造成比较大的压力 。边缘节点过多时 , 将会给系统稳定性带来不小的挑战 。
- 边缘无轻量化解决方案: 虽然OpenYurt没有修改Kubernets , 但是在边缘节点上增加YurtHub和Tunnel Agent组件 。目前在最小的1C1G的系统上运行成功 , 更小规格机器待验证 。
- 无设备管理能力:OpenYurt目前没有提供设备管理的相关能力 , 需要用户以workload形式来运行自己的设备管理解决方案 。虽然不算是架构设计的缺点 , 但是也算是一个边缘场景的不足点 。

- Lite-Apiserver: 代理各个边缘组件到K8s Master的通信请求 , 同时把请求返回的元数据持久化在节点磁盘 。当云边网络不稳定时 , 则利用本地磁盘数据来用于边缘业务的生命周期管控 。同时基于边缘Edge-Health上报信息 , 云端的Edge-Health Admission会管控边缘业务Pod的驱逐策略 。
- Tunnel Cloud/Tunnel Edge: 每个边缘节点上的Tunnel Edge将主动与云端Tunnel Cloud建立双向认证的加密的gRPC连接 , 同时云端将通过此连接访问到边缘节点及其资源 。
- Application-Grid Controller:引入的两个CRD资源: ServiceGrids和 DeploymentGrids. 前者为位于同一区域的业务流量提供闭环管理 。后者定义了一种新的边缘应用模型以节点池为单位来管理工作负载 。
推荐阅读
- 云计算的自动化至关重要
- 大规模运营云计算服务的6个复杂性挑战
- 如何准备迁移到云平台的检查清单
- 算法实现 | 贪心算法
- 云原生应用与容器架构
- 蓝队云:美国服务器速度变慢的原因
- 怎么下载云服务 下载云服务器
- 云服务平台app下载 手机app免费下载
- 免费领取小米云服务会员 小米云服务会员激活码
- 永久免费的云游戏平台手机版 免费不限时的云游戏平台
