幾年前，你可以構建一個(gè)在虛擬機中運行應用程序的基礎設施，其中一些裸機用于傳統應用程序。隨著(zhù)基礎設施的發(fā)展，虛擬機（VM）實(shí)現了更高水平的效率和敏捷性，但單靠虛擬機并不能完全滿(mǎn)足敏捷應用部署的需求。它們繼續作為運行許多應用程序的基礎，但越來(lái)越多的開(kāi)發(fā)人員關(guān)注容器的發(fā)展趨勢，以更好地開(kāi)發(fā)和部署應用程序——因為容器提供了更高級別的敏捷性和效率。
像Docker和Kubernetes這樣的容器技術(shù)正在成為構建容器化應用程序的主要標準。它們幫助企業(yè)擺脫了限制開(kāi)發(fā)敏捷性的復雜性。容器、容器基礎設施和容器部署技術(shù)已經(jīng)被證明是非常強大的抽象，可以應用于許多不同的用例。通過(guò)使用Kubernetes等技術(shù)，企業(yè)可以交付一個(gè)僅使用容器交付應用程序的云。
但是領(lǐng)先的私有云不僅僅是容器，容器并不適合所有的工作負載和用例。現在，大多數私有云基礎設施都需要包含用于管理基礎設施的裸機、用于傳統應用程序的虛擬機以及用于較新應用程序的容器。支持、管理和協(xié)調這三種方法的能力是運營(yíng)效率的關(guān)鍵。
OpenStack目前是構建私有云的最佳選擇，它能夠管理網(wǎng)絡(luò )、存儲和計算基礎設施，支持來(lái)自一個(gè)控制平面的虛擬機、裸機和容器。雖然Kubernetes可以說(shuō)是最受歡迎的容器編排器，并且已經(jīng)改變了應用程序交付的方式，但它取決于可靠的云基礎設施的可用性，而OpenStack為托管應用程序提供了最全面的開(kāi)源基礎設施。OpenStack的多租戶(hù)云基礎設施非常適合Kubernetes，擁有多個(gè)集成點(diǎn)、部署解決方案以及跨多個(gè)云聯(lián)合的能力。
在本文中，我們將探討容器如何在OpenStack中工作，查看各種用例，并提供讓容器成為易于采用和使用的技術(shù)的OpenStack等開(kāi)源項目的概述。
OpenStack中容器的總體視圖
容器和OpenStack的交匯有三個(gè)主要場(chǎng)景。
第一個(gè)場(chǎng)景稱(chēng)為基礎設施容器，允許運維者使用容器來(lái)改善云基礎設施的部署、管理和運維。在這種情況下，容器設置在裸機基礎設施上，并允許對主機資源進(jìn)行特權訪(fǎng)問(wèn)。這種訪(fǎng)問(wèn)使它們能夠直接利用計算、網(wǎng)絡(luò )和存儲資源，容器運行時(shí)通常不為用戶(hù)所見(jiàn)。這些容器隔離了每個(gè)應用程序所依賴(lài)的復雜的依賴(lài)關(guān)系集，同時(shí)允許基礎設施應用程序直接管理和操作底層系統資源。當要升級服務(wù)時(shí)，可以在不改變依賴(lài)關(guān)系的情況下處理升級。
新版本的OpenStack已經(jīng)接受了這種基礎設施容器模型，現在通常使用編排工具和容器化服務(wù)的組合來(lái)管理OpenStack部署的整個(gè)生命周期。基礎設施容器使運維者能夠使用容器編排技術(shù)來(lái)解決許多問(wèn)題，特別是快速迭代/升級現有軟件（包括OpenStack）。在容器中運行OpenStack有助于解決時(shí)間要求較高的挑戰，包括為服務(wù)添加新組件，快速升級軟件版本以及跨機器和數據中心快速滾動(dòng)更新。這種方法將容器的敏捷性帶入了OpenStack的部署和升級。
第二個(gè)場(chǎng)景是關(guān)于在云基礎設施上托管容器化的應用程序框架。這可以包括Docker Swarm和Kubernetes等容器編排引擎（COE），或者更輕量級的容器專(zhuān)用服務(wù)和無(wú)服務(wù)器應用程序編程接口（API）。無(wú)論是在裸機還是虛擬機上，OpenStack社區都致力于確保可以在安全的、租戶(hù)隔離的云主機上交付容器化應用程序。驅動(dòng)程序促進(jìn)了這種場(chǎng)景，這些驅動(dòng)程序允許像Kubernetes這樣的項目直接利用OpenStack API進(jìn)行存儲、負載均衡和身份識別。它還包括用于按需提供托管Kubernetes集群和應用程序容器的API。借助這些功能，開(kāi)發(fā)團隊可以編寫(xiě)新的容器化應用程序，并在OpenStack云中快速提供Kubernetes集群。這是一個(gè)完整的應用程序生命周期解決方案，提供開(kāi)發(fā)、測試和調試代碼所需的資源，并通過(guò)強大的自動(dòng)化功能將應用程序部署到生產(chǎn)環(huán)境中。
在最后一個(gè)場(chǎng)景中，我們考慮了獨立OpenStack和COE部署之間的交互，在本文特指Kubernetes集群。跨OpenStack和Kubernetes集群的API的一致性和互操作性是此場(chǎng)景成功的關(guān)鍵。例如，Kubernetes可以直接連接到OpenStack Cinder托管卷，使用OpenStack Keystone作為授權和身份驗證后端，或者作為網(wǎng)絡(luò )覆蓋連接到OpenStack Neutron。反過(guò)來(lái)，OpenStack云可能與Neutron驅動(dòng)共享相同的網(wǎng)絡(luò )覆蓋。第三種場(chǎng)景不太關(guān)注云服務(wù)的托管方式（無(wú)論是Kubernetes還是OpenStack），而是更多地關(guān)注獨立的服務(wù)如何交互。
OpenStack容器集成點(diǎn)
在容器上部署OpenStack基礎設施
正如介紹中指出的那樣，隨著(zhù)容器的崛起，OpenStack的部署和管理發(fā)生了顯著(zhù)變化，因為容器帶來(lái)了管理基礎設施代碼的新方法。以前的管理策略需要創(chuàng )建和維護重量級的“黃金”機器鏡像，或者使用脆弱的狀態(tài)維護配置管理系統。每種方法都有其復雜性和限制。進(jìn)一步增加難度的是管理一系列服務(wù)，這些服務(wù)都需要各自的依賴(lài)關(guān)系，而這些依賴(lài)關(guān)系在每個(gè)發(fā)布中都會(huì )變化。如果沒(méi)有某種形式的應用程序隔離，解決依賴(lài)關(guān)系變得很困難。
基礎設施容器使新的OpenStack部署項目能夠在兩者之間取得平衡，同時(shí)很好地解決了依賴(lài)性問(wèn)題。使用輕量級、獨立、自包含且通常為無(wú)狀態(tài)的應用程序容器，云運維者在部署復雜的控制平面時(shí)可獲得極大的靈活性。結合容器運行時(shí)和編排引擎，基礎設施容器使得快速部署、維護和升級復雜且高度可用的基礎設施成為可能。
在構建OpenStack集群時(shí)，選擇部署技術(shù)要考慮多個(gè)維度。運維者可以為其基本容器選擇Linux Containers（LXC）或Docker，使用預先構建的或定制的應用程序容器，并選擇用于編排的傳統配置管理系統或像Kubernetes這樣的更現代的方法。表1總結了現有的OpenStack部署項目及其基礎技術(shù)。
在這些部署系統之下，是為OpenStack代碼和支持服務(wù)構建一組容器的不同方法。OpenStack Ansible（OSA）和Kolla項目提供了自己的項目托管構建系統，而LOCI則側重于構建項目應用程序容器，不考慮特定的編排系統。在高層面上，它們之間的差異是：
- OSA的獨特之處在于它依賴(lài)于較低層次的LXC容器，并且具有用于創(chuàng )建LXC應用程序容器的自定義構建系統。
- Kolla構建系統生成Docker容器（每個(gè)服務(wù)都有一個(gè)容器），還有支持初始化和管理OpenStack部署的容器。Kolla容器具有高度可配置性，可選擇基本操作系統、源或軟件包安裝，以及用于進(jìn)一步定制的模板引擎。
- 構建OpenStack應用程序容器的最終選擇是LOCI。LOCI也構建Docker容器，為每個(gè)項目提供一個(gè)容器。LOCI專(zhuān)注于快速生產(chǎn)緊湊和安全的容器，并期望它們被部署系統用為基礎。
裸機基礎設施——OpenStack和解決Bootstrap問(wèn)題
每個(gè)云的基礎中，都有一個(gè)承載基礎設施服務(wù)的裸機服務(wù)器數據中心。即使是“無(wú)服務(wù)器計算”，也在數據中心硬件上的云上運行軟件。如何引導硬件基礎設施的問(wèn)題是OpenStack軟件有獨特資格來(lái)解決的一個(gè)關(guān)鍵問(wèn)題，它可以提供類(lèi)似于云的裸機管理質(zhì)量。
OpenStack Ironic提供裸機即服務(wù)。作為獨立服務(wù)，它可以發(fā)現裸機節點(diǎn)，在管理數據庫中對其進(jìn)行編目，并管理整個(gè)服務(wù)器生命周期（包括注冊、提供、維護和退役）。當用作OpenStack Nova的驅動(dòng)程序并結合全套OpenStack服務(wù)時(shí)，它可以提供強大的類(lèi)似云的服務(wù)來(lái)管理整個(gè)裸機基礎設施。
這引出了一個(gè)問(wèn)題：一個(gè)bootstrap OpenStack服務(wù)如何管理裸機基礎設施？一個(gè)典型的解決方案是使用與前面章節中所述相同的基于容器的安裝工具來(lái)創(chuàng )建種子安裝。這個(gè)通常被稱(chēng)為“undercloud”的種子可以用來(lái)完全自動(dòng)化裸機集群的管理，就好像它是一個(gè)虛擬化的云。
這帶來(lái)了機會(huì )，不僅可以在裸機云上運行OpenStack虛擬化，而且還可以運行裸機Kubernetes安裝（可以通過(guò)OpenStack服務(wù)充分利用身份、存儲、網(wǎng)絡(luò )和其他可用的云API）。
在OpenStack上交付基于容器的應用程序
基礎設施容器和裸機基礎設施都很重要，但是當大多數人想到容器時(shí)，他們想到的是應用程序容器。容器提供的隔離、封裝和易維護性使其成為交付應用程序的理想解決方案。但是，容器仍然需要一個(gè)主機平臺來(lái)為它們提供服務(wù)，無(wú)論是裸機、公有云還是私有云。
Kubernetes是一個(gè)交付應用程序的平臺，可以與云API一起使用，從而實(shí)現關(guān)鍵基礎設施的自動(dòng)交付（如永久存儲、負載均衡器、網(wǎng)絡(luò )和動(dòng)態(tài)分配計算節點(diǎn)）。OpenStack提供云基礎設施，無(wú)論是作為本地私有云還是通過(guò)任何可用的公有或托管OpenStack云。
OpenStack是Kubernetes的首批上游云提供商之一，其活躍的開(kāi)發(fā)團隊維護著(zhù)“Kubernetes / Cloud Provider OpenStack”插件。這個(gè)插件允許Kubernetes利用Cinder塊存儲、Neutron和Octavia Load Balancers，以及使用Nova直接管理計算資源。使用非常簡(jiǎn)單，只需將驅動(dòng)程序部署到Kubernetes安裝中，設置一個(gè)標志來(lái)加載驅動(dòng)程序，并提供本地用戶(hù)云憑證。
在OpenStack上安裝Kubernetes和其他應用程序框架有許多解決方案。提供容器框架的最簡(jiǎn)單方法之一是使用Magnum——這是一個(gè)OpenStack項目，它提供了一個(gè)簡(jiǎn)單的API來(lái)部署完全受管理的、有多個(gè)應用程序平臺（包括Kubernetes）選擇的集群。這是一個(gè)依賴(lài)于OpenStack API和云提供商插件的Kubernetes部署系統的例子。例如，現在它被用在CERN的OpenStack現場(chǎng)云以及合作伙伴云上管理超過(guò)200個(gè)獨立和聯(lián)合的Kubernetes安裝。如果你在首選OpenStack云中沒(méi)有可用的Magnum API，你可以使用任何其他Kubernetes安裝工具（例如kubeadm、Kubernetes Anywhere、Cross-Cloud或Kubespray）在OpenStack上安裝和管理Kubernetes集群。因為每個(gè)用戶(hù)都使用標準的Kubernetes，所以很容易啟用云提供商接口來(lái)利用存儲和負載均衡。
另一個(gè)OpenStack項目Zun提供了一個(gè)輕量級的容器服務(wù)API，用于管理單個(gè)容器，而無(wú)需管理服務(wù)器或集群。OpenStack托管的Kubernetes集群具有彈性，因為它可以直接通過(guò)Nova API向集群添加或刪除云資源來(lái)動(dòng)態(tài)調整大小。另外，Kubernetes可以作為OpenStack Zun的容器后端，將pod基礎設施的管理轉交給Zun。它提供了一個(gè)更輕量級和多租戶(hù)容器服務(wù)API，用于運行容器而無(wú)需直接創(chuàng )建服務(wù)器。與Neutron和Cinder的直接集成被用于為單個(gè)容器提供網(wǎng)絡(luò )和卷。
最后，Qinling項目提供了“Function as a Service”，旨在提供一個(gè)支持無(wú)服務(wù)器功能的平臺，類(lèi)似于Lambda、Azure Functions或Google Cloud Functions。它進(jìn)一步抽象了容器的管理，允許用戶(hù)通過(guò)事件驅動(dòng)的、無(wú)需服務(wù)器的計算體驗來(lái)加速開(kāi)發(fā)（這種體驗可按需伸縮）。Qinling支持不同的容器編排后端（如Kubernetes和Docker swarm）、各種流行的功能包存儲后端（如本地存儲和OpenStack Swift）。
Kata Containers——通過(guò)虛擬化保證應用安全
Kata Containers是一個(gè)新的開(kāi)源項目。它是一個(gè)輕量級虛擬機的新穎實(shí)現，可無(wú)縫集成到容器生態(tài)系統中。Kata Containers與容器一樣輕而快，并與容器管理層（包括Docker和Kubernetes等常用編排工具）集成，同時(shí)還提供了虛擬機的安全優(yōu)勢。Kata Containers符合開(kāi)放容器倡議（OCI）標準——OpenStack基金會(huì )是其中的一個(gè)活躍成員。Kata Containers由OpenStack基金會(huì )托管，但它是OpenStack項目之外的獨立項目，擁有自己的治理和社區。
轉向容器帶來(lái)了獨特挑戰，即在多租戶(hù)環(huán)境中保護用戶(hù)工作負載（有可信任和不可信任的工作負載）。Kata Containers使用硬件支持的隔離作為每個(gè)容器或pod中容器集合的邊界。這種方法解決了傳統容器架構中共享內核的安全問(wèn)題。
Kata Containers非常適合基于事件的按需部署（如持續集成/持續交付）和更長(cháng)時(shí)間運行的Web服務(wù)器應用程序。Kata還簡(jiǎn)化了從傳統虛擬化環(huán)境向容器的過(guò)渡，因為它支持傳統訪(fǎng)客內核和設備通過(guò)功能。Kata Containers提供增強的安全性、可擴展性和更高的資源利用率，同時(shí)帶來(lái)堆棧的整體簡(jiǎn)化。
并行的OpenStack和Kubernetes集成
選擇開(kāi)源平臺的一個(gè)主要優(yōu)勢在于，跨平臺標準部署的接口的穩定性。OpenStack基金會(huì )和CNCF都在為OpenStack云和Kubernetes集群維護互操作標準，確保庫、應用程序和驅動(dòng)程序可以在所有平臺上運行，而不用管它們在哪里部署。這為并行集成創(chuàng )造了機會(huì )，允許OpenStack和Kubernetes利用彼此的資源。
Kubernetes社區中的OpenStack特別興趣小組（SIG-OpenStack）維護Cloud Provider OpenStack插件。除了在OpenStack上運行Kubernetes的云提供商接口外，它還保留了幾個(gè)驅動(dòng)程序，允許Kubernetes利用單個(gè)OpenStack服務(wù)。這些驅動(dòng)程序包括：
- 兩個(gè)獨立的Cinder驅動(dòng)程序。Flex Volume驅動(dòng)程序使用基于exec的模型與驅動(dòng)程序進(jìn)行交互，為容器編排系統使用標準接口的Container Storage Interface（CSI）驅動(dòng)程序將任意存儲系統暴露給其容器工作負載。通過(guò)支持70多種存儲驅動(dòng)程序，這些驅動(dòng)程序可以通過(guò)一個(gè)Cinder API與大量經(jīng)過(guò)測試的專(zhuān)有和開(kāi)源存儲設備連接。
- 基于webhook的Keystone認證和授權接口。每個(gè)模式、認證和授權，都可以彼此獨立配置。雖然這項工作還在進(jìn)行中，但該接口支持軟多租戶(hù)（使用OpenStack Keystone支持Kubernetes RBAC）。
OpenStack和Kubernetes都支持由多種驅動(dòng)程序支持的高度動(dòng)態(tài)網(wǎng)絡(luò )模型。由于有這些標準網(wǎng)絡(luò )接口，可以輕松構建具有強大網(wǎng)絡(luò )集成的獨立OpenStack和Kubernetes集群。在OpenStack中，Kuryr項目生成了一個(gè)Common Network Interface（CNI）驅動(dòng)程序，可將Neutron網(wǎng)絡(luò )提供給Docker和Kubernetes。另一方面，像Calico這樣的項目提供Neutron驅動(dòng)程序，通過(guò)標準的Neutron API提供對Kubernetes網(wǎng)絡(luò )覆蓋的直接訪(fǎng)問(wèn)。
