K8s 還是 k3s？This is a question

本文來自：Rancher Labs

 
自k3s問世以來，社區里有許多小伙伴都問過這樣的問題“除了中間的數字之外，k3s和K8s的區別在哪里？”，“在兩者之間應該如何選擇？”。本文將簡單介紹它們兩者的區別。
 

 

什么是Kubernetes?

正如大家所了解到的那樣，Kubernetes是一個“容器編排平臺”，也就是說你可以從一組機器中選擇其中之一來運行你所需要使用的容器。
 

它也處理諸如升級你的容器之類的事情，所以如果你發布網站的新版本，它會逐漸使用新版本來啟動容器，并放棄舊版本，這一過程僅需一到兩分鐘。
 

那么，究竟什么是K8s？

K8s是Kubernetes的縮寫，因為在K和s之間有8個字母，故稱K8s。然而，通常情況下，無論人們談論的是Kubernetes還是K8s，他們正在說的是原生上游的Kubernetes，由Google所設計的一個真正高可用且可擴展的平臺。
 

問題是，雖然你可以使用諸如Minikube之類的工具在本地計算機上運行Kubernetes，但是如果要在生產環境中運行它，你將很快獲得一些“最佳實踐”的建議，如：
 

1. 將你的節點和master分開，使用你的master運行控制平面，使用你的節點運行工作負載，兩者永遠也不會見面

2. 在獨立的集群上運行etcd，以確保它能夠處理負載

3. 理想狀態下，分離Ingress()節點，以便它們能夠輕松處理進入的流量，即便一些底層節點已經十分忙碌

很快，你將擁有3倍的K8S master、3倍的etcd、2倍的Ingress以及你的節點。所以在你到達需要詢問“我的站點需要多少個節點”這一階段之前，實際情況下你至少已經有了8個中型實例。

別誤會，我不是在指責這些建議不好。相反，如果你正在運行一個生產工作負載，那么這些建議是十分明智的。畢竟，沒有比在星期五晚上調試過載的停機生產集群更糟糕的了！

 
但是，如果你只是想學習Kubernetes，或者給一些非核心的應用托管一個development/staging集群，那么采納上述建議就有些“殺雞用牛刀“的感覺了，不是嗎？至少對我來說是這樣的。如果我只是想啟動集群來查看我的Kubernetes manifest（包括部署配置等等）是否是正確的，我并不愿意每月為此付出幾百元。
 

k3s的優勢在哪里？

Rancher Labs是業界領先的容器軟件提供商，其旗艦產品Rancher是一款開源的企業級Kubernetes管理平臺，極為出色地管理和安裝Kubernetes集群。他們發布了一系列產品，構成他們的生態，例如，Longhorn是一個輕量級并且可靠的容器化分布式塊存儲解決方案，可用于Kubernetes中，并在近期被收納入CNCF沙箱項目中。閑雜讓我們回到這篇文章的主題，Rancher Labs也是k3s這款輕量級Kubernetes發行版的創建者。

k3s將安裝Kubernetes所需的一切打包進僅有60MB大小的二進制文件中，并且完全實現了Kubernetes API。為了減少運行Kubernetes所需的內存，Rancher刪除了很多不必要的驅動程序，并用附加組件對其進行替換。
 

k3s是一款完全通過CNCF認證的Kubernetes發行版，這意味著你可以編寫YAML來對完整版的Kubernetes進行操作，并且它們也將適用于k3s集群。

由于它只需要極低的資源就可以運行，因此它能夠在任何512MB RAM以上的設備上運行集群，換言之，我們可以讓pod在master和節點上運行。

當然，既然它是一個小型的二進制文件，那么我們可以在短時間內安裝它，相比于啟動常規Kubernetes集群，安裝它僅需一小部時間。通常我們僅需要不到2分鐘的時間就能夠啟動一個帶有幾個節點的k3s集群，也就是說，你可以一有機會就部署應用程序來學習或者進行測試。
 

聽起來不錯，實際如何呢？

當人們提到Kubernetes時，他們想到的是如果節點死亡，容器會自動在其他節點上啟動，容器之間的負載均衡、隔離和滾動部署，所有這些優點在完整版的Kubernetes和k3s之間是相同的。

但是，k3s并不總是只有優點，否則的話每個人都會去使用k3s。那么，為什么有些人沒有使用k3s呢？

首先，當前k3s的版本（k3s v0.8.1）僅能運行單個master，這意味著如果你的master宕機，那么你就無法管理你的集群，即便已有集群要繼續運行。但是在k3s v0.10的版本中，多主模式已經是實驗功能，也許在下一個版本中能夠GA。

其次，在單個master的k3s中，默認的數據存儲是SQLite，這對于小型數據庫十分友好，但是如果遭受重擊，那么SQLite將成為主要痛點。但是，Kubernetes控制平面中發生的更改更多是與頻繁更新部署、調度Pod等有關，因此對于小型開發/測試集群而言，數據庫不會造成太大負載。
 

結 語

K8s和k3s各有優劣，使用場景也有所區別，因此不能一概而論。如果你要進行大型的集群部署，那么我建議你選擇使用K8s；如果你處于邊緣計算等小型部署的場景或僅僅需要部署一些非核心集群進行開發/測試，那么選擇k3s則是性價比更高的選擇。

趕緊試試看吧！