docker編排工具分析

1、Docker 編排工具分析 2017年04月10日研發(fā)中心研發(fā)中心Docker 簡(jiǎn)介容器編排什么是 Docker與虛擬機(jī)的區(qū)別鏡像容器倉(cāng)庫(kù)卷網(wǎng)絡(luò)編排工具編排工具對(duì)比vDocker 是一個(gè)開源的應(yīng)用容器引擎，讓開發(fā)者可以打包應(yīng)用以及依賴包到一個(gè)可移植的容器中，然后發(fā)布到任何流行的 Linux 機(jī)器上,容器是完全使用沙箱機(jī)制，相互之間不會(huì)有任何接口。v在 LXC 的基礎(chǔ)上Docker進(jìn)行了進(jìn)一步的封裝，讓使用者不需要去關(guān)心容器的管理，使得操作更為簡(jiǎn)便。使用者操作 Docker 的容器就像操作一個(gè)快速輕量級(jí)的“虛擬機(jī)”一樣簡(jiǎn)單特性特性Docker虛擬機(jī)虛擬機(jī)啟動(dòng)秒級(jí)分鐘級(jí)硬盤使用一般為MB一般為GB

2、性能接近原生弱于原生系統(tǒng)支持量（單機(jī)）千級(jí)一般幾十個(gè)虛擬機(jī)實(shí)現(xiàn)資源隔離的方法是利用獨(dú)立的OS，并利用Hypervisor虛擬化CPU、內(nèi)存、IO設(shè)備等實(shí)現(xiàn)的。docker利用namespace實(shí)現(xiàn)系統(tǒng)環(huán)境的隔離；利用Cgroup實(shí)現(xiàn)資源限制；利用鏡像實(shí)現(xiàn)根目錄環(huán)境的隔離。利用的是宿主機(jī)的內(nèi)核，因此不需要Guest OS虛擬化技術(shù)SaaSPaaSIaaS融合：融合： docker運(yùn)行在openstack管理的虛擬機(jī)上。 openstack組件運(yùn)行在docker容器里。鏡像：鏡像： 一堆只讀層的統(tǒng)一視角，一個(gè)鏡像是永久不會(huì)變的。由于鏡像不可寫，所以鏡像是無(wú)狀態(tài)的。父鏡像：父鏡像： 每一個(gè)鏡像都可能

3、依賴于由一個(gè)或多個(gè)下層的組成的另一個(gè)鏡像。下層那個(gè) 鏡像是上層鏡像的父鏡像?；A(chǔ)鏡像：基礎(chǔ)鏡像： 一個(gè)沒(méi)有任何父鏡像的鏡像，謂之基礎(chǔ)鏡像。鏡像鏡像ID： 所有鏡像都是通過(guò)一個(gè) 64 位十六進(jìn)制字符串 （內(nèi)部是一個(gè) 256 bit 的值）來(lái)標(biāo)識(shí)的。 為簡(jiǎn)化使用，前 12 個(gè)字符可以組成一個(gè)短ID，可以在命令行中使用。短ID還是有一定的 碰撞機(jī)率，所以服務(wù)器總是返回長(zhǎng)ID。Metadata(元數(shù)據(jù)元數(shù)據(jù))： 鏡像層中包含的關(guān)于這個(gè)層的額外信息。 能夠讓Docker獲取運(yùn)行和構(gòu)建時(shí)的信息。 父層的層次信息指針：指針： 每層都包括一個(gè)指向父層的指針。 如果一層沒(méi)有這個(gè)指針，說(shuō)明它是基礎(chǔ)鏡像。容器：容器

