來自CoreOS的高安全保障水平容器引擎：rkt迎來1.0版本

今天可謂CoreOS rkt的大日子——這是一套專門面向安全性、執行效率以及兼容能力設計而成的容器引擎。作為以安全與兼容性為核心訴求的容器引擎，rkt誕生于2014年，當時各類云原生計算方案與容器機制才剛剛開始崛起。自那時開始，市場對于高安全性、生產就緒型容器支持時方案的需求變得日益強烈。

今天，CoreOS則正式推出了其rkt的1.0版本。

我們一直在努力讓rkt能夠更好且更靈活地同真實世界中的架構相契合，同時保障最佳安全實踐，而社區方面提供的貢獻與支持亦開始不斷增長。經過15個月的持續開發，rkt已經接收到超過3000項提交內容，貢獻者總數量超過100位。

rkt發展道路上的一大里程碑

在rkt 1.0版本當中，我們引入了：

• 穩定的界面與磁盤格式: 命令行用戶體驗與磁盤格式現在開始已經非常穩定，而且可供用戶根據需要加以開發。針對這些界面的任何變更都具備向下兼容能力，且與現有棄用情況保持一致。
• 高級安全功能: 憑借著KVM容器隔離、SELinux支持、TPM集成、鏡像簽名驗證以及權限拆分等功能，rkt已經成為高安全要求使用場景下的重要容器引擎選項。
• 運行現有Docker鏡像以及標準化應用容器鏡像: 盡管rkt針對標準做出承諾，但其仍然能夠與Docker鏡像格式順利兼容。這意味著大家可以構建Docker鏡像并將其運行在rkt當中。除此之外，CoreOS還將在未來以App Container Image格式為基礎支持持續發展的工具生態系統。
• 強大的技術社區: rkt的生態系統正不斷發展，并逐步成為開發人員與運維人員的工作根據地——他們在這里不斷提供安全的、可組合且基于標準的容器引擎方案。目前rkt已經能夠運行在Arch、CoreOS、Ubuntu、Fedora、MinxOS以及其它多種Linux平臺之上，而且采用rkt的項目與產品也在快速增加。

為什么選擇rkt？發展歷程概述

在慶祝這一重要里程碑的同時，我們也有必要回顧rkt項目的發展歷程，了解CoreOS方面當初為什么決定對其進行持續投入。正如我們在立項之初所言，rkt的構建工作是為了打造出一套能夠真正實現安全性、組合性與標準遵循效果的容器引擎。

• 安全性 ：rkt當中包含有權限拆分功能，旨在避免不必要的操作以root權限運行，同時提供默認的簽名驗證與其它出于安全性考量的先進功能。
• 可組合性 ：rkt不需要配合長期運行的后臺守護程序，且能夠與systemd或者upstart等現有init系統順暢協作。
• 基于標準 ：只要多款工具共享同一套經過精心制定的標準，從而引導用戶構建并打包容器鏡像，我們才能將其稱為“標準容器”。rkt的設計初衷恰好在于支持并提供面向各類容器標準的向下兼容能力。

著眼于安全之相關功能

rkt在構建之初就始終著眼于以安全性為主要考量之運行環境。其中大多數原則并非源自CoreOS——相反，我們當時是考慮到了容器行業在很大程度上忽視了各類安全最佳實踐的客觀現狀。

面向最佳實踐之架構設計

rkt力求體現Unix“工具”這一理念，并充分從過去幾十年積累到的架構與安全性最佳實踐中汲取營養。其中包括默認提供鏡像簽名驗證機制、在不同任務之間進行權限隔離，例如rkt不允許以root權限執行容器發現與檢索，從而解決容器執行默認要求root權限的難題。另外，rkt采用的無守護程序模式意味著其能夠輕松與標準init系統相集成，例如systemd與upstart，或者其它集群編排系統，例如Nomad與Kubernetes。

可插拔隔離機制，包括基于KVM之“Clear Container”

模塊化隔離意味著rkt支持一系列運行容器所必需的技術方案。盡管軟件隔離已經成為Linux cgroup容器的默認處理方式，但以英特爾的KVM“Clear Container”或者主機級rkt為代表的各類先進解決方案都能夠提供可選容器限定級別。

英特爾Clear Container

隨著英特爾推出立足于Clear Container的stage1，rkt已經能夠利用CPU強制隔離機制執行標準ACI。這就成功在兩類核心訴求之間取得了平衡：應用程序本身專注于打包與部署效率，而硬件則要求保證虛擬機隔離。

rkt fly

