Kubernetes应用部署模型解析（原理篇）
2019獨(dú)角獸企業(yè)重金招聘Python工程師標(biāo)準(zhǔn)>>>
Kubernetes應(yīng)用部署模型解析（原理篇） 博客分類(lèi)： Kubernetes【編者按】Kubernetes可用來(lái)管理Linux容器集群，加速開(kāi)發(fā)和簡(jiǎn)化運(yùn)維（即DevOps）。但目前網(wǎng)絡(luò)上關(guān)于Kubernetes的文章介紹性遠(yuǎn)多于實(shí)際使用。本系列文章著眼于實(shí)際部署，帶您快速掌握Kubernetes。本文為上篇，主要介紹部署之前需要了解的原理和概念，包括Kubernetes的組件結(jié)構(gòu)，各個(gè)組件角色的功能，以及Kubernetes的應(yīng)用模型等。
十多年來(lái)Google一直在生產(chǎn)環(huán)境中使用容器運(yùn)行業(yè)務(wù)，負(fù)責(zé)管理其容器集群的系統(tǒng)就是Kubernetes的前身Borg。其實(shí)現(xiàn)在很多工作在Kubernetes項(xiàng)目上的Google開(kāi)發(fā)者先前就在Borg這個(gè)項(xiàng)目上工作。多數(shù)Kubernetes的應(yīng)用部署模型的思想都起源于Borg,了解這些模型是掌握Kubernetes的關(guān)鍵。Kubernetes的API版本目前是v1，本文以代碼0.18.2版為基礎(chǔ)來(lái)介紹它的應(yīng)用部署模型，最后我們用一個(gè)簡(jiǎn)單的用例來(lái)說(shuō)明部署過(guò)程。在部署結(jié)束后，闡述了它是如何用Iptables規(guī)則來(lái)實(shí)現(xiàn)各種類(lèi)型Service的。
?
Kubernetes架構(gòu)
?
Kubernetes集群包括Kubernetes代理(agents )和Kubernetes服務(wù)(master node)兩種角色，代理角色的組件包括Kube-proxy?和Kubelet，它們同時(shí)部署在一個(gè)節(jié)點(diǎn)上，這個(gè)節(jié)點(diǎn)也就是代理節(jié)點(diǎn)。服務(wù)角色的組件包括kube-apiserver，kube-scheduler，kube-controller-manager，它們可以任意布屬，它們可以部署在同一個(gè)節(jié)點(diǎn)上，也可以部署在不同的節(jié)點(diǎn)上（目前版本好像不行）。Kubernetes集群依賴(lài)的第三方組件目前有etcd和docker兩個(gè)。前者提供狀態(tài)存儲(chǔ)，二者用來(lái)管理容器。集群還可以使用分布式存儲(chǔ)給容器提供存儲(chǔ)空間。下圖顯示了目前系統(tǒng)的組成部分：
?
Kubernetes代理節(jié)點(diǎn)
Kubelet和Kube-proxy運(yùn)行在代理節(jié)點(diǎn)上。他們監(jiān)聽(tīng)服務(wù)節(jié)點(diǎn)的信息來(lái)啟動(dòng)容器和實(shí)現(xiàn)Kubernetes網(wǎng)絡(luò)和其它業(yè)務(wù)模型，比如Service、Pod等。當(dāng)然每個(gè)代理節(jié)點(diǎn)都運(yùn)行Docker。Docker負(fù)責(zé)下載容器鏡像和運(yùn)行容器。
?
?
Kubelet
?
Kubelet組件管理Pods和它們的容器，鏡像和卷等信息。
?
Kube-Proxy
Kube-proxy是一個(gè)簡(jiǎn)單的網(wǎng)絡(luò)代理和負(fù)載均衡器。它具體實(shí)現(xiàn)Service模型，每個(gè)Service都會(huì)在所有的Kube-proxy節(jié)點(diǎn)上體現(xiàn)。根據(jù)Service的selector所覆蓋的Pods, Kube-proxy會(huì)對(duì)這些Pods做負(fù)載均衡來(lái)服務(wù)于Service的訪(fǎng)問(wèn)者。
?
?
Kubernetes服務(wù)節(jié)點(diǎn)
Kubernetes服務(wù)組件形成了Kubernetes的控制平面，目前他們運(yùn)行在單一節(jié)點(diǎn)上，但是將來(lái)會(huì)分開(kāi)來(lái)部署，以支持高可用性。
?
?
etcd
所有的持久性狀態(tài)都保存在etcd中。Etcd同時(shí)支持watch，這樣組件很容易得到系統(tǒng)狀態(tài)的變化，從而快速響應(yīng)和協(xié)調(diào)工作。
?
?
Kubernetes API Server
這個(gè)組件提供對(duì)API的支持，響應(yīng)REST操作，驗(yàn)證API模型和更新etcd中的相應(yīng)對(duì)象。
?
?
Scheduler
通過(guò)訪(fǎng)問(wèn)Kubernetes中/binding API, Scheduler負(fù)責(zé)Pods在各個(gè)節(jié)點(diǎn)上的分配。Scheduler是插件式的，Kubernetes將來(lái)可以支持用戶(hù)自定義的scheduler。
?
?
Kubernetes Controller Manager Server
Controller Manager Server負(fù)責(zé)所有其它的功能，比如endpoints控制器負(fù)責(zé)Endpoints對(duì)象的創(chuàng)建，更新。node控制器負(fù)責(zé)節(jié)點(diǎn)的發(fā)現(xiàn)，管理和監(jiān)控。將來(lái)可能會(huì)把這些控制器拆分并且提供插件式的實(shí)現(xiàn)。
?
?
Kubernetes模型
Kubernetes的偉大之處就在于它的應(yīng)用部署模型，主要包括Pod、Replication controller、Label和Service。
?
?
Pod
Kubernetes的最小部署單元是Pod而不是容器。作為First class API公民，Pods能被創(chuàng)建，調(diào)度和管理。簡(jiǎn)單地來(lái)說(shuō)，像一個(gè)豌豆莢中的豌豆一樣，一個(gè)Pod中的應(yīng)用容器同享同一個(gè)上下文：
?
?
?
從生命周期來(lái)說(shuō)，Pod應(yīng)該是短暫的而不是長(zhǎng)久的應(yīng)用。 Pods被調(diào)度到節(jié)點(diǎn)，保持在這個(gè)節(jié)點(diǎn)上直到被銷(xiāo)毀。當(dāng)節(jié)點(diǎn)死亡時(shí)，分配到這個(gè)節(jié)點(diǎn)的Pods將會(huì)被刪掉。將來(lái)可能會(huì)實(shí)現(xiàn)Pod的遷移特性。在實(shí)際使用時(shí)，我們一般不直接創(chuàng)建Pods, 我們通過(guò)replication controller來(lái)負(fù)責(zé)Pods的創(chuàng)建，復(fù)制，監(jiān)控和銷(xiāo)毀。一個(gè)Pod可以包括多個(gè)容器，他們直接往往相互協(xié)作完成一個(gè)應(yīng)用功能。
?
Replication controller
復(fù)制控制器確保Pod的一定數(shù)量的份數(shù)(replica)在運(yùn)行。如果超過(guò)這個(gè)數(shù)量，控制器會(huì)殺死一些，如果少了，控制器會(huì)啟動(dòng)一些。控制器也會(huì)在節(jié)點(diǎn)失效、維護(hù)的時(shí)候來(lái)保證這個(gè)數(shù)量。所以強(qiáng)烈建議即使我們的份數(shù)是1，也要使用復(fù)制控制器，而不是直接創(chuàng)建Pod。
?
在生命周期上講，復(fù)制控制器自己不會(huì)終止，但是跨度不會(huì)比Service強(qiáng)。Service能夠橫跨多個(gè)復(fù)制控制器管理的Pods。而且在一個(gè)Service的生命周期內(nèi)，復(fù)制控制器能被刪除和創(chuàng)建。Service和客戶(hù)端程序是不知道復(fù)制控制器的存在的。
復(fù)制控制器創(chuàng)建的Pods應(yīng)該是可以互相替換的和語(yǔ)義上相同的，這個(gè)對(duì)無(wú)狀態(tài)服務(wù)特別合適。
Pod是臨時(shí)性的對(duì)象，被創(chuàng)建和銷(xiāo)毀，而且不會(huì)恢復(fù)。復(fù)制器動(dòng)態(tài)地創(chuàng)建和銷(xiāo)毀Pod。雖然Pod會(huì)分配到IP地址，但是這個(gè)IP地址都不是持久的。這樣就產(chǎn)生了一個(gè)疑問(wèn)：外部如何消費(fèi)Pod提供的服務(wù)呢？
?
Service
Service定義了一個(gè)Pod的邏輯集合和訪(fǎng)問(wèn)這個(gè)集合的策略。集合是通過(guò)定義Service時(shí)提供的Label選擇器完成的。舉個(gè)例子，我們假定有3個(gè)Pod的備份來(lái)完成一個(gè)圖像處理的后端。這些后端備份邏輯上是相同的，前端不關(guān)心哪個(gè)后端在給它提供服務(wù)。雖然組成這個(gè)后端的實(shí)際Pod可能變化，前端客戶(hù)端不會(huì)意識(shí)到這個(gè)變化，也不會(huì)跟蹤后端。Service就是用來(lái)實(shí)現(xiàn)這種分離的抽象。
?
對(duì)于Service，我們還可以定義Endpoint，Endpoint把Service和Pod動(dòng)態(tài)地連接起來(lái)。
?
Service Cluster IP和 kuber proxy
每個(gè)代理節(jié)點(diǎn)都運(yùn)行了一個(gè)kube-proxy進(jìn)程。這個(gè)進(jìn)程從服務(wù)進(jìn)程那邊拿到Service和Endpoint對(duì)象的變化。 對(duì)每一個(gè)Service, 它在本地打開(kāi)一個(gè)端口。 到這個(gè)端口的任意連接都會(huì)代理到后端Pod集合中的一個(gè)Pod IP和端口。在創(chuàng)建了服務(wù)后，服務(wù)Endpoint模型會(huì)體現(xiàn)后端Pod的 IP和端口列表，kube-proxy就是從這個(gè)endpoint維護(hù)的列表中選擇服務(wù)后端的。另外Service對(duì)象的sessionAffinity屬性也會(huì)幫助kube-proxy來(lái)選擇哪個(gè)具體的后端。缺省情況下，后端Pod的選擇是隨機(jī)的?？梢栽O(shè)置service.spec.sessionAffinity?成"ClientIP"來(lái)指定同一個(gè)ClientIP的流量代理到同一個(gè)后端。在實(shí)現(xiàn)上，kube-proxy會(huì)用IPtables規(guī)則把訪(fǎng)問(wèn)Service的Cluster IP和端口的流量重定向到這個(gè)本地端口。下面的部分會(huì)講什么是service的Cluster IP。
?
注意：在0.18以前的版本中Cluster IP叫PortalNet IP。
?
內(nèi)部使用者的服務(wù)發(fā)現(xiàn)
Kubernetes在一個(gè)集群內(nèi)創(chuàng)建的對(duì)象或者在代理集群節(jié)點(diǎn)上發(fā)出訪(fǎng)問(wèn)的客戶(hù)端我們稱(chēng)之為內(nèi)部使用者。要把服務(wù)暴露給內(nèi)部使用者，Kubernetes支持兩種方式：環(huán)境變量和DNS。
?
?
環(huán)境變量
當(dāng)kubelet在某個(gè)節(jié)點(diǎn)上啟動(dòng)一個(gè)Pod時(shí)，它會(huì)給這個(gè)Pod的容器為當(dāng)前運(yùn)行的Service設(shè)置一系列環(huán)境變量，這樣Pod就可以訪(fǎng)問(wèn)這些Service了。一般地情況是{SVCNAME}_SERVICE_HOSTh和{SVCNAME}_SERVICE_PORT變量, 其中{SVCNAME}是Service名字變成大寫(xiě)，中劃線(xiàn)變成下劃線(xiàn)。比如Service "redis-master"，它的端口是 TCP? 6379，分配到的Cluster IP地址是 10.0.0.11，kubelet可能會(huì)產(chǎn)生下面的變量給新創(chuàng)建的Pod容器：
?
REDIS_MASTER_SERVICE_HOST=?10.0.0.11
REDIS_MASTER_SERVICE_PORT=6379
REDIS_MASTER_PORT=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP_PROTO=tcp
REDIS_MASTER_PORT_6379_TCP_PORT=6379
REDIS_MASTER_PORT_6379_TCP_ADDR=?10.0.0.11
注意，只有在某個(gè)Service后創(chuàng)建的Pod才會(huì)有這個(gè)Service的環(huán)境變量。
?
DNS
一個(gè)可選的Kubernetes附件（強(qiáng)烈建議用戶(hù)使用）是DNS服務(wù)。它跟蹤集群中Service對(duì)象，為每個(gè)Service對(duì)象創(chuàng)建DNS記錄。這樣所有的Pod就可以通過(guò)DNS訪(fǎng)問(wèn)服務(wù)了。
?
比如說(shuō)我們?cè)贙ubernetes 名字空間"my-ns"中有個(gè)叫my-service的服務(wù)，DNS服務(wù)會(huì)創(chuàng)建一條"my-service.my-ns"的DNS記錄。同在這個(gè)命名空間的Pod就可以通過(guò)"my-service"來(lái)得到這個(gè)Service分配到的Cluster IP，在其它命名空間的Pod則可以用全限定名"my-service.my-ns"來(lái)獲得這個(gè)Service的地址。
?
Pod IP and Service Cluster?IP
Pod IP 地址是實(shí)際存在于某個(gè)網(wǎng)卡(可以是虛擬設(shè)備)上的，但Service Cluster IP就不一樣了，沒(méi)有網(wǎng)絡(luò)設(shè)備為這個(gè)地址負(fù)責(zé)。它是由kube-proxy使用Iptables規(guī)則重新定向到其本地端口，再均衡到后端Pod的。我們前面說(shuō)的Service環(huán)境變量和DNS都使用Service的Cluster IP和端口。
?
就拿上面我們提到的圖像處理程序?yàn)槔?。?dāng)我們的Service被創(chuàng)建時(shí)，Kubernetes給它分配一個(gè)地址10.0.0.1。這個(gè)地址從我們啟動(dòng)API的service-cluster-ip-range參數(shù)(舊版本為portal_net參數(shù))指定的地址池中分配，比如--service-cluster-ip-range=10.0.0.0/16。假設(shè)這個(gè)Service的端口是1234。集群內(nèi)的所有kube-proxy都會(huì)注意到這個(gè)Service。當(dāng)proxy發(fā)現(xiàn)一個(gè)新的service后，它會(huì)在本地節(jié)點(diǎn)打開(kāi)一個(gè)任意端口，建相應(yīng)的iptables規(guī)則，重定向服務(wù)的IP和port到這個(gè)新建的端口，開(kāi)始接受到達(dá)這個(gè)服務(wù)的連接。
當(dāng)一個(gè)客戶(hù)端訪(fǎng)問(wèn)這個(gè)service時(shí)，這些iptable規(guī)則就開(kāi)始起作用，客戶(hù)端的流量被重定向到kube-proxy為這個(gè)service打開(kāi)的端口上，kube-proxy隨機(jī)選擇一個(gè)后端pod來(lái)服務(wù)客戶(hù)。這個(gè)流程如下圖所示：
根據(jù)Kubernetes的網(wǎng)絡(luò)模型，使用Service Cluster IP和Port訪(fǎng)問(wèn)Service的客戶(hù)端可以坐落在任意代理節(jié)點(diǎn)上。外部要訪(fǎng)問(wèn)Service，我們就需要給Service外部訪(fǎng)問(wèn)IP。
?
外部訪(fǎng)問(wèn)Service
Service對(duì)象在Cluster IP range池中分配到的IP只能在內(nèi)部訪(fǎng)問(wèn)，如果服務(wù)作為一個(gè)應(yīng)用程序內(nèi)部的層次，還是很合適的。如果這個(gè)Service作為前端服務(wù)，準(zhǔn)備為集群外的客戶(hù)提供業(yè)務(wù)，我們就需要給這個(gè)服務(wù)提供公共IP了。
?
外部訪(fǎng)問(wèn)者是訪(fǎng)問(wèn)集群代理節(jié)點(diǎn)的訪(fǎng)問(wèn)者。為這些訪(fǎng)問(wèn)者提供服務(wù)，我們可以在定義Service時(shí)指定其spec.publicIPs，一般情況下publicIP 是代理節(jié)點(diǎn)的物理IP地址。和先前的Cluster IP range上分配到的虛擬的IP一樣，kube-proxy同樣會(huì)為這些publicIP提供Iptables 重定向規(guī)則，把流量轉(zhuǎn)發(fā)到后端的Pod上。有了publicIP，我們就可以使用load balancer等常用的互聯(lián)網(wǎng)技術(shù)來(lái)組織外部對(duì)服務(wù)的訪(fǎng)問(wèn)了。
spec.publicIPs在新的版本中標(biāo)記為過(guò)時(shí)了，代替它的是spec.type=NodePort，這個(gè)類(lèi)型的service，系統(tǒng)會(huì)給它在集群的各個(gè)代理節(jié)點(diǎn)上分配一個(gè)節(jié)點(diǎn)級(jí)別的端口，能訪(fǎng)問(wèn)到代理節(jié)點(diǎn)的客戶(hù)端都能訪(fǎng)問(wèn)這個(gè)端口，從而訪(fǎng)問(wèn)到服務(wù)。
?
Label和Label selector
Label標(biāo)簽在Kubernetes模型中占著非常重要的作用。Label表現(xiàn)為key/value對(duì)，附加到Kubernetes管理的對(duì)象上，典型的就是Pods。它們定義了這些對(duì)象的識(shí)別屬性，用來(lái)組織和選擇這些對(duì)象。Label可以在對(duì)象創(chuàng)建時(shí)附加在對(duì)象上，也可以對(duì)象存在時(shí)通過(guò)API管理對(duì)象的Label。
?
在定義了對(duì)象的Label后，其它模型可以用Label 選擇器（selector)來(lái)定義其作用的對(duì)象。
Label選擇器有兩種，分別是Equality-based和Set-based。
比如如下Equality-based選擇器樣例：
?
environment = production tier != frontend environment = production，tier != frontend?
對(duì)于上面的選擇器，第一條匹配Label具有environment key且等于production的對(duì)象，第二條匹配具有tier key，但是值不等于frontend的對(duì)象。由于kubernetes使用AND邏輯，第三條匹配production但不是frontend的對(duì)象。
Set-based選擇器樣例：
?
environment in (production, qa) tier notin (frontend, backend) partition?
第一條選擇具有environment key，而且值是production或者qa的label附加的對(duì)象。第二條選擇具有tier key，但是其值不是frontend和backend。第三條選則具有partition key的對(duì)象，不對(duì)value進(jìn)行校驗(yàn)。
replication controller復(fù)制控制器和Service都用label和label selctor來(lái)動(dòng)態(tài)地配備作用對(duì)象。復(fù)制控制器在定義的時(shí)候就指定了其要?jiǎng)?chuàng)建Pod的Label和自己要匹配這個(gè)Pod的selector，?API服務(wù)器應(yīng)該校驗(yàn)這個(gè)定義。我們可以動(dòng)態(tài)地修改replication controller創(chuàng)建的Pod的Label用于調(diào)式，數(shù)據(jù)恢復(fù)等。一旦某個(gè)Pod由于Label改變從replication controller移出來(lái)后，replication controller會(huì)馬上啟動(dòng)一個(gè)新的Pod來(lái)確保復(fù)制池子中的份數(shù)。對(duì)于Service，Label selector可以用來(lái)選擇一個(gè)Service的后端Pods。
?
http://www.csdn.net/article/2015-06-11/2824933
轉(zhuǎn)載于:https://my.oschina.net/xiaominmin/blog/1598568
總結(jié)
以上是生活随笔為你收集整理的Kubernetes应用部署模型解析（原理篇）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 21天实战人工智能系列：人工智能产品经理
- 下一篇： 在Kubernetes Pod中使用Se