「译文」CNCF 边缘原生应用程序原则白皮书

简介: 「译文」CNCF 边缘原生应用程序原则白皮书

目标

许多地方都提到了“Edge Native(边缘原生)”一词,包括 GartnerMarcometaFutureCIO 等行业博客。包括 State of the EdgeLinux Foundation(LF) 在内的组织也讨论了边缘原生应用程序,但没有关注边缘原生原则。

本白皮书重点介绍边缘原生应用程序以及如何定义这些原则。

什么是边缘 (Edge)?

边缘计算是一种使数据处理更接近源 (source) 的范例,例如工厂中的机器人控制。

在未来五年内,边缘计算 (Edge Computing) 将变得更加普遍,预计该行业将 从 2022 年到 2030 年增长 38.9%。公司看到了在边缘拥有计算能力的以下好处:

  • 减少延迟
  • 带宽管理
  • 提高敏感数据的隐私性
  • 在不可靠的网络下不间断地运营

边缘计算有各种各样的定义,但本文将重点讨论的是基于数据处理资源的地理位置 (the geographical location of data processing resources) 的定义。 基于地理的边缘根据与用户的距离被分类为多个类别。 下图显示了 Linux Foundation Edge 白皮书 中定义的类别。

Edge 类别

(译者注)根据距离中央(云)数据中心由远到近依次为:

  1. 用户边缘 (User Edge)
  1. 受限的设备边缘 (Constrained Device Edge): 基于微控制器,在物理世界中高度分布式。如智能灯泡,智能温度计。
  2. 智能设备边缘 (Smart Device Edge): 包括 IoT(无头)和可访问位置的最终用户客户端计算设备。如:智能路由器,智能手机。
  3. 本地数据中心边缘 (On-Perm Data Center Edge): 安全位置中基于服务器的计算。如:放在监控室的机柜。
  1. 服务提供商边缘 (Service Provider Edge): 距离用户边缘相隔最后一公里网络 (Last Mile Networks)
  1. 访问边缘 (Access Edge): 电信网络和边缘交换站点的基于服务器的计算
  2. 区域边缘 (Region Edge): 区域电信公司和直接对等站点的基于服务器的计算
  1. 中央数据中心 (Centralized Data Centers): 通过互联网边缘 (Internet Edge) 与服务提供商边缘相连;传统云数据中心中的基于服务器的计算

边缘原生原则与云原生原则共享许多相似之处;

但是,也有一些关键的区别。

云原生 (Cloud Native) VS 边缘原生 (Edge Native)

云原生计算基金会(CNCF) 定义的云原生技术包括:

“云原生技术使组织能够在公共云、私有云和混合云等现代动态环境中构建和运行可扩展的应用程序。 容器、服务网格、微服务、不可变架构和声明式 API 就是这种方法的例证。

这些技术使松散耦合的系统具有弹性、可管理性和可观察性。

结合强大的自动化功能,它们允许工程师以最少的工作量频繁地、可预测地进行高影响力的变更。”

这一广泛的使命仍然适用于边缘应用程序,因为 边缘计算开放词汇表 (The Open Glossary of Edge Computing) 指出,“边缘原生应用程序”利用云原生原则:

“应用程序是为了利用边缘计算功能而本机构建的,这在集中式数据中心中运维是不切实际或不可取的。 边缘原生应用利用云原生原则,同时考虑到边缘在资源限制、安全性、延迟和自主性等方面的独特特征。 边缘原生应用程序的开发方式充分利用云并与上游资源协同工作。 不理解集中式云计算资源、远程管理和编排或利用 CI/CD 的边缘应用程序不是真正的“边缘原生”,而是更类似于传统的内部部署应用程序。”

随着云原生使用案例走出传统云,在边缘位置整合数据和事件,新的工具和技术也在不断发展,以实现交付具有弹性、可管理和可观察性的松耦合系统的目标,同时还能管理边缘的独特特征。

相似性

许多云原生原则适用于边缘原生。 本节将介绍这些相似之处。

