[[338613]]

本文轉(zhuǎn)載自微信公眾號(hào)「新鈦云服」，作者肖力 翻譯 。轉(zhuǎn)載本文請(qǐng)聯(lián)系新鈦云服公眾號(hào)。   

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

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

容器OS解決了運(yùn)行大型容器集群時(shí)經(jīng)常遇到的幾個(gè)問題，例如緊跟操作系統(tǒng)漏洞和修補(bǔ)潛在的數(shù)百個(gè)實(shí)例，處理潛在沖突的依賴關(guān)系時(shí)更新程序包，大型依賴關(guān)系樹導(dǎo)致的性能下降以及其他操作系統(tǒng)難題。幾臺(tái)服務(wù)器能夠完成挑戰(zhàn)，而在管理數(shù)千臺(tái)服務(wù)器時(shí)，如果沒有基礎(chǔ)架構(gòu)的支持幾乎是不可能的。

AWS Bottlerocket

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

從本質(zhì)上講，Bottlerocket是Linux 5.4內(nèi)核，從用戶界面實(shí)用程序中添加的內(nèi)容足以運(yùn)行容器化。Bottlerocket主要由Rust編寫，針對(duì)運(yùn)行Docker和Open Container Initiative(OCI)鏡像進(jìn)行了優(yōu)化。沒有什么可以將Bottlerocket限制為EKS，F(xiàn)argate，ECS甚至AWS。

Bottlerocket是一個(gè)自包含的容器操作系統(tǒng)，使用Red Hat風(fēng)格的Linux的任何人都會(huì)熟悉。

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

Bottlerocket的安全性

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

通過在容器中運(yùn)行所有服務(wù)來減少攻擊面。盡管容器可能受到破壞，但由于容器隔離，整個(gè)系統(tǒng)受到破壞的可能性較小。通過操作系統(tǒng)隨附的Kubernetes運(yùn)算符運(yùn)行Amazon提供的Bottlerocket版本時(shí)，將自動(dòng)應(yīng)用更新。

不可變的根文件系統(tǒng)會(huì)創(chuàng)建根文件系統(tǒng)塊的哈希，并使用dm-verity依賴于經(jīng)過驗(yàn)證的引導(dǎo)路徑，從而確保不會(huì)篡改系統(tǒng)二進(jìn)制文件。該配置是無狀態(tài)的，并且/etc/已安裝在RAM磁盤上。在AWS上運(yùn)行時(shí)，配置是通過API完成的，并且這些設(shè)置在重新啟動(dòng)后會(huì)保留下來，因?yàn)樗鼈儊碜訟WS基礎(chǔ)架構(gòu)中的文件模板。還可以使用實(shí)現(xiàn)CNI和CSI規(guī)范的自定義容器配置網(wǎng)絡(luò)和存儲(chǔ)，并通過Kubernetes控制器將它們與其他守護(hù)程序一起部署。

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

Bottlerocket開源

Bottlerocket構(gòu)建系統(tǒng)基于Rust，考慮到除了對(duì)Docker和Kubernetes的支持之外沒有其他構(gòu)建，這很好。Rust剛進(jìn)入前20種編程語(yǔ)言之列，并且由于其C ++的語(yǔ)法和自動(dòng)內(nèi)存管理等優(yōu)勢(shì)而受到關(guān)注。Rust已獲得MIT或Apache 2許可。

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

管理Bottlerocket實(shí)例

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

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

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

代替軟件包更新系統(tǒng)，Bottlerocket使用基于鏡像的簡(jiǎn)單模型，該模型可在必要時(shí)進(jìn)行快速而完整的回滾。這消除了沖突和破壞的機(jī)會(huì)，并使您更容易使用協(xié)調(diào)器(例如EKS)有信心地應(yīng)用整個(gè)機(jī)隊(duì)范圍的更新。

要直接訪問Bottlerocket實(shí)例，需要運(yùn)行“控制”容器，該容器由一個(gè)單獨(dú)的containerd實(shí)例管理。該容器運(yùn)行AWS SSM代理，因此可以在一個(gè)或多個(gè)實(shí)例上執(zhí)行遠(yuǎn)程命令或啟動(dòng)Shell。默認(rèn)情況下，控件容器處于啟用狀態(tài)。

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

Google Container-Optimized OS

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

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

Container-Optimized OS安全性

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

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

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

