Docker（二）：理解容器編排工具Kubernetes內(nèi)部工作原理

一、Kubernetes是什么


　　要說到Docker就不得不說說Kubernetes。當(dāng)Docker容器在微服務(wù)的環(huán)境下數(shù)量一多，那么統(tǒng)一的，自動(dòng)化的管理自然少不了。而Kubernetes就是一個(gè)這樣的工具，它不僅僅提供了健康檢查和自修復(fù)，還有自動(dòng)擴(kuò)容縮容，以及服務(wù)發(fā)現(xiàn)和負(fù)載均衡等等功能。
總的來說它使我們對于大量的Docker容器管理更加的方便。

二、Kubernetes整體架構(gòu)圖及對應(yīng)功能分析



?

　　1、kubectl：
這是相當(dāng)于用戶客戶端一樣，也是我們較常使用的命令行工具，通過這個(gè)工具可以發(fā)起對應(yīng)的請求到master節(jié)點(diǎn)中，當(dāng)然自己開發(fā)的客戶端同樣可以
通過HTTP協(xié)議發(fā)起對應(yīng)的RESTAPI請求訪問APIServer。

　　2、Master：
Master節(jié)點(diǎn)是整個(gè)Kubernetes的核心節(jié)點(diǎn)，主要職責(zé)是負(fù)責(zé)調(diào)度，即應(yīng)用放在哪里運(yùn)行，同樣為了高可用可運(yùn)行多個(gè)Master。而Master中主要有APIServer，ControllerManager，Scheduler，Etcd，Kube-dns。對應(yīng)的職責(zé)分別如下：

　　2.1、APIServer：
提供了資源操作的唯一入口，注意其他節(jié)點(diǎn)是無法被外面請求操作的（不是說內(nèi)部運(yùn)行的容器無法被訪問，而是說無法通過發(fā)請求的方式直接操作Node），只有Master節(jié)點(diǎn)才能接受外面的請求進(jìn)行操作Node節(jié)點(diǎn)，其中主要提供了認(rèn)證、授權(quán)、訪問控制整個(gè)集群
。而dashboard是提供了一個(gè)展示界面。

　　2.2、Scheduler：負(fù)責(zé)資源的調(diào)度，根據(jù)一定的調(diào)度策略，將對應(yīng)Node上面的Pod運(yùn)行起來。

　　2.3、ControllerManager：
負(fù)責(zé)維護(hù)集群的狀態(tài)，比如故障檢測，擴(kuò)縮容，滾動(dòng)更新。在Pod運(yùn)行起來，就由ControllerManager負(fù)責(zé)管理其狀態(tài)

　　2.4、ETCD：
用于一致性存儲(chǔ)，保存pod，service等等的Kubernetes狀態(tài)。這里可以理解為MySQL在我們?nèi)粘ｍ?xiàng)目中的存儲(chǔ)作用，只要是用于存取Kubernetes中所有的持久化數(shù)據(jù)。

　　2.5、Kube-dns：DNS組件負(fù)責(zé)整個(gè)集群的DNS服務(wù)。使得內(nèi)部Pod相互之間可通過名字訪問
。有了這個(gè)功能就不需要寫繁瑣的IP地址，通過服務(wù)的名字即可訪問對方。

　　3、Node：理解為分支節(jié)點(diǎn)，
主要作用在于提供Kubernetes運(yùn)行時(shí)的環(huán)境，以及維護(hù)Pod。內(nèi)部主要有Kubblet，kube-proxy，docker等

　　3.1、Kubblet：
通過Master發(fā)送的請求到Node分支上的Kubblet，然后就由Kubblet負(fù)責(zé)維護(hù)當(dāng)前節(jié)點(diǎn)上容器的生命周期，也負(fù)責(zé)維護(hù)當(dāng)前節(jié)點(diǎn)的數(shù)據(jù)卷及網(wǎng)絡(luò)。

