乐趣区

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

jiezi

📚️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 和弱小的自动化的简略范式，这些范式曾经在云计算中促使云原生技术获得成功。

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

  1. 云：云核心，对立治理，外围计算；
  2. 边：边缘侧，边缘计算，边缘网络，联通到云端；
  3. 端：端侧设施。

计划至多须要实现以下指标：

  • 云边协同：通过云端治理边端的所有容器集群。治理至多包含 2 方面：下发指令，查看衰弱状态；
  • 边缘自治：云 / 边网络中断 / 不稳固 / 异样时，边端无奈连贯到云端，这种状况下边端能够失常运行；
  • 边端轻量化：须要资源少，反对 arm 架构，能够在资源受限的状况下失常运行

IoT 边缘容器集群治理的几种架构计划

总结来看，有以下多种基于开源的实际计划：

  1. Rancher + K3s: Rancher 用于云端场景，K3s 用于边场景。端是各类设施。多个 K3s 边集群通过 Rancher 对立治理。
  2. HashiCorp 解决方案: Nomad+ (consul 可选）+ docker/ 容器，这是一种受欢迎水平也很广，然而比起 k8s 还是略低的编排技术。通过 Nomad UI/API/CLI 对立治理，将 nomad agent + (consul agent 可选）+ docker/ 其余容器 作为边 / 端场景。
  3. portainer+ docker: Portainer 是相似 rancher 的容器治理计划，然而能够治理多种容器编排零碎，如：Docker, Docker Swarm, Kubernetes, Nomad. 这里抉择间接治理 docker 及 docker swarm 的形式。Portainer 用于云端场景，作为对立治理入口，docker + portainer agent 作为边 / 端场景。
  4. KubeEdge: KubeEdge 是一个开源零碎，用于将本地容器化利用协调能力扩大到边缘的主机。它建设在 kubernetes 之上，为网络、利用部署和云与边缘之间的元数据同步提供根本的基础设施反对。在这种计划下，Kubernetes 集群 /Kubeedge CloudCore 作为云端场景，EdgeCore 作为边，edged 作为端。

  5. 除了以上较成熟且有案例的计划外，还有以下计划：

    1. OpenYurt
    2. SuperEdge
    3. Akri
    4. WasmEdge, 基于 Wasm, WasmEdge 为云原生和边缘原生环境中的 Linux 容器提供了一个轻量级、疾速、平安和可移植的代替计划。将来可期。

这里重点对前 4 个笔者认为较为成熟的、当初曾经可落地的计划做一个简要阐明。

持续浏览

  1. 大规模 IoT 边缘容器集群治理的几种架构 -1-Rancher+K3s
  2. 大规模 IoT 边缘容器集群治理的几种架构 -2-HashiCorp 解决方案 Nomad
  3. 大规模 IoT 边缘容器集群治理的几种架构 -3-Portainer
  4. 大规模 IoT 边缘容器集群治理的几种架构 -4-Kubeedge
  5. 大规模 IoT 边缘容器集群治理的几种架构 -5- 总结

参考资料

  • WHAT ARE EDGE CONTAINERS? (stackpath.com)
  • Getting Started With Kubernetes at the Edge – Container Journal
  • 8 CNCF Tools to Run Kubernetes at the Edge and Bare Metal – Container Journal

三人行, 必有我师; 常识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.

退出移动版