大规模 IoT 边缘容器集群管理的几种架构 -6- 个人体验及推荐

简介: 大规模 IoT 边缘容器集群管理的几种架构 -6- 个人体验及推荐

概述

在前文,我列出以下几种解决方案:

  • Rancher + K3s
  • HashiCorp 解决方案 — Nomad + Docker
  • Portainer + Docker
  • Kubeedge

其中,Rancher + K3s 是基于且兼容 K8s 的解决方案;Kubeedge 是构建于 K8s 之上的,但是核心的 Kubeedge 架构是完全另外一套体系;而 Hashicorp 解决方案和 Portainer 解决方案可以说是和 K8s 没有关系,主要是基于 Docker 等容器的。而且也可以基于其他的驱动(如 podman 等等)

笔者基于边缘架构主要为:单片 arm 开发板 的情况,对以上的各个方案进行了深入的体验。

在深入体验另外 2 个容器平台:hashicorp nomad 和 portainer 时,明显感触到:相比 k8s k3s,这 2 个更适合物联网场景。(本章先抛开 KubeEdge 不谈,KubeEdge 我个人认为是适合更复杂的、和业务耦合更深或者需要调度边缘 AI 的高级边缘计算体系。)

K8s 不适合物联网,原因有:

  • 资源占用高,
  • 对网络要求高
  • 网络模型复杂。

K3s 只是(部分)解决了资源占用的问题,但是后两个问题仍然存在。

📝Notes

K3s 是完全兼容 K8s 的发行版,从 1.23 之后,随着 K8s 功能的增加,K3s 也变得越来越重。

根据 K3s 安装要求:

  • 对于 arm64 设备,操作系统必须使用 4k 页面大小;
  • CPU/ 内存 最低是 1 核 512MB 内存,推荐是 2 核 1G; 但是实际应用场景中,要求会更高,一般内存都是 2G 起步。
  • 更要命的是对存储的要求,K3s 默认启动需要的 K8s 镜像,差不多就需要占用 4-6 G 的空间,如果运行 etcd, 那么 SD 卡这种边缘场景常见的存储是无法满足的。
    关于网络模型,近期 K3s 也添加了和 tailscale 整合 的功能以进一步简化网络模型。但是 K8s 自带的 主机网络 /Service IP/Cluster IP 是绕不过去的。

这两个,相比 k3s 都更轻量。而且对网络要求不高,甚至所有设备可以只用一套 server 端管理。

网络模型也很简单,主机网络就行。

此外,这两个针对物联网场景还有特殊优化,如 网络单向联通;边缘端断线情况下优化;支持管理非 docker 资源等等。

Rancher + K3s 模型在边缘存在的问题

在实际应用中,Rancher + K3s 的边缘部署架构如下:

Rancher + K3s 边缘架构

Rancher + K3s 落地案例

落地案例更明显:

  • 1 套:“云”中部署一套 Rancher 集群,Rancher 负责管理下属所有的“边”中的 K3s 集群,Rancher 集群中同时可以部署云端的业务应用,负责和边缘侧业务系统同步, 以及下发数据或指令。
  • N 套:“边” 设备中安装 K3s,K3s 中部署“边”的业务应用,供“端”连接使用。🐾这里一个 " 边 " 就是需要一套 K3s 集群的,也就是说既有 K3s Worker, 也有 K3s Master.
  • “端”作为业务应用的最边缘端,通过网络连接“边”,完成业务组网,形成以“边”为中心的业务应用。

这样的架构在实际应用中,存在什么问题呢?

" 边 " 端存储容量

很多边端设备只有 8G 存储,除去系统和一些必要的软件包,空间就剩 4 - 6 G 了,而且 K8s 是对存储空间有强制 GC 的。那么极端情况下,可能 K3s master 都 pull 不下来完整的镜像包,导致系统报错,K3s 启动失败。

" 边 " 端存储性能不足

" 边 " 端存储主要是 SD 卡或 emmc 存储,如果下边挂载较多 K3s worker. K3s Master 还面临存储性能 IO 不足的情况。

" 边 " 端 K3s Master 和 Worker 对网络要求高

