極簡Docker和Kubernetes發展史
- 2019 年 10 月 3 日
- 筆記
2013年
Docker項目開源
2013年，以AWS及OpenStack，以Cloud Foundry為代表的開源Pass項目，成了雲計算領域的一股清流，pass提供了一種「應用託管」的能力。
當時的虛假機和雲計算已經是比較普遍的技術了，主流用法就是租一批AWS或者OpenStack的虛擬機，然後用腳本或者手工的方式在機器上部署應用
Cloud Foudry這樣的Pass項目，核心組件就是一套打包和分發機制，會調用作業系統的Cgroups和Namespace機制 為每個應用單獨創建「沙盒」的隔離環境，然後在「沙盒」中運行這些進程，實現了多用戶、批量、隔離運行的目的。
這個「沙盒」，就是所謂的容器。
這一年還叫dotCloud的Docker公司，也是Pass熱潮中的一員。只不過，比起Heroku、Pivotal、Red Hat等大佬，dotCloud公司顯得太微不足道，主打產品跟主流的CloudFoundry社區脫節，眼看就要陣亡的時候，dotCloud公司決定開源自己的容器項目Docker
「容器」其實不是什麼新鮮的東西，不是Docker發明的，當時最熱的Pass項目Cloud Foundry中，容器也只是最底層、最不受關注的一部分。
短短几個月，Docker就迅速崛起了，然後Cloud Foundry等所有Pass社區還沒來得及成為對手，就已經被淘汰了。
Docker項目大部分和Cloud Foundry容器大部分功能和實現原理是一樣的，但是不一樣的「Docker鏡像」，解決了環境打包的問題，直接打包了應用運行所需要的整個作業系統，賦予了本地環境和雲端環境調度一致的能力，避免了用戶通過「試錯」來匹配不同環境之間差異的痛苦過程， 這也是Docker的精髓。
Pass的定義變成了一套以Docker容器為技術核心，以Docker鏡像為打包標準的「容器化」思路
2013年年底，dotClound公司正式改名為Docker公司
2014年
Docker發布Docker Swarm
Docker發布Docker Swarn，以一個完整的整體來對外提供集群管理功能，最大的亮點就是完全使用Docker項目原來的容器管理API來完成集群管理。
docker run "容器"只需要變成
docker run -H "swarm集群API地址" "容器"用戶只需要使用原先的docker指令創建一個容器，這個請求就會被swarm攔截處理，通過具體的調度演算法找到一個適合的Docker Daemon。
這種方式對已經熟悉docker命令行的開發者們非常的友好。
Docker收購Fig，並改名Compose
Docker公司收購了Fig項目，後改名為（Compose）。
Fig項目在開發者面前第一次提出了「容器編排」（Container Orchestration）
在雲計算領域，「編排」主要指用戶如何通過某些工具或者配置來完成一組虛擬機以及關聯資源的定義、配置、創建、刪除等工作，然後由雲計算平台按照這些指定的邏輯來完成的過程
而容器時代，「編排」就是對Docker容器的一系列定義、配置和創建動作的管理。
Docker和Mesosphere公司的競爭
除了Docker生態外，Mesos和背後的創建公司Mesosphere也是一個非常大的熱力，Mesos是大數據最受歡迎的資源管理項目，跟Yarn項目競爭的實力派對手。
大數據關注的計算密集型離線業務，其實不像Web服務那樣適合用容器進行託管和擴容，也沒有應用打包的強烈需要，所以Hadoop、Spark等項目現在也沒在容器技術投入很大的精力，但是Mesos作為大數據套件之一，天生的兩層調度機制讓它非常容易從大數據領域獨立出來去支援更廣泛的Pass業務，所以Mesos公司發布了Marathon項目，成為了Docker Swarm的一個強有力的競爭對手。
雖然不能提供像Swarm那樣的Docker API，但是Mesos社區擁有一個非常大的競爭力：超大規模集群管理經驗
Mesos+Marathon組合進化成了一個調度成熟的Pass項目，同時能支援大數據業務，
Docker和CoreOS
CoreOS是一個基礎設施領域創業公司，核心產品是一個訂製化的作業系統，用戶可以按照分散式集群的方式，管理所有安裝了這個系統的節點，使用用戶在集群里部署應用像使用單機一樣方便
Docker項目發布後，Corecd很快認識到可以把容器的概念無逢集成到自己的這套方案中，從而為用戶提供更高層次的Pass能力，所以CoreOS很早就成了Docker項目的貢獻者，然而在2014年結束了合作，推出了自己的容器Rocket（rkt），然而這個rkt容器完全被Docker公司壓制了。
OCI標準制定
由CoreOS、Google、RatHat等公司共同宣布，Docker公司將Libcontainer（容器運行時庫）捐出，並改名為RunC項目，交由一個完全中立的基金會管理，以RunC為依據共同制定一套容器和鏡像的標準規範
，叫OCI（Open Container Initiative），意在將容器運行時和鏡像的實現從Docker項目中完全剝離出來，以此來壓制Docker公司一家獨大的現狀，同時也為不依賴Docker項目構建平台層能力提供了可能。
不過並沒有改變Docker在容器領域一家獨大的現狀
Kubernetes誕生
2014年6月，基礎設施領域的領先者Google發，正式宣告了Kubernetes項目的誕生（Borg的開源版本），如同Docker橫空出世一樣，再一次改變了容器市場的格局。
微軟、RedHat、IBM、Docker加入Kubernetes社區
2015年
CNCF基金會成立
為了在容器編排地位取得絕對的優勢，同Swarm和Mesos競爭，Google、RedHat等開源基礎設施公司，共同發起了一個名為CNCF的基金會：希望以Kubernetes為基礎，建立一個由開源基礎設施領域廠商主導、按照獨立基礎會方式運營的平台社區，來對抗以Docker公司為核心的容器商業生態。簡單的說就是打造一個圍繞Kubernetes項目的「護城河」。
Docker擅長Docker生態的無縫集成，Mesos擅長大規模集群的調度與管理，Kubernetest選擇了Pod、Sidecar等功能和模式作為切入點（大多來自Borg和Omega系統的內部特性）。
Kubernetes的團隊規模很少，投入的工程能力有限，RedHat在這時候和Google聯盟，正式開戶了容器編排「三國鼎立」的書面。
Kubernetes來自Google公司在容器化基礎設施領域多年來實踐經驗的沉澱和升華，在Github上的各項指標一路飆升，將Swarm項目遠遠地甩在了後邊。
同年，Kubernetes發布Helm軟體包管理系統、kubeam安裝工具、發布Mikibube等一列更新操作
CNCF社區迅速增加了Prometheus、Fluentd、OpenTracing、CNI等一系列容器生態的知名工具和項目
大量的公司和創建團隊將注意力投向CNCF社區而不再是Docker公司
2016年
Docker公司放棄現有的Swarm項目，將容器編排和集群管理功能內置到Docker中
面對CNCF的競爭優勢，Docker公司宣布放棄現有的Swarm項目，將容器編排和集群管理功能內轉到Docker項目當中。
然而這種改變帶來的技術複雜度和維護難度，給Docker項目造成了非常不利的書面
Kuberntes支援OpenApi，給開發人員訂製化提供更大的靈活性
不同於Docker公司，Kubernetes推進「民主化」架構：從API到容器運行的每一層，都給開發者暴露出了可擴展的插件機制，鼓勵用戶通過程式碼的方式介入每一個階段。
Kubernetes項目的這個變革非常有效，很快在整個容器社區中催生出了大量的、基於Kubernetes API和擴展介面的二次創新產品：
- 熱度極高的Istio微服務治理工具
- 應用部署框架Operator
- Rook開源創業項目，把Ceph重量級產品封裝成了簡單易用的容器存儲插件
Docker公司在Kubernetes社區的崛起和壯大後，敗下陣來。
2017年
Docker將Containerd捐獻給CNCF社區
Docker公司將容器運行時部分Containerd捐獻給CNCF社區，標誌著Docker項目你下面升級成為了一個Pass平台，Docker公司宣布將Docker項目改名為Moby，交給社區自行維護，而Docker公司的商業產品還佔有Docker這個註冊商標。
同年10月，Docker宣布將在自己主打產品Docker企業版中內置Kubernetes項目，持續了兩年的容器編排之爭終於落下帷幕
2018年
RatHat宣布2.5億美元收購CoreOS
Docker公司CTO Solomon Hykes宣布辭職，容器技術圈子從此塵埃落定
