Kubernetes無處不在——開發者的筆記本、樹莓派、雲、資料中心、混合雲甚至多雲上都有Kubernetes。它已然成為現代基礎設施的基礎，抽象了底層的計算、儲存和網路服務。Kubernetes隱藏了各種基礎設施環境之間的差異，它將多雲變成了現實。
Kubernetes也成為了編排的通用控制平面，不僅僅是容器編排，還包括虛擬機器、資料庫，甚至SAP Hana例項等各種資源。
儘管Kubernetes發展迅猛，但還是給開發者和運營商丟擲了許多挑戰。其中一個關鍵挑戰是在邊緣執行Kubernetes。與雲或資料中心相比，邊緣是非常不同的。它執行在一個高度受限環境中的遠端位置。與執行在資料中心的同類裝置相比，邊緣裝置的計算、儲存和網路資源只有一小部分。邊緣裝置與雲的連線是斷斷續續的，而且它們主要在離線環境中執行。這些因素使得很難在邊緣部署和管理Kubernetes叢集。
基於此，業界應用最為廣泛的K8S管理平臺建立者Rancher Labs釋出了K3s，這是一個Kubernetes的發行版，它針對邊緣進行了高度優化。雖然K3s是Kubernetes的簡化版、迷你版，但API的一致性和功能並沒有受到影響。從kubectl到Helm再到Kubernetes，幾乎所有的雲原生生態系統的工具都能與K3s無縫對接。實際上，K3s是一個經過CNCF認證的、符合要求的Kubernetes發行版，可以在生產環境中部署。幾乎所有執行完整的Kubernetes叢集的工作負載都能保證在K3s叢集上工作。
Kubernetes這個10個字母的單詞，在社群裡被稱為K8S。由於K3s正好是Kubernetes記憶體的一半，Rancher為新的發行版找到了一個5個字母的單詞，並將其簡稱為K3s。
深入瞭解K3s架構
K3s的魅力在於它的簡單性。作為一個單一的二進位制檔案（約100MB）進行打包和部署，你只需幾秒鐘就可以得到一個完全成熟的Kubernetes叢集。安裝體驗就像在叢集的每個節點上執行一個指令碼一樣簡單。
K3s二進位制檔案是一個自給自足的封裝實體，它幾乎執行了Kubernetes叢集的所有元件，包括API server、scheduler和controller。預設情況下，每個K3s的安裝都包括控制平面、kubelet和containerd執行時，這些已經足以執行Kubernetes工作負載。當然，也可以新增只執行kubelet agent和containerd執行時的專用worker節點，來排程和管理pod生命週期。
與傳統的Kubernetes叢集相比，K3s中的master節點和worker節點沒有明顯的區別。可以在任何節點上排程和管理Pod，不管它們扮演的是什麼角色。所以，master節點和worker節點的命名方式不適用於k3s叢集。
在k3s叢集中，將執行控制平面元件與kubelet的節點稱為server，而只執行kubelet的節點稱為agent。server和agent都有容器執行時和一個kubeproxy，管理整個叢集的tunnel和網路流量。
在典型的k3s環境中，你執行一個server和多個agent。在安裝過程中，如果你傳遞了server的URL，節點就會變成一個agent；否則，你最終會執行另一個獨立的k3s叢集，有自己的控制平面。
那麼，Rancher是如何降低k3s的記憶體呢？首先，他們去除了Kubernetes的很多可選元件，這些元件對於執行一個最低限度的叢集來說並不重要。然後，它增加了一些必要的元素，包括containerd、Flannel、CoreDNS、CNI、Traefik ingress controller、本地儲存程式、一個嵌入式服務負載均衡器和一個整合的網路策略controller。所有這些元件都被打包成一個二進位制檔案，並在同一個程式中執行。除了這些，該發行版還支援開箱即用的Helm chart。
上游的Kubernetes發行版是臃腫的，有很多程式碼可以刪除。例如，儲存volume外掛和雲提供商API，這些會極大增加發行版的記憶體。K3s省略了所有這些，以最大限度地減少二進位制的大小。
另一個關鍵的區別是叢集狀態的管理方式。Kubernetes依靠分散式鍵值資料庫etcd來儲存整個叢集的狀態。K3s用名為SQLite的輕量級資料庫取代了etcd，SQLite是一個成熟的嵌入式場景資料庫。很多移動應用都會捆綁SQLite來儲存狀態。
通過在至少三個節點上執行etcd，Kubernetes控制平面變得高度可用。另一方面，SQLite並不是分散式資料庫，它成為為了實現控制平面的高可用，K3s server可以指向外部資料庫端點。支援的資料庫包括etcd、MySQL和PostgreSQL。通過有效地將狀態委託給外部資料庫，K3s支援多個控制平面例項，使得叢集具有高可用性。
Rancher正在試驗一種名為DQLite的分散式版本的SQLite，它最終可能會成為K3s的預設資料儲存。
K3s最大的優點是它的 “包含電池但可替換 "的方式。例如，我們可以用Docker CE執行時替換containerd執行時，用Calico替換Flannel，用Longhorn替換本地儲存等等。
關於K3s架構的詳細討論，我強烈推薦你觀看K3s的架構師Darren Shepherd在北美KubeCon 2019上的演講：
K3s部署場景和拓撲結構
K3s發行版支援多種架構，包括AMD64、ARM64和ARMv7。憑藉一致的安裝體驗，K3s可以在Raspberry Pi Zero、NVIDIA Jetson Nano、Intel NUC或Amazon EC2 a1.4xlarge例項上執行。
在你需要一個單節點Kubernetes叢集來維護部署manifest的相同工作流程的環境中，請在伺服器或邊緣裝置上安裝K3s。這使你可以靈活地使用你現有的CI/CD流水線和容器映象以及Helm chart或YAML檔案。
如果你需要一個在AMD64或ARM64架構上執行的高可用叢集，安裝一個3節點的etcd叢集，然後是3個K3s server和一個或多個agent。這樣就可以為你提供一個生產級的環境，併為控制平面提供HA。
當在雲中執行K3s叢集時，將server指向一個託管資料庫，如Amazon RDS或Google Cloud SQL，以執行一個具有多個agent的高可用控制平面。每個K3s server可以執行在不同的可用性區域，以獲得最大的正常執行時間。
如果你在具有可靠的、始終線上連線的邊緣計算環境中執行K3s，則在雲中執行server，在邊緣執行agent。這使你可以靈活地在雲中執行一個高可用和可管理的控制平面，同時在遠端環境中執行agent。
最後，你可以將K3s HA控制平面部署在5G邊緣位置，如AWS Wavelength和Azure Edge Zones環境中，agent在裝置中執行。這種拓撲結構呼應了智慧建築、智慧工廠和智慧醫療場景。
在此係列的下一篇文章中，我將介紹在邊緣環境中部署HA叢集的步驟，保持關注！