由于 K3s 是完全兼容 K8s 的,而 K8s 的 watch-list 机制是为稳定的数据中心场景设计的。在边端,也对网络要求很高。但是这在边端是不可能的情况,在实践中,边端出现:

  • Master 和 Worker 长时间不通
  • Master 和 Worker 时不时不通
  • Worker 长时间离线
  • DNS 网络异常
  • Master 能连 Worker, Worker 连不到 Master
  • Master 不能连 Worker, Worker 能连 Master
  • Master 和 Worker 间带宽很小
  • Master 和 Worker IP 地址变动

各种各样网络不稳定的情况太常见了,以上任何一种情况,都可能导致 K3s worker 上应用异常、K3s master 异常甚至整个 K3s 边端集群异常。

这一点是基于 K8s 的边缘架构存在的最大问题

" 云 " 端和 " 边 " 端对网络要求也高 异常后无法自愈

" 云 " 端和 " 边 " 端是通过 Rancher 的 Agent 来连接的,走的是 websocket 协议。

但是实际应用中,还是发现 " 云 " 端和 " 边 " 端对网络要求也高," 云 " 端要管理 " 边 " 端,是有大量的数据要实时同步的,网络出现异常后,也会导致 " 边 " 端离线,无法自愈重连。

" 边 " 端自愈能力差

因为 " 边 " 端复杂的网络情况与 K8s 架构的不相容,导致实际应用中," 边 " 端自愈能力很差。

在 " 边 " 端异常的情况下,十有八九都是需要人工登录边端处置恢复的。

" 边 " 端对 CPU 和 内存资源要求也高

" 边 " 端是一套完整的 K8s 集群,那么这些服务都是需要启动的:

  • etcd 或 K3s kine + sqlite
  • k8s api server
  • k8s scheduler
  • k8s 各种 controller
  • CRI: 容器运行时 containerd
  • CNI: 网络插件
  • CSI: 至少也是 local-path pod
  • CoreDNS
  • Metrics Server
  • Ingress: Traefik
  • kubelet
  • kubeproxy

除了这些 pod, 还需要主机级别的服务:

  • IPTables 或 nftables
  • Netfilter
  • Overlay fs

这么一大堆 Pod 和服务都要启动,对边缘端的 CPU 和 内存资源也是巨大的消耗。

" 边 " 端网络模型复杂

还是 K8s 带来的问题," 边 " 端是一套完整的 K8s/k3s 集群,那么 " 边 " 端网络模型自然包括:

  • Host Network
  • Service Network
  • Cluster Network
  • DNS

要实现 K8s CNI 模型,又会引入 overlay 网络。

甚至为了实现 " 云 " “边” “端” 的联通,可能还需要引入:

  • 隧道网络
  • 边缘网关网络

进一步提升了网络的复杂性!

导致出现问题非常难以处理,简单问题复杂化。

小结

Rancher + K3s, 在边缘计算场景下的网络拓扑架构是:

  • 1 套:“云”中部署一套 Rancher 集群,Rancher 负责管理下属所有的“边”中的 K3s 集群,Rancher 集群中同时可以部署云端的业务应用,负责和边缘侧业务系统同步, 以及下发数据或指令。
  • N 套:“边” 设备中安装 K3s,K3s 中部署“边”的业务应用,供“端”连接使用。🐾这里一个 " 边 " 就是需要一套 K3s 集群的,也就是说既有 K3s Worker, 也有 K3s Master.
  • “端”作为业务应用的最边缘端,通过网络连接“边”,完成业务组网,形成以“边”为中心的业务应用。

K3s 是基于 K8s 的兼容实现,同时因为网络拓扑架构,导致这种架构存在以下问题:

  • " 边 " 端存储容量不足
  • " 边 " 端存储性能不足
  • " 边 " 端无法满足 K3s Master 和 Worker 对网络的高要求
  • " 云 " 端和 " 边 " 端对网络要求也过高 异常后无法自愈
  • " 边 " 端自愈能力差
  • " 边 " 端对 CPU 和 内存资源要求也高
  • " 边 " 端网络模型复杂

