雲原生是一座由精妙理論所構築的摩天大廈，但其中的磚石還需加固。
當雲原生將容器技術作為下一代雲計算的基礎之一時，並不意味著容器本身停止了演化。事實上，以Docker為代表的傳統容器在遇到多租戶場景時，它的安全問題立刻暴露了出來，這時，人們才懷念起虛擬化的好處。
於是，採用虛擬化技術的「安全容器」這一概念應運而生，而開啟這一變革的，正是Kata Containers，前不久，它剛剛度過兩周年。
新的Kata Containers為我們帶來虛擬機的安全性和隔離性、與容器兼容的API介面，同時還有與容器同一級別的性能，這意味著採用安全容器的時機已經成熟。
與此相對的是，上個月，Docker的企業級業務被打包出售，據稱出售價格甚至不及幾輪下來的融資總額。
所有在生產環境使用容器的公司，從現在開始都有必要審視自己的安全策略，並制定從容器到安全容器的遷移計劃。
這一切是怎麼發生的呢？聽我為你一一道來。
Docker的潰敗
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，大家在自己的集群上用得很愉快，但當雲廠商試圖向大眾提供容器服務時，多租戶安全問題出現了。
AWS的選擇
要理解這個問題，我們首先要了解容器的原理。
Linux容器的本質是一種進程隔離技術，通過cgroup和namespace，容器里的應用只使用給定的資源，不同容器之間互不侵犯。
從容器里應用的角度來看，它只能看到給定的計算存儲資源和為其定製的系統，但從容器外面的系統來看，它運行的是一個一個的進程。
如果這些容器都屬於同一個用戶那還沒什麼，但如果是雲服務，一台機器裡面運行著不同用戶的一個個進程，光是想一想就有一種四處漏風的感覺！
從技術角度講，AWS在它的官方博客中是這麼描述這個安全隱患的：
由於操作系統內核漏洞，Docker組件設計缺陷，以及不當的配置都會導致Docker容器發生逃逸，從而獲取宿主機許可權。由於頻發的安全及逃逸漏洞，在公有雲環境容器應用不得不也運行在虛擬機中，從而滿足多租戶安全隔離要求。而分配、管理、運維這些傳統虛擬機與容器輕量、靈活、彈性的初衷背道而馳，同時在資源利用率、運行效率上也存浪費。
這就是雲原生裡面的多租戶問題，其本質是容器安全問題。前幾年，雲廠商在推出Kubernetes集群服務方面進展神速，但在提供單一容器託管方面卻步伐遲緩，就是因為這個問題遲遲沒有解決。
並且，多租戶問題不僅僅在公有雲上存在，在公司內部的私有雲上同樣存在，不同部門、團隊的應用，理應進行強隔離，以免一個業務出現問題影響整個公司。但過去，大家應用容器的勢頭很強，裝作看不到這個問題罷了。
對於多租戶問題，雖然社區逐漸有了一些解決方案，但因為還不太成熟，也缺乏一個標誌性事件把它們推到前台。終於，2018年12月，AWS出手了。
眾所周知，AWS是雲計算行業的領頭羊，但在容器到雲原生這波浪潮里，AWS卻變成了跟隨者的角色，它肯定是不甘心的，最終，它在容器安全給出了自己的答案，重新走在了所有雲廠商的前面。
AWS的答案是Firecracker，一種輕量級虛擬機（MicroVM），這個輕量級是相對於全功能虛擬機來說的，後者的代表是QEMU，號稱能模擬所有硬體設備。Firecracker將能省的地方都省了，最終留下一個極其精巧的運行時，只保護該保護的地方。
從性能上來講，Firecracker和容器已經很接近了，它最初的意圖就是為AWS的Serverless服務Lambda提供保護，性能必須要跟上；從安全上來講，在該保護的地方，它提供的是虛擬機級別的保護，無論是來自內部和外部的漏洞和攻擊都能防護。
AWS還推出了Firecracker的containerd實現，這意味著可以用標準容器的方法來驅動Firecracker，說明用虛擬機來解決容器安全這條道路是可行的。
但是，AWS有自己的一套完整生態，Firecracker也是這個生態的一部分，雖然它開源了，社區並不能做到開箱即用，與Kubernetes有一些不兼容的地方。
這時，就輪到Kata Containers出場了。
面向雲原生的虛擬化
Kata Containers的前身是Hyper runV和Intel Clear Container，這兩者都試圖用虛擬化的技術來解決容器安全問題。
兩者都是2015年5月布的，後來發現彼此技術路徑差不多，兩邊的創始人聚到一起一合計，要不合併吧，於是Kata Containers就誕生了。
當時，正遭遇Kubernetes和CNCF強勁攻勢的OpenStack基金會，一眼看出了Kata Containers的應用潛力，於是在將戰略改為面向開放基礎設施的同時，將Kata Containers接納為第二個頂級開放基礎設施項目，與OpenStack同級。
但是，Kata Containers在誕生后一段時間裡，卻並不受社區的開發人員看好。
其重要原因有二，第一個是，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的兩周年之際，它給自己的定義是面向雲原生的虛擬化。
之所以要強調虛擬化，是因為它的本質是用的虛擬化技術，但與傳統虛擬化相比，Kata Containers走的是一個完全不同的發展方向，是適合雲原生場景下的虛擬化。
但是為什麼又叫它安全容器呢？現在回到我們開頭介紹的多租戶問題，使用Kata Containers后，當你啟動一個容器，實際上是啟動了一個虛擬機，但這個虛擬機的功能、生命周期、性能表現都和容器一模一樣。
鴨子測試說，如果一個動物走路像鴨子、說話像鴨子、長得像鴨子、啄食也像鴨子，那麼我們就認為它是一隻鴨子。放到Kata Containers也一樣。
Docker自身的技術路線，無法很好地解決安全問題，所以當CRI和安全容器出現之後，它的商業化探索已經註定不會有太好結局。
Kata Containers與安全容器的未來
軟體世界里有很多不確定性，但我們可以確定的是，安全問題一定會發生。
那麼，如何應對安全問題呢？Linus說過這樣一句話：
安全問題的唯一正解在於允許那些（導致安全問題的）Bug發生，但通過額外的隔離層來阻擋住它們。
—— LinuxCon NA 2015, Linus Torvalds
要一勞永逸地解決容器安全問題，可能唯有為其添加額外的隔離層，這也是Kata Containers的思路。
值得一提的是，安全容器並不是只有Kata Containers和Firecracker這一條路線，Google推出的gVisor是另一條路線，它是一個更純粹的隔離層，上層應用對系統的所有訪問都經過隔離層處理后，再將其中少數請求交給宿主機響應。
Kata Containers經過兩年耕耘，業界開始逐漸跟進，比如百度智能雲，在函數計算、容器服務、邊緣計算等方面開始嘗試。
2019年，Kata Containers創始人加入螞蟻金服，螞蟻並未乾涉Kata Containers的發展路線，Kata仍是社區主導的開源項目，Kata Containers也開始在螞蟻和阿里內部逐漸落地。
Kata Containers未來仍會繼續優化其性能，當然，更重要的是，容器和虛擬機就像是一座天平的兩端，Kata Containers需要不斷地摸索，去找到那個平衡點。
AWS已經證明了安全容器是公有雲落地Serverless的關鍵技術之一，與之類似，邊緣計算也將成為安全容器的典型應用場景。
隨著AWS以及各家雲廠商的跟進，可以預見，2020年將迎來安全容器落地的爆發。
參考文章：
作者：徐川
原文：以Docker為代表的傳統容器到了生死存亡之際
[admin
]
來源：OsChina
連結：https://www.oschina.net/news/112661/containers-cloud-native
展望2020：傳統容器已死，安全容器將成為雲原生標配已經有269次圍觀
