以Docker爲表明的傳統容器到了生死存亡之際

　　雲原生是一座由精妙理論所構築的摩天大廈，但其中的磚石還需加固。
　　當雲原生將容器技術做爲下一代雲計算的基礎之一時，並不意味着容器自己中止了演化。事實上，以 Docker 爲表明的傳統容器在遇到多租戶場景時，它的安全問題馬上暴露了出來，這時，人們才懷念起虛擬化的好處。
　　因而，採用虛擬化技術的「安全容器」這一律念應運而生，而開啓這一變革的，正是 Kata Containers，前不久，它剛剛度過兩週年。
　　新的 Kata Containers 爲咱們帶來虛擬機的安全性和隔離性、與容器兼容的 API 接口，同時還有與容器同一級別的性能，這意味着採用安全容器的時機已經成熟。
　　與此相對的是，上個月，Docker 的企業級業務被打包出售，據稱出售價格甚至不及幾輪下來的融資總額。
　　全部在生產環境使用容器的公司，從如今開始都有必要審視本身的安全策略，並制定從容器到安全容器的遷移計劃。
　　這一切是怎麼發生的呢？聽我爲你一一道來。
　　<strong>Docker 的潰敗</strong>
　　2019 年 11 月 13 日，私有云基礎設施公司 Mirantis 在其官方博客宣佈，收購 Docker 公司企業級業務，包括接管它的 700 多個客戶，這標誌着 Docker 公司從 2013 年開始的商業化探索完全失敗。
　　在不瞭解容器發展歷史的人看來，這種結果很難理解，Docker 是容器熱潮的開創者，容器則是這一輪雲計算技術演進的開啓者，爲何明明站在風口上了，卻仍然飛不起來？
　　這與 Docker 創始人的一系列迷之操做當然脫不了干係，但其實，Docker 今天的命運，在 4 年前就決定了。
　　在 2013 年之前，業界其實一直都沒有找到雲計算原生的打開方式，GAE 以及 Cloud Foundry 早期版本爲表明的 PaaS 將你們都帶到坑裏，只留下一地雞毛。直到 Docker 開源，你們才如夢方醒，原來不是方向不對，而是應用分發和交付的手段不行。
　　然而，Docker 公司將其核心代碼開源的初心並不僅是造福業界，它是想用這種方式吸引商業客戶。Docker 公司將 Docker 註冊爲商標，引發了社區的警覺，各類自創容器項目層出不窮。
　　爲告終束這種亂象，2015 年 6 月，容器開放推動組織 OCI 成立，旨在圍繞容器格式和運行時制定一個開放的標準，Docker 做爲創始成員，意圖將這個標準制定權抓在手裏。
　　然而，你們實在是被 Docker 在商業化和社區兩邊左右搖擺的態度嚇怕了，2014 年 Kubernetes 發佈後，迅速吸引了包括紅帽在內的一批成員，並在短短一年以後的 2015 年 7 月，Kubernetes 發佈了 1.0 版本，隨之而來的還有 CNCF 雲原生計算基金會。
　　CNCF 的誕生宣告雲計算技術演進的重心從容器轉移到容器編排，隨後的 2016 年，Kubernetes 發佈了容器運行時接口 CRI，只要符合這個接口，Kubernetes 就能夠經過它來運行容器，是否是 Docker 已經可有可無了。
　　就這樣，容器從 Docker 變成了一種標準接口實現，只要符合這個標準，不用管背後運行的是什麼。
　　結合容器和 Kubernetes，你們在本身的集羣上用得很愉快，但當雲廠商試圖向大衆提供容器服務時，多租戶安全問題出現了。
　　<strong>AWS 的選擇</strong>
　　要理解這個問題，咱們首先要了解容器的原理。
　　Linux 容器的本質是一種進程隔離技術，經過 cgroup 和 namespace，容器裏的應用只使用給定的資源，不一樣容器之間互不侵犯。
　　從容器裏應用的角度來看，它只能看到給定的計算存儲資源和爲其定製的系統，但從容器外面的系統來看，它運行的是一個一個的進程。
　　若是這些容器都屬於同一個用戶那還沒什麼，但若是是雲服務，一臺機器裏面運行着不一樣用戶的一個個進程，光是想想就有一種四處漏風的感受！
　　從技術角度講，AWS 在它的官方博客中是這麼描述這個安全隱患的：
　　因爲操做系統內核漏洞，Docker 組件設計缺陷，以及不當的配置都會致使 Docker 容器發生逃逸，從而獲取宿主機權限。因爲頻發的安全及逃逸漏洞，在公有云環境容器應用不得不也運行在虛擬機中，從而知足多租戶安全隔離要求。而分配、管理、運維這些傳統虛擬機與容器輕量、靈活、彈性的初衷背道而馳，同時在資源利用率、運行效率上也存浪費。
　　這就是雲原生裏面的多租戶問題，其本質是容器安全問題。前幾年，雲廠商在推出 Kubernetes 集羣服務方面進展神速，但在提供單一容器託管方面卻步伐遲緩，就是由於這個問題遲遲沒有解決。
　　而且，多租戶問題不只僅在公有云上存在，在公司內部的私有云上一樣存在，不一樣部門、團隊的應用，理應進行強隔離，以避免一個業務出現問題影響整個公司。但過去，你們應用容器的勢頭很強，裝做看不到這個問題罷了。
　　對於多租戶問題，雖然社區逐漸有了一些解決方案，但由於還不太成熟，也缺少一個標誌性事件把它們推到前臺。終於，2018 年 12 月，AWS 出手了。
　　衆所周知，AWS 是雲計算行業的領頭羊，但在容器到雲原生這波浪潮裏，AWS 卻變成了跟隨者的角色，它確定是不甘心的，最終，它在容器安全給出了本身的答案，從新走在了全部雲廠商的前面。
　　AWS 的答案是<strong>Firecracker</strong>，一種輕量級虛擬機（MicroVM），這個輕量級是相對於全功能虛擬機來講的，後者的表明是 QEMU，號稱能模擬全部硬件設備。Firecracker 將能省的地方都省了，最終留下一個極其精巧的運行時，只保護該保護的地方。
　　從性能上來說，Firecracker 和容器已經很接近了，它最初的意圖就是爲 AWS 的 Serverless 服務 Lambda 提供保護，性能必需要跟上；從安全上來說，在該保護的地方，它提供的是虛擬機級別的保護，不管是來自內部和外部的漏洞和***都能防禦。
　　AWS 還推出了 Firecracker 的 containerd 實現，這意味着能夠用標準容器的方法來驅動 Firecracker，說明用虛擬機來解決容器安全這條道路是可行的。
　　可是，AWS 有本身的一套完整生態，Firecracker 也是這個生態的一部分，雖然它開源了，社區並不能作到開箱即用，與 Kubernetes 有一些不兼容的地方。
　　這時，就輪到 Kata Containers 出場了。
　　<strong>面向雲原生的虛擬化</strong>
　　Kata Containers 的前身是 Hyper runV 和 Intel Clear Container，這二者都試圖用虛擬化的技術來解決容器安全問題。
　　二者都是 2015 年 5 月布的，後來發現彼此技術路徑差很少，兩邊的創始人聚到一塊兒一合計，要不合並吧，因而 Kata Containers 就誕生了。
　　當時，正遭遇 Kubernetes 和 CNCF 強勁攻勢的 OpenStack 基金會，一眼看出了 Kata Containers 的應用潛力，因而在將戰略改成面向開放基礎設施的同時，將 Kata Containers 接納爲第二個頂級開放基礎設施項目，與 OpenStack 同級。
　　可是，Kata Containers 在誕生後一段時間裏，卻<strong>並不受社區的開發人員看好</strong>。
　　其重要緣由有二，第一個是，Kata 雖然從第一天就將與 Kubernetes 集成做爲最優先目標，但 Kubernetes 早期版本只考慮瞭如何運行容器，要讓 Kubernetes 支持非容器技術須要額外作一些功夫，當時 runC 容器還如日中天，讓 Kubernetes 管理虛擬機是一個比較另類的作法。
　　第二，Kata 雖然成功地讓虛擬機兼容了容器的大部分接口，可是性能太差，其中一個主要緣由在於，它在底層採用了上面提到的 QEMU 做爲對接系統接口層，而 QEMU 是一個包含數百萬行代碼、數萬個文件的項目，雖然 Kata 努力對其進行了精簡，但帶來額外的性能損耗，仍是讓對安全不太敏感的應用難以接受。
　　事情的起色就在於 AWS Firecracker 的發佈，當時，Firecracker 只支持 AWS 本身的 Serverless 服務，可是明眼人都看得出來，Serverless 都支持了，容器還遠嗎？Firecracker 也讓你們更加關注容器安全問題，Kata Containers 開始受到更多的關注。
　　同時，Kata 也在利用包括 Firecracker 在內的最新開源社區進展，進一步下降開銷：好比，支持 Firecracker 做爲部分適用場景的 VMM，以及研發本身的 rust-VMM cloud-hypervisor，又將沙箱 agent 替換爲輕量的 rust-agent，讓內存佔用從十多 MB 下降到 1.1MB，提高肉眼可見，而且，這個開銷已經能夠接受。
　　另外一方面，在 Kata Containers 和社區的推進下，Kubernetes 開始接受安全容器了，在 Kubernetes 裏運行 Kata 再也不須要作額外處理。
　　在 Kata Containers 的兩週年之際，它給本身的定義是<strong>面向雲原生的虛擬化</strong>。
　　之因此要強調虛擬化，是由於它的本質是用的虛擬化技術，但與傳統虛擬化相比，Kata Containers 走的是一個徹底不一樣的發展方向，是適合雲原生場景下的虛擬化。
　　可是爲何又叫它安全容器呢？如今回到咱們開頭介紹的多租戶問題，使用 Kata Containers 後，當你啓動一個容器，其實是啓動了一個虛擬機，但這個虛擬機的功能、生命週期、性能表現都和容器如出一轍。
　　<strong>鴨子測試</strong>說，若是一個動物走路像鴨子、說話像鴨子、長得像鴨子、啄食也像鴨子，那麼咱們就認爲它是一隻鴨子。放到 Kata Containers 也同樣。
　　Docker 自身的技術路線，沒法很好地解決安全問題，因此當 CRI 和安全容器出現以後，它的商業化探索已經註定不會有太好結局。
　　<strong>Kata Containers 與安全容器的將來</strong>
　　軟件世界裏有不少不肯定性，但咱們能夠肯定的是，安全問題必定會發生。
　　那麼，如何應對安全問題呢？Linus 說過這樣一句話：
　　安全問題的惟一正解在於容許那些（致使安全問題的）Bug 發生，但經過額外的隔離層來阻擋住它們。
　　—— LinuxCon NA 2015, Linus Torvalds
　　要一勞永逸地解決容器安全問題，可能惟有爲其添加額外的隔離層，這也是 Kata Containers 的思路。
　　值得一提的是，安全容器<strong>並非只有 Kata Containers 和 Firecracker</strong>這一條路線，Google 推出的 gVisor 是另外一條路線，它是一個更純粹的隔離層，上層應用對系統的全部訪問都通過隔離層處理後，再將其中少數請求交給宿主機響應。
　　Kata Containers 通過兩年耕耘，業界開始逐漸跟進，好比百度智能雲，在函數計算、容器服務、邊緣計算等方面開始嘗試。
　　2019 年，Kata Containers 創始人加入螞蟻金服，螞蟻並未干涉 Kata Containers 的發展路線，Kata 還是社區主導的開源項目，Kata Containers 也開始在螞蟻和阿里內部逐漸落地。
　　Kata Containers 將來仍會繼續優化其性能，固然，更重要的是，容器和虛擬機就像是一座天平的兩端，Kata Containers 須要不斷地摸索，去找到那個平衡點。
　　AWS 已經證實了安全容器是公有云落地 Serverless 的關鍵技術之一，與之相似，邊緣計算也將成爲安全容器的典型應用場景。
　　隨着 AWS 以及各家雲廠商的跟進，能夠預見，2020 年將迎來安全容器落地的爆發。
　　<strong>Kata Containers 項目地址：</strong>
　　<a href="https://github.com/kata-containers" target="_blank">https://github.com/kata-containers</a>;