LXC
程序與隔離
資源配置設定
資源隔離
DOCKER
K8S
k8s極簡史
<code>Docker</code>和<code>K8S</code>已經是當下運維的必備技能，無論是行業技能要求還是前沿技術領域，現在還不能很好掌握這兩門技術的技術人員，在新一輪的技術疊代中将最終被抛棄。
AA6FB025-6CB8-4A96-B91D-702CD632331B
<code>Docker</code>其實是一門容器化技術，也是虛拟化技術的一種，隻是相對傳統的<code>kvm</code>,<code>xen</code>,<code>vmware</code>虛拟化技術而言，是基于程序級别的虛拟化技術，更為輕量，因而性能損耗更小。
虛拟化技術并不是一門新技術，最小可以追溯到<code>LXC</code>技術！
<code>LXC</code>為<code>Linux Container</code>的簡寫。可以提供輕量級的虛拟化，以便隔離程序和資源，而且不需要提供指令解釋機制以及全虛拟化的其他複雜性。相當于<code>C++</code>中的<code>NameSpace</code>。容器有效地将由單個作業系統管理的資源劃分到孤立的組中，以更好地在孤立的組之間平衡有沖突的資源使用需求。與傳統虛拟化技術相比，它的優勢在于：
與主控端使用同一個核心，性能損耗小；
不需要指令級模拟；
不需要即時(Just-in-time)編譯；
容器可以在CPU核心的本地運作指令，不需要任何專門的解釋機制；
避免了準虛拟化和系統調用替換中的複雜性；
輕量級隔離，在隔離的同時還提供共享機制，以實作容器與主控端的資源共享。
總結：<code>Linux Container</code>是一種輕量級的虛拟化的手段，提供了在單一可控主機節點上支援多個互相隔離的<code>server container</code>同時執行的機制。<code>Linux Container</code>有點像<code>chroot</code>，提供了一個擁有自己程序和網絡空間的虛拟環境，但又有别于虛拟機，因為<code>LXC</code>是一種作業系統層次上的資源的虛拟化
這裡衍生出來另外一個問題？<code>LXC</code>技術最早可以追溯到20世紀70年代，計算機系統剛誕生的時代，即LXC和系統是強關聯，為什麼一直到2010年左右才開始在曆史舞台大紫大紅呢？
這裡其實要講到程序和隔離了。
沒有電的電腦隻是一堆廢鐵，通了電的電腦隻是一堆帶電的廢鐵！！這句話充分诠釋了作業系統的重要性。
由于計算機隻認識二進制 0 和 1，是以無論哪種語言的實作，最後都需要通過某種方式編譯為二進制檔案，才能在計算機作業系統中運作起來。
而為了能夠讓這些代碼正常運作，我們還需要資料、代碼運作平台即作業系統。比如我們這個加法程式所需要的輸入檔案。這些資料加上代碼本身的二進制檔案，放在磁盤上，就是我們平常所說的一個“程式”，也叫代碼的可執行鏡像（executable image）。
然後，我們就可以在計算機上運作這個程式了。
首先，作業系統從“程式”中發現輸入資料儲存在一個檔案中
然後，這些資料就會被加載到記憶體中待命
接着，作業系統又讀取到了計算加法的指令
這時，它就需要訓示 CPU 完成加法操作。
而 CPU 與記憶體協作進行加法計算，又會使用寄存器存放數值、記憶體堆棧儲存執行的指令和變量。同時，計算機裡還有被打開的檔案，以及各種各樣的 I/O 裝置在不斷地調用中修改自己的狀态。
就這樣，一旦 程式 被執行起來，它就從磁盤上的二進制檔案，變成了計算機記憶體中的資料、寄存器裡的值、堆棧中的指令、被打開的檔案，以及各種裝置的狀态資訊的一個集合。像這樣一個程式運作起來後的計算機執行環境的總和，就是我們今天的主角：程序。
從上面可以看到，作業系統也是程序，隻是其無比複雜，複雜到可以把自己“虛拟成平台”并承載其它程序運作的程式，而作業系統在這個過程中起到兩個非常重要的角色是：資源配置設定和資源隔離。
衆所周知，<code>Linux</code>多使用者作業系統，即意味着可以多個同時使用作業系統，但作業系統隻有一個大腦(無論是幾個實體核心，其實真正都在同一時間隻有一個核心工作，雖然現代多核心技術在多核心協作上做了非常精巧的設計)。
那麼作業系統究竟該如何配置設定資源呢？如圖是top指令的傳回，第一列是程序ID，大家可能已經想到了，就是程序ID. 程序ID越小，優先級越高。程序ID是系統判斷資源配置設定的重要依據 。
當然，現代作業系統都是并行性作業系統，想像這麼一個場景：如果有多個程序都在申請同一塊記憶體，而另外一個程序一直在占用這塊記憶體不肯釋放，此時作業系統該怎麼辦呢？這種情形稱為“死瑣”，早在2.6版本以前的核心，在資源配置設定和資源隔離做的并不理想。尤其是資源隔離
程式的正常運作最少需要如下這些資源：
網絡資源
磁盤資源
記憶體資源
CPU計算資源
容器化
其次還有非常重要的檔案系統資源，和傳統虛拟化不同。傳統虛拟化是在磁盤上劃分出來一塊空間，在此空間上虛拟一個完整的作業系統，所有的資源與真實主機隔離。隔離安全性有保障，但性能損失不容忽視。
而<code>Docker</code>容器化不同的地方是<code>Docker</code>并不是一個作業系統，而隻是真實實體機作業系統中的一個程序，通過該程序來調用核心資源，使用<code>rootfs</code>檔案系統技術和<code>cgroup</code>隔離動技術，實作資源隔離。
性能幾乎無損耗，但隔離技術門檻較高，且3.10之前的核心版本不支援。時至今日，<code>Docker</code>在虛拟化隔離也不能做到安全性100%。
介紹這麼多，大家千萬不要誤解是因為<code>Docker</code>性能損耗少是以大紅大紫,真正促使<code>Docker</code>如日中天的原因其實是<code>PAAS</code>的發展
docker
從本世紀初開始，雲計算的呼聲不斷，到2009年王堅博士“騙”了馬雲10個億建立阿裡雲，到現在阿裡3年2000億、騰訊5年5000億在新基建的大力投入，不過短短20年時間。從早期的AWS,azure外資獨大，到現在阿裡、騰訊、華為雲獨占雲市場鳌頭，如日中天的AWS和盛極一時的<code>OpenStack</code>,帶動整個IT産品邁向<code>PAAS</code>時代.
但事情的發展總不以人的意識為導向。在家名為 <code>dotCloud</code>的公司在<code>PAAS</code>的浪潮中堅持不下去，無奈開源他們容器化項目：<code>Docker</code>。
令<code>dotCloud</code>公司自己都沒想到的是，這竟然會讓他們站在浪潮之巅并有機會和RedHat和Google一戰雌雄，甚至逼的Google不得不和RedHat合作，并拿出自家核秘密武器<code>Brog</code>卻隻為求得生存。
“容器”這個概念從來就不是什麼新鮮的東西，也不是 <code>dotCloud</code> 公司發明的。是以<code>dotCloud</code> 開源的決定在當時根本沒人在乎。
PaaS 項目被大家接納的一個主要原因，就是它提供了一種名叫“應用托管”的能力。在當時，虛拟機和雲計算已經是比較普遍的技術和服務了，使用者主流用法，就是租一批 <code>AWS</code> 或者 <code>OpenStack</code> 的虛拟機，然後像以前管理實體伺服器那樣，用腳本或者手工的方式在這些機器上部署應用。
當然，這個部署過程難免會碰到雲端虛拟機和本地環境不一緻的問題，是以當時的雲計算服務，比的就是誰能更好地模拟本地伺服器環境，能帶來更好的“上雲”體驗。而 <code>PaaS</code> 開源項目的出現，就是當時解決這個問題的一個最佳方案。
<code>Cloud Foundry</code>是當時 <code>PAAS</code> 的平台龍頭。在<code>Docker</code>開源時，其産品經理 <code>james Bayer</code>在社群做過詳細對比，并告訴大家 <code>Docker</code> 實際上隻是一個同樣使用了 <code>cgroup</code> 和<code>Namespace</code> 的"沙盒"工具而已，并不需要特别關注。
但僅在短短幾個月後，<code>Docker</code>就迅速崛起，速度之快連包括 <code>Cloud Foudry</code> 在内的所有 <code>PAAS</code> 公司沒來得及反應就<code>out</code>了.
而引導這一現象的原因卻僅僅是**<code>Docker</code>的鏡像功能**。
恐怕連 <code>Docker</code> 項目的作者 <code>Solomon Hykes</code> 自己當時都沒想到，這個小小的創新，在短短幾年内就如此迅速地改變了整個雲計算領域的發展曆程。
<code>PaaS</code> 之是以能夠幫助使用者大規模部署應用到叢集裡，是因為它提供了一套應用打包的功能。可偏偏就是這個打包功能，卻成了 <code>PaaS</code>日後不斷遭到使用者诟病的一個“軟肋”。
使用者一旦使用了 <code>PaaS</code>，就必須為每種語言、每種架構，甚至每個版本的應用維護一個打好的包。這個打包過程，沒有任何章法可循，更麻煩的是，明明在本地運作得好好的應用，卻需要做很多修改和配置工作才能在 <code>PaaS</code> 裡運作起來。而這些修改和配置，并沒有什麼經驗可以借鑒，基本上得靠不斷試錯，直到你摸清楚了本地應用和遠端 <code>PaaS</code> 比對的“脾氣”才能夠搞定。
而 Docker 鏡像解決的，恰恰就是打包這個根本性的問題
就這樣，容器化的時代開始了！
k8s
那<code>Docker</code>和<code>k8s</code>又有什麼關系呢？
前面介紹，<code>Docker</code> 項目一日千裡的發展勢頭，但使用者們最終要部署的，還是他們的網站、服務、資料庫，甚至是雲計算業務。
這就意味着，隻有那些能夠為使用者提供平台層能力的工具，才會真正成為開發者們關心和願意付費的産品。而 <code>Docker</code> 項目這樣一個隻能用來建立和啟停容器的小工具，最終隻能充當這些平台項目的“幕後英雄”。
即要想<code>Docker</code>能大面積普及，還需要解決大量<code>Docker</code>的協作編排問題。
談到<code>Docker</code>容器編排問題，就不得不說說 <code>Docker</code> 公司的老朋友和老對手 <code>CoreOS</code> 了。<code>CoreOS</code> 是一個基礎設施領域創業公司。它的核心産品是一個定制化的作業系統，使用者可以按照分布式叢集的方式，管理所有安裝了這個作業系統的節點。進而，使用者在叢集裡部署和管理應用就像使用單機一樣友善了.
<code>Docker</code> 項目釋出後，<code>CoreOS</code> 公司很快就認識到可以把“容器”的概念無縫內建到自己的這套方案中，進而為使用者提供更高層次的 <code>PaaS</code> 能力。是以，<code>CoreOS</code> 很早就成了 <code>Docker</code> 項目的貢獻者，并在短時間内成為了 <code>Docker</code> 項目中第二重要的力量。
然而，這段短暫的蜜月期到 2014 年底就草草結束了。<code>CoreOS</code> 公司以強烈的措辭宣布與 <code>Docker</code> 公司停止合作，并直接推出了自己研制的 <code>Rocket</code>（後來叫 <code>rkt</code>）容器。
這次決裂的根本原因，正是源于 <code>Docker</code> 公司對 <code>Docker</code>項目定位的不滿足。<code>Docker</code> 公司解決這種不滿足的方法就是，讓 <code>Docker</code> 項目提供更多的平台層能力，即向 <code>PaaS</code> 項目進化。而這，顯然與 <code>CoreOS</code> 公司的核心産品和戰略發生了嚴重沖突。
大紅大紫不差錢的 <code>Docker</code> 開始大私收購來完善自己的生态和平台能力。最出名的莫過于 <code>Fig</code>項目，即現在的 <code>Compose</code>，除此外，還有 SocketPlane, Flocker, Tutum等項目。
<code>Docker</code>的異常繁榮終于引起了行業巨頭的關注。
作為 <code>Docker</code> 項目早期的重要貢獻者，<code>RedHat</code> 也是因為對 <code>Docker</code>公司平台化戰略不滿而憤憤退出。但此時，它竟隻剩下 <code>OpenShift</code> 這個跟 <code>Cloud Foundry</code> 同時代的經典 <code>PaaS</code> 一張牌可以打，跟 <code>Docker Swarm</code> 和轉型後的 <code>Mesos</code>完全不在同一個“競技水準”之上。
2014年6月，基礎設施領域的翹楚 <code>Google</code> 公司突然發力，正式宣告了一個名叫 <code>Kubernetes</code>項目的誕生。而這個項目，不僅挽救了當時的 <code>CoreOS</code> 和 <code>RedHat</code>，還如同當年 <code>Docker</code>項目的橫空出世一樣，再一次改變了整個容器市場的格局。
2015年6月22日，由 <code>Docker</code> 公司牽頭，<code>CoreOS</code>、<code>Google</code>、<code>RedHat</code>等公司共同宣布，<code>Docker</code>公司将 <code>Libcontainer</code> 捐出，并改名為<code>RunC</code> 項目，交由一個完全中立的基金會管理，然後以 <code>RunC</code> 為依據，大家共同制定一套容器和鏡像的标準和規範。
但由于 <code>OCI</code> 的成立更多的是這些容器玩家出于自身利益進行幹涉的一個妥協結果。是以<code>OCI</code>的組織效率一直很低下。
<code>Docker</code> 公司之是以不擔心 <code>OCI</code> 的威脅，原因就在于它的 <code>Docker</code> 項目是容器生态的事實标準，而它所維護的 <code>Docker</code> 社群也足夠龐大。可是，一旦這場鬥争被轉移到容器之上的平台層，或者說 <code>PaaS</code> 層，<code>Docker</code> 公司的競争優勢便立刻捉襟見肘了。
<code>Google</code>、<code>RedHat</code> 等開源基礎設施領域玩家們，為了牽制<code>Docker</code>，共同牽頭發起了一個名為 <code>CNCF（Cloud Native Computing Foundation）</code>的基金會。這個基金會的目的其實很容易了解：它希望，以 <code>Kubernetes</code> 項目為基礎，建立一個由開源基礎設施領域廠商主導的、按照獨立基金會方式營運的平台級社群，來對抗以 <code>Docker</code> 公司為核心的容器商業生态。
k8s早先在社群一直被認為太過前衛先進，但随着時間的發展，<code>GOOGLE</code>的工程能力也逐漸得到社群的認可。而沒有大規模驗證的 <code>swarm</code> 逐漸淡出人們視野。
2016 年，Docker 公司宣布了一個震驚所有人的計劃：放棄現有的 Swarm 項目，将容器編排和叢集管理功能全部内置到 Docker 項目當中。
到此，容器編排之争落下帷幕。
滾滾長江東逝水 浪花淘盡英雄 是非成敗轉頭空 青山依舊在 幾度夕陽紅