以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&gt;
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章