前序
隨著現(xiàn)在容器技術(shù)的火熱，越來(lái)越多的人愿意接觸容器，而容器本身并不只是一個(gè)獨(dú)立工程，而是伴隨著容器的升級(jí)，改進(jìn)，其周邊衍生出了很多技術(shù)其中包括容器OS、容器引擎，基礎(chǔ)架構(gòu)的容器網(wǎng)絡(luò)、存儲(chǔ)、安全，容器運(yùn)行必不可少的鏡像倉(cāng)庫(kù)、編排，及運(yùn)維關(guān)注的監(jiān)控、日志等技術(shù)，而這些技術(shù)的核心就是，我們將各個(gè)功能組件根據(jù)自己的生產(chǎn)需求組合起來(lái)，構(gòu)成一個(gè)大的較為復(fù)雜的，功能齊全的技術(shù)戰(zhàn)參考阿里云發(fā)布的100個(gè)容器周邊項(xiàng)目，分為14個(gè)主要的類(lèi)別，并對(duì)我們身邊的技術(shù)做比較詳細(xì)的比較和講解。
容器引擎
容器引擎是容器集群生態(tài)圈的核心部分，容器引擎與內(nèi)核Namespace和CGroup等功能直接交互，并提供相應(yīng)API使得外部能夠與之集成的工具或服務(wù)。
docker與Rkt的區(qū)別
有一篇文章曾這樣講到兩者的聯(lián)系“Rocket和Docker沒(méi)有競(jìng)爭(zhēng)性。Docker平臺(tái)是一個(gè)產(chǎn)品，Rocket是一個(gè)組件。企業(yè)可以選擇Docker替代Cloud Foundry，也可以使用Rocket構(gòu)建Cloud Foundry。CoreOS在發(fā)布Rocket時(shí)就指出，Rocket的出現(xiàn)是因?yàn)橛行┤诵枰粋€(gè)更“純凈”的容器。換句話(huà)說(shuō)，Rocket算是“App Container Specification”的標(biāo)準(zhǔn)實(shí)現(xiàn)”
功能邊界
CoreOS認(rèn)為引擎作為一個(gè)獨(dú)立的組件，而Docker目前已發(fā)展成為一個(gè)平臺(tái)，這也是CoreOS推出Rocket的官方原因之一。從功能角度來(lái)對(duì)比，Docker提供了日志、鏡像和管理，甚至在1.12版本集成了swarm集群功能。而Rocket（rkt）的邊界為在Linux系統(tǒng)上運(yùn)行應(yīng)用容器的功能組件。
容器安全
兼容性
發(fā)布較晚的rkt在對(duì)Docker兼容性方面采用包容的態(tài)度，且rkt和kubernetes保持一致，基本運(yùn)行單元為pod。
Systemd與docker的命名空間
關(guān)于Rocket的討論最多的話(huà)題是systemd-spawn或者是 systemd，其中systemd做的或者說(shuō)能夠做的事情多是進(jìn)程管理。 CoreOS已將systemd作為他們Linux發(fā)行版的init系統(tǒng)。他們可以接著使用Init 腳本或者upstar，但是他們選擇使用了將來(lái)會(huì)成為所有主流Linux版本標(biāo)準(zhǔn)的init系統(tǒng)。不是使用Rocket必須要用systemd，而Rocket僅僅是“重用”了systemd和systemd-nspawn
Docker一直倡導(dǎo)一個(gè)容器運(yùn)行一個(gè)進(jìn)程。因?yàn)長(zhǎng)inux容器主要是為了實(shí)現(xiàn)主機(jī)的進(jìn)程隔離，而每個(gè)容器運(yùn)行一個(gè)進(jìn)程，會(huì)給你帶來(lái)更多的靈活性和復(fù)合型，獨(dú)立的更新、回滾等，操作更加簡(jiǎn)單。然而，當(dāng)你創(chuàng)建一個(gè)新的Docker容器或事實(shí)上LXC容器，容器被重新分配一套由libcontainer提供的全新的Linux命名空間。實(shí)話(huà)說(shuō)，我覺(jué)得這有點(diǎn)浪費(fèi)。于Docker還挺有意義，因?yàn)槟阋谝粋€(gè)容器中運(yùn)行一個(gè)單獨(dú)的進(jìn)程，并且如果你想提供更通用的進(jìn)程環(huán)境，來(lái)覆蓋大多數(shù)的用例，你可能需要libcontainer高效提供的大量可用命名空間。 只為一個(gè)進(jìn)程創(chuàng)建一組命名空間，增加了內(nèi)核大量的額外管理工作。如果你的主機(jī)上運(yùn)行了很多的容器，可能會(huì)出現(xiàn)內(nèi)核某些方面的瓶頸。你可能會(huì)說(shuō)開(kāi)銷(xiāo)很小，但是為什么非要過(guò)度占用內(nèi)核呢？因此，為了節(jié)省開(kāi)銷(xiāo)，可以共享進(jìn)程之間的命名空間。但是有個(gè)問(wèn)題，如果你開(kāi)始共享命名空間，并且創(chuàng)建它的容器已經(jīng)終止，它會(huì)刪除共享命名空間的所有的進(jìn)程。Kubernetesde在設(shè)計(jì)Pod時(shí)，就考慮到這個(gè)問(wèn)題了。 Kubernetes Pod中第一個(gè)被創(chuàng)建的容器，會(huì)被從internal/24 VLAN中分配一個(gè)IP地址，該IP地址也被Pod內(nèi)共享一個(gè)network namespaces的容器共享。
Hyper
Hyper是一個(gè)可以在hypervisor上，不安裝完整操作系統(tǒng)，直接運(yùn)行Docker Image的運(yùn)行引擎。Hyper可以在hypervisor上運(yùn)行一組相關(guān)的Docker Image，而不是一個(gè)，也正是Kubernetes所闡述的Pod的概念——不是一個(gè)虛機(jī)，不是一個(gè)胖容器，而是一組關(guān)聯(lián)的容器。再進(jìn)一步說(shuō)，Hyper致力于成為一個(gè)平臺(tái)中立、hypervisor中立的執(zhí)行引擎，除了支持KVM/QEMU外，接下來(lái)Hyper還將會(huì)支持Xen。
Hypervisor的最明顯的好處就在于，hypervisor的進(jìn)程是由另一個(gè)kernel調(diào)度，系統(tǒng)調(diào)用由另一個(gè)kernel處理，而并非宿主機(jī)的kernel。這樣，一方面用戶(hù)可以選擇自己的kernel，另一方面也增強(qiáng)了隔離性，hypervisor發(fā)生漏洞，對(duì)宿主機(jī)和其它虛擬機(jī)的威脅的概率是遠(yuǎn)低于容器漏洞的，畢竟容器向用戶(hù)進(jìn)程暴露了太多的入口點(diǎn)。虛擬機(jī)的另一個(gè)優(yōu)勢(shì)是，虛擬機(jī)相關(guān)的產(chǎn)業(yè)鏈已經(jīng)非常成熟，Xen/KVM已經(jīng)有十多年的歷史了，圍繞虛擬機(jī)打造的OpenStack也有五年的歷史了，和虛擬機(jī)有順暢合作的軟硬件上下游產(chǎn)品非常多，容器正在趕超，但虛擬機(jī)無(wú)疑是先行者。Hypervisor簡(jiǎn)化了硬件模型和kernel的硬件支持，這樣就不必費(fèi)力去掃描和初始化一些本沒(méi)有用的設(shè)備；我們省掉了完整的OS，這樣就沒(méi)有了init任務(wù)的影響；我們還是用了qboot，降低了老舊BIOS在引導(dǎo)過(guò)程中消耗的空間；此外還有一些流程上的細(xì)節(jié)優(yōu)化，最終呈現(xiàn)出了Hyper現(xiàn)在的性能。
Garden
在CloudFoundry的下一代PaaS項(xiàng)目Diego中，Pivotal團(tuán)隊(duì)對(duì)于Warden進(jìn)行了基于Golang的重構(gòu)，并建立了一個(gè)獨(dú)立的項(xiàng)目Garden。在Garden中，容器管理的功能被從server代碼里分離出來(lái)，即server部分只負(fù)責(zé)接收協(xié)議請(qǐng)求，而原先的容器管理則交給backend組件，包括將接收到的請(qǐng)求映射成為L(zhǎng)inux（假如是Linux backend的話(huà)）操作。值得注意的是：這樣backend架構(gòu)再次透露出了warden跨平臺(tái)的野心，可以想象一旦Windowsbackend被社區(qū)（比如IronFoundry）貢獻(xiàn)出來(lái)后的威力。更重要的是，RESTful風(fēng)格的API終于被引入到了Garden里面，原作者說(shuō)是為了實(shí)驗(yàn)和測(cè)試，但實(shí)際上Docker最成功的一點(diǎn)正是友好的API和以此為基礎(chǔ)的擴(kuò)展能力。
Pouch
Pouch是一款輕量級(jí)的容器技術(shù)，擁有快速高效、可移植性高、資源占用少等特性，主要幫助阿里更快的做到內(nèi)部業(yè)務(wù)的交付，同時(shí)提高超大規(guī)模下數(shù)據(jù)中心的物理資源利用率。
Pouch 技術(shù)優(yōu)勢(shì)
隔離性強(qiáng)
隔離性是企業(yè)走云化之路過(guò)程中，無(wú)法回避的一個(gè)技術(shù)難題。隔離性強(qiáng)，意味著技術(shù)具備了商用的初步條件；反之則幾乎沒(méi)有可能在業(yè)務(wù)線(xiàn)上鋪開(kāi)。哪怕是阿里巴巴這樣的技術(shù)公司，實(shí)踐容器技術(shù)伊始，安全問(wèn)題都無(wú)法幸免。眾所周知，行業(yè)中的容器方案大多基于 Linux 內(nèi)核提供的 cgroup 和 namespace 來(lái)實(shí)現(xiàn)隔離，然后這樣的輕量級(jí)方案存在弊端：
容器間，容器與宿主間，共享同一個(gè)內(nèi)核；
內(nèi)核實(shí)現(xiàn)的隔離資源，維度不足。
面對(duì)如此的內(nèi)核現(xiàn)狀，阿里巴巴采取了三個(gè)方面的工作，來(lái)解決容器的安全問(wèn)題：
用戶(hù)態(tài)增強(qiáng)容器的隔離維度，比如網(wǎng)絡(luò)帶寬、磁盤(pán)使用量等；
給內(nèi)核提交 patch，修復(fù)容器的資源可見(jiàn)性問(wèn)題，cgroup 方面的 bug；
實(shí)現(xiàn)基于 Hypervisor 的容器，通過(guò)創(chuàng)建新內(nèi)核來(lái)實(shí)現(xiàn)容器隔離。
容器安全的研究，在行業(yè)中將會(huì)持續(xù)相當(dāng)長(zhǎng)時(shí)間。
P2P 鏡像分發(fā)
蜻蜓是基于智能 P2P 技術(shù)的通用文件分發(fā)系統(tǒng)。解決了大規(guī)模文件分發(fā)場(chǎng)景下分發(fā)耗時(shí)、成功率低、帶寬浪費(fèi)等難題。大幅提升發(fā)布部署、數(shù)據(jù)預(yù)熱、大規(guī)模容器鏡像分發(fā)等業(yè)務(wù)能力
富容器技術(shù)
富容器”技術(shù)的實(shí)現(xiàn)，主要是為了在 Linux 內(nèi)核上創(chuàng)建一個(gè)與虛擬機(jī)體驗(yàn)完全一致的容器。如此一來(lái)，比一般容器要功能強(qiáng)大，內(nèi)部有完整的 init 進(jìn)程，以及業(yè)務(wù)應(yīng)用需要的任何服務(wù)，當(dāng)然這也印證了 Pouch 為什么可以做到對(duì)應(yīng)用沒(méi)有“侵入性”。技術(shù)的實(shí)現(xiàn)過(guò)程中，Pouch 需要將容器的執(zhí)行入口定義為 systemd，而在內(nèi)核態(tài)，Pouch 引入了 cgroup namespace 這一最新的內(nèi)核 patch，滿(mǎn)足 systemd 在富容器模式的隔離性。從企業(yè)運(yùn)維流程來(lái)看，富容器同樣優(yōu)勢(shì)明顯。它可以在應(yīng)用的 Entrypoint 啟動(dòng)之前做一些事情，
內(nèi)核兼容性
Pouch 支持所有內(nèi)核版本，而現(xiàn)有的容器技術(shù)支持的 Linux 內(nèi)核都在 3.10 以上。不過(guò)技術(shù)層面萬(wàn)幸的是，對(duì) 2.6.32 等老版本內(nèi)核而言，namespace 的支持僅僅缺失 user namespace；其他 namespace 以及常用的 cgroup 子系統(tǒng)均存在；但是 /proc/self/ns 等用來(lái)記錄 namespace 的輔助文件當(dāng)時(shí)還不存在，setns 等系統(tǒng)調(diào)用也需要在高版本內(nèi)核中才能支持。而阿里的技術(shù)策略是，通過(guò)一些其他的方法，來(lái)繞過(guò)某些系統(tǒng)調(diào)用，實(shí)現(xiàn)老版本內(nèi)核的容器支持。
Pouch 架構(gòu)
Pouch 的生態(tài)架構(gòu)主要包含兩個(gè)方面：1.如何對(duì)接容器編排系統(tǒng)；2.如何加強(qiáng)容器運(yùn)行時(shí)。
參考
https://yq.aliyun.com/articles/593097?utm_content=m_49901
https://www.kubernetes.org.cn/2250.html
http://www.infoq.com/cn/news/2015/06/Hyper-Hypervisor-Docker
https://blog.csdn.net/resouer/article/details/40503903
http://www.infoq.com/cn/articles/alibaba-pouch
