本文來自：Rancher Labs

創(chuàng)新互聯(lián)服務(wù)緊隨時代發(fā)展步伐，進(jìn)行技術(shù)革新和技術(shù)進(jìn)步，經(jīng)過十多年的發(fā)展和積累，已經(jīng)匯集了一批資深網(wǎng)站策劃師、設(shè)計師、專業(yè)的網(wǎng)站實施團(tuán)隊以及高素質(zhì)售后服務(wù)人員，并且完全形成了一套成熟的業(yè)務(wù)流程，能夠完全依照客戶要求對網(wǎng)站進(jìn)行做網(wǎng)站、網(wǎng)站建設(shè)、建設(shè)、維護(hù)、更新和改版，實現(xiàn)客戶網(wǎng)站對外宣傳展示的首要目的，并為客戶企業(yè)品牌互聯(lián)網(wǎng)化提供全面的解決方案。

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

 

什么是Kubernetes?

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

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

那么，究竟什么是K8s？

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

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

1. 將你的節(jié)點和master分開，使用你的master運行控制平面，使用你的節(jié)點運行工作負(fù)載，兩者永遠(yuǎn)也不會見面

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

3. 理想狀態(tài)下，分離Ingress()節(jié)點，以便它們能夠輕松處理進(jìn)入的流量，即便一些底層節(jié)點已經(jīng)十分忙碌

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

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

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

k3s的優(yōu)勢在哪里？

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

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

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

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

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

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

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

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

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

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

結(jié) 語

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

趕緊試試看吧！