想象一下，你的任務是從頭開始構建整個私有云基礎設施。你的預算有限，帶領一個小而專的團隊，而且被要求創(chuàng)造奇跡。

　　幾年前，你會構建一個基礎設施，包含在虛擬機中運行的應用程序，以及一些用于遺留應用程序的裸機。隨著基礎設施的發(fā)展，虛擬機（VM）可以實現(xiàn)更高的效率和靈活性，但僅靠虛擬機并不能完全滿足敏捷的應用程序部署方法的需求。它們繼續(xù)作為運行許多應用程序的基礎，但越來越多的開發(fā)人員正在尋求容器的新興趨勢，以進行前沿的應用程序開發(fā)和部署——因為容器提供了更高的靈活性和效率。

　　Docker和Kubernetes等容器技術正在成為構建容器化應用的領先標準。它們幫助組織消除了限制開發(fā)靈活性的復雜性。容器、容器基礎設施和容器部署技術已被證明是非常強大的抽象，可應用于許多不同的用例。使用Kubernetes等技術，組織可以提供僅使用容器進行應用程序交付的云。

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

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

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

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

　　第一種場景稱為基礎設施容器，允許運維人員以改進云基礎設施部署、管理和運維的方式利用容器。在此場景中，容器在裸機基礎設施上設置，并允許對主機資源進行特權訪問。此訪問權限允許它們直接利用容器運行時通常試圖不讓用戶感知的計算、網(wǎng)絡和存儲資源。容器隔離了每個應用程序所依賴的復雜依賴關系，同時仍允許基礎設施應用程序直接管理和操作底層系統(tǒng)資源。當需要升級服務時，可以在不改變依賴關系的情況下處理升級，從而不破壞共址服務。

　　新版本的OpenStack已經(jīng)采用了這種基礎設施容器模型，現(xiàn)在通過組合編排工具和容器化服務來管理OpenStack部署的整個生命周期是正常的。基礎設施容器使運維人員能夠使用容器編排技術來解決許多問題，尤其是在快速迭代/升級現(xiàn)有軟件（包括OpenStack）的過程中。在容器內運行OpenStack有助于運維人員解決Day 2的挑戰(zhàn)，包括為服務添加新組件、快速升級軟件版本以及跨機器和數(shù)據(jù)中心快速滾動更新。這種方法將容器的敏捷性好處帶給了OpenStack的部署和升級。

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

　　在最后一種場景中，我們考慮了獨立OpenStack和COE部署之間的交互，而本文特別考慮了Kubernetes集群�？鏞penStack和Kubernetes集群的API的一致性和互操作性是此方案成功的主要原因。例如，Kubernetes可以直接連接到OpenStack Cinder托管卷，使用OpenStack Keystone作為授權和身份驗證后端，或者連接到OpenStack Neutron作為OpenStack Kuryr的網(wǎng)絡覆蓋。相反，OpenStack云可能與Kubernetes集群共享相同的網(wǎng)絡覆蓋，其中包含用于Calico等項目的Neutron驅動程序。第三種場景不太關注如何托管云服務（無論是Kubernetes還是OpenStack），而是更關注獨立服務如何交互。

　　如引言中所述，OpenStack的部署和管理隨著容器的出現(xiàn)而發(fā)生了顯著變化，因為容器帶來了管理基礎設施代碼的新方法。以前的管理策略要么需要創(chuàng)建和維護重量級的黃金級機器鏡像，要么使用脆弱的狀態(tài)維護配置管理系統(tǒng)。每種方法都有其復雜性和限制。難上加難的是管理一系列服務——這些服務都需要自己的依賴關系，這些依賴關系隨發(fā)布版本的變化而變。如果沒有某種形式的應用程序隔離，解決依賴關系的問題會很困難甚至不可能。

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

　　在構建OpenStack集群時，選擇部署技術有幾個方面。運維人員可以為其基本容器選擇Linux Containers（LXC）或Docker，使用預構建或定制的應用程序容器，并選擇傳統(tǒng)的配置管理系統(tǒng)進行編排或更現(xiàn)代的方法（如Kubernetes）。表1總結了現(xiàn)有的OpenStack部署項目及其基礎技術。

　　每個部署系統(tǒng)的基礎是為OpenStack代碼和支持服務構建一組容器的不同方法。 OpenStack Ansible（OSA）和Kolla項目提供它們自己的項目管理構建系統(tǒng)，而LOCI專注于構建項目應用程序容器，而不管特定的編排系統(tǒng)。在更高的層次上，它們之間的差異是：

　　OSA的獨特之處在于它依賴于較低級別的LXC容器，并且具有用于創(chuàng)建LXC應用程序容器的自定義構建系統(tǒng)。

　　Kolla構建系統(tǒng)生成Docker容器（每個服務一個），以及用于初始化和管理OpenStack部署的支持容器。 Kolla容器具有高度可配置性，可選擇基本操作系統(tǒng)、源或包安裝，以及用于進一步定制的模板引擎。

　　構建OpenStack應用程序容器的最后一個選選擇是LOCI。LOCI還構建了一個Docker容器，并為每個項目提供了一個容器。LOCI專注于為所有常見版本快速生成緊湊且安全的容器，并期望它們可用作部署系統(tǒng)構建的基礎。

　　裸機基礎設施——OpenStack和解決Bootstrap問題

　　在每個云的基礎上，都有一個托管基礎設施服務的裸機服務器數(shù)據(jù)中心。甚至“無服務器計算”也在數(shù)據(jù)中心的硬件上運行云上的軟件。如何引導硬件基礎設施是一個關鍵問題，OpenStack軟件在這一點上很獨特，可為裸機管理提供類似云的質量。

　　OpenStack Ironic提供裸機即服務。作為一項獨立服務，它可以發(fā)現(xiàn)裸機節(jié)點，在管理數(shù)據(jù)庫中對它們進行編目，并管理整個服務器生命周期，包括注冊、配置、維護和退役。當用作OpenStack Nova的驅動程序并與OpenStack服務套件結合使用時，它為管理整個裸機基礎設施提供了強大的類似云的服務。

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

　　這不僅可以在裸機云上運行OpenStack虛擬化，還可以運行裸機Kubernetes安裝，從而利用OpenStack服務提供的身份、存儲、網(wǎng)絡和其他云API。 。

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

　　Kubernetes是一個提供最適合云API的應用程序的平臺，可以自動交付關鍵基礎設施，如永久存儲、負載均衡器、網(wǎng)絡和計算節(jié)點的動態(tài)分配。OpenStack提供云基礎設施，可以是本地私有云，也可以是任何公有或托管的OpenStack云。

　　OpenStack是Kubernetes的第一個上游云提供商之一，擁有一個活躍的開發(fā)團隊，負責維護“Kubernetes / Cloud Provider OpenStack”插件。該插件允許Kubernetes利用Cinder塊存儲、Neutron和Octavia負載均衡器，并使用Nova直接管理計算資源。使用provider就像將驅動程序部署到Kubernetes安裝，設置標志以加載驅動程序并提供本地用戶云憑證一樣簡單。

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

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

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

　　https://www.openstack.org/containers/leveraging-containers-and-openstack/

　　獲取更多開源云技術資訊&大咖交流&免費活動，歡迎添加開源云中文社區(qū)小助手，備注開源云！