在fly stage1隔離環境，rkt會執行一套標準化容器鏡像，并保證其擁有對主機環境的全面接入能力。這意味著大家可以運行具備特定權限要求的軟件，例如需要進行主機全面訪問的系統管理工具，但同時又保證鏡像簽名與部署策略繼續生效。將rkt與fly相結合能夠在底層系統程序中充分保留應用程序容器的打包能力與分布式優勢。

自動化SELinux

在SELinux內核當中，rkt能夠以自動化方式將合適的SELinux標簽配置至各個執行pod當中，從而保證各容器與主機進程不致相互干擾。這意味著即使容器本身遭遇入侵，對方仍然無法借此訪問其它容器或者主機。

TPM集成

rkt將現代服務器系統上所特有的受信平臺模塊（簡稱TPM）引入進入，旨在對pod運行狀態進行防篡改驗證記錄，而這一舉措在容器安全性保障領域無疑是一項重要創新。TPM集成已經成為一類新型基礎設施的關鍵性組成部分——我們將其稱為“分布式受信計算”。

appc以及OCI

rkt社區積極支持開放標準。rkt最初作為App Container（簡稱appc）項目中的一項實現方案開發而成。2015年年中，另一相關實體由此誕生——這就是旨在圍繞應用程序容器構建更多標準規范的開放容器倡議（簡稱OCI）。從表面上看，appc項目與OCI的最終訴求似乎基本相同。但具體二言，二者之間雖然存在一定交集，但仍有相當可觀的協作空間。

2016年OCI與appc發展狀況展望

在我們看來，容器標準的一大核心要點在于提供一套可供開發人員打包且能夠簡化發布流程的鏡像格式。著眼于appc項目，該格式為App Container Image（簡稱ACI），而Docker則專門使用自家獨特的Docker鏡像格式。盡管共享式標準非常重要，但經過六個月的努力，開放容器倡議（簡稱OCI）仍未最終決定其是否要開發一套標準化鏡像格式。目前，OCI社區的主要工作在于針對容器運行時環境構建標準，而非著眼于容器鏡像。容器運行時之功能規范同樣是一項值得探討的議題，不過我們認為當下還有更為迫切的需求——一套標準化容器鏡像規范，這將成為更為開放且更具發展空間的容器行業的立足基礎。總而言之，OCI與appc之間息息相關但卻并不相互排斥。具體來講，仍有充足的空間讓二者在現在與未來保持相互合作及彼此推進。

總結來講，我們的目標是確保開發人員能夠構建并使用標準化格式的應用容器鏡像，同時選擇多種工具并將其部署在各類運行時當中。有鑒于此，我們仍在同appc社區以協作方式不斷推動App Container規范及相關鏡像格式。我們在兼容性方面做出的選擇意味著rkt能夠支持以ACI或者DOcker典型鏡像格式打包的應用程序。

生產型容器需要強大的生態系統作為支撐

我們已經通過與社區的緊密合作推出了rkt 1.0版本，而今天我們除了要感謝那些將rkt打造成安全性最出色的容器運行時方案的參與者們，同時也要著眼于新興生態系統的培育。歸功于同英特爾間的協作、利用Sysdig對生產環境下的rkt加以監控、利用Calico項目實現rkt網絡功能集成以及Quay帶來的rkt容器存儲等等，如今我們終于能夠將rkt作為虛擬機進行啟動。這些切實得到驗證的成果展示了rkt與appc相關社區的快速發展，同時亦再次強調了開放標準在推動合作伙伴構建創新成果方面發揮的重要作用。

下面來看rkt與生態系統之間的項目合作與相關故事：

Apcera

Apcera創造出了Kurma——另一套基于App Container規范的容器運行時。

“我們對rkt的1.0版本十分贊賞，因為它已經成為容器運行時標準領域的一大里程碑。rkt是第一款立足于App Container（即appc）規范的1.0版本實現方案，且已經做好進入生產環境的準備，”Apcera公司首席架構師Ken Robertson表示。“Apcera堅信appc與容器標準的價值將通過我們對自身Kurma項目的不斷投入得到進一步凸顯。”

BlaBlaCar

BlaBlaCar公司，一家成立于2006年的高聲譽拼車服務供應商，其早在rkt發展早期即參與其中并將其全部業務轉移到容器領域。

“自rkt開發工作開始進行以來，我們就一直驚訝于rkt的出色穩定性與靈活度水平——即使當時其僅處于早期版本階段，”BlaBlaCar公司系統工程師Simon Lallemand表示。“我們正在將自身全部服務遷移到rkt與CoreOS當中。截至目前，我們90%的產品都已經運行在該平臺之上。”

Deis（Engine Yard）