而且每个问题几乎无解。

边缘计算场景对容器编排的需求

结合上述场景,我理解的边缘计算场景对容器编排的需求:

  • " 边 " 端最好一个 agent, 不要引入过多其他镜像资源,也不要引入过多其他组件
  • 资源占用轻量,agent CPU 内存 存储都消耗极少
  • 最好统一 " 云 " 端管理," 边 " 端不需要再有一个消耗资源的管理端
  • 弱网环境适应性强
  • 自愈能力强
  • 不要额外再引入其他网络模型,最好能直接基于主机网络运行,也不强依赖 DNS

那么基于 Docker 的边缘容器集群管理方案:

  • HashiCorp Nomad
  • Portainer

就表现地更有优势。

Portainer 边缘计算

Portainer 架构

对于 Edge, Portainer 有专门优化,可以参考左侧的 Edge 架构。

  • " 云 " 端负责管理,portainer server 位于云端
  • " 边 " 端都是 Edge Agent
  • “云” " 边 " 不需要双向通信,而是 " 边 " 端通过直连或隧道定期去 Server 端 pull 信息

以上是针对网络模型的优化,使其更适合边缘计算的场景。

另外,Poratiner 的 Agent 非常轻量级,只使用大约 10MB 的内存,而且边缘端就只需要部署这一个 Agent, 这就是为什么它也可以在硬件资源有限的边缘设备上运行。唯一的依赖就是边缘端需要安装有 Docker.

开源版边缘功能

  • Edge Agent 默认网络策略:pull
  • Edge Compute 相关模块和菜单:
  • Edge Groups: 将一组边缘设备 / 环境通过静态 / 动态的方式归为一个 Edge Group, 方便批量管理
  • Edge Stacks: 类似 Docker Compose 的概念,可以将一套边缘服务批量推向一个或所有的 Edge Group
  • Edge Jobs: 类似 crontab 的功能,在边缘端批量运行 job.
  • 边缘应急特性支持:
  • Interl OpenAMT
  • FDO
  • 管理边缘端 OS 层文件系统(通过 docker linux socket 实现)

通过这些功能,Portainer 可以:

  • 边缘端通过 pull 心跳在复杂网络条件下保持与 Portainer Server 的联通和受管
  • 通过 Edge Compute 的 Edge Groups/Edge Stacks/Edge Jobs 模块,实现对边缘端的批量服务部署和 job 部署

但是开源版相比商业版,阉割的功能较多,比如开源版无法实现一键批量 onboarding 等重要边缘功能。

商业版额外功能

  • 一键 onboaring: 边缘设备一键批量安装
  • 安全通信:在复杂网络条件下,离线条件下,实现基于隧道的连接。
  • Edge Devices: 边缘设备管理
  • Waiting Room: 等候室,有选择地连接请求接入 server 端的边缘设备

小结

个人认为,相比 Rancher + k3s 的方案,portainer 的边缘计算解决方案有以下突出优势:

  • 资源占用少
  • 网络模型针对边缘网络优化

更详细来说,这些功能特性相比 Rancher + K3s 的更适合边缘场景:

  • " 云 " 端 Server, " 边 " 端只有 Agent
  • Edge Agent 轻量,运行内存 10MB 左右
  • Edge Agent pull 模型,针对边缘网络适应性强
  • 没有引入其他网络模型,也不强依赖 DNS

但是,开源版 portainer 也存在明显的功能缺失,最主要的功能缺失是:

  • 一键 onboaring: 边缘设备一键批量安装

的功能。

HashiCorp Nomad 边缘计算

Nomad 边缘参考架构

HashiCorp Nomad 自 1.3 版本以来,针对边缘端增加了很多实用功能:

  • 1.3 引入:Nomad 原生服务发现(简单场景下不再需要 Consul 组件)
  • 1.4 引入:
  • 健康检查
  • Nomad Variables(简单场景下不再需要 Vault 组件)
  • 1.5 引入:
  • 节点动态元数据,更方便 Node 动态管理
  • 1.6 引入:
  • Node Pool 节点池概念,更方便节点批量管理

