在前面的13天中，我們介紹了基於 Device 端與 Edge 端服務整合的 KubeEdge，並提出了以原生 kubernetes 的差異性測試實作，在 kubeEdge 相依於原生 kubernetes 叢集 Master Node 的服務，並透過對外洩漏 API 入口與 edgecontroller 溝通下，將服務派送資料給予 Edge Node 進行服務建立，在整體規劃在架構上，Cloud 端仍然需要有較大算力的設備介入調度，才可減輕多個 Edge 端的服務調度壓力，而如何建立一個 輕量化的叢集與邊緣運算基礎架構 則是我們後續討的方向，在此訴求之下，我們找到了一個相同於 kubernetes 體系的小型化(精緻閹割?)叢集服務系統 k3s，因此往後幾天的文章，我們將測試 k3s 在原生 kubernetes 服務的基礎功能訴求之下，與其服務架構與差異性值比較，最終也將統整 kubernetes、kubeEdge、k3s 上的服務差異進行檢視。
k3s 是基於 k8(ubernetes)s 的架構進行開發，主要由 Rancher Labs (社群)進行維護與開發建置，內部架構主要是將特定版本的 kubernetes 進行封裝打包(會有版本更新時差)，再從 kubernetes 裡面刪除部分功能項目，而刪除的項目總共有 5 個，因此得名 k3s，Rancher Labs 在終端設備之中，了解到 User 終端(IOT、Edge)接入設備多半以Raspberry Pi 或是基礎運算 PC 平台搭建，希望降低入門型設備運算瓶頸、對於 ARM 架構的平台的支援，因此在 k3s 的最小封裝版本約為 40MB，且最低僅需 512MB 的 RAM 即可啟動，並且在架構上提供 ARM64、ARMHF、AMD64 平台上的支援，而在安裝部分 官方 Release 的 Binary 包中同時提供 Server / Cluster Node 的功能，這比起 kubernetes 的服務安裝來說，可說是 超級/超級/超級(很重要所以說三遍)的輕量化與快速使用的搭建叢集方案了！。
圖片來源 https://blog.docker.com/2017/08/what-is-containerd-runtime/
簡單來說，功能面刪除了 非必要性的 服務外掛，對於 kubernetes 部分未穩定與非正式的開發版本功能 與 外掛形式的輔助功能，進行了完美的斷捨離切割降低出問題的機會，也同步減輕整體環境的執行容量，在安裝部分，提出了較為簡易的安裝方案，透過下載 Linux 執行檔(.bin)的方式，下載之後即可執行使用作法，此種安裝方案與原生 kubernetes 的繁瑣套件安裝的服務搭建快速不少，而在安全性添加 TLS 認證功能進行安全性管理，在驗證節點加入與重新連線時是否屬於合法連線，另外在服務容器化 (Containerlize)的功能之中，為了降低 Container 啟動時溝通的層級(如上圖)，因此將 Docker Container 採取選用機制，內部封裝使用較為底層的 containerd 進行 Pod 的調度使用，並額外提供自動化派送服務 yaml 檔案的功能，此外，在雲端服務之中最為看中的網路服務，k3s 預設使用 Fannel CNI 進行 Pod 網路建構，並以 CoreDNS服務 協助服務導向，在眾多的功能收斂與調整之下，我們可以看到 40MB 的 k3s 服務中，雖刪除了不少原生 kubernetes 的營運外掛項目，但內容仍然是相當豐富的。
圖片來源 https://k3s.io/
在服務架構圖(上圖)，可看到 k3s 的服務架構，其實與原生 kubernetes 的服務架構大同小異，分別以 Server (kubernetes Master)、Agent(kubernetes cluster) 為叢集架構角色主體，但 k3s 的叢集服務為 Process 存在 User OS 之中執行，並建立 k3s 的 Master 與 Agent 的兩個角色，提供 Agent 端向 Master 端進行節點註冊(類似 kubeadm join)，在 k3s 之中 Master 與 Agent 端的溝通，同以 kubernetes 的 kube proxy 之方式進行處理，並在 Agent 端透過 kubelet 的功能處理來自於 Master 端的調度指令，而 Pod 服務則透過 kubelet 的解析並告知 containerd 進行啟動，而整體服務架構的功能，已在封裝 k3s 的應用程式 (.bin) 之中，僅需以不同的指令進行 Master / Agent 角色啟動，k3s 整體叢集架構而言，k3s 雖進行了 kubernetes 之中應用服務的功能刪減與調整，但實際規劃叢集架構仍然與 原生 kubernetes 架構循序而行，並且向 輕量化 與 支援 ARM 架構的叢集服務前進。
在 Rachaner Lab 的 k3s 服務封裝之中，在基於 kubernetes 的主線的功能開發上，透過一定時間的需求性與功能必要性分析，對於用途較為著重的功能給予保留，並將支援性形態的服務調整成使用者額外安裝的選項，在節點添加的方案，也同樣給予類似於 kubernetes hash-key 認證方案，對於添加的節點的新增與連線進行安全性的認證，而容器化(containerlize)服務則使用接近底層的 containerd，從而減輕使用 Docker container 轉譯調度 container 的執行時間差，並提供自動化派送服務(yaml 檔案放置特定位置)，基於 Pod 服務概念之上，Pod Network 的 Flannel CNI 也以在 k3s 的服務執行檔提供，在整體架構之上，同以 k8s 的基礎服務功能 在 Rachaner Lab 的 k3s 服務封裝之中，在基於 kubernetes 的主線的功能開發上，透過一定時間的需求性與功能必要性分析，對於用途較為著重的功能給予保留，並將支援性形態的服務調整成使用者額外安裝的選項，在節點添加的方案，也同樣給予類似於 kubernetes hash-key 認證方案，對於添加的節點的新增與連線進行安全性的認證，而容器化(containerlize)服務則使用接近底層的 containerd，從而減輕使用 Docker container 轉譯調度 container 的執行時間差，並提供自動化派送服務(yaml 檔案放置特定位置)，基於 Pod 服務概念之上，Pod Network 的 Flannel CNI 也以在 k3s 的服務執行檔提供，在整體架構之上，同以 k8s 的基礎服務架構之下，在不同平台與架構的拓展性提出相容方案，並建立最低的系統資源存取，提升整體叢集的服務品質，並對於較為低階的入門設備，提供輕量化叢集的方案。
iThome鐵人賽
看影片追技術