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