使得其在边缘端,不再需要依赖:

  • Cosul
  • Vault

这 2 个组件,仅通过 Nomad Agent 就可以实现边缘端的:

  • 容器编排管理
  • 基本服务发现和管理
  • 变量参数 / 环境变量 / 配置管理

等功能。

与 Portainer 类似,其在边缘端也只有一个 Edge Agent. 内存占用也仅为 20-40 MB 左右。

Nomad 支持地理上遥远的客户端,这意味着 Nomad 服务器集群不需要在客户端附近运行。(K8s 就做不到这样。)

此外,断开连接的客户端的 allocations (分配) 可以正常重新连接,处理边缘设备遇到网络延迟或临时连接丢失的情况。

这里特别提到 Nomad 的 2 个参数:

max_client_disconnect

如果不设置此属性,Nomad 将运行其默认行为:当 Nomad 客户机的心跳失败时,Nomad 将把该客户机标记为停机 (down),并把 allocations 分配标记为丢失 (lost)。Nomad 将自动在另一个客户端上安排新的分配。但是,如果关闭的客户端重新连接到服务器,它将关闭其现有的分配。这是次优的,因为 Nomad 将停止在重新连接的客户端上运行分配,只是为了放置相同的分配。(K8s 的行为也是,且只能是这样。)

对于许多边缘工作负载,特别是具有高延迟或不稳定网络连接的工作负载,这是破坏性的,因为断开连接的客户端并不一定意味着客户端关闭。Allocations 可以继续在临时断开连接的客户端上运行。对于这些情况,就需要设置 max_client_disconnect 属性,以正常处理断开连接的客户端分配。

如果设置了 max_client_disconnect ,当客户端断开连接时,Nomad 仍将在另一个客户端上安排分配。但是,当客户端重新连接时:

  • Nomad 将重新连接的客户端标记为就绪 (ready)。
  • 如果有多个作业版本,Nomad 将选择最新的作业版本并停止所有其他分配。
  • 如果 Nomad 将丢失的分配重新调度到新客户端,并且新客户端具有更高的节点等级,则 Nomad 将继续新客户端中的分配并停止所有其他客户端。
  • 如果新客户端具有更差的节点排名或存在平局,则 Nomad 将恢复重新连接的客户端上的分配并停止所有其他客户端。

这是具有高延迟或不稳定网络连接的边缘工作负载的首选行为,尤其是在断开分配是有状态的情况下。

举例来说:

在某一个边缘设备中运行有 1 个 web 服务,此时,边缘设备与 (边缘容器管理的) Server 端断开连接

  • 在 K8s 中,就是 Node Unknown 或 NotReady 的状态,会认为 web 服务已宕机,会在另外一台边缘设备中启动 web 服务;在恢复连接后,发现最新的实例是在另一台边缘设备中,那么前一台设备的服务会被关闭。对于使用该 web 的用户来说,可能就是在边缘设备重新连接到 (边缘容器管理的) Server 端后发现 web 服务异常(被管理端关闭)
  • 在启用该参数的 Nomad 中,Node 会是 lost 状态,分配的服务会是 Unknown 状态。会在另外一台边缘设备中启动 web 服务;在恢复连接后,发现 web 服务正常运行,关闭后启动的 web 服务。对于使用该 web 的用户来说,体验是一直没有中断的。

Template change_mode

另外还有一个参数,是 Template 块下的 change_mode

将 Template 节 change_mode 设置为 noop。默认情况下, change_mode 设置为 restart ,如果您的客户端无法连接到 Nomad 服务器,这将导致任务失败。由于 Nomad 在边缘数据中心上调度此作业,因此如果边缘客户端与 Nomad 服务器断开连接(从而断开服务发现),则服务将使用先前的模板配置。

小结

个人认为,相比 Rancher + k3s 的方案,HashiCorp Nomad 的边缘计算解决方案有以下突出优势:

  • 资源占用少 - 边缘只有 Nomad Agent
  • 管理端和 Agent 端可以物理距离很远 - 天南地北的所有边缘设备可以通过一个云端中心来管理
  • 相关参数针对边缘网络优化 - 如 max_client_disconnect