属性 云原生 & 边缘原生
应用程序和服务可移植性 应用程序和服务将它们的耦合从架构中抽象出来。 一个写得很好的应用程序不能告诉它在哪里运行,可以预期它是跨平台的。
可观察性 该平台附带了一套记录良好的界面和工具选项,可用于检测问题和收集指标。 这使得开发人员能够构建具有弹性和高效管理的系统。
可管理性 (Manageability) 提供了接口和工具选项来大规模管理应用和资源。 该平台还具有插件机制,可提供基线网络连接、服务和管理功能。
不可知语言和框架支持 应用程序和服务可以使用各种流行的语言和框架来实现和托管。

差异性

属性 云原生 边缘原生
应用模型 (App Model) 大多数微服务组件是无状态构建的,用于负载平衡的水平扩展。 虽然服务提供商边缘应用程序可能非常相似,但用户边缘 (User Edge) 应用程序可能是单独的“单体 (monolithic)”; 在这两种情况下,状态都可以与应用程序位于同一位置。
数据模型 (Data Model) 支持无状态组件的集中式模型很常见。 通常使用缓存 (caching)、流 (streaming)、实时 (real-time) 和分布式模型。
弹性 快速扩容和缩容;通常将底层资源视为无限的。 由于边缘硬件资源有限,弹性有限;如果可用,扩展可能是“垂直”的,直扩展到连接的云。
恢复能力 (Resilience) 使用跨故障域分布的冗余节点将恢复能力外包给云提供商。 通常依赖于加固的架构,以及用于有状态组件的恢复体系架构;在许多情况下,恢复能力可能低于云中的恢复能力。
扩展 (Scale) 通常仅限于几个地点和实例。 可跨越大量位置(多达 10,000 个),支持大量外部设备(多达 100,000 个)。
编排 大型公有云或内部部署云中的流程编排旨在通过在集中池化主机上运行工作负载并以水平方式进行调度来实现效率和可用性。 边缘是分散式的,工作负载以分布式方式部署,通常以特定于位置的方式进行调度。
管理 虽然云原生和边缘原生都是可管理的,但机制各不相同;云原生依赖于集中管理和自动化。 Edge 原生需要远程和集中化管理以及零接触配置硬件和软件。 边缘工作人员可能未经培训、不受信任、人数极少,甚至根本不存在。 “板砖”标准化,“原子”化升级由于恢复挑战而变得合乎需要。
网络 应用程序可以依赖具有丰富功能的高速网络。 应用程序需要考虑不同的速度(从间歇性的、差的到优秀的网络)和功能。
包括基于移动网络和无线电网络,集成来自非 IP 协议网络的数据和事件。
安全 安全设施内的可信结构。 不安全环境中的零信任。
硬件感知 由于计算资源事实上是一致的,并且具有迎合大多数应用的风格,因此应用很少需要关心硬件放置。 应用程序可能具有更高的实时要求,这使得硬件平台、位置和 / 或安全感知成为一项要求。 开发人员需要了解各种各样的硬件和接口。
与外部资源交互 应用程序很少需要与本地硬件资源交互。 部署在边缘的服务通常需要与本地环境交互:摄像头、传感器、执行器、用户等。

边缘原生应用

边缘原生应用程序是为边缘编写的应用程序和服务。 它们的编写方式考虑到了上述的相似性和差异性。 这些应用程序的核心原则如下所示:

