1. 程式人生 > 程式設計 >K8s 還是 k3s?This is a question

K8s 還是 k3s?This is a question

本文來自:Rancher Labs

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

file

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

趕緊試試看吧!

歡迎新增小助手(wx:rancher2),進官方技術群,瞭解更多Kubernetes使用攻略