自2019年百度宣布将边缘计算框架Baetyl捐赠给Linux基金会以来，Baetyl在开放中立的社区环境中不断得到支持与发展，多位活跃开发者为 Baetyl 带来了全新功能。这些贡献让 Baetyl 向着其发展的根本目标——自由、开放、标准的边缘计算平台——进一步靠拢了。
因此，我们将包括远程管理功能和 Kubernetes 生态支持在内的这一新版名定为2.0，标志着 Baetyl 走向了一个新的阶段。
Baetyl 2.0 最重要的亮点包括：
增加全新的远程管理系统 Baetyl-Cloud，支持对多个边缘节点的管理。
边缘和远程管理框架全部向云原生演化，已支持运行在原生 Kubernetes 或 K3S 之上。
引入声明式的设计，通过设备影子实现端云同步。
升级内部架构，支持未来升级到边缘集群。
全新的远程管理系统Baetyl-Cloud
Baetyl的构建者一直认为，一个完整的边缘计算系统即要有支持应用和服务在各种设备上运行的托管能力，还应该让开发者摆脱不安全的物理控制台，设备应当能被批量的远程操作和管理，这对于那些将要被安置在偏远、危险或者恶劣环境下的设备尤其有意义。
远程管理还能将边缘计算与既有的云计算有机地结合起来，使数据可以按照理想的模式自由跨越物理边界，让应用的开发和部署更加敏捷。
远程管理功能被命名为Baetyl-Cloud，为了保证代码的内聚性，我们将代码提交到了一个新的仓库，如下：https://github.com/baetyl/bae...。首个 Baetyl-Cloud 正式版会通过 OpenAPI 的形式提供多方面的管理能力：
边缘节点管理：支持多个设备的分组管理，基于标签的应用同步，节点基础信息和应用信息的采集和显示
应用部署管理：支持按照标签自动匹配普通容器应用、函数计算和AI推断服务
配置管理：支持对节点、函数、密文、证书和镜像库凭证的管理
批量管理：使用预先准备好的配置对大量设备进行预装，实现开箱即用
云原生演化升级
另一个重要的变化是对云原生的支持：Baetyl 的底层运行时从 Docker 变为 Kubernetes，主程序运行方式的改变使其成为运行在 Kubernetes 之内的一个具有管理特权的容器实例。这种变化将为开发者带来多方面的收益，包括：
可更新的主程序。在原先的模式里，Baetyl 系统本身需要使用手工或操作系统包管理器进行更新，这就势必要求操作者获得控制台。新的模式将“系统更新”看作 Baetyl OTA 的一部分，这将让边缘计算设备总能第一时间获得安全更新和Bug修复。
可独立更新的多容器应用。在原先的模式里，每个容器虽然是完全独立运行的服务，但升级却需要统一进行，管理员也不能定义服务之间的依赖关系。新的模式充分利用的 Kubernetes 丰富的应用定义，并且使每个服务都能被独立的部署和升级，这将让边缘计算拥有更加多样的功能。
未来对边缘集群的支持。在原先的模式里，限于 Docker 的能力，一个 Baetyl 实例只能被部署在一台单独的计算设备上。新的模式基于 Kubernetes 的编排能力，可以让一个 Baetyl 实例分布在多个不同的计算节点上，这既能提升总的计算能力，又能获得更高的可用性。
资源声明机制优化
在这些全新功能的背后，Baetyl2.0重新设计了连接 Baetyl 和 Baetyl-Cloud 的通信协议，融合了 Kubernetes的声明式资源定义和物联网的设备影子机制。
声明式资源定义实现一种幂等的分布式通信方法，巧妙的保证了资源在整个分布式系统中的一致性。然而这种方法依赖于优质的网络条件，在高延迟、丢包和不定时网络中断情况的边缘计算场景里，需要一种更轻量级的适合不稳定网络的通信机制。
基于这样的原因，Baetyl-Cloud会将对资源的声明转化为对影子设备的状态期望，并不断通过 MQTT 协议向Baetyl 设备发送通知，后者将资源声明解码使用后再以 MQTT 协议汇报新的影子设备状态。
通过这样的方法，我们就能够在弱网络条件下让云和边缘总是能正确的同步。
