目錄
容器技術發展史
Jail時代
1979年貝爾實驗室發明chroot
2000年FreeBSD 4.0發行FreeBSD Jail
2001年Linux VServer發行
2004年Solaris Containers發行
云時代
2006年google推出Process Containers
2008年LXC推出
2011年CloudFoundry推出Warden
2013年LMCTFY啟動
2013年Docker推出到風靡全球
云原生時代
Google &Docker競爭
2013年CoreOS發布和Docker由合作終止
2014年6月Google發布開源的容器編排引擎Kubernetes（K8S）
2014年12月CoreOS發布開源容器引擎Rocket(rkt)
2015年Docker推出容器集群編排組件Swarm
2015年6月Docker成立OCI
2015年7月Google帶頭成立CNCF
k8s成為云原生事實標準
2016年發布CRI標準
2016年Docker捐獻containerd
2016年CRI-O發布
2017年containerd確定作為標準CRI
編排與容器的技術演進之路
DockerClient
RUNC&Shim
CRI-Containerd
CRI-O
Containerd
實際生產的集群采用的什么運行時組件？
容器技術發展史
Jail時代
容器不是一個新概念或者新技術，很早就有了，只是近幾年遇到了云計算，整個技術被徹底引爆了。
1979年貝爾實驗室發明chroot
chroot 系統調用是在1979 年開發第7 版Unix期間引入的。貝爾實驗室在Unix V7 的開發過程中，發現當一個系統軟件編譯和安裝完成后，整個測試環境的變量就會發生改變，下一次測試需要重新配置環境信息。
設計者們思考能否隔離出來一個獨立的環境，來構建和搭建測試環境，所以發明了chroot，可以把一個進程的文件系統隔離起來。
chroot系統調用可以將進程及其子進程的根目錄更改為文件系統中的新位置。隔離以后，該進程無法訪問到外面的文件，因此這個被隔離出來的新環境像監獄一樣，被命名為Chroot Jail （監獄）。后續測試只需要把測試信息放到Jail中就可以完成測試了。
這一進步是進程隔離的開始：為每個進程隔離文件訪問。所以chroot可以認為是容器技術的鼻祖。
2000年FreeBSD 4.0發行FreeBSD Jail
2000 年，當時一家小型共享環境托管提供商提出了FreeBSD Jail，以實現其服務與其客戶服務之間的明確分離，以實現安全性和易于管理。每個Jail都是一個在主機上運行的虛擬環境，有自己的文件、進程、用戶和超級用戶帳戶,能夠為每個系統分配一個IP 地址。
FreeBSD Jail不僅僅有chroot的文件系統隔離，并且擴充了獨立的進程和網絡空間。
2001年Linux VServer發行
與FreeBSD Jails 一樣，Linux VServer是一種監獄機制，可以對計算機系統上的資源（文件系統、網絡地址、內存）進行分區。
2004年Solaris Containers發行
2004 年， Solaris Containers的第一個公開測試版發布，結合系統資源控制和區域進行隔離，并添加了快照和克隆能力。
這個時期的進程隔離技術大多以Jail模式為核心，基本實現了進程相關資源的隔離操作，沒有更大的應用場景發展有限。
云時代
云時代即云計算時代，其核心是通過互聯網提供計算資源和服務，用戶可按需使用并支付費用，無需自行建設和維護硬件設施。這一時代的標志是IaaS、PaaS、SaaS等云服務模式的普及，例如企業通過AWS、Azure等平臺租用服務器，或使用Salesforce等在線軟件服務。云時代的本質是計算資源的抽象化與集中管理，用戶無需關注底層硬件，只需通過互聯網獲取資源。
隨著互聯網的蓬勃發展，業務規模也在不斷擴大，我們會更多考慮如果出現比現在多1000倍, 10000倍的數據量的情況，我們該如何處理?如果還想以前一樣原子化的根據業務購置機器進行部署，對于很多企業來說維護并不方便，同時這種原子化的配置也不能很好的將資源利用起來。
2006年，Google 101 計劃提出云的概念，對當前的主流開發模式產生深遠的影響。隨后，亞馬遜、IBM 等行業巨頭也陸續宣布各自的“云”計劃，宣告“云”技術時代的來臨。
云（通常指云計算）是一種基于互聯網的計算方式，它通過將計算資源、存儲資源、軟件服務等集中管理和調度，以按需、易擴展的方式為眾多用戶和應用程序提供服務。云通過硬件資源虛擬化、資源池化等技術將算力資源變的像水、電一樣可以進行按需交易，企業可以可以根據業務靈活申請對應量的算力資源，并且利用提供的服務，對算力資源進行統一管理。
要想讓”云”發揮潛能，與此相關的編程和操作就應該與使用互聯網一樣簡單。此外云計算需要處理海量數據、超高并發、快速擴展等問題，因為資源池化，還需要面對不同業務不同環境不會相互干擾，所以此時云不僅僅需要隔離還需要能夠對資源進行控制和調配。
2006年google推出Process Containers
Process Containers（由Google 于2006 年推出）旨在限制、統計和隔離一組進程的資源使用（CPU、內存、磁盤I/O、網絡）。一年后它更名為“Control Groups (cgroups)”，并最終合并到Linux 內核2.6.24。
2008年LXC推出
LXC（Linux 容器）是Linux 容器管理器的第一個、最完整的實現。它是在2008 年使用cgroups 和Linux 命名空間實現的，它可以在單個Linux 內核上運行，不需要任何補丁。
同年谷歌推出GAE（Google App Engine），首次把開發平臺當做一種服務來提供，采用云計算技術，跨越多個服務器和數據中心來虛擬化應用程序。
同時Google在GAE中使用了Borg （Kubernetes的前身）來對容器進行編排和調度。LXC和Borg其實就相當于最早的docker和k8s.
2011年CloudFoundry推出Warden
2011 年啟動了Warden，早期使用LXC，后來替換為自己的實現,直接對Cgroups以及Linux Namespace操作。開發了一個客戶端-服務器模型來管理跨多個主機的容器集合，并且可以管理cgroups、命名空間和進程生命周期。
2013年LMCTFY啟動
Let Me Contain That For You (LMCTFY) 于2013 年作為Google 容器堆棧的開源版本啟動，提供Linux 應用程序容器。應用程序可以“容器感知”，創建和管理它們自己的子容器。在谷歌開始和docker合作，后續轉向了docker公司的libcontainer，LMCTFY 的于2015 年停止。
2013年Docker推出到風靡全球
Docker最初是一個叫做dotCloud的PaaS服務公司的內部項目，后來該公司改名為Docker。Docker在初期與Warden類似，使用的也是LXC，之后才開始采用自己開發的libcontainer來替代LXC，它是將應用程序及其依賴打包到幾乎可以在任何服務器上運行的容器的工具。與其他只做容器的項目不同的是，Docker引入了一整套管理容器的生態系統，這包括高效、分層的容器鏡像模型、全局和本地的容器注冊庫、清晰的REST API、命令行等等。
Docker為提供了一整套的解決方案，不僅解決了容器化問題，而且解決了分發問題，很快被各大廠商選擇變成了云基礎設施，廠商圍繞Docker也開始了生態建設。
云原生時代
云原生時代則是云計算發展的高級階段，其核心是為云環境設計應用程序和架構，以充分利用云的彈性、可擴展性和自動化能力。云原生技術包括容器化（如Docker）、微服務架構、服務網格（如Istio）、不可變基礎設施和聲明式API等，代表工具如Kubernetes。云原生應用強調快速迭代、持續集成/交付（CI/CD）、自動化運維和彈性伸縮，例如電商平臺在促銷時自動擴展服務器資源，或通過微服務架構實現獨立部署和故障隔離。
Google &Docker競爭
2013年CoreOS發布和Docker由合作終止
技術革命帶來新的市場機遇，CoreOS也是其中的一員，在容器生態圈中貼有標簽：專為容器設計的操作系統CoreOS，作為互補，CoreOS+Docker曾經也是容器部署的靈魂伴侶。CoreOS為Docker的推廣和源碼社區都做出了巨大的貢獻。
Docker生態擴張，與最開始是“一個簡單的基礎單元”不同，Docker也在通過開發或收購逐步完善容器云平臺的各種組件，準備打造自己的生態圈，而這與CoreOS的布局有直接競爭關系。
2014年6月Google發布開源的容器編排引擎Kubernetes（K8S）
容器只是解決了容器化，分發問題，但是一個軟件的網絡問題、負載均衡問題、監控、部署、更新、鏡像管理、發布等很多問題并沒有有效的解決。
Google內部調度系統Borg已經擁有10多年的使用容器經驗，在2014年6月推出了開源的K8S,可以支持對容器的編排和管理，完成生態的閉環。
同年7月，微軟、Red Hat、IBM、Docker、CoreOS、Mesosphere和Saltstack 等公司，相繼加入K8S。之后的一年內，VMware、HP、Intel等公司，也陸續加入。
2014年12月CoreOS發布開源容器引擎Rocket(rkt)
2014年底，CoreOS正式發布了CoreOS的開源容器引擎Rocket（簡稱rkt），和Docker正式分開發展。Google于2015年4月領投CoreOS 1200萬美元，而CoreOS也發布了Tectonic，成為首個支持企業版本kubernetes的公司。從此，容器江湖分為兩大陣營，Google派系和Docker派系。
2015年Docker推出容器集群編排組件Swarm
在Docker 1.12 及更高版本中，Swarm 模式與Docker 引擎集成,為Docker 容器提供原生集群管理功能。
兩大派系的競爭愈演愈烈，行業標準的訴求越來越強烈。
2015年6月Docker成立OCI
Docker公司在容器運行因為高速迭代導致變更頻繁，影響較大。
2015 年6 月22 日，由Docker 公司牽頭，CoreOS、Google、RedHat 等公司共同宣布，Docker 公司將Libcontainer 捐出，并改名為RunC 項目，交由一個完全中立的基金會管理，然后以RunC 為依據，大家共同制定一套容器和鏡像的標準和規范。RUNC的本質就是可以不通過Docker Damon直接運行容器。
規范就是OCI，旨在“制定并維護容器鏡像格式和容器運行時的正式規范（OCI Specifications）”。其核心產出是OCI Runtime Spec（容器運行時規范）、OCI Image Spec（鏡像格式規范）、OCI Distribution Spec（鏡像分發規范）。所以OCI 組織解決的是容器的構建、分發和運行問題。
社區們期望通過標準來約束Docker公司的話語權，不過Docker公司并沒有積極推動OCI的發展，而且OCI也無法影響Docker的地位，因為Docker已經是事實的容器標準。
Google和RedHat等公司將方向調轉到容器上面的平臺層。
2015年7月Google帶頭成立CNCF
Google聯合Linux 基金會成立CNCF （Cloud Native Computing Foundation）云原生計算基金會。旨在構建云原生基礎設施。K8S是第一個納入進來的項目，像后續有名的監控設施Prometheus，配置設施ETCD都加入進來。CNCF 組織解決的是應用管理及容器編排問題。和OCI共同制定了一系列行業事實標準。
k8s成為云原生事實標準
2016年發布CRI標準
Google就和紅帽主導了CRI標準，用于k8s和特定的容器運行時解耦。CRI(Container Runtime Interface容器運行時接口)本質上就是k8s定義的一組與容器運行時進行交互的接口，所以只要實現了這套接口的容器運行時都可以對接k8s。
但是這個時候Docker還是事實標準，并CRI并沒有話語權，但是又必須支持Docker，所以就有了dockershim,dockershim的本質其實就是k8s對接docker的一個CRI的實現。
2016年Docker捐獻containerd
containerd作為運行時標準，Docker將其從Docker Engine中剝離出來，捐獻給CNCF.這個時候Google為了將containerd加入到cri標準中，又開發了cri-containerd，用來完成k8s和容器之間的交互。
2016年CRI-O發布
CRI-O可以讓開發者直接從Kubernetes來運行容器，這意味著Kubernetes可以不依賴于傳統的容器引擎（比如Docker），也能夠管理容器化工作負載。這促使容器回歸到自己的位置，如何更好的封裝云原生的程序。
在2016年，Docker公司宣布了一個震驚全部人的計劃：放棄現有的Swarm項目，將容器編排和集群管理功能所有內置到Docker項目中。
而Kubernetes的應對策略則是反其道而行之，開始在整個社區推動“民主化”架構，從API到容器運行時的每一層，Kubernetes項目都為開發者暴露出了能夠擴展的插件機制，鼓勵用戶經過代碼的方式介入到Kubernetes項目的每個階段。
在進入2017年之后，更多的廠商愿意把寶壓在K8S上，投入到K8S相關生態的建設中來。這兩年包括阿里云、騰訊、百度等中國科技企業也陸續加入CNCF，全面擁抱容器技術與云原生。
Swarm 的失敗后, 社區版Docker 項目改名為moby，將Docker引流到Docker的企業版上去，螳臂擋車。
2017年containerd確定作為標準CRI
2017年各大廠商都開始擁抱Kubernetes，亞馬遜AWS，Microsoft Azure，VMware，有的甚至拋棄了自家的產品。
亞馬遜網絡服務（AWS）于八月份以白金會員（最高級別）加入了CNCF。
VMware都作為CNCF的白金會員注冊.
Docker Inc.ocker企業版框架中添加了本地Kubernetes支持。Docker自己的Swarm技術也借鑒了k8s的技術進一步發展。
至此Kubernetes 已成了容器編排領域的絕對標準， 而Docker 已成容器事實的標準。
編排與容器的技術演進之路
DockerClient
此時K8s只是編排領域的一個選擇，而Docker此時一家獨大，所以K8s的客戶端只是作為Docker的客戶端來調用Docker 引擎來完成服務。
RUNC&Shim
OCI催生runc，剝離Docker Engine的一家獨大的情況，確保各個廠商都可以搭建自己的容器平臺。CRI標準確立了但是Docker并沒有接入該標準。此時催生了臨時技術shim.
CRI-Containerd
containerd被捐獻出來，谷歌開發cri-containerd接入CRI標準。
CRI-O
k8s已經成為事實的編排標準，促使容器回歸云原生本質。
Containerd
containerd實現CRI，成為CRI的事實標準.
實際生產的集群采用的什么運行時組件？
以騰訊的TKE（騰訊商用K8S產品)為例，支持選擇containerd和docker兩種模式的選擇。
如何選擇呢？
（1）Containerd 調用鏈更短，組件更少，更穩定，占用節點資源更少。建議選擇Containerd。
（2）以下情況還是要用docker
?使用 docker build/push/save/load 等命令。
?調用 docker API
?需要 docker compose 或docker swarm。
 和 View#callOnClick() 的差異)
