[[338613]]

本文轉載自微信公眾號「新鈦云服」，作者肖力 翻譯 。轉載本文請聯系新鈦云服公眾號。   

運行大量容器以部署應用程序需要重新考慮操作系統的作用。Google的Container-Optimized OS和AWS的Bottlerocket采用了傳統的虛擬化范例，并將其應用于操作系統，而容器則是虛擬OS和最小化的Linux，可充當虛擬化引擎的角色。

針對容器而優化的各種Linux版本已經問世了幾年，并且隨著管理和用戶實用程序遷移到集群管理層或容器。當需要以最少的設置在Kubernetes中運行應用程序，不想擔心安全性、更新或需要云提供商的OS支持時，這些容器優化的操作系統是理想的選擇。

容器OS解決了運行大型容器集群時經常遇到的幾個問題，例如緊跟操作系統漏洞和修補潛在的數百個實例，處理潛在沖突的依賴關系時更新程序包，大型依賴關系樹導致的性能下降以及其他操作系統難題。幾臺服務器能夠完成挑戰，而在管理數千臺服務器時，如果沒有基礎架構的支持幾乎是不可能的。

AWS Bottlerocket

Bottlerocket是專門為在Amazon基礎架構中托管容器而構建的。它在Amazon Elastic Kubernetes服務(EKS)，AWS Fargate和Amazon Elastic Container Service(ECS)中運行。

從本質上講，Bottlerocket是Linux 5.4內核，從用戶界面實用程序中添加的內容足以運行容器化。Bottlerocket主要由Rust編寫，針對運行Docker和Open Container Initiative(OCI)鏡像進行了優化。沒有什么可以將Bottlerocket限制為EKS，Fargate，ECS甚至AWS。

Bottlerocket是一個自包含的容器操作系統，使用Red Hat風格的Linux的任何人都會熟悉。

Bottlerocket與諸如Amazon EKS之類的容器編排器集成在一起，以管理和編排更新，并且可以通過構建操作系統的變體來添加對其他編排器的支持，以向構建中添加必要的編排代理或自定義組件。

Bottlerocket的安全性

Bottlerocket的安全性方法是最大程度地減少攻擊面，以抵御外部攻擊者的侵害，最大程度地降低漏洞對系統的影響，并提供容器間隔離。為了隔離容器，Bottlerocket使用容器控制組(cgroup)和內核名稱空間來隔離系統上運行的容器。eBPF(增強的Berkeley數據包過濾器)用于進一步隔離容器并驗證需要低級系統訪問的容器代碼。eBPF安全模式禁止指針算術，跟蹤I/O并限制容器可以訪問的內核功能。

通過在容器中運行所有服務來減少攻擊面。盡管容器可能受到破壞，但由于容器隔離，整個系統受到破壞的可能性較小。通過操作系統隨附的Kubernetes運算符運行Amazon提供的Bottlerocket版本時，將自動應用更新。

不可變的根文件系統會創建根文件系統塊的哈希，并使用dm-verity依賴于經過驗證的引導路徑，從而確保不會篡改系統二進制文件。該配置是無狀態的，并且/etc/已安裝在RAM磁盤上。在AWS上運行時，配置是通過API完成的，并且這些設置在重新啟動后會保留下來，因為它們來自AWS基礎架構中的文件模板。還可以使用實現CNI和CSI規范的自定義容器配置網絡和存儲，并通過Kubernetes控制器將它們與其他守護程序一起部署。

SELinux默認情況下處于啟用狀態，無法禁用它。通常這可能是個問題，但是在容器OS用例中，無需放松此要求。目的是防止其他OS組件或容器修改設置或容器。此安全功能正在進行中。

Bottlerocket開源

Bottlerocket構建系統基于Rust，考慮到除了對Docker和Kubernetes的支持之外沒有其他構建，這很好。Rust剛進入前20種編程語言之列，并且由于其C ++的語法和自動內存管理等優勢而受到關注。Rust已獲得MIT或Apache 2許可。

亞馬遜在利用GitHub作為其開發平臺方面做得很好，使開發人員可以輕松參與其中。任何開發人員都將熟悉工具鏈和代碼工作流，并通過設計鼓勵最終用戶創建操作系統的變體。這是為了支持多個業務流程代理。為了使OS占用空間盡可能小，每個Bottlerocket變體都在特定的編排平面上運行。亞馬遜包括Kubernetes的變體和本地開發版本。例如，可以通過更改容器的URL來創建自己的更新運算符或控件容器。