　　3.2、Kube-proxy：提供內(nèi)部的服務(wù)發(fā)現(xiàn)和負(fù)載均衡?？梢栽趫D上看見虛線框起來的三個(gè)框，可以認(rèn)為這三個(gè)Pod算是一個(gè)服務(wù)，即service，
而外部可通過Kube-proxy暴露的端口來進(jìn)行統(tǒng)一的訪問。并且默認(rèn)是使用輪詢的負(fù)載均衡策略來訪問。

三、Pod詳解

　　Pod作為Kubernetes的核心資源，這里單獨(dú)拿出來解釋。在Kubernetes集群中，Pod是所有業(yè)務(wù)類型的基礎(chǔ)，
它是一個(gè)或多個(gè)容器的組合，也就是Pod內(nèi)部可以有多個(gè)Docker容器存在，不是一個(gè)Pod代表一個(gè)容器，注意區(qū)分概念
。在其中的這些容器共享存儲(chǔ)、網(wǎng)絡(luò)和命名空間，以及如何運(yùn)行的規(guī)范。在Pod中，所有容器都被同一安排和調(diào)度，并運(yùn)行在共享的上下文中。對于具體應(yīng)用而言，Pod是它們的邏輯主機(jī)，Pod包含業(yè)務(wù)相關(guān)的多個(gè)應(yīng)用容器。這些容器可以通過localhost發(fā)現(xiàn)彼此。
每一個(gè)Pod有自己的一個(gè)IP地址。

　　1、Pod工作方式


　　　　在Kubernetes中一般不會(huì)直接創(chuàng)建一個(gè)獨(dú)立的Pod，這是因?yàn)镻od是臨時(shí)存在的一個(gè)實(shí)體。當(dāng)直接創(chuàng)建一個(gè)獨(dú)立的Pod時(shí)，如果缺少資源或者所被調(diào)度到的Node失敗，則Pod會(huì)直接被刪除。這里需要注意的是，
重起Pod和重起Pod中的容器不是一個(gè)概念，Pod自身不會(huì)運(yùn)行，它只是容器所運(yùn)行的一個(gè)環(huán)境
。Pod本身沒有自愈能力，如果Pod所在的Node失敗，或者如果調(diào)度操作本身失敗，則Pod將會(huì)被刪除；同樣的，如果缺少資源，Pod也會(huì)失敗。Kubernetes使用高層次的抽象，即控制器來管理臨時(shí)的Pod。通過控制器能夠創(chuàng)建和管理多個(gè)Pod，并在集群范圍內(nèi)處理副本、部署和提供自愈能力。

　　2、重啟策略


　　　　Pod既然內(nèi)部運(yùn)行著容器，那么免不了會(huì)因?yàn)楫惓５仍驅(qū)е缕浣K止退出，Pod支持三種重啟策略，需要在配置文件中通過restartPolicy字段設(shè)置重啟策略：

　　　　Always：只要退出就會(huì)重啟

　　　　OnFailure：只有在失敗退出（即exit code不等于0時(shí)），才會(huì)重啟

　　　　Never：只要退出就不再重啟

　　3、鏡像拉取策略


　　　　前一篇博客有講容器與鏡像的概念，在Kubernetes中運(yùn)行容器時(shí)，需要為容器獲取鏡像。Pod中容器的鏡像有三個(gè)來源，即Docker公共鏡像倉庫、私有鏡像倉庫和本地鏡像。當(dāng)在內(nèi)網(wǎng)使用的Kubernetes場景下，就需要搭建和使用私有鏡像倉庫。Pod支持三種鏡像拉取策略，在配置文件中通過imagePullPolicy字段設(shè)置鏡像拉取策略：

　　　　Always：不管本地是否存在鏡像都會(huì)進(jìn)行一次拉取

　　　　Never：不管本地是否存在鏡像都不會(huì)進(jìn)行拉取

　　　　IfNotPresent：僅在本地鏡像不存在時(shí)，才會(huì)進(jìn)行鏡像拉取


　　這里有需要注意的點(diǎn)：鏡像拉取策略的默認(rèn)值IfNotPresent，但:lastest標(biāo)簽的鏡像默認(rèn)為Always。所以生產(chǎn)環(huán)境中避免使用:lastest標(biāo)簽。還有就是拉取鏡像時(shí)docker會(huì)進(jìn)行校驗(yàn)，如果鏡像中的MD5碼沒有變，則不會(huì)拉取鏡像數(shù)據(jù)。

