大规模 IoT 边缘容器集群管理的几种架构-0-边缘容器及架构简介

最新推荐文章于 2024-06-16 01:21:03 发布

东风微鸣

最新推荐文章于 2024-06-16 01:21:03 发布

阅读量619

点赞数

文章标签： kubernetes 云原生

本文链接：https://blog.csdn.net/east4ming/article/details/129112342

版权

📚️Reference: IoT 边缘计算系列文章

什么是边缘容器？

边缘容器的概念

边缘容器是分散的计算资源，尽可能靠近最终用户或设备，以减少延迟、节省带宽并增强整体数字体验。

可以访问互联网的设备数量每天都在增加。有包括但不限于：

智能电视
智能家居
智能手机
智能汽车
物联网 IoT 创造的多种多样其他智能设备

大多数用户运行对时间敏感的应用程序，滞后会降低用户体验的质量。遥远的集中式云服务存在高延迟，通常是应用程序性能不佳的罪魁祸首。开发边缘计算旨在使数据处理更接近用户并解决与网络相关的性能问题。

具体而言，边缘容器允许组织通过将应用程序的关键组件移动到网络边缘来分散服务。通过将智能转移到边缘，组织可以实现更低的网络成本和更快的响应时间。

但是，当组织采用边缘容器/计算时，他们会遇到诸如管理异构设备（不同的处理器、操作系统等），资源受限的设备，以及间歇性连接等问题。

边缘计算的发展趋势

📚️Reference:

Edge Computing will be 4x larger than cloud and will generate 75% of data worldwide by 2025. With hardware and software spread across hundreds or thousands of locations, the only feasible way to manage these distributed systems are the simple paradigms around observability, loosely coupled systems, declarative APIs, and robust automation, that have made cloud native technologies so successful in the cloud. Kubernetes is already becoming a key part of the edge ecosystem, driving integrations and operations.

到 2025 年，全世界** 75%的数据将会产生于边缘，边缘计算的规模将会比云大 4 倍。由于软硬件分散部署在成百上千的不同位置上，管理这些分布式系统的唯一可行的方法是围绕可观测性、松耦合系统、声明式 API 和强大的自动化**的简单范式，这些范式已经在云计算中促使云原生技术获得成功。Kubernetes 已经成为边缘生态系统的关键部分，持续推动其集成和运维。

-- Reported from Kubernetes on EDGE DAY

为什么需要容器？

容器是易于部署的软件包，容器化应用程序易于分发，使其成为边缘计算解决方案的自然选择。与传统云容器相比，边缘容器可以并行部署到地理位置不同的接入点（PoP），以实现更高级别的可用性。

云容器和边缘容器之间的主要区别在于位置。虽然云容器在遥远的区域数据中心运行，但边缘容器位于网络的边缘，更接近最终用户。

由于主要区别在于位置，边缘容器使用与云容器相同的工具，因此开发人员可以使用其现有的 Docker 专业知识进行边缘计算。若要管理容器，组织可以使用 Web UI、terraform/ansible 或容器编排系统 (K8S 等）。

边缘容器的优点

低延迟：边缘容器提供极低的延迟，因为它们距离最终用户只有"最后一公里"。
可扩展性：边缘网络比集中式云具有更多的 PoP。因此，边缘容器可以同时部署到多个位置，使组织有机会更好地满足区域需求。
成熟度：Docker 等容器技术被认为是成熟的，经过实战考验。此外，无需重新训练，因此测试边缘容器的开发人员可以使用他们熟悉的相同 Docker 工具。
减少带宽：集中式应用程序可能会产生高额网络费用，因为所有流量都集中在云供应商的数据中心。边缘容器靠近用户，可以提供预处理和缓存。

边缘容器的缺点

管理复杂性：将多个容器，多个操作系统，多个架构设备分布在许多区域需要仔细规划和运维/监控。
增加攻击面：边缘设备往往由于绑定硬件以及分散分布，一般难以及时更新，导致边缘设备经常成为被攻击成功的对象。
PoP 之间的网络费用：除了常规的入口和出口费用外，边缘容器还对 PoP 之间的流量收取单独的费用，需要考虑这些费用。（如：5G 物联网卡的网络费用）
资源紧张: CPU/ 内存 / 存储资源紧张，边缘设备相比云中心的资源，资源更为紧张，提供不了云中心类似的 CPU/内存/存储。一个边缘设备的资源一般在：1C0.5G8G - 2C8G32G 之间
网络条件恶劣: 比如存在 5G 收费网络的情况，且访问的目的端地址需要开通权限，且按照流量收费，且因为 5G 网络条件，网络传输能力受限，且不稳定（可能会在一段时间内离线）

边缘计算的应用场景

这里由于笔者的能力所限，仅做部分举例：

商业卫星
航空设备：如战斗机等
交通行业：
- 收费站
- 智慧交管
- 车路协同
- 智慧停车
能源行业
- 煤矿设备
工业制造
- 产线
CDN
智能汽车
智慧园区
金融：银行终端
智慧物流
电力
- 电力巡检
安防监控

IoT 边缘容器集群管理的通用架构

针对边缘容器的缺点之一：管理的复杂性，由于软硬件分散部署在成百上千的不同位置上，管理这些分布式系统的唯一可行的方法是围绕可观测性、松耦合系统、声明式 API 和强大的自动化的简单范式，这些范式已经在云计算中促使云原生技术获得成功。

通用的架构是：云-边-端三层架构。

云：云中心，统一管理，核心计算；
边：边缘侧，边缘计算，边缘网络，联通到云端；
端：端侧设备。

方案至少需要实现以下目标：

云边协同：通过云端管理边端的所有容器集群。管理至少包括 2 方面：下发指令，查看健康状态；
边缘自治：云/边网络中断/不稳定/异常时，边端无法连接到云端，这种情况下边端可以正常运行；
边端轻量化：需要资源少，支持 arm 架构，可以在资源受限的情况下正常运行

IoT 边缘容器集群管理的几种架构方案

总结来看，有以下多种基于开源的实践方案：

Rancher + K3s: Rancher 用于云端场景，K3s 用于边场景。端是各类设备。多个 K3s 边集群通过 Rancher 统一管理。
HashiCorp 解决方案: Nomad+ (consul 可选）+ docker/容器，这是一种受欢迎程度也很广，但是比起 k8s 还是略低的编排技术。通过 Nomad UI/API/CLI 统一管理，将 nomad agent + (consul agent 可选） + docker/其他容器作为边/端场景。
portainer+ docker: Portainer 是类似 rancher 的容器管理方案，但是可以管理多种容器编排系统，如：Docker, Docker Swarm, Kubernetes, Nomad. 这里选择直接管理 docker 及 docker swarm 的方式。Portainer 用于云端场景，作为统一管理入口，docker + portainer agent 作为边/端场景。
KubeEdge: KubeEdge 是一个开源系统，用于将本地容器化应用协调能力扩展到边缘的主机。它建立在 kubernetes 之上，为网络、应用部署和云与边缘之间的元数据同步提供基本的基础设施支持。在这种方案下，Kubernetes 集群/Kubeedge CloudCore 作为云端场景，EdgeCore 作为边，edged 作为端。
除了以上较成熟且有案例的方案外，还有以下方案：
1. OpenYurt
2. SuperEdge
3. Akri
4. WasmEdge, 基于 Wasm, WasmEdge 为云原生和边缘原生环境中的 Linux 容器提供了一个轻量级、快速、安全和可移植的替代方案。未来可期。