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

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

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

在前文，我列出以下几种解决方案：

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 的边缘部署架构如下：

落地案例更显著：

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 是齐全兼容 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 架构的不相容，导致理论利用中，” 边 ” 端自愈能力很差。

在 ” 边 ” 端异样的状况下，十有八九都是须要人工登录边端处理复原的。

“ 边 ” 端是一套残缺的 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

就体现地更有劣势。

对于 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 自 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>"]
}

在 IoT 边缘容器集群治理畛域，基于 K8s 的解决方案（包含 Rancher + K3s) 显著不太适应，笔者体验 2 年左右坑太多了，次要起因是：

资源耗费高
网络条件要求高
网络模型简单
自愈能力差
引入了过多额定组件

然而，HashiCorp Nomad，Portainer 相比 k8s k3s, 在物联网 / 边缘计算畛域是更有劣势的。值得一试。因为它们：

轻量：只有一个 Agent 且内存占用极低
针对边缘网络做了非凡优化
没有引入简单网络模型（如 Service Network, Pod Network, Overlay Network…, 次要依赖 Host Network, 容器端口映射，顶多多一个 bridge 网络）, 不依赖 DNS
自愈能力强
没有引入了过多额定组件，就多了一个 Agent

我集体更举荐应用 Nomad (小规模 / 家庭场景能够应用 Portainer).

以上.

如果您有更好的教训, 欢送交换探讨~

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

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

前文回顾

概述

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

“ 边 ” 端存储容量

“ 边 ” 端存储性能有余

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

“ 云 ” 端和 ” 边 ” 端对网络要求也高异样后无奈自愈

“ 边 ” 端自愈能力差

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

“ 边 ” 端网络模型简单

小结

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

Portainer 边缘计算

开源版边缘性能

商业版额定性能

小结

HashiCorp Nomad 边缘计算

`max_client_disconnect`

Template `change_mode`

小结

总结

前文回顾

概述

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

“ 边 ” 端存储容量

“ 边 ” 端存储性能有余

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

“ 云 ” 端和 ” 边 ” 端对网络要求也高 异样后无奈自愈

“ 边 ” 端自愈能力差

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

“ 边 ” 端网络模型简单

小结

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

Portainer 边缘计算

开源版边缘性能

商业版额定性能

小结

HashiCorp Nomad 边缘计算

max_client_disconnect

Template change_mode

小结

总结

“ 云 ” 端和 ” 边 ” 端对网络要求也高异样后无奈自愈

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

`max_client_disconnect`

Template `change_mode`