前文回顧
大規模 IoT 邊緣容器叢集管理的幾種架構-0-邊緣容器及架構簡介
?️Reference:
IoT 邊緣計算系列文章
Rancher + K3s
簡介
- Rancher： Kubernetes 統一管理平臺， Rancher 是為採用容器的團隊提供的一個完整的軟體棧。它解決了管理多個 Kubernetes 叢集的操作和安全挑戰，同時為 DevOps 團隊提供了執行容器化工作負載的整合工具。
- K3s： 完美適配邊緣， K3s 是一個高可用的、經過認證的 Kubernetes 發行版，設計用於無人值守、資源受限的遠端地點或物聯網裝置內的生產工作負載。K3s 被打包成一個<60MB的二進位制檔案，減少了安裝、執行和自動更新一個生產型 Kubernetes 叢集所需的依賴性和步驟。ARM64 和 ARMv7 都被支援，二進位制檔案和多架構映象都可以使用。K3s 在小到 Raspberry Pi，大到 AWS a1.4xlarge 32GiB 伺服器上都能很好地工作。
參考架構
此方案藉助 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 等又較為複雜。
繼續閱讀
- 大規模 IoT 邊緣容器叢集管理的幾種架構-2-HashiCorp 解決方案 Nomad
- 大規模 IoT 邊緣容器叢集管理的幾種架構-3-Portainer
- 大規模 IoT 邊緣容器叢集管理的幾種架構-4-Kubeedge
- 大規模 IoT 邊緣容器叢集管理的幾種架構-5-總結
參考文件
三人行, 必有我師; 知識共享, 天下為公. 本文由東風微鳴技術部落格 EWhisper.cn 編寫.