4、： 容器定義和鏡像幾乎一模一樣，唯一區(qū)別在于容器的最上面那一層是可讀可寫的。 容器 = 鏡像 + 可讀層。CoW： CoW(copy-on-write)是一個(gè)類型共享和復(fù)制的策略。 需要相同數(shù)據(jù)的容器會(huì)共享他們所需的數(shù)據(jù)，不會(huì)每容器都保存一份。 只有當(dāng)一個(gè)進(jìn)程（容器）需要對(duì)共享文件進(jìn)行修改或者寫入數(shù)據(jù)的時(shí)候，操作系統(tǒng)才會(huì)復(fù)制一份該文件給這個(gè)進(jìn)程使用。 只有這個(gè)進(jìn)程（容器）對(duì)需要修改的數(shù)據(jù)副本有訪問(wèn)權(quán)限，其他所有進(jìn)程繼續(xù)使用原始數(shù)據(jù)。 Cow策略優(yōu)化了鏡像使用的存儲(chǔ)空間和容器啟動(dòng)花費(fèi)的時(shí)間。Registry(倉(cāng)庫(kù)注冊(cè)服務(wù)器)倉(cāng)庫(kù)私有倉(cāng)庫(kù)公開倉(cāng)庫(kù)Docker HubAlicloud倉(cāng)庫(kù)(Ubunt

5、u)Ubuntu-14.0Ubuntu-12.0Ubuntu-16.0倉(cāng)庫(kù)(Centos)倉(cāng)庫(kù)：倉(cāng)庫(kù)： 集中存放鏡像的場(chǎng)所。 公開倉(cāng)庫(kù)分國(guó)內(nèi)倉(cāng)庫(kù)和國(guó)外倉(cāng)庫(kù)。 可以使用registry配置本地的私有倉(cāng)庫(kù)。Union File System(聯(lián)合文件系統(tǒng)聯(lián)合文件系統(tǒng))： 指容器中只讀層及在頂部的讀寫層的組合。 容器修改了現(xiàn)有的一個(gè)已經(jīng)存在的文件，那該文件將會(huì)從讀寫層下面的只讀層復(fù)制一份到讀寫層。 刪除Docker容器，并通過(guò)該鏡像重新啟動(dòng)時(shí)，之前對(duì)該文件的更改將會(huì)丟失。Volume： 繞過(guò)默認(rèn)的聯(lián)合文件系統(tǒng)，而以正常的文件或者目錄的形式存在于宿主機(jī)上。 能夠保存（持久化）數(shù)據(jù)。 數(shù)據(jù)共享，使A容器

6、可以訪問(wèn)B容器的Volume。 容易備份 可以在刪除容器時(shí)，一并把volumes刪掉，但是當(dāng)這個(gè)volumes被多個(gè)容器共享時(shí)，則必須將所有共享此volumes的容器都刪掉才能同時(shí)刪除這個(gè)volumes。Host： 這個(gè)容器將不會(huì)獲得一個(gè)獨(dú)立的Network Namespace，而是和宿主機(jī)共用一個(gè)Network Namespace。使用宿主機(jī)的IP和端口。 網(wǎng)絡(luò)沒(méi)有隔離，存在安全隱患。Bridge： Docker默認(rèn)的網(wǎng)絡(luò)模式。 會(huì)為每一個(gè)容器分配Network Namespace、設(shè)置IP等，并將一個(gè)主機(jī)上的Docker容器連接到一個(gè)虛擬網(wǎng)橋上。None： 該模式下不會(huì)配置任何網(wǎng)絡(luò)。網(wǎng)絡(luò)創(chuàng)

7、建責(zé)任完全交給用戶n網(wǎng)絡(luò)存在的問(wèn)題：網(wǎng)絡(luò)存在的問(wèn)題： 在同一臺(tái)宿主機(jī)器內(nèi)，容器間可以相互訪問(wèn)，跨主機(jī)訪問(wèn)成為問(wèn)題。 雖然使用網(wǎng)橋模式可以跨主機(jī)，但性能較差。 使用Host模式也可以實(shí)現(xiàn)跨主機(jī)，但存在安全問(wèn)題。 Weave Flannel Pipwork Calico 網(wǎng)絡(luò)模式優(yōu)缺點(diǎn)分析參考Swarm ModeKubernetesMesos+MSwarm Mode節(jié)點(diǎn)（Node）任務(wù)(Task)服務(wù)(Service) 管理節(jié)點(diǎn)，能添加Task，也可以被設(shè)置成只具管理功能 工作節(jié)點(diǎn)，由管理節(jié)點(diǎn)指派Task，有Activer,Pause,Drain 三種狀態(tài)Active：集群中該Node可以被指派T