原则 描述
资源和设备感知 硬件感知 开发人员需要了解各种各样的硬件和接口,而不是拥有同质的硬件平台。
外部设备连接 应用程序必须知道如何连接到其环境中的设备,并了解运行时的功能更改。 例如,在初始配置或新设备进入网络后,它们必须响应传感器与边缘服务器的断开 / 连接。 能力不是一成不变的;相反,它包括环境,所以编排器应该能够协调应用程序状态的能力变化。
可变网络可用性感知 应用程序必须通过使用异步通信、队列和缓存等机制来适应不可靠甚至不可用(网络隔离)的网络连接。
边缘从中央站点拉取配置时,可能需要“拉取 (pull)”机制来克服规模、网络连接和安全问题。
大规模管理 中心可观测 虽然边缘和云原生应用都需要集中观察,但边缘原生应用有独特的考虑因素。 边缘原生应用实例可能部署在大规模实例中,并且 / 或者面临人员或现场支持受限的情况。 由于这些原因,需要诸如分布式数据收集和集中式聚合、开环 (open loop)(人类可观察 / 可操作)和闭环自动化(机器可操作)的组合等技术。 可观察性包括指标、日志、数字孪生、警报 (alerting)(事件 (events) 和警报 (alarms))和运行状况监控。
大规模架构和平台管理 大规模的架构和平台管理对于边缘应用程序非常重要,因此需要基于声明性意图的机制。 此外,可能存在独特的要求,如设备加载、水平扩展限制、管理裸机环境等。 在平台级别,部署或管理 Kubernetes 或虚拟化层以及各种插件也是一个问题;同时尽可能保持平台层与厂商无关以实现应用程序的可移植性。
大规模应用管理 边缘应用程序的数量和这些应用程序的实例数量可能非常大,需要从声明性放置和配置意图、通过闭环自动化实现的自动化服务保证,以及跨多个应用程序实例的聚合管理视图等一系列自动化。 应用程序也可能有实时需求,这意味着应用程序和架构 / 平台之间的联系(例如使用 GPU、DPU、FPGA、CPU 架构、内核优化、Kubernetes 插件)可能比云应用程序更紧密。 换句话说,应用程序协调可以触发底层的架构 / 平台协调。
扩展 (Spanning) 应用程序不存在于一个位置;层可以跨越地理、延迟和故障域边界。 事实上,边缘应用程序也可以跨越公共云或集中式私有云。
资源使用优化 由于边缘计算资源有限,应用程序必须持续优化资源使用。这可能意味着按需启动和关闭应用程序,可能意味着根据放置和可用性意图进行迁移和复制,可能意味着在一天中的不同时间运行不同的工作负载。
应用程序可移植且可重复使用(有限制) 抽象层试图通过厂商中立的 PaaS 提供架构和平台无关的可移植性。 但是,由于本地资源、硬件平台、安全性、移动网络等认知,需要配置选项适应本地差异。

这九项原则可以归纳为五大项原则。 硬件感知、外部设备连接和可变网络可用性感知都可以在资源和设备感知的更广泛原则下考虑。 类似地,边缘应用程序需要可大规模管理、可集中观察。 并且具有可管理的架构和平台,都可以在大规模管理的原则下进行分类。 以下是扩大后的五项原则:扩展、资源使用优化、可移植性和可重复使用性(有限制)、资源和设备感知以及大规模管理。

总结和下一步

本文件是第一版,可能会经过修订。 预计今后将发表与本文件各小节有关的文章。

如何参与

CNCF 物联网边缘工作组有定期会议、邮件列表和 Slack。 请参阅工作组 GitHub 页面的 通信部分 以获取最新信息。

我们欢迎读者参与进来,介绍与边缘相关的项目,为小组的工作领域提出想法,或帮助修改本白皮书和 / 或起草后续文件。

项目和举措

作为本白皮书的一部分,CNCF 物联网边缘工作组正在收集开源项目的工作列表,这些项目可帮助应用开发人员实现本文中概述的边缘原生应用原则。

该列表可在此电子表格中或通过 QR 码找到。 要获得添加项目的编辑权限,请加入 IoT Edge Working Group Google 群组。


引用