> “rkt容器運行時滿足了市場的迫切需要，”Deis公司CTO Gabriel Monroy指出。“隨著我們開始幫助客戶將容器引入生產環境，我們愈發意識到容器運行時能夠出色地完成其既定任務。CoreOS技術團隊已經證明了他們有能力提供一套擁有極佳穩定性與安全性保障的分布式系統——rkt當然也不例外。”

Giant Swarm

> “我們可以說是rkt的忠實擁護者，而且對于rkt 1.0版本的發布感到振奮不已，”Giant Swarm公司初始人兼CTO Timo Derstappen指出。“CoreOS在安全領域擁有領先地位，這不僅體現在rkt身上，同時也包括CoreOS產品套件。隨著整個行業開始構建下一代基礎設施并轉向微服務架構，rkt成為正確發展方向上的又一重要里程碑。”

HashiCorp

> HashiCorp公司已經在Nomad當中添加了對rkt的支持能力。

“我很高興地看到rkt如今已經走向1.0版本，”HashiCorp公司創始人Mitchell Hasimoto指出。“我們在Nomad以及其它驅動程序當中支持rkt，這樣各企業客戶就能夠輕松實現rkt容器部署工作。Nomad還顯著簡化了從一套到數千套rkt容器的規模各異的部署任務流程。”

華為

華為公司通過多種方式為rkt提供貢獻，其中主要包括容器注冊表與提供ARM支持能力兩大方面。

“祝賀CoreOS推出了這套容器運行時正式版本，即rkt v1.0。這是容器技術世界迎來的又一座里程碑，”華為公司PaaS首席架構師熊英博士指出。“在與其它技術加以結合之后，rkt已經成為我們整體容器技術堆棧中的組成部分，并為我們的客戶及合作伙伴提供重要幫助。”

英特爾

> “以rkt為代表的容器型環境能夠為數據中心工作負載提供令人驚嘆的可移植能力。我們與CoreOS協作以對rkt做出優化，旨在盡可能發揮英特爾平臺技術的全部優勢，從而面向更為廣泛的市場部署需求提供經過改進的工作負載隔離、基于硬件的安全功能以及效率提升成效。我們著眼于同CoreOS以協作方式將基于rkt的解決方案推向市場，”英特爾公司首席工程師兼軟件定義基礎設施架構師Das Kamhout表示。

Kubernetes

> “rkt體現了Kubernetes作為核心特色的開放性與可選擇性原則，我們也很高興地看到其迎來了1.0版本這一發展里程碑，”Kubernetes核心貢獻者Dawn Chen表示。“我們樂于同CoreOS以及rkt社區進行協作，從而確保Kubernetes能夠被確切整合于其中，最終幫助用戶根據需要選擇最適合自己的鏡像格式。”

Calico項目（Metaswitch Networks）

今天Calico項目開發方公布了其面向rkt 1.0版本的容器網絡接口（簡稱CNI）網絡插件：

“我們從起步階段就一直在支持App Container規范以及相關CNI規范，旨在確保各類容器用戶能夠輕松將其接入自己的容器，并利用需要的網絡功能實現業務成功，”Metaswitch Networks公司Calico項目總經理兼布道者Andy Randall表示。“Calico項目榮幸地構建起了自己的開發社區，從而實現基于容器之應用程序的安全部署——而這一切都要歸功于rkt的強大安全性同Calico項目細粒化策略執行機制的協作配合。”

Sysdig

今天，Sysdig剛剛立足于Sysdig Cloud與Sysdig開源項目發布了面向rkt容器的實時監控與故障排查方案。作為惟一一套容器原生型監控解決方案，Sysdig的新功能允許用戶以可視化方式掌握物理基礎設施、容器甚至是運行于rkt內之應用程序的性能表現。

Sysdig對rkt容器進行監控

“rkt 1.0標志著容器技術社區已經取得了偉大的成就，同時亦將幫助我們將安全性機制內置于應用程序的開發與部署流程當中，”Sysdig公司CEO Loris Degioanni表示。“為了幫助rkt社區將其方案部署至生產環境當中，Sysdig公司目前已經立足于Sysdig Cloud與Sysdig開源項目提供rkt監控、警報與故障排查方案。”

systemd

> “我認為在rkt模式當中，”system首席開發者Lennart Poettering表示，“容器與服務管理機制并結合于一處，這種將容器與主機服務以1：1形式加以映射的方式是個極好的主意。容器與服務的資源管理、自我排查、生命周期管理——這一切都緊密集成在操作系統當中; 而這正是容器管理工具的設計初衷。”

原文鏈接： The Security-minded Container Engine by CoreOS: rkt Hits 1.0