大规模 IoT 边缘容器集群管理的几种架构-1-Rancher+K3s

前文回顾

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

大规模 IoT 边缘容器集群管理的几种架构-1-Rancher+K3s

Rancher： Kubernetes 统一管理平台， Rancher 是为采用容器的团队提供的一个完整的软件栈。它解决了管理多个 Kubernetes 集群的操作和安全挑战，同时为 DevOps 团队提供了运行容器化工作负载的集成工具。
K3s：完美适配边缘， K3s 是一个高可用的、经过认证的 Kubernetes 发行版，设计用于无人值守、资源受限的远程地点或物联网设备内的生产工作负载。K3s 被打包成一个<60MB的二进制文件，减少了安装、运行和自动更新一个生产型 Kubernetes 集群所需的依赖性和步骤。ARM64 和 ARMv7 都被支持，二进制文件和多架构镜像都可以使用。K3s 在小到 Raspberry Pi，大到 AWS a1.4xlarge 32GiB 服务器上都能很好地工作。

大规模 IoT 边缘容器集群管理的几种架构-1-Rancher+K3s

此方案借助 Kubernetes 的生态，并且 100%开源，无锁定，方便插件扩展，也提供了 UI 入口以提供良好的用户体验。并且核心完全是基于 Kubernetes，具备非常好的群众基础。

“云”中部署一套 Rancher 集群，Rancher 负责管理下属所有的“边”中的 K3s 集群，Rancher 集群中同时可以部署云端的业务应用，负责和边缘侧业务系统同步，以及下发数据或指令。
“边”设备中安装轻量化操作系统 MicroOS（一种不可变 OS，在本文不是重点，不展开），以及 K3s，K3s 中部署“边”的业务应用，供“端”连接使用。
“端”作为业务应用的最边缘端，通过网络连接“边”，完成业务组网，形成以“边”为中心的业务应用。

云边协同：云侧 Rancher 与边缘侧 K3s 集群之间网络（通过 rancher-cluster-agent 建立 websocket 隧道）连通时，可通过 Rancher 管理下属所有的 K3S 集群，如观测各个 K3s 集群运行状态，其上业务应用运状态等；同时 Rancher 所在集群中部署的云端业务应用可向边缘侧业务应用下发数据或指令。
边缘自治: 无论网络如何，边缘侧 K3s 集群均可以自行运行（就是一套精简的 K8s), 无需依赖云端 Rancher, 实现运行环境的边缘自治；其上运行的边缘侧业务应用如果不依赖云端应用即可正常运行，则可以做到业务的边缘自治。
轻量化 K8s: 使用轻量化的 K8s 解决方案 K3s 作为运行环境，可在硬件资源紧张的情况下提供基于 K8s 的容器服务，使业务享受 K8s 的技术红利。
100%开源: 100%开源，无锁定
原生 Kubernetes 生态: 借助完全兼容 Kubernetes 的生态，方便插件扩展，且开箱即用提供了：flannel, load balancer service, Traefik, coredns...
UI 精美: 提供了 UI 入口以提供良好的用户体验
GitOps: Rancher 默认集成 GitOps 工具 - Fleet, 提供 GitOps 自动化体验。
运维简单: Rancher 和 K3s 文档齐全，提供很多方便的运维自动化工具。
完整的企业功能: 如：认证、鉴权、单点登录、API...

K3s 相比纯容器占用资源还是略多
rancher-cluster-agent 占用资源较多: 在我的使用经验中，该 agent 可能占用 > 1G 内存的资源，这在边端是难以承受的。
网络复杂且较弱: K3s CNI 默认是 flannel, 对于边缘复杂的网络情况没有做进一步的优化和适配。如果边是 K3s Server, 端是 K3s Agent, 边端网络也不稳定，对于这种情况 K3s 基于原生 K8s 网络的能力是无法做到很好应对的。相比 Kubeedge, 边缘网络适配能力弱；相比纯容器方案，flannel/load balancer service, Traefik, coredns 等又较为复杂。