K8s該快速入門

這篇文章將為大家詳細(xì)講解有關(guān)K8s該快速入門，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。

通過一個(gè)業(yè)務(wù)發(fā)展的故事，分享 K8s 出現(xiàn)的原因以及它的運(yùn)作方式。適合所有技術(shù)開發(fā)人員，尤其是前端開發(fā)者。

0 序

去年下半年，我做了一次轉(zhuǎn)崗，開始接觸到 kubernetes，雖然對(duì) K8s  的認(rèn)識(shí)還非常的不全面，但是非常想分享一下自己的一些收獲，希望通過本文能夠幫助大家對(duì) K8s  有一個(gè)入門的了解。文中有不對(duì)的地方，還請(qǐng)各位老司機(jī)們幫助指點(diǎn)糾正。

其實(shí)介紹 K8s 的文章，網(wǎng)上一搜一大把，而且 kubernetes 官方文檔也寫的非常友好，所以直接上來講  K8s，我覺得我是遠(yuǎn)遠(yuǎn)不如網(wǎng)上的一些文章講的好的，所以我想換一個(gè)角度，通過一個(gè)業(yè)務(wù)發(fā)展的故事，來講一下 K8s 是怎么出現(xiàn)的，它又是如何運(yùn)作的。

這里適合所有搞技術(shù)的同學(xué)，特別是前端的同學(xué)，因?yàn)榍岸斯こ袒鼛啄臧l(fā)展的非常迅猛，K8s  目前解決的問題和發(fā)展的形式，我相信假以時(shí)日也會(huì)出現(xiàn)在前端領(lǐng)域，畢竟不同領(lǐng)域的工程化發(fā)展其實(shí)是殊途同歸的。

1 故事開始

隨著中國老百姓生活水平的不斷提高，家家戶戶都有了小汽車，小王預(yù)計(jì) 5 年后，汽車報(bào)廢業(yè)務(wù)將會(huì)迅速發(fā)展，而且國家在 19  年也出臺(tái)了新政策《報(bào)廢機(jī)動(dòng)車回收管理辦法》，取消了汽車報(bào)廢回收的“特種行業(yè)”屬性，將開放市場(chǎng)化的競(jìng)爭(zhēng)。

小王覺得這是一個(gè)創(chuàng)業(yè)的好機(jī)會(huì)，于是找到了我和幾個(gè)志同道合的小伙伴開始了創(chuàng)業(yè)，決定做一個(gè)叫“淘車網(wǎng)”的平臺(tái)。

2 故事發(fā)展

淘車網(wǎng)一開始是一個(gè) all in one 的 Java  應(yīng)用，部署在一臺(tái)物理機(jī)上(小王同學(xué)，現(xiàn)在都啥時(shí)候了，你需要了解一下阿里云)，隨著業(yè)務(wù)的發(fā)展，發(fā)現(xiàn)機(jī)器已經(jīng)快扛不住了，就趕緊對(duì)服務(wù)器的規(guī)格做了升級(jí)，從  64C256G 一路升到了 160C1920G，雖然成本高了點(diǎn)，但是系統(tǒng)至少?zèng)]出問題。

業(yè)務(wù)發(fā)展了一年后，160C1920G 也扛不住了，不得不進(jìn)行服務(wù)化拆分、分布式改造了。為了解決分布式改造過程中的各種問題，引入了一系列的中間件，類似  hsf、tddl、tair、diamond、metaq 這些，在艱難的業(yè)務(wù)架構(gòu)改造后，我們成功的把 all in one 的 Java  應(yīng)用拆分成了多個(gè)小應(yīng)用，重走了一遍阿里當(dāng)年中間件發(fā)展和去 IOE 的道路。

分布式改完了后，我們管理的服務(wù)器又多起來了，不同批次的服務(wù)器，硬件規(guī)格、操作系統(tǒng)版本等等都不盡相同，于是應(yīng)用運(yùn)行和運(yùn)維的各種問題就出來了。

還好有虛擬機(jī)技術(shù)，把底層各種硬件和軟件的差異，通過虛擬化技術(shù)都給屏蔽掉啦，雖然硬件不同，但是對(duì)于應(yīng)用來說，看到的都是一樣的啦，但是虛擬化又產(chǎn)生了很大的性能開銷。

恩，不如我們使用 docker 吧，因?yàn)?docker 基于 cgroup 等 linux  的原生技術(shù)，在屏蔽底層差異的同時(shí)，也沒有明顯的性能影響，真是一個(gè)好東西。而且基于 docker 鏡像的業(yè)務(wù)交付，使得我們 CI/CD  的運(yùn)作也非常的容易啦。

不過隨著 docker 容器數(shù)量的增長，我們又不得不面對(duì)新的難題，就是大量的 docker  如何調(diào)度、通信呢?畢竟隨著業(yè)務(wù)發(fā)展，淘車網(wǎng)已經(jīng)不是一個(gè)小公司了，我們運(yùn)行著幾千個(gè) docker 容器，并且按照現(xiàn)在的業(yè)務(wù)發(fā)展趨勢(shì)，馬上就要破萬了。

