幾年前，你可以構建一個在虛擬機中運行應用程序的基礎設施，其中一些裸機用于傳統(tǒng)應用程序。隨著基礎設施的發(fā)展，虛擬機（VM）實現了更高水平的效率和敏捷性，但單靠虛擬機并不能完全滿足敏捷應用部署的需求。它們繼續(xù)作為運行許多應用程序的基礎，但越來越多的開發(fā)人員關注容器的發(fā)展趨勢，以更好地開發(fā)和部署應用程序——因為容器提供了更高級別的敏捷性和效率。

　　像Docker和Kubernetes這樣的容器技術正在成為構建容器化應用程序的主要標準。它們幫助企業(yè)擺脫了限制開發(fā)敏捷性的復雜性。容器、容器基礎設施和容器部署技術已經被證明是非常強大的抽象，可以應用于許多不同的用例。通過使用Kubernetes等技術，企業(yè)可以交付一個僅使用容器交付應用程序的云。

　　但是領先的私有云不僅僅是容器，容器并不適合所有的工作負載和用例。現在，大多數私有云基礎設施都需要包含用于管理基礎設施的裸機、用于傳統(tǒng)應用程序的虛擬機以及用于較新應用程序的容器。支持、管理和協(xié)調這三種方法的能力是運營效率的關鍵。

　　OpenStack目前是構建私有云的最佳選擇，它能夠管理網絡、存儲和計算基礎設施，支持來自一個控制平面的虛擬機、裸機和容器。雖然Kubernetes可以說是最受歡迎的容器編排器，并且已經改變了應用程序交付的方式，但它取決于可靠的云基礎設施的可用性，而OpenStack為托管應用程序提供了最全面的開源基礎設施。OpenStack的多租戶云基礎設施非常適合Kubernetes，擁有多個集成點、部署解決方案以及跨多個云聯(lián)合的能力。

　　在本文中，我們將探討容器如何在OpenStack中工作，查看各種用例，并提供讓容器成為易于采用和使用的技術的OpenStack等開源項目的概述。

　　容器和OpenStack的交匯有三個主要場景。

　　第一個場景稱為基礎設施容器，允許運維者使用容器來改善云基礎設施的部署、管理和運維。在這種情況下，容器設置在裸機基礎設施上，并允許對主機資源進行特權訪問。這種訪問使它們能夠直接利用計算、網絡和存儲資源，容器運行時通常不為用戶所見。這些容器隔離了每個應用程序所依賴的復雜的依賴關系集，同時允許基礎設施應用程序直接管理和操作底層系統(tǒng)資源。當要升級服務時，可以在不改變依賴關系的情況下處理升級。

　　新版本的OpenStack已經接受了這種基礎設施容器模型，現在通常使用編排工具和容器化服務的組合來管理OpenStack部署的整個生命周期。基礎設施容器使運維者能夠使用容器編排技術來解決許多問題，特別是快速迭代/升級現有軟件（包括OpenStack）。在容器中運行OpenStack有助于解決時間要求較高的挑戰(zhàn)，包括為服務添加新組件，快速升級軟件版本以及跨機器和數據中心快速滾動更新。這種方法將容器的敏捷性帶入了OpenStack的部署和升級。

　　第二個場景是關于在云基礎設施上托管容器化的應用程序框架。這可以包括Docker Swarm和Kubernetes等容器編排引擎（COE），或者更輕量級的容器專用服務和無服務器應用程序編程接口（API）。無論是在裸機還是虛擬機上，OpenStack社區(qū)都致力于確保可以在安全的、租戶隔離的云主機上交付容器化應用程序。驅動程序促進了這種場景，這些驅動程序允許像Kubernetes這樣的項目直接利用OpenStack API進行存儲、負載均衡和身份識別。它還包括用于按需提供托管Kubernetes集群和應用程序容器的API。借助這些功能，開發(fā)團隊可以編寫新的容器化應用程序，并在OpenStack云中快速提供Kubernetes集群。這是一個完整的應用程序生命周期解決方案，提供開發(fā)、測試和調試代碼所需的資源，并通過強大的自動化功能將應用程序部署到生產環(huán)境中。

　　在最后一個場景中，我們考慮了獨立OpenStack和COE部署之間的交互，在本文特指Kubernetes集群。跨OpenStack和Kubernetes集群的API的一致性和互操作性是此場景成功的關鍵。例如，Kubernetes可以直接連接到OpenStack Cinder托管卷，使用OpenStack Keystone作為授權和身份驗證后端，或者作為網絡覆蓋連接到OpenStack Neutron。反過來，OpenStack云可能與Neutron驅動共享相同的網絡覆蓋。第三種場景不太關注云服務的托管方式（無論是Kubernetes還是OpenStack），而是更多地關注獨立的服務如何交互。