更详细来说,这些功能特性相比 Rancher + K3s 的更适合边缘场景:

  • " 云 " 端 Server, " 边 " 端只有 Agent
  • Nomad Agent 轻量,运行内存 20-40MB 左右
  • Nomad Agent 与 Server 心跳检测是基于 pull 模型,针对边缘网络适应性强
  • 专为边缘设计的 max_client_disconnect 参数
  • 没有引入其他网络模型,也不强依赖 DNS

另外,相比开源版 portainer, Nomad 还有一重优势,即:

  • 一键 onboaring: 边缘设备一键批量安装甚至是预安装

得益于 Nomad 的良好架构,其天生是为大规模容器编排而设计的,可以做到使用 Terraform 或 Ansible 一键批量部署,甚至是预安装(烧录). 典型如 Nomad Agent 配置,统一如下:

data_dir  = "/opt/nomad/data"
bind_addr = "0.0.0.0"
client {
  enabled = true
  servers = ["<nomad_server_ip_list>"]
}
HCL

总结

在 IoT 边缘容器集群管理领域,基于 K8s 的解决方案(包括 Rancher + K3s) 明显不太适应,笔者体验 2 年左右坑太多了,主要原因是:

  • 资源消耗高
  • 网络条件要求高
  • 网络模型复杂
  • 自愈能力差
  • 引入了过多额外组件

但是,HashiCorp Nomad,Portainer 相比 k8s k3s, 在物联网 / 边缘计算领域是更有优势的。值得一试。因为它们:

  • 轻量:只有一个 Agent 且内存占用极低
  • 针对边缘网络做了特殊优化
  • 没有引入复杂网络模型(如 Service Network, Pod Network, Overlay Network…, 主要依赖 Host Network, 容器端口映射,顶多多一个 bridge 网络), 不依赖 DNS
  • 自愈能力强
  • 没有引入了过多额外组件,就多了一个 Agent

我个人更推荐使用 Nomad (小规模 / 家庭场景可以使用 Portainer).

以上.