不行，我們一定要做一個(gè)系統(tǒng)，這個(gè)系統(tǒng)能夠自動(dòng)的管理服務(wù)器(比如是不是健康啊，剩下多少內(nèi)存和 CPU 可以使用啊等等)、然后根據(jù)容器聲明所需的 CPU 和  memory 選擇最優(yōu)的服務(wù)器進(jìn)行容器的創(chuàng)建，并且還要能夠控制容器和容器之間的通信(比如說某個(gè)部門的內(nèi)部服務(wù)，當(dāng)然不希望其他部門的容器也能夠訪問)。

我們給這個(gè)系統(tǒng)取一個(gè)名字，就叫做容器編排系統(tǒng)吧。

3 容器編排系統(tǒng)

那么問題來了，面對(duì)一堆的服務(wù)器，我們要怎么實(shí)現(xiàn)一個(gè)容器編排系統(tǒng)呢?

先假設(shè)我們已經(jīng)實(shí)現(xiàn)了這個(gè)編排系統(tǒng)，那么我們的服務(wù)器就會(huì)有一部分會(huì)用來運(yùn)行這個(gè)編排系統(tǒng)，剩下的服務(wù)器用來運(yùn)行我們的業(yè)務(wù)容器，我們把運(yùn)行編排系統(tǒng)的服務(wù)器叫做  master 節(jié)點(diǎn)，把運(yùn)行業(yè)務(wù)容器的服務(wù)器叫做 worker 節(jié)點(diǎn)。

既然 master 節(jié)點(diǎn)負(fù)責(zé)管理服務(wù)器集群，那它就必須要提供出相關(guān)的管理接口，一個(gè)是方便運(yùn)維管理員對(duì)集群進(jìn)行相關(guān)的操作，另一個(gè)就是負(fù)責(zé)和 worker  節(jié)點(diǎn)進(jìn)行交互，比如進(jìn)行資源的分配、網(wǎng)絡(luò)的管理等。

我們把 master 上提供管理接口的組件稱為 kube apiserver，對(duì)應(yīng)的還需要兩個(gè)用于和 api server  交互的客戶端，一個(gè)是提供給集群的運(yùn)維管理員使用的，我們稱為 kubectl;一個(gè)是提供給 worker 節(jié)點(diǎn)使用的，我們稱為 kubelet。

現(xiàn)在集群的運(yùn)維管理員、master 節(jié)點(diǎn)、worker 節(jié)點(diǎn)已經(jīng)可以彼此間進(jìn)行交互了，比如說運(yùn)維管理員通過 kubectl 向 master  下發(fā)一個(gè)命令，“用淘車網(wǎng)用戶中心 2.0 版本的鏡像創(chuàng)建 1000個(gè) 容器”，master 收到了這個(gè)請(qǐng)求之后，就要根據(jù)集群里面 worker  節(jié)點(diǎn)的資源信息進(jìn)行一個(gè)計(jì)算調(diào)度，算出來這 1000 個(gè)容器應(yīng)該在哪些 worker 上進(jìn)行創(chuàng)建，然后把創(chuàng)建指令下發(fā)到相應(yīng)的 worker  上。我們把這個(gè)負(fù)責(zé)調(diào)度的組件稱為 kube scheduler。

那 master 又是怎么知道各個(gè) worker 上的資源消耗和容器的運(yùn)行情況的呢?這個(gè)簡(jiǎn)單，我們可以通過 worker 上的 kubelet  周期性的主動(dòng)上報(bào)節(jié)點(diǎn)資源和容器運(yùn)行的情況，然后 master 把這個(gè)數(shù)據(jù)存儲(chǔ)下來，后面就可以用來做調(diào)度和容器的管理使用了。至于數(shù)據(jù)怎么存儲(chǔ)，我們可以寫文件、寫  db 等等，不過有一個(gè)開源的存儲(chǔ)系統(tǒng)叫 etcd，滿足我們對(duì)于數(shù)據(jù)一致性和高可用的要求，同時(shí)安裝簡(jiǎn)單、性能又好，我們就選 etcd 吧。

現(xiàn)在我們已經(jīng)有了所有 worker 節(jié)點(diǎn)和容器運(yùn)行的數(shù)據(jù)，我們可以做的事情就非常多了。比如前面所說的，我們使用淘車網(wǎng)用戶中心 2.0 版本的鏡像創(chuàng)建了  1000 個(gè)容器，其中有5個(gè)容器都是運(yùn)行在 A 這個(gè) worker 節(jié)點(diǎn)上，那如果 A 這個(gè)節(jié)點(diǎn)突然出現(xiàn)了硬件故障，導(dǎo)致節(jié)點(diǎn)不可用了，這個(gè)時(shí)候 master  就要把 A 從可用 worker 節(jié)點(diǎn)中摘除掉，并且還需要把原先運(yùn)行在這個(gè)節(jié)點(diǎn)上的 5 個(gè)用戶中心 2.0 的容器重新調(diào)度到其他可用的 worker  節(jié)點(diǎn)上，使得我們用戶中心 2.0 的容器數(shù)量能夠重新恢復(fù)到 1000  個(gè)，并且還需要對(duì)相關(guān)的容器進(jìn)行網(wǎng)絡(luò)通信配置的調(diào)整，使得容器間的通信還是正常的。我們把這一系列的組件稱為控制器，比如節(jié)點(diǎn)控制器、副本控制器、端點(diǎn)控制器等等，并且為這些控制器提供一個(gè)統(tǒng)一的運(yùn)行組件，稱為控制器管理器(kube-controller-manager)。