管理Bottlerocket實例

不能通過Shell來管理Bottlerocket。實際上，幾乎沒有什么操作系統需要管理，而所需的操作則由HTTP API，命令行客戶端(eksctl)或Web控制臺完成。

要更新，需要將更新容器部署到實例上。在GitHub上查看bottlerocket-update-operator(一個Kubernetes運算符)。Bottlerocket使用“兩個分區模式”完成單步更新，其中映像在磁盤上具有兩個可引導分區。一旦成功將更新寫入非活動分區，每個分區的GUID分區表中的優先級位就會交換，并且“活動”和“非活動”分區角色將互換。重新引導后，系統將升級，或者在發生錯誤的情況下回滾到最后一個已知良好的映像。

與NanoBSD和其他嵌入式操作系統一樣，沒有可以安裝的軟件包，只有容器和更新是基于映像的。AWS傳播者Jeff Barr解釋了做出此決定的原因：

代替軟件包更新系統，Bottlerocket使用基于鏡像的簡單模型，該模型可在必要時進行快速而完整的回滾。這消除了沖突和破壞的機會，并使您更容易使用協調器(例如EKS)有信心地應用整個機隊范圍的更新。

要直接訪問Bottlerocket實例，需要運行“控制”容器，該容器由一個單獨的containerd實例管理。該容器運行AWS SSM代理，因此可以在一個或多個實例上執行遠程命令或啟動Shell。默認情況下，控件容器處于啟用狀態。

還有一個管理容器在實例的內部控制平面上運行(即在單獨的容器實例上)。啟用后，此管理容器將運行SSH服務器，可以使用Amazon注冊的SSH密鑰以ec2用戶身份登錄。盡管這對于調試很有用，但由于這些實例的安全策略，它實際上并不適合進行配置更改。

Google Container-Optimized OS

Container-Optimized OS是Google維護的基于開源Chromium OS項目的操作系統。與Bottlerocket一樣，Container-Optimized OS是基于映像的操作系統，針對在Google Compute Engine VM中運行Docker容器進行了優化。容器優化的操作系統可滿足更新，安全性和易于管理的類似需求。盡管開發人員可以在KVM上運行它以進行測試，但它不能在Google Cloud Platform之外運行。僅支持基于Docker的映像。

彈性工作負載擴展已成為發展趨勢，Container-Optimized OS的既定目標之一就是快速擴展。最小的基于映像的OS的啟動速度很快，并且可以通過cloud-init和Google的Cloud SDK的組合來管理大規模配置。這意味著可以響應需求和工作負載變化的高峰而快速增加應用程序服務。

Container-Optimized OS安全性

安全性最重要的規則之一是減少攻擊面。容器優化的OS通過將所有服務移出OS用戶/系統空間并移入容器來實現此目的。因此，裸機操作系統安裝了最少數量的軟件包以支持容器管理，并且容器管理自己的依賴性。該內核還具有與安全性相關的改進，例如完整性度量體系結構(IMA-measurement)，IMA審核，內核頁表隔離以及從Chromium OS中獲取的一些Linux安全模塊。如果應用程序需要，可以通過Seccomp和AppArmor添加細粒度的安全策略。

Container-Optimized OS實例的默認設置也具有安全意識，這使保護大型群集更加容易。例如，沒有可訪問的用戶帳戶，并且防火墻設置會丟棄除SSH以外的所有連接，從而減少了攻擊面。可以通過Google的IAM角色或通過在實例元數據中添加和刪除SSH密鑰來管理對實例的訪問。不允許基于密碼的登錄。兩因素身份驗證是一種選擇。

安全性也在文件系統級別實現。例如，Container-Optimized OS使用了一個只讀的根文件系統，該文件系統在啟動時已由內核驗證，從而防止了任何攻擊者進行永久的本地更改。雖然這對安全性有好處，但確實使配置成為挑戰。為了啟用配置，對操作系統進行了設置，使得/ etc /是可寫的，但是是臨時的，因此，每次重新啟動時，都會重新構建操作系統配置。

