為什么有了 K8s，還需要 K3s？
隨著容器化技術(shù)的普及和微服務(wù)架構(gòu)的廣泛應(yīng)用，K8s逐漸成為行業(yè)標(biāo)準(zhǔn)的容器編排平臺，然而，K8s 的復(fù)雜性和資源消耗在某些場景下也成為了一個很重要的限制因素。為了解決這些問題，Rancher Labs 推出了K3s。
那么，K8s是什么？K3s又是什么？它們之間有什么關(guān)聯(lián)和區(qū)別？這篇文章，我們將對 K3s 與 K8s 進(jìn)行詳細(xì)的分析與對比。
一、K8s
1. 什么是 K8s?
K8s，全稱 Kubernetes，它是一個開源的容器編排平臺，由 Google發(fā)起，旨在自動化部署、擴(kuò)展和管理容器化應(yīng)用，為分布式系統(tǒng)提供強大的工具鏈和平臺。
2. K8s的核心組件
(1) Master 節(jié)點組件：
- kube-apiserver：提供 Kubernetes API 服務(wù)，是整個集群的控制平面。
- etcd：分布式鍵值存儲，用于保存集群的全部數(shù)據(jù)。
- kube-scheduler：負(fù)責(zé)將 Pods 調(diào)度到合適的節(jié)點上。
- kube-controller-manager：運行各種控制器，管理集群狀態(tài)。
(2) Worker 節(jié)點組件：
- kubelet：負(fù)責(zé)與節(jié)點上容器運行時通信，管理 Pod 生命周期。
- kube-proxy：處理網(wǎng)絡(luò)代理和負(fù)載均衡。
- 容器運行時：如 Docker、containerd 等，執(zhí)行容器。
如下圖：
3. K8s的工作原理
Kubernetes通過聲明式的配置管理集群狀態(tài)，用戶通過 YAML 或 JSON 文件描述期望的集群狀態(tài)，K8s 通過其控制器不斷調(diào)整實際狀態(tài)以匹配期望狀態(tài)。調(diào)度器決定 Pod 運行的位置，控制器管理 Pods、ReplicaSets、Deployments 等資源，確保應(yīng)用的高可用與可擴(kuò)展。
二、K3s
1. 什么是 K3s?
K3s 是由 Rancher Labs 開發(fā)的輕量級 Kubernetes 發(fā)行版，旨在簡化 Kubernetes 的部署和管理，適用于資源受限的環(huán)境，如邊緣計算、物聯(lián)網(wǎng)（IoT）設(shè)備等。K3s 減少了 Kubernetes 的一些組件和依賴，使其更加輕便且易于安裝。
2. K3s的核心組件
- 簡化的控制平面：將多個組件打包，減少資源占用。
- 輕量級的 etcd：使用 SQLite 作為默認(rèn)數(shù)據(jù)存儲，也支持外部 etcd。
- 內(nèi)置的網(wǎng)絡(luò)插件：采用 Flannel 作為默認(rèn) CNI 插件。
- 內(nèi)置的服務(wù)與關(guān)聯(lián)工具：如 Traefik 作為默認(rèn)的 ingress 控制器。
如下圖：
3. K3s的工作原理
K3s 在保持 Kubernetes 核心功能的基礎(chǔ)上，通過移除不必要的插件和組件、優(yōu)化代碼結(jié)構(gòu)，減少了資源消耗和復(fù)雜度。它支持 ARM 架構(gòu)，適合在邊緣設(shè)備上運行，并提供一鍵安裝腳本，簡化了部署過程。
三、K3s 與 K8s的對比
雖然 K3s支持大多數(shù)Kubernetes的API和功能，但它有以下關(guān)鍵特點使其與眾不同：
- 更低的資源需求：K3s比完整的Kubernetes集群占用更少的內(nèi)存、CPU和磁盤空間，使其成為資源受限環(huán)境的理想選擇。
- 更簡便的安裝與維護(hù)：K3s可以通過一個命令快速安裝，無需繁瑣的配置過程。它還能自動處理證書管理和其他日常任務(wù)，進(jìn)一步簡化了部署和維護(hù)。
- 單一二進(jìn)制文件：與Kubernetes將組件拆分為多個二進(jìn)制文件不同，K3s將所有必要的組件集成到一個二進(jìn)制文件中。這不僅減少了攻擊面，也簡化了更新和維護(hù)。
- 更輕量級的聯(lián)網(wǎng)：K3s采用了一種更輕量級的聯(lián)網(wǎng)方式，減少了對網(wǎng)絡(luò)組件如kube-proxy的需求，并簡化了復(fù)雜的聯(lián)網(wǎng)設(shè)置。
- 精簡的功能集：盡管 K3s支持大多數(shù)核心Kubernetes功能，但它有意排除了一些高級特性，如自動擴(kuò)展和高級網(wǎng)絡(luò)插件支持。這種設(shè)計選擇使得K3s能夠保持其輕量級特性，專注于核心功能。
特性/方面 | K3s | K8s（傳統(tǒng) Kubernetes） |
資源消耗 | 顯著較小的占用 | 占用較大，資源需求較高 |
安裝復(fù)雜度 | 簡單，單一命令安裝 | 設(shè)置復(fù)雜，需要配置多個組件 |
架構(gòu) | 單體架構(gòu)，所有組件集成在一個二進(jìn)制文件中 | 模塊化架構(gòu)，組件分離（API 服務(wù)器、etcd、調(diào)度器等） |
部署簡易性 | 需要最少的設(shè)置和配置 | 需要詳細(xì)的配置和安裝程序 |
網(wǎng)絡(luò)模型 | 輕量級，減少了網(wǎng)絡(luò)開銷 | 更全面的網(wǎng)絡(luò)模型，包含 kube-proxy |
功能集 | 支持核心 Kubernetes 功能 | 支持全套 Kubernetes 功能，包括高級能力 |
目標(biāo)環(huán)境 | 邊緣計算、物聯(lián)網(wǎng)、本地開發(fā) | 數(shù)據(jù)中心、云環(huán)境、大規(guī)模部署 |
用例 | 資源受限的環(huán)境 | 大規(guī)模應(yīng)用，復(fù)雜架構(gòu) |
社區(qū)和支持 | 社區(qū)強大，支持不斷增長 | 成熟的生態(tài)系統(tǒng)，來自 CNCF 和貢獻(xiàn)者的廣泛支持 |
更新和維護(hù) | 更新和維護(hù)簡化 | 定期更新，升級過程可能更復(fù)雜 |
高級功能 | 排除了一些高級功能，如水平 Pod 自動擴(kuò)展、復(fù)雜網(wǎng)絡(luò)插件 | 支持 Kubernetes 的全套功能，包括自動擴(kuò)展、廣泛的網(wǎng)絡(luò)選項 |
四、如何選擇？
1. 使用場景分析
K8s 比較適合以下的場景：
- 大規(guī)模企業(yè)應(yīng)用：需要支持?jǐn)?shù)千個 Pod、復(fù)雜的服務(wù)網(wǎng)格和多租戶環(huán)境。
- 高可用性系統(tǒng)：需要支持多數(shù)據(jù)中心部署、自動故障恢復(fù)和滾動更新。
- 復(fù)雜的 CI/CD 流水線：需要集成多種工具和自動化流程。
K3s 比較適合以下的場景：
- 邊緣計算節(jié)點：需要在資源受限的邊緣設(shè)備上運行，且對延遲敏感。
- 物聯(lián)網(wǎng)應(yīng)用：設(shè)備數(shù)量多且多為低功耗、低性能設(shè)備。
- 開發(fā)與測試環(huán)境：快速搭建輕量級集群，方便開發(fā)人員進(jìn)行測試和迭代。
2. 性能與資源考慮
如果環(huán)境資源充足，且需要全面的 Kubernetes 功能支持，選擇 K8s。
如果資源有限，或需要在嵌入式設(shè)備、邊緣節(jié)點上運行，選擇 K3s。
3. 管理與維護(hù)
- K8s：維護(hù)復(fù)雜，需要專業(yè)的 DevOps 團(tuán)隊，適合有能力管理大規(guī)模集群的企業(yè)。
- K3s：維護(hù)簡便，適合小團(tuán)隊或希望快速部署容器編排平臺的用戶。
4. 成本效益
- K8s：可能需要更多的硬件資源和人力投入，適合需要高性能和高可用性的應(yīng)用。
- K3s：降低了硬件和管理成本，適合預(yù)算有限或希望快速上線的項目。
五、結(jié)論
本文，我們分析以及對比了 K8s 和 K3s，K8s 作為當(dāng)前最流行的容器編排平臺，擁有強大的功能和廣泛的社區(qū)支持，適用于大規(guī)模和復(fù)雜的應(yīng)用場景，然而，K8s 的資源消耗和復(fù)雜性在某些場景下成為限制因素。K3s 作為輕量級的 K8s 發(fā)行版，通過簡化架構(gòu)和減少資源占用，填補了在資源受限環(huán)境下的需求。
在實際應(yīng)用中，選擇 K3s 還是 K8s，應(yīng)根據(jù)具體的應(yīng)用場景、資源情況和管理能力來決定，對于需要全面功能支持和高可用性的企業(yè)級應(yīng)用，K8s 依然是首選；而對于邊緣計算、物聯(lián)網(wǎng)、小規(guī)模部署或快速開發(fā)測試環(huán)境，K3s 則是更為合適的選擇。