相关文章
|
运维 监控 安全
阿里巴巴DevOps实践指南(十五)| 应用环境能力
应用环境解决方案并不仅仅是将应用的开发环境、基础环境搭建起来即可,还涉及到环境的稳定性如何保证,基于环境如何规范变更的流程,基于环境如何提升开发效率等等。环境治理需要站在更高的角度,综合看待上述问题,否则就会陷入环境问题年年治理、年年被吐槽的怪圈。
阿里巴巴DevOps实践指南(十五)| 应用环境能力
|
测试技术 数据库 安全
带你读《C++代码整洁之道:C++17 可持续软件开发模式实践》之二:构建安全体系
如果想用C++语言编写出易维护的、扩展性良好的以及生命力强的软件,那么,对于所有的软件开发人员、软件设计人员、对现代C++代码感兴趣或想降低开发成本的项目领导者来说,本书都是必需品。如果你想自学编写整洁的C++代码,那么本书也是你需要的。本书旨在通过一些示例帮助各个技术层次的开发人员编写出易懂的、灵活的、可维护的和高效的C++代码。即使你是一名资深的开发工程师,在本书中也可以找到有价值的知识点。
|
10月前
|
机器学习/深度学习 人工智能 资源调度
隐语1.0正式发布|MVP部署体验包、资源调度框架Kuscia全新亮相!
隐语1.0正式发布|MVP部署体验包、资源调度框架Kuscia全新亮相!
231 0
|
运维 资源调度 Kubernetes
「开源人说」第五期 | KubeVela:一场向应用交付标准的“冲锋”
「开源人说」第五期聚焦云原生领域开源至今仅两年多的项目——KubeVela,将镜头对准 KubeVela 项目背后的代码贡献者和落地实践者,讲述这个从第一天就诞生在社区的技术,如何走到对不同场景应用“海纳百川”,直至成为 CNCF 孵化项目,并逐渐向应用交付领域的事实标准演进的故事。 阅读下文,让我们跟随 KubeVela 创始团队,一起了解它的开源背后的故事。
199689 1
「开源人说」第五期 | KubeVela:一场向应用交付标准的“冲锋”
|
边缘计算 缓存 运维
OpenYurt v1.2 新版本深度解读(一): 聚焦边云网络优化
云原生边缘计算智能开源平台 CNCF OpenYurt 于近期发布了 v1.2 版本。OpenYurt 是业界首个对云原生体系无侵入智能边缘计算平台,具备全方位的“云、边、端一体化”能力,能够快速实现海量边缘计算业务和异构算力的高效交付、运维及管理。
OpenYurt v1.2 新版本深度解读(一): 聚焦边云网络优化
|
运维 Kubernetes Cloud Native
|
运维 Cloud Native 前端开发
GIAC | KCL:声明式的云原生配置策略语言
大家好,我是来自蚂蚁集团的同学,很高兴能在GIAC的编程语言新范式板块和大家分享《KCL配置策略语言》。KCL语言是蚂蚁内部的Kusion解决方案中针对云原生基础设施配置代码化自研的DSL语言,目前已经在建站场景等一些场景开始小范围推广试用。
GIAC | KCL:声明式的云原生配置策略语言
|
存储 Prometheus 监控
KubeVela 1.5:灵活框选 CNCF 原子能力打造独特的企业应用发布平台
KubeVela 1.5 于近日正式发布。在该版本中为社区带来了更多的开箱即用的应用交付能力,包括新增系统可观测;新增 Cloud Shell 终端,将 Vela CLI 搬到了浏览器;增强的金丝雀发布;优化多环境应用交付工作流等。
KubeVela 1.5:灵活框选 CNCF 原子能力打造独特的企业应用发布平台
|
人工智能 自然语言处理 供应链
微软启动“解决方案优选计划”,演绎云时代“平台+生态”新境界
微软启动“解决方案优选计划”,演绎云时代“平台+生态”新境界
364 0
微软启动“解决方案优选计划”,演绎云时代“平台+生态”新境界
|
弹性计算 运维 Kubernetes
读完《云原生架构白皮书》,我们来谈谈开放应用模型(OAM)
受阿里云邀请,我有幸在《云原生架构白皮书》发布前试读了该书,本文结合白皮书内容,谈谈开放应用模型(OAM)
1366 0