Kubernetes和Mesos集成的優(yōu)勢(shì)與原理

　Kubernetes是一個(gè)docker集群管理工具，主要包含資源管理，部署運(yùn)行，服務(wù)發(fā)現(xiàn)，擴(kuò)容縮容等功能，幫助用戶(hù)把所有的應(yīng)用都部署在Docker Container里邊，Kubernetes可以看成是一個(gè)mini的PaaS平臺(tái)，主要用來(lái)幫助用戶(hù)管理Docker Container。
　　Apache Mesos是一款開(kāi)源集群管理軟件，由加州大學(xué)伯克利分校的AMPLab首先開(kāi)發(fā)；支持Hadoop、ElasticSearch、Spark、Storm 和Kafka等架構(gòu)。Mesos 為上層的應(yīng)用框架提供了資源共享，資源監(jiān)控，動(dòng)態(tài)擴(kuò)容等集群管理功能。由于其穩(wěn)定、通用等特性，越來(lái)越受到大型公司的青睞，例如Twitter、Facebook、Apple等都在生產(chǎn)環(huán)境中使用Mesos進(jìn)行集群管理。
　　集成優(yōu)勢(shì)
　　Kubernetes worker節(jié)點(diǎn)自動(dòng)擴(kuò)展
　　一個(gè)普通的Kubernetes集群會(huì)包含若干臺(tái)Master和Worker節(jié)點(diǎn)，這些都需要用戶(hù)手動(dòng)或者通過(guò)腳本去安裝，如果想實(shí)現(xiàn)Kubernets Auto Scaling的話，需要將Kubernetes部署在一個(gè)IaaS的云平臺(tái)之上，通過(guò)云平臺(tái)對(duì)Kubernetes提供資源，同時(shí)對(duì)Kubernets監(jiān)控，根據(jù)負(fù)載進(jìn)行自動(dòng)擴(kuò)展，但是Kubernetes和云平臺(tái)的集成稍顯厚重。
　　Kubernetes和Mesos集成完成之后，也可以實(shí)現(xiàn)Worker節(jié)點(diǎn)的自動(dòng)擴(kuò)展，所有Worker節(jié)點(diǎn)都是自動(dòng)創(chuàng)建的，不需要用戶(hù)手動(dòng)干預(yù)。詳細(xì)信息在“集成原理”會(huì)介紹。
　　資源共享
　　一旦Mesos和Kubernetes集成完成之后，Kubernetes會(huì)作為Mesos的一個(gè)Framework運(yùn)行在Mesos之上。因?yàn)橐粋€(gè)Mesos可以同時(shí)為多個(gè)Framework提供資源，當(dāng)Kubernetes作為Mesos的一個(gè)Framework之后，Mesos就可以實(shí)現(xiàn)Kubernetes和其它Framework之間的資源共享。
　　集成原理
　　
　　在Kuberntes與Mesos的集成中，Kubernetes的Scheduler會(huì)作為Mesos的Framework對(duì)Pod與Offer進(jìn)行匹配；而Kubernetes 的 kubelet 與 kube-proxy則會(huì)被新增加的Mesos Executor進(jìn)行管理來(lái)啟動(dòng)相應(yīng)的Worker并對(duì)網(wǎng)絡(luò)進(jìn)行配置，從而達(dá)到動(dòng)態(tài)擴(kuò)容的需求。
　　Kubernetes 與 Mesos集成中包含了多個(gè)方面內(nèi)容；本文的將主要集中介紹資源調(diào)度相關(guān)部分，后續(xù)會(huì)有文章介紹其它集成點(diǎn)，如資源執(zhí)行，環(huán)境搭建，測(cè)試等等。
　　Kubernetes Worker節(jié)點(diǎn)的創(chuàng)建
　　K8sm的kubernetes worker節(jié)點(diǎn)是動(dòng)態(tài)創(chuàng)建的，不需要用戶(hù)手動(dòng)創(chuàng)建。創(chuàng)建流程如下：
　　1） 當(dāng)k8sm的framework注冊(cè)成功后，馬上就會(huì)收到Mesos發(fā)來(lái)的Offer。因?yàn)镸esos的Offer都是Coarse-grained Offer，所以當(dāng)前發(fā)來(lái)的Offer會(huì)包含整個(gè)host的全部資源。
　　2） K8sm scheduler收到Offer后，會(huì)首先檢查當(dāng)前的Offer是不是合法的，所謂的合法Offer，需要滿足兩個(gè)條件，第一個(gè)就當(dāng)前的這個(gè)Offer的資源來(lái)自于Kubernetes的某個(gè)worker節(jié)點(diǎn)，第二個(gè)是當(dāng)前Offer的ExeuctorId必須是沒(méi)有或者只有一個(gè)，并且Offere的ExeuctorId和k8sm scheduler啟動(dòng)時(shí)設(shè)置的ExeuctorId相同。但是在k8s剛注冊(cè)的時(shí)候，是沒(méi)有任何worker節(jié)點(diǎn)的，這時(shí)候k8sm的scheduler做的事情就是Decline這個(gè)Offer，即把這個(gè)Offer返回給Mesos，但是會(huì)把這個(gè)Offer對(duì)應(yīng)的host為Kubernetes創(chuàng)建一個(gè)worker節(jié)點(diǎn)。一個(gè)合法的Offer需要滿足一下幾個(gè)條件：
　　● 當(dāng)前Offer的資源來(lái)自于Kubernetes的某個(gè)worker節(jié)點(diǎn)。
　　● 當(dāng)前Offer的ExeuctorId必須是沒(méi)有或者只有一個(gè)，并且Offer的ExeuctorId和k8sm scheduler啟動(dòng)時(shí)設(shè)置的ExeuctorId相同。
　　● 如果當(dāng)前Offer中只有一個(gè)ExecutorId，是否有效合法取決Agent的屬性是否有變化：如果屬性沒(méi)有變化，認(rèn)為Offer是合法的；否則認(rèn)為是無(wú)效的。
　　3） 如此周而復(fù)始，一直將Mesos集群中所有的節(jié)點(diǎn)加入Kubernetes的worker節(jié)點(diǎn)。
　　4） 當(dāng)有新的Mesos節(jié)點(diǎn)加入Mesos集群時(shí)，新加入的節(jié)點(diǎn)也會(huì)給k8sm scheduler發(fā)Offer，k8sm scheduler會(huì)將新加入的Mesos節(jié)點(diǎn)創(chuàng)建為一個(gè)Kunernetes的worker節(jié)點(diǎn)。
　　5） 所有的Kubenetes worker節(jié)點(diǎn)都會(huì)存在etcd中。用戶(hù)可以通過(guò)命令“kubectl get nodes”或者直接使用“etcdctl”查看Kubenetes中的所有worker節(jié)點(diǎn)。
　　當(dāng)Kubernetes Worker節(jié)點(diǎn)創(chuàng)建完成后，Mesos再發(fā)Offer時(shí)，如果發(fā)現(xiàn)當(dāng)前Offer的Host是Kubernetes的一個(gè)Worker節(jié)點(diǎn)，k8sm scheduler就會(huì)把這個(gè)Offer作為一個(gè)合法的Offer，同時(shí)將該Offer緩存起來(lái)，默認(rèn)的緩存時(shí)間是5s.
　　Offer生命周期管理
　　Framework 實(shí)現(xiàn)了 Mesos 的 SchedulerDriver接口；該接口用于Mesos 和 Framework之間的交互。當(dāng)k8sm scheduler啟動(dòng)后，會(huì)創(chuàng)建一個(gè)名為 OfferStorage 的 go routine 用于 Offer 的生命周期管理。下面會(huì)根據(jù)Offer的創(chuàng)建，使用及銷(xiāo)毀三個(gè)階段對(duì)Offer進(jìn)行分析。
　　Offer的創(chuàng)建
　　如上文描述的，當(dāng)Framework注冊(cè)到Mesos上后，Mesos會(huì)定期 （–allocation_interval） 向Framework發(fā)送Offer。k8sm scheduler 通過(guò)以下的原則檢測(cè)收到的Offer是否合法；如果合法，則放入Offer的緩存中；否則把資源返回給Mesos。
　　當(dāng)對(duì)Offer進(jìn)行緩存時(shí)，會(huì)有兩個(gè)隊(duì)列對(duì)Offer信息進(jìn)行存儲(chǔ)：delayed 和 Offers。Offers 用于Pod的運(yùn)行；而當(dāng)Offer銷(xiāo)毀時(shí)會(huì)使用 delayed 隊(duì)列；具體的銷(xiāo)毀過(guò)程會(huì)在”O(jiān)ffer的銷(xiāo)毀”進(jìn)行分析。
　　Offer的使用
　　在k8sm scheduler啟動(dòng)后，會(huì)有一個(gè)go routine周期性的檢查是不是有新的Pod創(chuàng)建請(qǐng)求。如果有新的Pod創(chuàng)建請(qǐng)求，將這個(gè)請(qǐng)求放入k8sm scheduler的任務(wù)隊(duì)列。k8sm scheduler會(huì)從這個(gè)任務(wù)隊(duì)列取出需要?jiǎng)?chuàng)建的Pod進(jìn)行調(diào)度，調(diào)度的主要目的是為當(dāng)前的Pod找到合適的服務(wù)器來(lái)運(yùn)行。
　　因?yàn)镵ubernetes是作為Mesos的framework來(lái)運(yùn)行的，所以對(duì)Offer的使用主要由兩個(gè)API來(lái)處理：ResourceOffers和LaunchTask。但是對(duì)Offer的處理可以主要分為三部分：獲取Offer，關(guān)聯(lián)Task和Offer，執(zhí)行task。每一個(gè)Task對(duì)應(yīng)一個(gè)Pod。
　　獲取Offer
　　Offer主要是通過(guò)ResourceOffer獲取的。這個(gè)API是Mesos Framework的API，所有的Frameworkd都需要實(shí)現(xiàn)這個(gè)API用來(lái)接收從Mesos發(fā)送來(lái)的Offer。前邊已經(jīng)講了ResourceOffer會(huì)觸發(fā)添加新的Kuernetes worker節(jié)點(diǎn)，同時(shí)這個(gè)Offer會(huì)被緩存起來(lái)，緩存時(shí)間可以通過(guò)參數(shù)配置，默認(rèn)是5s。
　　關(guān)聯(lián)Task和Offer
　　在k8sm scheduler啟動(dòng)后，會(huì)有一個(gè)go routine周期性的檢查是不是有新的Pod創(chuàng)建請(qǐng)求。如果有新的Pod創(chuàng)建請(qǐng)求，將這個(gè)請(qǐng)求放入k8sm scheduler的任務(wù)隊(duì)列。k8sm scheduler會(huì)從這個(gè)任務(wù)隊(duì)列取出需要?jiǎng)?chuàng)建的Pod進(jìn)行調(diào)度。
　　在對(duì)Pod進(jìn)行調(diào)度的時(shí)候，k8sm scheduler回選擇將Task和Offer關(guān)聯(lián)。k8sm scheudler現(xiàn)在默認(rèn)是FCFS算法調(diào)度。FCFS對(duì)Pod進(jìn)行調(diào)度的時(shí)候，主要是為T(mén)ask挑選合適的Offer，對(duì)當(dāng)前緩存的Offer逐個(gè)進(jìn)行校驗(yàn)，直到為當(dāng)前的Task選出合適Offer。對(duì)Offer的選擇主要通過(guò)四個(gè)方法來(lái)進(jìn)行檢驗(yàn)：
　　1） 第一個(gè)校驗(yàn)是Node的校驗(yàn)，主要是檢查當(dāng)前Offer的host是不是可以被當(dāng)前的Pod使用。因?yàn)镻od在創(chuàng)建的時(shí)候，可以直接在Pod的YAML文件中指定創(chuàng)建的host或者NodeSelector，Node的校驗(yàn)主要是檢查當(dāng)前Offer的host是不是可以為這個(gè)Pod所用。如果當(dāng)前的Host可以為Pod所用，那么當(dāng)前的Node校驗(yàn)就會(huì)把Host作為隨后校驗(yàn)的參數(shù)；反之則校驗(yàn)下一個(gè)Offer。
　　2） 第二個(gè)校驗(yàn)是Pod的資源校驗(yàn)，主要是檢查當(dāng)前的Host是不是有足夠的資源啟動(dòng)Pod?，F(xiàn)在檢查的主要是CPU和Memeory。如果資源足夠，進(jìn)行下一個(gè)校驗(yàn)。
　　3） 第三個(gè)校驗(yàn)主要是端口的校驗(yàn)，主要是檢查端口沖突。檢查當(dāng)前Host上的端口是不是可以為Pod所用。
　　4） 第四個(gè)校驗(yàn)，也就是最后一個(gè)校驗(yàn)，主要是校驗(yàn)Executor。K8sm scheduler主要是使用一個(gè)executor管理了所有的task，所以如果Executor校驗(yàn)發(fā)現(xiàn)當(dāng)前Offer中有兩個(gè)Exeuctor ID，會(huì)返回錯(cuò)誤，校驗(yàn)下一個(gè)Offer；如果發(fā)現(xiàn)當(dāng)前Offer已經(jīng)包含一個(gè)Executor ID了，這時(shí)候直接返回，當(dāng)前Offer可用；如果發(fā)現(xiàn)當(dāng)前Offer中不包含Executor ID，還需要查一下當(dāng)前的Offer有沒(méi)有足夠的資源啟動(dòng)Executor，如果有足夠的資源啟動(dòng)Executor，當(dāng)前Offer可用。
　　以上四個(gè)校驗(yàn)主要是檢查一個(gè)Offer是否可用和一個(gè)Task綁定。如果檢驗(yàn)完成后，Offer可用，k8sm scheduler就會(huì)把該Offer和當(dāng)前Task關(guān)聯(lián)起來(lái)。
　　在Task Launch之前，還會(huì)檢查下當(dāng)前的Task是不是關(guān)聯(lián)一個(gè)Offer，如果Task沒(méi)有關(guān)聯(lián)Offer，k8sm scheduler會(huì)返回錯(cuò)誤，因?yàn)門(mén)ask在運(yùn)行的時(shí)候，必須從某個(gè)Offer獲取資源才可以運(yùn)行。
　　LaunchTask
　　當(dāng)Task和Offer關(guān)聯(lián)完成后，k8sm scheduler就開(kāi)始執(zhí)行Task了。在執(zhí)行LaunchTasks之前，需要對(duì)Task信息按照Mesos需要的格式進(jìn)行構(gòu)建，例如設(shè)置Task名字，Task需要的SlaveId，Task需要的資源，Task ID，Task的Executor信息等等。接下來(lái)就調(diào)用Mesos Framework API LaunchTasks去創(chuàng)建Pod了，具體創(chuàng)建Pod的工作由k8sm的Executor執(zhí)行。
　　在Worker節(jié)點(diǎn)，Mesos 的 Agent 會(huì)負(fù)責(zé)Executor管理。k8sm的Executor會(huì)先創(chuàng)建一個(gè)名為MinionServer的對(duì)象來(lái)負(fù)責(zé)proxy 和 executor 的管理：proxy通過(guò)nsenter， iptables等對(duì)網(wǎng)絡(luò)進(jìn)行配置；而executor則實(shí)現(xiàn)了Mesos Executor接口，用于接收并執(zhí)行作業(yè)，例如在Docker中啟動(dòng)Pod。限于篇幅，網(wǎng)絡(luò)配置和Pods的執(zhí)行細(xì)節(jié)會(huì)以后的文章會(huì)進(jìn)行具體的描述。