　　正如介紹中指出的那樣，隨著容器的崛起，OpenStack的部署和管理發(fā)生了顯著變化，因為容器帶來了管理基礎設施代碼的新方法。以前的管理策略需要創(chuàng)建和維護重量級的“黃金”機器鏡像，或者使用脆弱的狀態(tài)維護配置管理系統(tǒng)。每種方法都有其復雜性和限制。進一步增加難度的是管理一系列服務，這些服務都需要各自的依賴關系，而這些依賴關系在每個發(fā)布中都會變化。如果沒有某種形式的應用程序隔離，解決依賴關系變得很困難。

　　基礎設施容器使新的OpenStack部署項目能夠在兩者之間取得平衡，同時很好地解決了依賴性問題。使用輕量級、獨立、自包含且通常為無狀態(tài)的應用程序容器，云運維者在部署復雜的控制平面時可獲得極大的靈活性。結合容器運行時和編排引擎，基礎設施容器使得快速部署、維護和升級復雜且高度可用的基礎設施成為可能。

　　在構建OpenStack集群時，選擇部署技術要考慮多個維度。運維者可以為其基本容器選擇Linux Containers（LXC）或Docker，使用預先構建的或定制的應用程序容器，并選擇用于編排的傳統(tǒng)配置管理系統(tǒng)或像Kubernetes這樣的更現代的方法。表1總結了現有的OpenStack部署項目及其基礎技術。

　　在這些部署系統(tǒng)之下，是為OpenStack代碼和支持服務構建一組容器的不同方法。OpenStack Ansible（OSA）和Kolla項目提供了自己的項目托管構建系統(tǒng)，而LOCI則側重于構建項目應用程序容器，不考慮特定的編排系統(tǒng)。在高層面上，它們之間的差異是：

　　每個云的基礎中，都有一個承載基礎設施服務的裸機服務器數據中心。即使是“無服務器計算”，也在數據中心硬件上的云上運行軟件。如何引導硬件基礎設施的問題是OpenStack軟件有獨特資格來解決的一個關鍵問題，它可以提供類似于云的裸機管理質量。

　　OpenStack Ironic提供裸機即服務。作為獨立服務，它可以發(fā)現裸機節(jié)點，在管理數據庫中對其進行編目，并管理整個服務器生命周期（包括注冊、提供、維護和退役）。當用作OpenStack Nova的驅動程序并結合全套OpenStack服務時，它可以提供強大的類似云的服務來管理整個裸機基礎設施。

　　這引出了一個問題：一個bootstrap OpenStack服務如何管理裸機基礎設施？一個典型的解決方案是使用與前面章節(jié)中所述相同的基于容器的安裝工具來創(chuàng)建種子安裝。這個通常被稱為“undercloud”的種子可以用來完全自動化裸機集群的管理，就好像它是一個虛擬化的云。

　　這帶來了機會，不僅可以在裸機云上運行OpenStack虛擬化，而且還可以運行裸機Kubernetes安裝（可以通過OpenStack服務充分利用身份、存儲、網絡和其他可用的云API）。

　　基礎設施容器和裸機基礎設施都很重要，但是當大多數人想到容器時，他們想到的是應用程序容器。容器提供的隔離、封裝和易維護性使其成為交付應用程序的理想解決方案。但是，容器仍然需要一個主機平臺來為它們提供服務，無論是裸機、公有云還是私有云。

　　Kubernetes是一個交付應用程序的平臺，可以與云API一起使用，從而實現關鍵基礎設施的自動交付（如永久存儲、負載均衡器、網絡和動態(tài)分配計算節(jié)點）。OpenStack提供云基礎設施，無論是作為本地私有云還是通過任何可用的公有或托管OpenStack云。

　　OpenStack是Kubernetes的首批上游云提供商之一，其活躍的開發(fā)團隊維護著“Kubernetes / Cloud Provider OpenStack”插件。這個插件允許Kubernetes利用Cinder塊存儲、Neutron和Octavia Load Balancers，以及使用Nova直接管理計算資源。使用非常簡單，只需將驅動程序部署到Kubernetes安裝中，設置一個標志來加載驅動程序，并提供本地用戶云憑證。

