作为一种围绕 "边缘" 的新型产业形态, 服务提供商率先以 5G 边缘平台作为试点进行产业布局, 而其他行业的定义的 "边缘" 也同样在进行快速布局, 这是未来边缘平台发展的大势所趋. 本文提出了一个基于开源, 原生云技术的边缘平台概念.
将密集的工作负载从云端移动到网络边缘以降低延迟, 降低带宽, 缩短回程路径 - 这些都是边缘计算的人尽皆知的优势. 2018 年, 不论是移动便携设备还是物联网设备, 不论是视频流数据还是机器学习数据, 都在向终端设备靠近, 集中.
作为一种围绕 "边缘" 的新型产业形态, 服务提供商率先以 5G 边缘平台作为试点进行产业布局, 而其他行业的定义的 "边缘" 也同样在进行快速布局, 这是未来边缘平台发展的大势所趋. 本文提出了一个基于开源, 原生云技术的边缘平台概念.
多集群编排边缘计算
由于大多数核心边缘用例都有云参与, 故一种理解边缘计算的方法就是 "云的扩展". 例如, 企业可以在云中训练机器学习模型, 并将最新模型应用于边缘节点. 因此, 边缘平台应该具有如云一般的弹性负载, 支持现有的云平台技术如 Kubernetes 的特性, 以确保云和边缘应用部署的一致性. 一个边缘微数据中心, 即云和终端设备之间的一组服务器, 也即对应一个 Kubnenetes 集群.
在边缘计算中使用 Kubernetes 是极为有利的, 因为它支持不同种类的工作负载, 包括容器, 函数和虚拟机. 但是简单地将 Kubernetes 安装到数千个这些微数据中心并不能解决边缘计算所面临的独特的技术挑战. 例如, 如何大规模为这些边缘设备引导程序, 并在所有站点上安装 Kubernetes 和平台工具.
因此, 应用程序开发人员必须解决同时将不同的工作负载部署到多边缘集群的问题. 开发人员可以通过隐式部署 ("把应用程序放到流量" 中) 来解决这一问题, 而不必考虑成千上万的边缘微数据中心实际运行哪个应用程序. 为了解决跨集群的流量负载均衡问题, 可以将每个请求都解析到最近的边缘服务器. 边缘集群还应该能够自主地跨集群加载工作负载, 这就需要边缘站点之间具有一些 "邻居意识". 边缘管理员还可以将这些微数据中心组织为复杂的拓扑结构, 以便在本区域或本地部署不同的工作负载.
最后, 管理跨地域的边缘集群还面临一系列后勤挑战, 不同于管理大量的物联网设备, 管理边缘集群还存在物理安全问题, 异构硬件问题和调试网络配置等问题.
面向端到端的边缘平台
建立一个边缘平台来解决上述所有技术需求是不可能的, 也没有人能够建立起这样一个神奇的, 统一的边缘平台. 但我认为, 利用一些常见的开源工具并结合边缘平台生态系统, 可以大大加速边缘平台创新.
那么这个边缘平台会是什么样子呢?
首先, 每个组件 -- 包括设备, 平台和应用程序管理等, 将其添加进入相同的边缘目录. 通过像 RackHD 这样的裸金属工具可以从边缘目录中取出一组 MAC 地址, 远程控制这些设备, 然后再将结果反馈至目录中. 平台管理者可以从边缘目录中获取这些结果, 包括一些用户自定义的边缘设备信息, 通过安装 Kubernetes 以及其他平台工具, 如 Fluentd and Prometheus 可以进一步进行日志记录和监控. 要想将所有的边缘站点聚集以应对新的工作负载, 这些边缘 Kubernetes 集群的顶部必须部署逻辑层, 以处理隐式应用程序部署和跨集群负载均衡.
前两个组件, 设备和平台的管理, 可以通过编写现有工具解决相应问题. 但是, 最后一个组件, 应用的管理, 是一个尚未解决的问题: 成千上万的 Kubernetes 集群如何与微监督协同工作?
下一个阻碍: 边缘应用管理
边缘计算只是多个 Kubernetes 集群的一个用例, 管理多个 Kubernetes 集群的概念并不新鲜. 早在 2016 年, Kubernetes 就已经引入了 "Cluster Federation 集群联合" 机制 -- 用于多集群负载调度和负载均衡的控制平面. 从那时起, 研发人员就已经逐渐放弃 Kubernetes 集群集中控制平面方法, 朝着更为分散的 API, 入口控制器和工具集合转移. 而所有这些工具都转向了云部署 Kubernetes."集群联合" 机制目前只支持群集托管在谷歌云.
因此, 为了实现未来边缘平台部署的愿景, 必须创建新的工具来解决原生 Kubernetes 中的多集群编排. 为此, 我们设计一个更高级的结构应用于多集群应用程序管理器.
该边缘应用程序管理器的核心原理是, 集群能够尽可能自主地运行, 而不依赖于中央控制平面. 也就是说, 必须集中, 自主运行一定数量的业务.
例如, 应该有一个集成的用户界面和一个 API, 让应用程序开发者在不必与单个集群交互的情况下将工作负载部署到边缘. 也可能有一个中央 DNS 服务器, 可以路由进入的边缘流量. 例如, 假设一个边缘集群正在运行一个应用程序, 另一个集群没有运行. 终端设备向该应用程序提出请求, 通过 anycast 通信, DNS 请求路由到最近的边缘集群. 这个边缘集群与中央 DNS 服务器对话, 并返回运行相关应用程序的集群列表. 这样, 边缘 DNS 服务器可以将设备的请求转发到运行该应用程序的最接近的边缘站点, 并告诉终端设备:"我没有运行您需要的应用, 而我的相邻集群正在运行". 定制核心 DNS 插件并运行在中心和边缘位置可以实现这一目标.
该边缘应用程序管理器还具有其他特性, 如负载均衡, 跨集群流量控制服务(多集群 Istio), 以及跨集群 scale-up 和 scale-to-zero, 统一认证和安全策略. 这个边缘应用程序管理器将来可能包含多个不同的工具, 包括新开发的和现有的, 来协调这些微数据中心的应用程序.
最后, 可以肯定的是, 这是一个振奋人心的边缘计算时代, 眼前的工作是创建一个弹性负载的原生云平台以运行边缘应用程序. 撸起袖子加油干吧.
译者注:
Istio: 一个开源项目, 提供统一的连接, 安全, 管理和监控微服务的方法. 目前的版本针对 Kubernetes 环境; 在未来几个月内为虚拟机和 Cloud Foundry 等其他环境增加支持. Istio 将流量管理添加到微服务中, 并为增值功能 (如安全性, 监控, 路由, 连接管理和策略) 创造了基础. 该软件使用来自 Lyft 的经过测试的特使代理构建, 并提供对流量的可见性和控制, 而不需要对应用程序代码进行任何更改. Istio 为 CIO 提供了强大的工具, 可以在整个企业中实施安全性, 政策和合规性要求.
译者介绍:
张德俊, 虚拟化, 云计算, 大数据, 网络安全从业者, 热爱 AI, 区块链等前沿技术
来源: http://cloud.51cto.com/art/201804/571527.htm