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則是性價比更高的選擇。

趕忙試試看吧！

歡迎添加微信助手（rancher2)，進官方技術羣，瞭解更多Kubernetes使用攻略