　　4、資源限制


　　　　Kubernetes通過cgroups來限制容器的CPU和內(nèi)存等計(jì)算資源，在創(chuàng)建Pod時(shí)，可以為Pod中的每個(gè)容器設(shè)置資源請求(request)和資源限制(limit)，
資源請求是容器需要的最小資源要求，資源限制為容器所能使用的資源上限。CPU的單位是核(core)，內(nèi)存(Memory)的單位是字節(jié)(byte)。

　　5、終止Pod


　　　　在集群中，Pod代表運(yùn)行的進(jìn)程，但不再需要這些進(jìn)程時(shí)，如何優(yōu)雅的終止這些進(jìn)程是非常重要的。當(dāng)用戶請求刪除一個(gè)Pod時(shí)，Kubernetes將會(huì)發(fā)送一個(gè)終止信號(hào)給每個(gè)容器，一旦過了優(yōu)雅期，就會(huì)發(fā)送kill信號(hào)，從而通過APIServer刪除Pod。
通常默認(rèn)的優(yōu)雅退出時(shí)間為30s。緩慢關(guān)閉的Pod依然可以對外繼續(xù)服務(wù)，直到負(fù)載均衡器將其移除，當(dāng)超過優(yōu)雅的退出時(shí)間，在Pod中任何正在運(yùn)行的進(jìn)程都會(huì)被kill。

四、Pod的生命周期

　　1、Pending

　　　　Pod已經(jīng)被Kubernetes系統(tǒng)接受，但是還有一個(gè)或者多個(gè)容器鏡像未被創(chuàng)建。這包括Pod正在被調(diào)度和從網(wǎng)絡(luò)上下載鏡像的時(shí)間。

　　2、Running

　　　　Pod已經(jīng)被綁定到了一個(gè)Node，所有容器已經(jīng)被創(chuàng)建，至少有一個(gè)容器在運(yùn)行

　　3、Succeeded

　　　　在Pod中所有容器已經(jīng)被成功停止，并且不再重啟

　　4、Failed

　　　　在Pod中所有容器已經(jīng)被終止，并且至少有一個(gè)容器是非正常終止的，即容器以非零狀態(tài)退出或者被系統(tǒng)強(qiáng)行終止的。

　　5、Unknown

　　　　Pod在某些原因下不能被獲取。通常是網(wǎng)絡(luò)問題。

五、service圖


　　前面有說到Docker目前在微服務(wù)架構(gòu)運(yùn)行的很廣泛，而Kubernetes作為編排Docker容器的強(qiáng)大工具自然是我們的首選。而Kubernetes又是怎么和微服務(wù)結(jié)合起來的呢？



?

　　上面有說到Pod擁有自己的IP地址，實(shí)際上在Pod外面還包裹著一層Service，
這個(gè)Service是邏輯存在的，在最上面的架構(gòu)圖中就類似kube-proxy串在一起的三個(gè)Pod，而service的IP是由kube-proxy給我們提供。
這就是與微服務(wù)之間能夠連起來了。其中同一個(gè)service的Pod應(yīng)該是相同的，kube-proxy會(huì)自動(dòng)給我們做負(fù)載均衡，默認(rèn)使用輪詢
。同樣與Docker不相同的是Pod之間是可以通過名字直接訪問的，Node同樣也是，這就為我們的服務(wù)調(diào)用提供了很便利的方式。

六、總結(jié)


　　Kubernetes是一個(gè)容器編排及其自動(dòng)化管理的工具。隨著業(yè)務(wù)增長Docker容器越來越多，如果需要每一個(gè)自己手動(dòng)管理，那么將會(huì)翻倍的增加我們的工作量。所以Kubernetes是我們在學(xué)習(xí)Docker中需要進(jìn)階的知識(shí)。

　

?

• ? 上一篇：如何快速融入團(tuán)隊(duì)并成為團(tuán)隊(duì)核心(六)
• ? 下一篇：MySql配置環(huán)境變量