容器優化的操作系統利用Google的最佳實踐和基礎架構來構建和部署映像。操作系統的內核和程序包源代碼是由Google擁有的代碼存儲庫構建的，可以通過自動升級機制來修補和發布所有錯誤或漏洞。默認情況下啟用的自動升級功能使群集中的節點與群集主版本保持最新。這既提高了安全性，又減少了維護開銷。Google還提供漏洞掃描功能，因此，如果在容器優化的操作系統中檢測到漏洞，則補丁會在可用時自動推出。

Container-Optimized OS的開源

作為Chromium OS項目的一部分，Container-Optimized OS是開源的，盡管除了實驗之外沒有理由自己構建它。與Bottlerocket不同，Container-Optimized OS并未預見到客戶需要在集群上構建和部署自定義映像，并且由于依賴于Google的基礎架構，因此沒有理由。

構建Container-Optimized OS需要Google獨有的Chromium工具鏈和腳本。這些開發映像確實允許用戶訪問外殼程序，并且主要是供Google工程師用來構建，測試和調試系統的。可以使用KVM運行圖像或將圖像導入到計算引擎實例中。

管理Container-Optimized OS實例

Google Container-Optimized OS不包括程序包管理器，但是可以使用CoreOS Toolbox安裝其他工具，CoreOS Toolbox會啟動一個容器，可以使用自己喜歡的調試或管理工具。

在大多數情況下，容器優化的OS實例將作為Kubernetes管理的群集的一部分運行。為了進行實驗，可以定義一個映像，然后使用Cloud Console或gcloud命令行工具在GCE實例上運行它，然后像其他任何GCE實例一樣將其SSH進入它。基本映像支持公共容器注冊表，因此您可以立即開始使用自己喜歡的Docker映像。

Google提供了一些不錯的功能來幫助進行生產部署。其中之一是Node Problem Detector，用于監視容器優化的OS實例的運行狀況。使用Google Cloud Monitoring，可以使用Google Operations儀表板查看容量和錯誤報告，并可視化集群的運行狀況。

時間與Linux的systemd-timesyncd同步。使用與SNTP同步的程序包是有點不尋常的，特別是如果您有長時間運行的實例需要對時間進行細粒度的控制，但是如果需要，可以始終在容器中安裝完整版本的NTPd。

升級在大多數情況下都會自動應用，并且有三個滾動發布渠道可供選擇：dev，beta和穩定版。這些通道提供了進入功能管道的窗口，并允許滾動升級群集。通常，群集中的一小部分將處于開發階段，beta階段會更多一些，而大多數處于穩定狀態。這降低了遇到群集范圍的問題的風險。

自動更新使用主動/被動根分區進行，其中一個分區是“活動”的，另一個分區是備份的。來自dev/beta/stable通道的映像更新將下載到被動分區，并且引導管理器在引導時選擇最新版本。如果遇到錯誤，則從舊分區引導系統。可以通過CLI界面手動控制更新，但是大多數情況下使用自動更新。

為云構建的容器優化的操作系統

容器優化的操作系統并不是新的。之前曾評論過CoreOS，RancherOS，Red Hat Atomic等。我認為我們處于操作系統開發這一行的最后階段，在該領域，操作系統只是整個云操作系統的一部分，就像共享庫為主機操作系統提供特定功能一樣。該操作系統是后臺基礎架構的一部分，意味著開發人員可以專注于他們的應用程序，而不是如何運行它們。Bottlerocket和容器優化的OS都能做到這一點。兩者都非常適合為其開發的云。

AWS的Bottlerocket融合了前輩的許多最佳創意，并增加了對多個云環境和容器協調器的支持，并在用例需要時創建了變體。Bottlerocket將在2020年的某個時候以GA形式提供。

與Bottlerocket相比，Google的Container-Optimized OS更接近microVM領域(例如AWS Fargate下的Firecracker技術)。與許多Google技術一樣，Container-Optimized OS對如何完成事情持堅定的態度，這通常是一件好事。

但是，如果正在考慮采用多云策略，那么Container-Optimized OS是一個障礙，而不是優勢。大多數人都在考慮多云并避免廠商鎖定。如果將來要部署到多個云，那么Bottlerocket將是一個更好的選擇。

原文鏈接：

https://www.infoworld.com/article/3570158/review-aws-bottlerocket-vs-google-container-optimized-os.html?