　　在OpenStack上安裝Kubernetes和其他應用程序框架有許多解決方案。提供容器框架的最簡單方法之一是使用Magnum——這是一個OpenStack項目，它提供了一個簡單的API來部署完全受管理的、有多個應用程序平臺（包括Kubernetes）選擇的集群。這是一個依賴于OpenStack API和云提供商插件的Kubernetes部署系統(tǒng)的例子。例如，現在它被用在CERN的OpenStack現場云以及合作伙伴云上管理超過200個獨立和聯(lián)合的Kubernetes安裝。如果你在首選OpenStack云中沒有可用的Magnum API，你可以使用任何其他Kubernetes安裝工具（例如kubeadm、Kubernetes Anywhere、Cross-Cloud或Kubespray）在OpenStack上安裝和管理Kubernetes集群。因為每個用戶都使用標準的Kubernetes，所以很容易啟用云提供商接口來利用存儲和負載均衡。

　　另一個OpenStack項目Zun提供了一個輕量級的容器服務API，用于管理單個容器，而無需管理服務器或集群。OpenStack托管的Kubernetes集群具有彈性，因為它可以直接通過Nova API向集群添加或刪除云資源來動態(tài)調整大小。另外，Kubernetes可以作為OpenStack Zun的容器后端，將pod基礎設施的管理轉交給Zun。它提供了一個更輕量級和多租戶容器服務API，用于運行容器而無需直接創(chuàng)建服務器。與Neutron和Cinder的直接集成被用于為單個容器提供網絡和卷。

　　最后，Qinling項目提供了“Function as a Service”，旨在提供一個支持無服務器功能的平臺，類似于Lambda、Azure Functions或Google Cloud Functions。它進一步抽象了容器的管理，允許用戶通過事件驅動的、無需服務器的計算體驗來加速開發(fā)（這種體驗可按需伸縮）。Qinling支持不同的容器編排后端（如Kubernetes和Docker swarm）、各種流行的功能包存儲后端（如本地存儲和OpenStack Swift）。

　　Kata Containers是一個新的開源項目。它是一個輕量級虛擬機的新穎實現，可無縫集成到容器生態(tài)系統(tǒng)中。Kata Containers與容器一樣輕而快，并與容器管理層（包括Docker和Kubernetes等常用編排工具）集成，同時還提供了虛擬機的安全優(yōu)勢。Kata Containers符合開放容器倡議（OCI）標準——OpenStack基金會是其中的一個活躍成員。Kata Containers由OpenStack基金會托管，但它是OpenStack項目之外的獨立項目，擁有自己的治理和社區(qū)。

　　轉向容器帶來了獨特挑戰(zhàn)，即在多租戶環(huán)境中保護用戶工作負載（有可信任和不可信任的工作負載）。Kata Containers使用硬件支持的隔離作為每個容器或pod中容器集合的邊界。這種方法解決了傳統(tǒng)容器架構中共享內核的安全問題。

　　Kata Containers非常適合基于事件的按需部署（如持續(xù)集成/持續(xù)交付）和更長時間運行的Web服務器應用程序。Kata還簡化了從傳統(tǒng)虛擬化環(huán)境向容器的過渡，因為它支持傳統(tǒng)訪客內核和設備通過功能。Kata Containers提供增強的安全性、可擴展性和更高的資源利用率，同時帶來堆棧的整體簡化。

　　選擇開源平臺的一個主要優(yōu)勢在于，跨平臺標準部署的接口的穩(wěn)定性。OpenStack基金會和CNCF都在為OpenStack云和Kubernetes集群維護互操作標準，確保庫、應用程序和驅動程序可以在所有平臺上運行，而不用管它們在哪里部署。這為并行集成創(chuàng)造了機會，允許OpenStack和Kubernetes利用彼此的資源。

　　Kubernetes社區(qū)中的OpenStack特別興趣小組（SIG-OpenStack）維護Cloud Provider OpenStack插件。除了在OpenStack上運行Kubernetes的云提供商接口外，它還保留了幾個驅動程序，允許Kubernetes利用單個OpenStack服務。這些驅動程序包括：

　　OpenStack和Kubernetes都支持由多種驅動程序支持的高度動態(tài)網絡模型。由于有這些標準網絡接口，可以輕松構建具有強大網絡集成的獨立OpenStack和Kubernetes集群。在OpenStack中，Kuryr項目生成了一個Common Network Interface（CNI）驅動程序，可將Neutron網絡提供給Docker和Kubernetes。另一方面，像Calico這樣的項目提供Neutron驅動程序，通過標準的Neutron API提供對Kubernetes網絡覆蓋的直接訪問。