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