8、askPause：集群中該Node不可以被指派新的Task，但是其他已經(jīng)存在的Task保持運(yùn)行Drain：集群中該Node不可以被指派新的Task，Swarm Scheduler停掉已經(jīng)存在的Task，并將它們調(diào)度到可用的Node上多節(jié)點(diǎn)上的多容器應(yīng)用，使用overlay網(wǎng)絡(luò)實(shí)現(xiàn)不同節(jié)點(diǎn)上的容器之間的通信RegistryRequestDiscoverFilterStrategyE內(nèi)置于Docker Engine管理節(jié)點(diǎn) 調(diào)度任務(wù)服務(wù)擴(kuò)展和縮減-scale，以容器為單位集群狀態(tài)監(jiān)控和維護(hù)-visualizer ,shipyard跨主機(jī)網(wǎng)絡(luò)-指定overlay網(wǎng)絡(luò)服務(wù)發(fā)現(xiàn)-內(nèi)嵌DNS服務(wù)器 負(fù)載均

9、衡-內(nèi)部和外部 通訊安全-強(qiáng)制TLS加密Rolling Update容器HA卷持久性掛載Pod：基本操作單元，相關(guān)的一個(gè)或多個(gè)容器構(gòu)成一個(gè)Pod，通常Pod里的容器運(yùn)行相同的應(yīng)用Replication Controller：保證Pods數(shù)量Service：LabelNodeEtcd：共享配置和服務(wù)發(fā)現(xiàn)的分布式，一致性的KV存儲(chǔ)系統(tǒng)API Server：封裝核心組件的接口，是連接其它服務(wù)組件的樞紐。Scheduler：負(fù)責(zé)Pod在集群節(jié)點(diǎn)中的調(diào)度分配Control Manager：故障檢查和恢復(fù)自動(dòng)化Kubelet：負(fù)責(zé)當(dāng)前Node上的Pod全生命周期管理，同時(shí)定時(shí)上報(bào)本Node的狀態(tài)信息給Ap

10、iserverKubeproxy：網(wǎng)絡(luò)代理，LBFlannel：讓集群中的不同節(jié)點(diǎn)主機(jī)創(chuàng)建的Docker容器都具有全集群唯一的虛擬IP地址，并使Docker容器可以互連Service模型抽象以Goolge Borg為原型運(yùn)行監(jiān)控資源調(diào)度內(nèi)部域名服務(wù)健康檢查-liveness probe,readiness probe灰度升級(jí)-平滑過(guò)渡服務(wù)擴(kuò)展和縮減-以Pod為單位集群狀態(tài)維護(hù)失敗冗余服務(wù)發(fā)現(xiàn)負(fù)載均衡DevOps滾動(dòng)更新Jobs,Scheduled jobsPet Sets -支持有狀態(tài)服務(wù)Kubernetes功能集Swarm Mode功能集Linux OSDistributed “OS”Res

11、ource ManagementLinuxKernelMesosProcess ManagementLinuxKernelDockerJob SchedulingInit.d,cronMarathonInter-Porcess CommunicationPipe,SocketRabbitMQFile Systemext4HDFSMesos-Master：管理framework和slave，將slaves上的資源分配給framework們。Mesos Slave：負(fù)責(zé)管理本節(jié)點(diǎn)上的各個(gè)mesos-task。Framework：計(jì)算框架，如Hadoop,Spark,Marathon等，通過(guò)Meso

