k8s極簡史

Docker和K8S已經(jīng)是當(dāng)下運(yùn)維的必備技能，無論是行業(yè)技能要求還是前沿技術(shù)領(lǐng)域，現(xiàn)在還不能很好掌握這兩門技術(shù)的技術(shù)人員，在新一輪的技術(shù)迭代中將最終被拋棄。

LXC

AA6FB025-6CB8-4A96-B91D-702CD632331B

Docker其實(shí)是一門容器化技術(shù)，也是虛擬化技術(shù)的一種，只是相對傳統(tǒng)的kvm,xen,vmware虛擬化技術(shù)而言，是基于進(jìn)程級別的虛擬化技術(shù)，更為輕量，因而性能損耗更小。

虛擬化技術(shù)并不是一門新技術(shù)，最小可以追溯到LXC技術(shù)！

LXC為linux Container的簡寫。可以提供輕量級的虛擬化，以便隔離進(jìn)程和資源，而且不需要提供指令解釋機(jī)制以及全虛擬化的其他復(fù)雜性。相當(dāng)于C++中的NameSpace。容器有效地將由單個(gè)操作系統(tǒng)管理的資源劃分到孤立的組中，以更好地在孤立的組之間平衡有沖突的資源使用需求。與傳統(tǒng)虛擬化技術(shù)相比，它的優(yōu)勢在于：

與宿主機(jī)使用同一個(gè)內(nèi)核，性能損耗小；
不需要指令級模擬；
不需要即時(shí)(Just-in-time)編譯；
容器可以在CPU核心的本地運(yùn)行指令，不需要任何專門的解釋機(jī)制；
避免了準(zhǔn)虛擬化和系統(tǒng)調(diào)用替換中的復(fù)雜性；
輕量級隔離，在隔離的同時(shí)還提供共享機(jī)制，以實(shí)現(xiàn)容器與宿主機(jī)的資源共享。

總結(jié)：Linux Container是一種輕量級的虛擬化的手段，提供了在單一可控主機(jī)節(jié)點(diǎn)上支持多個(gè)相互隔離的server container同時(shí)執(zhí)行的機(jī)制。Linux Container有點(diǎn)像chroot，提供了一個(gè)擁有自己進(jìn)程和網(wǎng)絡(luò)空間的虛擬環(huán)境，但又有別于虛擬機(jī)，因?yàn)長XC是一種操作系統(tǒng)層次上的資源的虛擬化

這里衍生出來另外一個(gè)問題？LXC技術(shù)最早可以追溯到20世紀(jì)70年代，計(jì)算機(jī)系統(tǒng)剛誕生的時(shí)代，即LXC和系統(tǒng)是強(qiáng)關(guān)聯(lián)，為什么一直到2010年左右才開始在歷史舞臺(tái)大紫大紅呢？

這里其實(shí)要講到進(jìn)程和隔離了。

進(jìn)程與隔離

沒有電的電腦只是一堆廢鐵，通了電的電腦只是一堆帶電的廢鐵！！ 這句話充分詮釋了操作系統(tǒng)的重要性。

由于計(jì)算機(jī)只認(rèn)識(shí)二進(jìn)制 0 和 1，所以無論哪種語言的實(shí)現(xiàn)，最后都需要通過某種方式編譯為二進(jìn)制文件，才能在計(jì)算機(jī)操作系統(tǒng)中運(yùn)行起來。

而為了能夠讓這些代碼正常運(yùn)行，我們還需要數(shù)據(jù)、代碼運(yùn)行平臺(tái)即操作系統(tǒng)。比如我們這個(gè)加法程序所需要的輸入文件。這些數(shù)據(jù)加上代碼本身的二進(jìn)制文件，放在磁盤上，就是我們平常所說的一個(gè)“程序”，也叫代碼的可執(zhí)行鏡像（executable image）。

然后，我們就可以在計(jì)算機(jī)上運(yùn)行這個(gè)程序了。

首先，操作系統(tǒng)從“程序”中發(fā)現(xiàn)輸入數(shù)據(jù)保存在一個(gè)文件中
然后，這些數(shù)據(jù)就會(huì)被加載到內(nèi)存中待命
接著，操作系統(tǒng)又讀取到了計(jì)算加法的指令
這時(shí)，它就需要指示 CPU 完成加法操作。

而 CPU 與內(nèi)存協(xié)作進(jìn)行加法計(jì)算，又會(huì)使用寄存器存放數(shù)值、內(nèi)存堆棧保存執(zhí)行的命令和變量。同時(shí)，計(jì)算機(jī)里還有被打開的文件，以及各種各樣的 I/O 設(shè)備在不斷地調(diào)用中修改自己的狀態(tài)。

