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

121次阅读

共计 7063 个字符，预计需要花费 18 分钟才能阅读完成。

前文回顾

  1. 大规模 IoT 边缘容器集群治理的几种架构 -0- 边缘容器及架构简介
  2. 大规模 IoT 边缘容器集群治理的几种架构 -1-Rancher+K3s
  3. 大规模 IoT 边缘容器集群治理的几种架构 -2-HashiCorp 解决方案 Nomad
  4. 大规模 IoT 边缘容器集群治理的几种架构 -3-Portainer
  5. 大规模 IoT 边缘容器集群治理的几种架构 -4-Kubeedge
  6. 大规模 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 模型在边缘存在的问题

在理论利用中，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 边缘计算

对于 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 边缘计算

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 编写.

正文完
运维
发表至： 运维
2023-08-27
 0
关于运维:融云-IMKit-Web-端上线带你感受开发效率的参差
关于运维:Nomad系列Nomad网络模式
关于运维:阿里云多账号管控与网络安全集中化管理能力升级发布
关于运维:玩转分布式架构下的可观测性