容器優(yōu)化的操作系統(tǒng)利用Google的最佳實(shí)踐和基礎(chǔ)架構(gòu)來構(gòu)建和部署映像。操作系統(tǒng)的內(nèi)核和程序包源代碼是由Google擁有的代碼存儲(chǔ)庫(kù)構(gòu)建的，可以通過自動(dòng)升級(jí)機(jī)制來修補(bǔ)和發(fā)布所有錯(cuò)誤或漏洞。默認(rèn)情況下啟用的自動(dòng)升級(jí)功能使群集中的節(jié)點(diǎn)與群集主版本保持最新。這既提高了安全性，又減少了維護(hù)開銷。Google還提供漏洞掃描功能，因此，如果在容器優(yōu)化的操作系統(tǒng)中檢測(cè)到漏洞，則補(bǔ)丁會(huì)在可用時(shí)自動(dòng)推出。

Container-Optimized OS的開源

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

構(gòu)建Container-Optimized OS需要Google獨(dú)有的Chromium工具鏈和腳本。這些開發(fā)映像確實(shí)允許用戶訪問外殼程序，并且主要是供Google工程師用來構(gòu)建，測(cè)試和調(diào)試系統(tǒng)的。可以使用KVM運(yùn)行圖像或?qū)D像導(dǎo)入到計(jì)算引擎實(shí)例中。

管理Container-Optimized OS實(shí)例

Google Container-Optimized OS不包括程序包管理器，但是可以使用CoreOS Toolbox安裝其他工具，CoreOS Toolbox會(huì)啟動(dòng)一個(gè)容器，可以使用自己喜歡的調(diào)試或管理工具。

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

Google提供了一些不錯(cuò)的功能來幫助進(jìn)行生產(chǎn)部署。其中之一是Node Problem Detector，用于監(jiān)視容器優(yōu)化的OS實(shí)例的運(yùn)行狀況。使用Google Cloud Monitoring，可以使用Google Operations儀表板查看容量和錯(cuò)誤報(bào)告，并可視化集群的運(yùn)行狀況。

時(shí)間與Linux的systemd-timesyncd同步。使用與SNTP同步的程序包是有點(diǎn)不尋常的，特別是如果您有長(zhǎng)時(shí)間運(yùn)行的實(shí)例需要對(duì)時(shí)間進(jìn)行細(xì)粒度的控制，但是如果需要，可以始終在容器中安裝完整版本的NTPd。

升級(jí)在大多數(shù)情況下都會(huì)自動(dòng)應(yīng)用，并且有三個(gè)滾動(dòng)發(fā)布渠道可供選擇：dev，beta和穩(wěn)定版。這些通道提供了進(jìn)入功能管道的窗口，并允許滾動(dòng)升級(jí)群集。通常，群集中的一小部分將處于開發(fā)階段，beta階段會(huì)更多一些，而大多數(shù)處于穩(wěn)定狀態(tài)。這降低了遇到群集范圍的問題的風(fēng)險(xiǎn)。

自動(dòng)更新使用主動(dòng)/被動(dòng)根分區(qū)進(jìn)行，其中一個(gè)分區(qū)是“活動(dòng)”的，另一個(gè)分區(qū)是備份的。來自dev/beta/stable通道的映像更新將下載到被動(dòng)分區(qū)，并且引導(dǎo)管理器在引導(dǎo)時(shí)選擇最新版本。如果遇到錯(cuò)誤，則從舊分區(qū)引導(dǎo)系統(tǒng)。可以通過CLI界面手動(dòng)控制更新，但是大多數(shù)情況下使用自動(dòng)更新。

為云構(gòu)建的容器優(yōu)化的操作系統(tǒng)

容器優(yōu)化的操作系統(tǒng)并不是新的。之前曾評(píng)論過CoreOS，RancherOS，Red Hat Atomic等。我認(rèn)為我們處于操作系統(tǒng)開發(fā)這一行的最后階段，在該領(lǐng)域，操作系統(tǒng)只是整個(gè)云操作系統(tǒng)的一部分，就像共享庫(kù)為主機(jī)操作系統(tǒng)提供特定功能一樣。該操作系統(tǒng)是后臺(tái)基礎(chǔ)架構(gòu)的一部分，意味著開發(fā)人員可以專注于他們的應(yīng)用程序，而不是如何運(yùn)行它們。Bottlerocket和容器優(yōu)化的OS都能做到這一點(diǎn)。兩者都非常適合為其開發(fā)的云。

AWS的Bottlerocket融合了前輩的許多最佳創(chuàng)意，并增加了對(duì)多個(gè)云環(huán)境和容器協(xié)調(diào)器的支持，并在用例需要時(shí)創(chuàng)建了變體。Bottlerocket將在2020年的某個(gè)時(shí)候以GA形式提供。

與Bottlerocket相比，Google的Container-Optimized OS更接近microVM領(lǐng)域(例如AWS Fargate下的Firecracker技術(shù))。與許多Google技術(shù)一樣，Container-Optimized OS對(duì)如何完成事情持堅(jiān)定的態(tài)度，這通常是一件好事。

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

原文鏈接：

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