那 master 又該如何實(shí)現(xiàn)和管理容器間的網(wǎng)絡(luò)通信呢?首先每個(gè)容器肯定需要有一個(gè)唯一的 ip 地址，通過這個(gè) ip  地址就可以互相通信了，但是彼此通信的容器有可能運(yùn)行在不同的 worker 節(jié)點(diǎn)上，這就涉及到 worker 節(jié)點(diǎn)間的網(wǎng)絡(luò)通信，因此每個(gè) worker  節(jié)點(diǎn)還需要有一個(gè)唯一的 ip 地址，但是容器間通信都是通過容器 ip 進(jìn)行的，容器并不感知 worker 節(jié)點(diǎn)的 ip 地址，因此在 worker  節(jié)點(diǎn)上需要有容器 ip 的路由轉(zhuǎn)發(fā)信息，我們可以通過 iptables、ipvs 等技術(shù)來實(shí)現(xiàn)。那如果容器 ip 變化了，或者容器數(shù)量變化了，這個(gè)時(shí)候相關(guān)的  iptables、ipvs 的配置就需要跟著進(jìn)行調(diào)整，所以在 worker 節(jié)點(diǎn)上我們需要一個(gè)專門負(fù)責(zé)監(jiān)聽并調(diào)整路由轉(zhuǎn)發(fā)配置的組件，我們把這個(gè)組件稱為 kube  proxy(此處為了便于理解，就不展開引入 Service 的內(nèi)容了)。

我們已經(jīng)解決了容器間的網(wǎng)絡(luò)通信，但是在我們編碼的時(shí)候，我們希望的是通過域名或者 vip 等方式來調(diào)用一個(gè)服務(wù)，而不是通過一個(gè)可能隨時(shí)會(huì)變化的容器  ip。因此我們需要在容器 ip 之上在封裝出一個(gè) Service 的概念，這個(gè) Service 可以是一個(gè)集群的  vip，也可以是一個(gè)集群的域名，為此我們還需要一個(gè)集群內(nèi)部的 DNS 域名解析服務(wù)。

另外雖然我們已經(jīng)有了 kubectl，可以很愉快的和 master 進(jìn)行交互了，但是如果有一個(gè) web  的管理界面，這肯定是一個(gè)更好的事情。此處之外，我們可能還希望看到容器的資源信息、整個(gè)集群相關(guān)組件的運(yùn)行日志等等。

像 DNS、web 管理界面、容器資源信息、集群日志，這些可以改善我們使用體驗(yàn)的組件，我們統(tǒng)稱為插件。

至此，我們已經(jīng)成功構(gòu)建了一個(gè)容器編排系統(tǒng)，我們來簡(jiǎn)單總結(jié)下上面提到的各個(gè)組成部分：

• Master 組件：kube-apiserver、kube-scheduler、etcd、kube-controller-manager

• Node 組件：kubelet、kube-proxy

• 插件：DNS、用戶界面 Web UI、容器資源監(jiān)控、集群日志

  
  

這些也正是 K8s 中的重要組成部分。當(dāng)然 K8s  作為一個(gè)生產(chǎn)級(jí)別的容器編排系統(tǒng)，這里提到的每一個(gè)組件都可以拿出來單獨(dú)講上很多內(nèi)容，本文只是一個(gè)簡(jiǎn)單入門，不再展開講解。

4 Serverless 的容器編排系統(tǒng)

雖然我們已經(jīng)成功實(shí)現(xiàn)了一個(gè)容器編排系統(tǒng)，并且也用的很舒服，但是淘車網(wǎng)的王總裁(已經(jīng)不是當(dāng)年的小王了)覺得公司花在這個(gè)編排系統(tǒng)上的研發(fā)和運(yùn)維成本實(shí)在是太高了，想要縮減這方面的成本。王總想著有沒有一個(gè)編排系統(tǒng)，能夠讓員工專注到業(yè)務(wù)開發(fā)上，而不需要關(guān)注到集群的運(yùn)維管理上，王總和技術(shù)圈的同學(xué)了解了一下，發(fā)現(xiàn)  Serverless 的理念和他的想法不謀而合，于是就在想啥時(shí)候出一個(gè) Serverless 的容器編排系統(tǒng)就好啦。

關(guān)于K8s該快速入門就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。