美國西部時間2月23号，docker舉辦了名為“containerd summit”的技術交流會議。邀請容器生态夥伴和containerd developer一起深度讨論containerd的設計、後續規劃以及和其他系統的內建。阿裡雲作為docker的戰略合作夥伴和containerd項目的初始成員，也受邀參加了此次會議。除阿裡雲外， aws、google、ibm等公司也都有參加。
随着容器技術的快速發展，生态逐漸地從圍繞單機環境建構和運作容器化應用，發展為支援大規模容器編排技術。雲平台成為了分布式網絡作業系統，而容器成為了“程序”執行單元。容器可以動态地運作在不同主控端環境之中。其中kubernetes, mesos, docker諸強争霸，各勝擅長。2016年6月，docker開始宣布在docker engine中内置swarm mode，極大簡化了容器編排的複雜性。但這也遭到了社群的強烈反彈。google發起cri（container runtime interface 容器運作時接口）項目，通過shim的抽象層使得排程架構支援不同的容器引擎實作。mesos推出了unified containerizer支援docker 、appc、oci等不同的鏡像格式，而無需docker engine。
面對這些挑戰，2016年12月14日，docker公司宣布将docker engine的核心元件containerd捐贈到一個新的開源社群獨立發展和營運，目标是提供一個标準化的容器runtime，注重簡單、 健壯性、可移植性。由于containerd隻包含容器管理最基本的能力，上層架構可以有更大的靈活性來提供容器的排程和編排能力。阿裡雲，aws， google，ibm和microsoft會作為containerd的初始成員，會為項目貢獻力量。
首先是docker公司的同學介紹了containerd的設計理念，新特性以及roadmap。
整個分享内容幹貨十足，涵蓋了containerd所有的子產品。細節不再一一贅述，簡單的總結下比較有趣的幾個點
當你用docker run image啟動容器的時候，docker會先檢查鏡像有沒有在本地，如果沒有，就從registry裡先把鏡像拉下來。拉鏡像的操作内置在docker daemon裡，對于大多數使用者來說，可以友善的使用docker指令就可以把鏡像從遠端docker registry裡下載下傳好。但是這種方式很不靈活，鏡像下載下傳邏輯内置在docker daemon裡，鏡像隻能存儲在docker registry裡，下載下傳過程嚴格遵循registry定義的api，下載下傳過程使用http/https。你可能希望以某些自定義的方式存儲鏡像，比如把鏡像的層加密之後再存儲，以免資料洩露造成安全風險，又或者希望使用諸如ftp、nfs的方式傳輸鏡像，而不是http，在docker都不支援。
containerd解耦了鏡像分發和使用。它能相容docker的鏡像分發機制，但是并不限制你使用其他方式。在containerd裡，你可以用自己的方式傳輸鏡像，隻要在最後把資料推給containerd就可以了。以前面的場景為例，你在nfs上儲存加密之後的鏡像，當你想用這些鏡像啟動容器的時候，隻需要先把nfs挂載到本地，然後執行
這是一個很簡單的指令，先把layer發給decrypt解密，最後送出給containerd。dist是containerd提供的鏡像管理工具。當然，上面的指令實際上隻處理了鏡像的一個層，用同樣的方式繼續處理鏡像的其他層。
docker的graph driver負責把多個鏡像層構造成一個完整的容器檔案系統。在containerd裡，用snapshot替代了原來的graph driver。snapshot設計上比graph driver更清晰簡單，适配新的檔案系統也更容易。目前已經支援overlay、btrfs，aufs不再支援。
使用docker啟動容器時，你可以選擇各種網絡模式：none、host、bridge、overlay，也可以是通過docker網絡插件自定義的網絡。在容器網絡方面，現在有兩套模型：docker的cnm（container network model）和k8s的cni（container network interface）。
containerd不明确定義網絡模型，不限制你用cnm還是cni還是其他的方式。在建立和啟動容器之間，你可以設定容器的namespace，利用oci hooks對namespace初始化。不需要寫插件，一個簡單shell腳本就夠了。
這些特性和containerd的定位有關：它面對的是上層的編排系統，而非直接使用者，是以更注重靈活性。對于普通使用者來說，使用docker足以滿足需求，更友善易用。
google的tim hockin分享了k8s cri（container runtime interface）設計。涵蓋了cri架構、接口設計、第三方內建等方面。其中提到了cri目前遇到的挑戰。
從功能上，隻有docker能完整支援k8s所有的功能，但是cri+docker的實作上有一些問題，一方面是層次太深了，整個請求棧從kubelet -> cri shim -> docker daemon -> containerd -> runc，另一方面docker裡有很多功能k8s根本用不到，比如volume，networking等，這些功能在k8s裡已經有了。是以containerd剛好解決了這些問題，完全滿足k8s需求。
然後ibm的phil estes分享了grpc的一些内容。
下午則是針對conatinerd的一些設計和要添加的新功能進行讨論。這場讨論給我的印象非常深刻，在場的很多都是業界知名的大牛，年紀很大的老前輩，但是都在認真的讨論containerd裡每個功能應該怎麼實作，怎麼設計接口才合理。這種對技術認真的追求和踏踏實實做技術的态度值得每一個程式員學習。
從這次會議能充分的感受到containerd作為未來開放的容器runtime标準，得到了廣泛的關注和支援。一方面containerd可以提供更加穩定和開放的容器runtime，另一方面允許上層編排系統靈活控制底層容器資源，滿足了不同容器技術供應商的訴求。容器生态再添一并利器，無論對容器開發者還是最終使用者，都是一件好事。
containerd計劃17年2q釋出，google已經計劃跟進并對k8s內建進行poc，計劃17年4q替換k8s底層相應實作。一個更輕量另外的容器管理引擎，能夠幫助編排系統更靈活的與底層的容器互動。
最後，猜猜這是誰？