12、sSchedulerDriver接入Mesos。Executor：執(zhí)行器，安裝到Mesos-slave上，用于啟動(dòng)計(jì)算框架中的task。u Mesos是一個(gè)為了構(gòu)建分布式系統(tǒng)提供服務(wù)的分布式系統(tǒng)uMesos并不負(fù)責(zé)調(diào)度而是負(fù)責(zé)委派授權(quán)u 調(diào)度器是和Mesos層（通過(guò)API等）通信，而不是直接跟物理機(jī)器打交道u可以在一批機(jī)器上運(yùn)行多個(gè)不同的分布式系統(tǒng)并進(jìn)行動(dòng)態(tài)劃分和資源共享u在IaaS 上運(yùn)行Mesos，在Meos上構(gòu)建PaaS建立在Apace Mesos分布式系統(tǒng)上運(yùn)行監(jiān)控資源調(diào)度內(nèi)部域名服務(wù)健康檢查-應(yīng)用依賴的，需要被手動(dòng)實(shí)現(xiàn)。服務(wù)擴(kuò)展和縮減集群狀態(tài)維護(hù)服務(wù)發(fā)現(xiàn)負(fù)載均衡Kubernetes功

13、能集Swarm Mode功能集Mesos+Marathon功能集生產(chǎn)環(huán)境需求：多機(jī)集群資源調(diào)度可擴(kuò)展性負(fù)載均衡虛擬網(wǎng)絡(luò)微服務(wù)化比較項(xiàng)目比較項(xiàng)目 KubernetesSwarm ModeMesos+Marathon來(lái)源GoogleDocker原生Apache mesos開發(fā)語(yǔ)言GoGoC+/Scala生產(chǎn)經(jīng)驗(yàn)暫無(wú)學(xué)習(xí)成本運(yùn)維成本社區(qū)活躍度適用場(chǎng)景對(duì)外服務(wù)，或者需要提供高可靠服務(wù)的場(chǎng)景對(duì)內(nèi)使用，當(dāng)作私有云來(lái)使用，或者對(duì)容器的可靠性要求不高大型生產(chǎn)環(huán)境，團(tuán)隊(duì)有足夠的Linux分布式經(jīng)驗(yàn)優(yōu)點(diǎn)優(yōu)點(diǎn)缺點(diǎn)缺點(diǎn)Swarm Mode學(xué)習(xí)門檻低，使用簡(jiǎn)單只能做 Docker API 規(guī)定的事情Kubernetes

14、動(dòng)態(tài)調(diào)整部署很方便，功能豐富架構(gòu)中輔助性支撐節(jié)點(diǎn)偏多，維護(hù)本身的框架所消耗的資源成本偏高，導(dǎo)致集群越大，成本越高，可拓展性預(yù)期比較差Mesos+marathon可擴(kuò)展性高，靈活門檻高，運(yùn)維工作量大具體需求具體需求是是否否只運(yùn)行Docker集群資源混用大型生產(chǎn)環(huán)境足夠豐富的 Linux 和分布式經(jīng)驗(yàn)Docker Swarm 獨(dú)立于Docker engine 需要額外的KV存儲(chǔ)（也可以用Docker Hub的token） 沒(méi)有服務(wù)模型 與Docker machine的集成 使用Docker CLISwarmkit 使用自己的CLI（swarmd負(fù)責(zé)管理，swarmctl用于控制） 沒(méi)有服務(wù)發(fā)現(xiàn)、負(fù)

15、載均衡和路由功能 提供編排和調(diào)度服務(wù) 是Swarm mode的基礎(chǔ)Docker Swarm Mode 集成到了Docker engine中（docker swarm子命令） 不需要額外的KV存儲(chǔ) 支持服務(wù)模型（及task概念）以及相應(yīng)的擴(kuò)容縮容、服務(wù)發(fā)現(xiàn)、滾動(dòng)升級(jí)、路由和負(fù)載均衡等 加密通信 還沒(méi)有和Docker machine與Docker compose集成 使用Docker CLI Swarm mode基于Swarmkit編寫忘記Docker Swarm，知道有個(gè)Swarmkit，要用就用Docker Swarm Mode。namespace機(jī)制是一種輕量級(jí)的虛擬化形式 對(duì)于每一個(gè)命名空間，從用戶看起來(lái)，應(yīng)該像一臺(tái)單獨(dú)的Linux計(jì)算機(jī)一樣，有自己的init進(jìn)程(PID為0)，其他進(jìn)