就這樣，一旦程序被執(zhí)行起來，它就從磁盤上的二進(jìn)制文件，變成了計(jì)算機(jī)內(nèi)存中的數(shù)據(jù)、寄存器里的值、堆棧中的指令、被打開的文件，以及各種設(shè)備的狀態(tài)信息的一個(gè)集合。像這樣一個(gè)程序運(yùn)行起來后的計(jì)算機(jī)執(zhí)行環(huán)境的總和，就是我們今天的主角：進(jìn)程。

從上面可以看到，操作系統(tǒng)也是進(jìn)程，只是其無比復(fù)雜，復(fù)雜到可以把自己“虛擬成平臺(tái)”并承載其它進(jìn)程運(yùn)行的程序，而操作系統(tǒng)在這個(gè)過程中起到兩個(gè)非常重要的角色是：資源分配和資源隔離。

資源分配

眾所周知，Linux多用戶操作系統(tǒng)，即意味著可以多個(gè)同時(shí)使用操作系統(tǒng)，但操作系統(tǒng)只有一個(gè)大腦(無論是幾個(gè)物理核心，其實(shí)真正都在同一時(shí)間只有一個(gè)核心工作，雖然現(xiàn)代多核心技術(shù)在多核心協(xié)作上做了非常精巧的設(shè)計(jì))。

那么操作系統(tǒng)究竟該如何分配資源呢？如圖是top命令的返回，第一列是進(jìn)程ID，大家可能已經(jīng)想到了，就是進(jìn)程ID. 進(jìn)程ID越小，優(yōu)先級越高。進(jìn)程ID是系統(tǒng)判斷資源分配的重要依據(jù) 。

當(dāng)然，現(xiàn)代操作系統(tǒng)都是并行性操作系統(tǒng)，想像這么一個(gè)場景：如果有多個(gè)進(jìn)程都在申請同一塊內(nèi)存，而另外一個(gè)進(jìn)程一直在占用這塊內(nèi)存不肯釋放，此時(shí)操作系統(tǒng)該怎么辦呢？這種情形稱為“死瑣”，早在2.6版本以前的內(nèi)核，在資源分配和資源隔離做的并不理想。尤其是資源隔離

資源隔離

程序的正常運(yùn)行最少需要如下這些資源：

網(wǎng)絡(luò)資源
磁盤資源
內(nèi)存資源
CPU計(jì)算資源

容器化

其次還有非常重要的文件系統(tǒng)資源，和傳統(tǒng)虛擬化不同。傳統(tǒng)虛擬化是在磁盤上劃分出來一塊空間，在此空間上虛擬一個(gè)完整的操作系統(tǒng)，所有的資源與真實(shí)主機(jī)隔離。隔離安全性有保障，但性能損失不容忽視。

而Docker容器化不同的地方是Docker并不是一個(gè)操作系統(tǒng)，而只是真實(shí)物理機(jī)操作系統(tǒng)中的一個(gè)進(jìn)程，通過該進(jìn)程來調(diào)用內(nèi)核資源，使用rootfs文件系統(tǒng)技術(shù)和cgroup隔離動(dòng)技術(shù)，實(shí)現(xiàn)資源隔離。

性能幾乎無損耗，但隔離技術(shù)門檻較高，且3.10之前的內(nèi)核版本不支持。時(shí)至今日，Docker在虛擬化隔離也不能做到安全性100%。

介紹這么多，大家千萬不要誤解是因?yàn)镈ocker性能損耗少所以大紅大紫,真正促使Docker如日中天的原因其實(shí)是PAAS的發(fā)展

DOCKER

docker

從本世紀(jì)初開始，云計(jì)算的呼聲不斷，到2009年王堅(jiān)博士“騙”了馬云10個(gè)億創(chuàng)建阿里云，到現(xiàn)在阿里3年2000億、騰訊5年5000億在新基建的大力投入，不過短短20年時(shí)間。從早期的AWS,azure外資獨(dú)大，到現(xiàn)在阿里、騰訊、華為云獨(dú)占云市場鰲頭，如日中天的AWS和盛極一時(shí)的OpenStack,帶動(dòng)整個(gè)IT產(chǎn)品邁向PAAS時(shí)代.

但事情的發(fā)展總不以人的意識(shí)為導(dǎo)向。在家名為 dotCloud的公司在PAAS的浪潮中堅(jiān)持不下去，無奈開源他們?nèi)萜骰?xiàng)目：Docker。

令dotCloud公司自己都沒想到的是，這竟然會(huì)讓他們站在浪潮之巔并有機(jī)會(huì)和RedHat和google一戰(zhàn)雌雄，甚至逼的Google不得不和RedHat合作，并拿出自家核秘密武器Brog卻只為求得生存。

“容器”這個(gè)概念從來就不是什么新鮮的東西，也不是 dotCloud 公司發(fā)明的。所以dotCloud 開源的決定在當(dāng)時(shí)根本沒人在乎。