如果您有更好的经验, 欢迎交流探讨~

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务&nbsp;ACK 容器服务&nbsp;Kubernetes&nbsp;版(简称&nbsp;ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情:&nbsp;https://www.aliyun.com/product/kubernetes
相关文章
|
1月前
|
Kubernetes 开发者 Docker
基于容器技术的微服务架构
基于容器技术的微服务架构
32 0
|
1月前
|
运维 API Docker
深入浅出:微服务架构与容器化技术的完美融合
【2月更文挑战第13天】 在现代软件开发领域,微服务架构和容器化技术已成为推动企业快速发展的两大核心力量。本文将从微服务的基本概念出发,深入探讨其与容器化技术结合的必然性与优势,进而分析如何在实践中有效地实现二者的完美融合。通过对微服务架构的细致解析及容器化技术的应用展示,旨在为读者提供一种全新的视角,理解并掌握这一前沿技术趋势,以指导实际工作中的技术选择与架构设计。
|
2月前
|
开发者 Docker 微服务
深入浅出:使用Docker容器化部署微服务架构
在当今快速迭代的软件开发环境中,微服务架构因其高度解耦和独立性而成为企业首选。然而,微服务的管理和部署可能会变得复杂和繁琐。本文将探讨如何利用Docker,一个轻量级的容器化技术,来简化和加速微服务的部署。我们将从Docker的基础概念入手,详细介绍如何创建、配置和运行微服务容器,最后讨论Docker在微服务架构中的优势和挑战。本文旨在为开发者提供一条清晰的路径,通过容器化技术实现微服务架构的高效部署和管理。
87 0
|
2月前
|
Kubernetes 开发者 Docker
深入浅出:使用Docker容器化部署微服务架构
在当今快速演进的软件开发领域,微服务架构因其高度的模块化和可伸缩性而受到广泛欢迎。然而,微服务的部署和管理也带来了新的挑战。本文旨在通过深入浅出的方式,探讨如何利用Docker容器技术有效地部署和管理微服务架构。我们将从Docker的基本概念出发,逐步深入到如何构建、部署微服务,并讨论在此过程中可能遇到的常见问题及其解决策略。本文不仅适合刚接触Docker和微服务的新手,也为有经验的开发者提供了实用的参考。
56 1
|
2月前
|
JSON JavaScript Docker
深入浅出:使用Docker容器化部署微服务架构
本文旨在向读者展示如何利用Docker技术高效地构建和部署微服务架构。通过深入浅出的方式,我们将探索Docker的基本概念、容器化的优势以及如何将其应用于微服务架构中。此外,文章还将提供一个简单的示例,指导读者实践如何使用Docker将一个现有的后端应用容器化,并部署到本地开发环境中。不同于传统的摘要,这里我们强调实践操作的重要性,鼓励读者通过实际操作来加深对Docker和微服务架构的理解。
52 1
|
2月前
|
Java 开发者 Docker
深入浅出:使用Docker容器化部署微服务架构
在本文中,我们将探索Docker容器技术如何革新微服务架构的部署方式,提高开发效率和应用的可扩展性。不同于传统摘要的概述风格,我们将通过一个实际案例,步骤明晰地展示如何将一个简单的微服务应用容器化,并在Docker环境中部署运行。本文旨在为开发者提供一个清晰、易懂的指南,帮助他们理解容器化技术的基本原理和操作流程,无论是初学者还是有经验的开发人员都能从中获益。
|
2月前
|
存储 Kubernetes Docker
深入浅出:使用Docker容器化部署微服务架构
在当今快速迭代的软件开发周期中,微服务架构凭借其高度的模块化和灵活性成为了众多企业的首选。然而,随之而来的是对环境一致性和服务部署效率的挑战。本文将探讨如何利用Docker这一轻量级容器技术,实现微服务的快速、一致和可靠部署。通过深入浅出的方式,我们将介绍Docker的基本概念、容器化微服务的优势以及步骤详解,旨在为读者提供一个清晰的实践指南,帮助他们在微服务架构的部署过程中提升效率和可靠性。
66 0
|
2月前
|
设计模式 运维 Docker
深入浅出:使用Docker容器化部署微服务架构
本文旨在为读者提供一个全面且易于理解的指南,介绍如何使用Docker技术来容器化部署微服务架构。随着云计算和微服务架构的普及,Docker作为一种轻量级的容器解决方案,已经成为开发和运维领域的热门技术。本文将从Docker的基本概念出发,详细讲解如何将传统的应用服务转化为容器化的微服务,包括Dockerfile的编写、镜像构建、容器部署以及服务编排等关键步骤。此外,文章还会探讨使用Docker部署微服务架构的最佳实践和常见问题,帮助读者有效地管理和优化其微服务系统。
73 1
|
2月前
|
Kubernetes API Docker
深入浅出:使用Docker容器化部署微服务架构
在本文中,我们将探索如何利用Docker容器技术实现微服务架构的高效部署与管理。不同于传统的摘要方式,我们将采用一个故事化的场景引入,设想在一个快速发展的互联网公司中,随着业务的扩张,传统的单体应用逐渐变得难以维护和扩展。开发团队决定采用微服务架构来解决这一问题,而Docker作为容器化技术的佼佼者,被选为部署和管理微服务的关键工具。文章将详细介绍Docker的基本概念、微服务架构的优势,以及如何结合两者进行高效的应用部署和管理。
25 0
|
2月前
|
存储 运维 Docker
深入浅出:使用Docker容器化部署微服务架构
在快速迭代和高效部署的今天,Docker作为一种轻量级的容器化技术,已经成为开发和运维领域的热门话题。本文将从容器化技术的基础出发,详细介绍如何使用Docker来容器化部署微服务架构。我们不仅会探讨Docker的基本概念、核心优势以及与传统虚拟化技术的区别,还将通过一个实际的微服务应用示例,指导读者如何构建、部署并管理Docker容器。此外,文章还将涉及Docker Compose工具的使用,以简化多容器应用的管理。无论你是开发人员还是运维工程师,本文都将为你提供一条清晰的学习路径,助你掌握使用Docker容器化部署微服务架构的关键技能。