容器社群最新進展
Moby(Docker)社群
Docker在17年4月的時候推出了名為Moby專案,Moby著眼於“一個將元件裝配成定製化基於容器的系統的框架和一個所有容器發燒友試驗與交流想法的場所”,它內部除了Docker 容器引擎外，還孵化了多個專案：Moby,buildkit，Datakit，HyperKit，VpnKit。Docker對Moby的玩法，就是從Moby中抽取Docker版本，然後將其他孵化專案中比較成熟的部分納入到Docker裡。其中BuildKit就是一個成功孵化並進入Docker的例子。
釋出Moby之後Docker-ce（docker的開源版本）釋出採用兩種方式，Stable版本和edge版本。Stable版本顧名思義為穩定版本，而兩次Stable版本之間一月發一次Edge版本，一般的商用選擇都是Stable版本。
截止到18年上半年之前，Docker版本的釋出採用3個月左右為週期進行釋出。這樣導致了上游社群特別是K8s社群對接上的麻煩，為了減少Docker使用者頻繁的更新版本， Docker在18年Q4調整了版本釋出計劃，從Docker 18.09開始，Docker版本保證6個月左右的版本維護期，中間不再發布Edge版本 ，下一個版本是Docker-CE 19.03
Moby社群在過去的18年釋出瞭如下Docker-ce stable版本：
| 版本 | 釋出時間 | 重大變更 |
|---|---|---|
| Docker 17.12.1 | 18年2月 | 採用GOLANG1.9.4編譯，containerd 切換為1.0.1 |
| Docker 18.03.0 | 18年3月 | 修正大量BUG |
| Docker 18.03.1 | 18年5月 | GOLANG採用1.9.5，containerd 升級到1.0.3 |
| Docker 18.06.0 | 18年7月 | containerd 1.1.1,引入實驗性質的映象構建後端buildkit工具 |
| Docker 18.06.1 | 18年8月 | contaienrd 1.1.2 |
| Docker 18.09.0 | 18年11月 | containerd 1.2.0rc1,Buildkit可以已非實驗性質執行，加入local log驅動 |
Docker（Moby）近期最大的變化實際發生在17年11月的Docker-ce 17.11，對應的Stable版本為18年2月出現的Docker-ce 17.12 在這兩個版本中Docker使用的Containerd從Containerd0.2.x一躍升級為Containerd 1.x。 Containerd 0.2.x和Containerd1.x之間API級不相容，且架構發生重大變更
。由此引發了Docker-ce架構的巨大變更。這是Docker社群在17年底到18年發生的重大的變更項。
2014 年開始，Docker 和 Microsoft 便積極展開合作，在 2016 年，先讓 Windows Server 整合了 Docker 引擎。到 2017 年，整合了 Windows 容器，讓 Docker 能一次通吃 Linux、Windows 容器叢集。 在18年1月份，釋出了Docker Desktop 的Deta版本，在其上在可以部署kubernete叢集了 ，在Docker con舊金山大會上， Docker公司正式對外展示了Docker Desktop-Windows部署kubernete叢集 。
我們可以看到在18年度，Moby社群有大量Microsoft貢獻者在活躍，在18年的所有Docker釋出版本中可以看到大量Windows容器的特性和Bug修正。
其中最大的突破出現在18年，Docker Desktop和Docker-ce原本就是兩個獨立的產品。但是在Docker-ce18.09之前Docker Desktop採用Docker-CE的版本號，例如18年8月推出了18.06.1-ce-win73 。 但是在Docker-ce 18.09時刻，Docker Desktop正式採用了自己獨立的版本為2.0.0.0;其中引擎部分還是採用的Docker-ce 18.09
Containerd社群
Containerd是Docker從16年12月推出的一個子專案，它將Docker引擎中的containerd捐獻到社群中，由此出現了一個Containerd社群。Containerd的目標是開發遵循OCI規範的商用環境容器執行時。
containerd並不是直接面向終端使用者的，而是設計為被用於整合到更上層的系統裡，如Swarm， Kubernetes， Mesos等容器編排系統。它利用已有的runtime，對容器生命期管理、容器映象和容器儲存上做出更多工作；而容器網路和編排交給了Docker引擎、Kubernetes等編排系統。
Containerd社群在18年發生的大事件有：
-
18年7月釋出Containerd1.1.2正式將CRI-containerd以外掛形式cri-plugion整合到了Containerd中。理論上來說，從此刻開始Containerd就可以獨立支援Kubelete CRI了。
-
18年9月Containerd1.2.rc0出現，它實現為支援VM型別的容器，提供了shimv2抽象。而Containerd 1.2在19年1月15日才正式釋出。Containerd 1.2的出現標誌著Containerd對VM容器（Kata容器，runV容器）的支援上了一個新臺階。
Containerd的釋出時就定位成容器編排工具的底層執行時，也就意味著Containerd可以被多種編排工具呼叫，一同提供容器服務。現階段有Docker，阿里的Pouch這兩個容器引擎使用Containerd作為自己的執行時。Kubernete從1.7開始使用cri-containerd的方式支援kubelete使用containerd；而Kubelete 1.10以上的版本就支援了直調containerd（通過containerd的cri-plugin）。在Kubelete直接使用containerd商用嘗試上，谷歌走在了前列。 在18年11月，它在自家公有云下kubenete服務GKE 1.1上宣佈提供beta方式的支援kubelete直調containerd 。
rkt社群
rkt（Rocket）是由前coreOS公司在14年底推出的容器引擎，rkt推出的初衷是因為當時Docker引入了Docker swarm編排工具，向著Docker平臺化的方向大步前行。coreOS認為Docker的設計理念偏離。所喲coreOS推出了自己的容器引擎Rocket（在15年更名為rkt）。rkt的設計目標就是純粹的容器引擎，它不提供容器平臺，不提供容器的編排。rkt從14年底推出0.0.0到18年4月11日推出最後一個版本1.30一共推出了46個版本。 在rkt的github社群上列出了幾個商用客戶 ，由於不知所以本文就不再列出。
rtk和kubenete的整合出現在kubenete1.3版本，也就是因為rkt這一類容器的出現才促使kubenete社群在16年底kubenete1.5時刻推出的自己容器執行時標準介面CRI。在17年kubenete社群孵化了rkt的cri介面層rktlet，至今為止它只在17年11月推出了一個版本0.1.0。 這個版本只通過了部分kubenete 1.9 e2e測試用例 。
rkt和rktlet社群都以coreOS公司為主導。 18年發生了一個大事件，導致了rkt實際死亡，那就是18年1月紅帽收購了coreOS 。由於紅帽早已大力主推自己的容器執行時專案CRI-O，所以rkt專案的實際運作在18年4月份中止了，rkt和rktlet的最後更新都停止在了18年4月。可以認為紅帽將coreOS rkt資源投入到了CRI-O中。
gvisor社群
在18年5月，谷歌推出了一種全新的沙盒式容器執行時gvisor。gvisor它是一個支援OCI規範的容器執行時。它能夠為容器提供更安全的隔離，同時比VM更輕量。gvisor的設計者認為現在的容器使用了使用者態隔離而核心卻是共用的，雖然使用seccomp，selinux和Appamor在控制了潛在的安全風險。但是傳統容器中惡意應用依然存在逃逸的可能性。針對這樣的安全風險，VM容器可以實現基於虛擬化層的強隔離；但是VM容器也引入了不小的虛擬化層開銷——更多的cpu、記憶體消耗。而gvisor使用了類似於使用者態Linux的方式，在核心和容器之間引入的新的linux系統呼叫隔離層將所有的容器內部發起的系統呼叫進行 截擊並重新實現 。
gvisor架構圖
gvisor現在由兩種系統呼叫截擊方案：
- ptrace方案
- kvm方案
ptrace方案可以應用於任何宿主機包括雲主機環境上，它採用ptrace方式，在容器內部應用發起系統呼叫的時刻將應用跳轉到自己實現的系統呼叫程式碼中。ptrace模式的工作模式類似於使用gdb除錯使用者態程序的方式。此外gvisor還支援kvm方式，在 KVM 模式下，gVisor 能夠截獲應用程式的每個系統呼叫，並將其轉交給 gvisor自己實現的系統呼叫層進行處理。相比較 VM，我們看不到 Qemu 的身影，也看不到 Guest Kernel，gvisor自己實現的系統呼叫層包攬了所有必要的操作。這種對虛擬化的實現方法，我們稱之為“程序級虛擬化”。gvisor只實現了部分的系統呼叫：實現了 200 個左右的系統呼叫，而 Linux Kernel 則為 X86_64 提供了 318 個系統呼叫。所以現在部分軟體還不支援gvisor，例如postgel。而且現階段gvisor實現的部分系統呼叫依然依賴於宿主機上的核心系統呼叫。
對於容器網路，gvisor實現了使用者態網路協議棧。其整個資料流跟原生容器一樣，唯一區別在於 gVisor 需要捕獲到安全容器內應用程式關於網路的系統呼叫。例如, listen/accept/sendmsg 等等。之後再將其轉換成 host 的系統呼叫來進行網路通訊。
對於檔案訪問，gvisor實現了自己的vfs層。其上實現了實現具體的檔案系統。有 9p，tmpfs，procfs，sysfs 。真正的檔案訪問使用9pfs檔案系統訪問到宿主機上的檔案。
gvisor作為容器執行時，它實際上和Docker世界的RunC是同層次的。 gvisor目前支援替換runC作為Docker容器的執行時 。Kubenete使用gvisor有兩種方式，第一種方式是在Minikube裡使用gvisor容器；另外一種方式是使用kubelete對接Containerd，配置Containerd使用gvisor-containerd-shim，那麼所有帶特定標記的容器都會以gvisor方式建立。
截止到18年9月社群上kubenete +docker+gvisor這條路依然沒有走通。
目前來看gvisor成熟尚需時日，未見任何商用用例。
CRI-O社群
CRI-O（其O代表OCI），前身是OCID——OCI Daemon，它的誕生源於2016年夏天谷歌的K8s工程師和Docker CTO在社交媒體上的一起大論戰。這場大論戰背後是Docker在16年7月推出的Docker 1.12將Swarm整合到了Docker引擎內部，這無疑是動了K8s的蛋糕，所以雙發終於在16年夏天擦槍走火。這場大論戰的詳細過程本文不去回顧，感興趣者可以參考 《容器，你還只用Docker嗎？》 。但是這場大論戰的直接後果就是在谷歌的推動下K8s社群推出的了OCID專案，也就是現在的CRI-O專案。CRI-O在社群中有非常強有力的推動力量——谷歌和紅帽（紅帽因為Systemd和Docker之間也存在罅隙），而IBM，SUSE，Intel，Hyper等公司也是CRI-O的contributor。
CRI-O認為大多數的使用者只是使用k8s的容器，而並不關注其容器執行時到底是Docker、rkt還是別的什麼。CRI-O 設計目標就是為OCI相容的容器runtime實現了一個K8s CRI介面層。目前CRI-O支援兩種runtime：RunC和Kata。CRI-O是一個非常輕量的工具集，它使用runtime去管理容器的生命期，使用CNI外掛建立容器網路，使用 container/storage 來管理容器的rootfs，使用 container/image 來管理容器映象，使用conmon來監控容器的執行。container/storage目前支援overlayfs、devicemapper、AUFS和btrfs，Overlayfs作為預設的儲存驅動。目前計劃支援網路檔案系統nfs,ceph和Glusterfs。container/image支援從映象倉庫中pull映象，支援Dokcer V1和V2兩個版本的映象。
原本CRI-O的設計初衷是為了對接Kubenete，並不是直接對接終端客戶可以不提供類似於Docker cli一樣的命令列。但是為了除錯目的，CRI-O推薦使用：crictl除錯CRI-O容器引擎，podman工具管理kubenete Pod，buildah構建、推送映象為映象簽名，skopeo拷貝、刪除、檢視和簽名映象。
CRI-O的架構
CRI-O是目前容器社群中除了Docker外，商用程序最快的、最廣泛應用的容器引擎。紅帽為CRI-O投入了大量的資源，包含了收購CoreOS後獲得RKT的資源都投入到CRI-O中。CRI-O在17年推出了1.0版本，它對應的Kubenete版本是1.7.x。CRI-O 1.10與Kubenete 1.10相容，CRI 1.11與kubenete 1.11相容，CRI-O 1.12與Kubenete1.12相容，CRI-O
1.13與kubenete1.13相容。總之CRI-O與kubenete在版本號一致時，保持相容性。CRI-O在18年度商用程序突然加速，紅帽的kubenete發行版本openshift3.9 中將CRI-O標記為GA，在18年8月Redhat宣佈在自己的雲服務Openshift Online starter 裡執行openshift 3.11使用CRI-O作為容器執行時。 而在即將推出的openshift4.x中，在RedHat Enterprise Linux和RHCOS(Redhat CoreOS )平臺上，將正式將CRI-O作為預設的容器執行時（雖然此版本依然可以使用Docker） 。在已經發布的Redhat Enterprise Linux 8 beta中，除了CRI-O外還包含了前文中介紹的Podman，Buildah和Skopeo，通過這些工具在紅帽8上，使用者可以獲得和Docker一樣的容器操作使用者體驗。這無疑是整個容器社群非Docker容器最大的商用進展。
容器社群18年度大事記
18年度容器社群大事記1
18年度容器社群大事記2
總結
- rtk在18年度死亡
- containerd在18年度從谷歌走向試商用
- cri-o 18在紅帽openshift上完成試商用，在redhat8上將正式商用化
- docker社群變化不大
- gvisor處於萌芽期