PaaS 項(xiàng)目被大家接納的一個(gè)主要原因，就是它提供了一種名叫“應(yīng)用托管”的能力。在當(dāng)時(shí)，虛擬機(jī)和云計(jì)算已經(jīng)是比較普遍的技術(shù)和服務(wù)了，用戶主流用法，就是租一批 AWS 或者 OpenStack 的虛擬機(jī)，然后像以前管理物理服務(wù)器那樣，用腳本或者手工的方式在這些機(jī)器上部署應(yīng)用。

當(dāng)然，這個(gè)部署過程難免會(huì)碰到云端虛擬機(jī)和本地環(huán)境不一致的問題，所以當(dāng)時(shí)的云計(jì)算服務(wù)，比的就是誰能更好地模擬本地服務(wù)器環(huán)境，能帶來更好的“上云”體驗(yàn)。而 PaaS 開源項(xiàng)目的出現(xiàn)，就是當(dāng)時(shí)解決這個(gè)問題的一個(gè)最佳方案。

Cloud Foundry是當(dāng)時(shí) PAAS 的平臺(tái)龍頭。在Docker開源時(shí)，其產(chǎn)品經(jīng)理 james Bayer在社區(qū)做過詳細(xì)對比，并告訴大家 Docker 實(shí)際上只是一個(gè)同樣使用了 cgroup 和Namespace 的"沙盒"工具而已，并不需要特別關(guān)注。

但僅在短短幾個(gè)月后，Docker就迅速崛起，速度之快連包括 Cloud Foudry 在內(nèi)的所有 PAAS 公司沒來得及反應(yīng)就out了.

而引導(dǎo)這一現(xiàn)象的原因卻僅僅是**Docker的鏡像功能**。

恐怕連 Docker 項(xiàng)目的作者 Solomon Hykes 自己當(dāng)時(shí)都沒想到，這個(gè)小小的創(chuàng)新，在短短幾年內(nèi)就如此迅速地改變了整個(gè)云計(jì)算領(lǐng)域的發(fā)展歷程。

PaaS 之所以能夠幫助用戶大規(guī)模部署應(yīng)用到集群里，是因?yàn)樗峁┝艘惶讘?yīng)用打包的功能。可偏偏就是這個(gè)打包功能，卻成了 PaaS日后不斷遭到用戶詬病的一個(gè)“軟肋”。

用戶一旦使用了 PaaS，就必須為每種語言、每種框架，甚至每個(gè)版本的應(yīng)用維護(hù)一個(gè)打好的包。這個(gè)打包過程，沒有任何章法可循，更麻煩的是，明明在本地運(yùn)行得好好的應(yīng)用，卻需要做很多修改和配置工作才能在 PaaS 里運(yùn)行起來。而這些修改和配置，并沒有什么經(jīng)驗(yàn)可以借鑒，基本上得靠不斷試錯(cuò)，直到你摸清楚了本地應(yīng)用和遠(yuǎn)端 PaaS 匹配的“脾氣”才能夠搞定。

而 Docker 鏡像解決的，恰恰就是打包這個(gè)根本性的問題

就這樣，容器化的時(shí)代開始了！

K8S

k8s

那Docker和k8s又有什么關(guān)系呢？

前面介紹，Docker 項(xiàng)目一日千里的發(fā)展勢頭，但用戶們最終要部署的，還是他們的網(wǎng)站、服務(wù)、數(shù)據(jù)庫，甚至是云計(jì)算業(yè)務(wù)。

這就意味著，只有那些能夠?yàn)橛脩籼峁┢脚_(tái)層能力的工具，才會(huì)真正成為開發(fā)者們關(guān)心和愿意付費(fèi)的產(chǎn)品。而 Docker 項(xiàng)目這樣一個(gè)只能用來創(chuàng)建和啟停容器的小工具，最終只能充當(dāng)這些平臺(tái)項(xiàng)目的“幕后英雄”。

即要想Docker能大面積普及，還需要解決大量Docker的協(xié)作編排問題。

談到Docker容器編排問題，就不得不說說 Docker 公司的老朋友和老對手 CoreOS 了。CoreOS 是一個(gè)基礎(chǔ)設(shè)施領(lǐng)域創(chuàng)業(yè)公司。它的核心產(chǎn)品是一個(gè)定制化的操作系統(tǒng)，用戶可以按照分布式集群的方式，管理所有安裝了這個(gè)操作系統(tǒng)的節(jié)點(diǎn)。從而，用戶在集群里部署和管理應(yīng)用就像使用單機(jī)一樣方便了.

Docker 項(xiàng)目發(fā)布后，CoreOS 公司很快就認(rèn)識(shí)到可以把“容器”的概念無縫集成到自己的這套方案中，從而為用戶提供更高層次的 PaaS 能力。所以，CoreOS 很早就成了 Docker 項(xiàng)目的貢獻(xiàn)者，并在短時(shí)間內(nèi)成為了 Docker 項(xiàng)目中第二重要的力量。

然而，這段短暫的蜜月期到 2014 年底就草草結(jié)束了。CoreOS 公司以強(qiáng)烈的措辭宣布與 Docker 公司停止合作，并直接推出了自己研制的 Rocket（后來叫 rkt）容器。

這次決裂的根本原因，正是源于 Docker 公司對 Docker項(xiàng)目定位的不滿足。Docker 公司解決這種不滿足的方法就是，讓 Docker 項(xiàng)目提供更多的平臺(tái)層能力，即向 PaaS 項(xiàng)目進(jìn)化。而這，顯然與 CoreOS 公司的核心產(chǎn)品和戰(zhàn)略發(fā)生了嚴(yán)重沖突。

大紅大紫不差錢的 Docker 開始大私收購來完善自己的生態(tài)和平臺(tái)能力。最出名的莫過于 Fig項(xiàng)目，即現(xiàn)在的 Compose，除此外，還有 SocketPlane, Flocker, Tutum等項(xiàng)目。

Docker的異常繁榮終于引起了行業(yè)巨頭的關(guān)注。

作為 Docker 項(xiàng)目早期的重要貢獻(xiàn)者，RedHat 也是因?yàn)閷?Docker 公司平臺(tái)化戰(zhàn)略不滿而憤憤退出。但此時(shí)，它竟只剩下 OpenShift 這個(gè)跟 Cloud Foundry 同時(shí)代的經(jīng)典 PaaS 一張牌可以打，跟 Docker Swarm 和轉(zhuǎn)型后的 Mesos完全不在同一個(gè)“競技水平”之上。

2014年6月，基礎(chǔ)設(shè)施領(lǐng)域的翹楚 Google 公司突然發(fā)力，正式宣告了一個(gè)名叫 Kubernetes項(xiàng)目的誕生。而這個(gè)項(xiàng)目，不僅挽救了當(dāng)時(shí)的 CoreOS 和 RedHat，還如同當(dāng)年 Docker項(xiàng)目的橫空出世一樣，再一次改變了整個(gè)容器市場的格局。

2015年6月22日，由 Docker 公司牽頭，CoreOS、Google、RedHat 等公司共同宣布，Docker公司將 Libcontainer 捐出，并改名為 RunC 項(xiàng)目，交由一個(gè)完全中立的基金會(huì)管理，然后以 RunC 為依據(jù)，大家共同制定一套容器和鏡像的標(biāo)準(zhǔn)和規(guī)范。

但由于 OCI 的成立更多的是這些容器玩家出于自身利益進(jìn)行干涉的一個(gè)妥協(xié)結(jié)果。所以O(shè)CI的組織效率一直很低下。

Docker 公司之所以不擔(dān)心 OCI 的威脅，原因就在于它的 Docker 項(xiàng)目是容器生態(tài)的事實(shí)標(biāo)準(zhǔn)，而它所維護(hù)的 Docker 社區(qū)也足夠龐大。可是，一旦這場斗爭被轉(zhuǎn)移到容器之上的平臺(tái)層，或者說 PaaS 層，Docker 公司的競爭優(yōu)勢便立刻捉襟見肘了。

Google、RedHat 等開源基礎(chǔ)設(shè)施領(lǐng)域玩家們，為了牽制Docker，共同牽頭發(fā)起了一個(gè)名為 CNCF（Cloud Native Computing Foundation）的基金會(huì)。這個(gè)基金會(huì)的目的其實(shí)很容易理解：它希望，以 Kubernetes 項(xiàng)目為基礎(chǔ)，建立一個(gè)由開源基礎(chǔ)設(shè)施領(lǐng)域廠商主導(dǎo)的、按照獨(dú)立基金會(huì)方式運(yùn)營的平臺(tái)級社區(qū)，來對抗以 Docker 公司為核心的容器商業(yè)生態(tài)。

k8s早先在社區(qū)一直被認(rèn)為太過前衛(wèi)先進(jìn)，但隨著時(shí)間的發(fā)展，GOOGLE的工程能力也逐步得到社區(qū)的認(rèn)可。而沒有大規(guī)模驗(yàn)證的 swarm 逐步淡出人們視野。

2016 年，Docker 公司宣布了一個(gè)震驚所有人的計(jì)劃：放棄現(xiàn)有的 Swarm 項(xiàng)目，將容器編排和集群管理功能全部內(nèi)置到 Docker 項(xiàng)目當(dāng)中。

到此，容器編排之爭落下帷幕。