引言
想像一下，你的任務是從頭開始構建整個私有雲基礎設施。你的預算有限，帶領一個小而專的團隊，而且被要求創造奇蹟。
幾年前，你會構建一個基礎設施，包含在虛擬機中運行的應用程式，以及一些用於遺留應用程式的裸機。隨著基礎設施的發展，虛擬機（VM）可以實現更高的效率和靈活性，但僅靠虛擬機並不能完全滿足敏捷的應用程式部署方法的需求。它們繼續作為運行許多應用程式的基礎，但越來越多的開發人員正在尋求容器的新興趨勢，以進行前沿的應用程式開發和部署——因為容器提供了更高的靈活性和效率。
Docker和Kubernetes等容器技術正在成為構建容器化應用的領先標準。它們幫助組織消除了限制開發靈活性的複雜性。容器、容器基礎設施和容器部署技術已被證明是非常強大的抽象，可應用於許多不同的用例。使用Kubernetes等技術，組織可以提供僅使用容器進行應用程式交付的雲。
但是，領先的私有雲不僅僅是容器，容器也不適合所有工作負載和用例。如今，大多數私有雲基礎設施都需要包含用於管理基礎設施的裸機、用於遺留應用程式的虛擬機以及用於新應用程式的容器。支持、管理和協調這三種方法的能力是運營效率的關鍵所在。
OpenStack是目前構建私有雲的最佳選擇，具有管理網絡、存儲和計算基礎設施的能力，支持來自一個控制平面的虛擬機、裸機和容器。雖然Kubernetes可以說是最受歡迎的容器編排器並且已經改變了應用程式的交付，但它取決於是否有可靠的雲基礎設施，而OpenStack為託管應用程式提供了最全面的開源基礎設施。OpenStack的多租戶雲基礎設施非常適合Kubernetes，擁有多個集成點、部署解決方案和跨多個雲聯合的能力。
在本文中，我們將探討容器如何在OpenStack中工作，檢查各種用例，並提供OpenStack等開源項目的概述——這有助於使容器成為易於採用和利用的技術。
I. OpenStack中容器的高級視圖
容器和OpenStack的交匯有三種主要場景。
第一種場景稱為基礎設施容器，允許運維人員以改進雲基礎設施部署、管理和運維的方式利用容器。在此場景中，容器在裸機基礎設施上設置，並允許對主機資源進行特權訪問。此訪問權限允許它們直接利用容器運行時通常試圖不讓用戶感知的計算、網絡和存儲資源。容器隔離了每個應用程式所依賴的複雜依賴關係，同時仍允許基礎設施應用程式直接管理和操作底層系統資源。當需要升級服務時，可以在不改變依賴關係的情況下處理升級，從而不破壞共址服務。
新版本的OpenStack已經採用了這種基礎設施容器模型，現在通過組合編排工具和容器化服務來管理OpenStack部署的整個生命周期是正常的。基礎設施容器使運維人員能夠使用容器編排技術來解決許多問題，尤其是在快速迭代/升級現有軟體（包括OpenStack）的過程中。在容器內運行OpenStack有助於運維人員解決Day 2的挑戰，包括為服務添加新組件、快速升級軟體版本以及跨機器和數據中心快速滾動更新。這種方法將容器的敏捷性好處帶給了OpenStack的部署和升級。
第二種場景涉及在雲基礎設施上託管容器化應用程式框架。包括像Docker Swarm和Kubernetes這樣的Container Orchestration Engines（COE），或者更輕量級的容器專用服務和無伺服器API。無論是在裸機還是虛擬機上，OpenStack社區都致力於確保在安全、租戶隔離的雲主機上提供容器化應用程式。驅動程序推動了這種場景，這些驅動程序允許像Kubernetes這樣的項目直接利用OpenStack API進行存儲、負載均衡和身份識別。它還包括用於按需配置託管Kubernetes集群和應用程式容器的API。藉助這些功能，開發團隊可以編寫新的容器化應用程式，並在OpenStack雲上快速配置Kubernetes集群。它是一個完整的應用程式生命周期解決方案，提供開發、測試和調試代碼所需的資源，並具有強大的自動化功能，可將應用程式部署到生產環境中。
在最後一種場景中，我們考慮了獨立OpenStack和COE部署之間的交互，而本文特別考慮了Kubernetes集群。跨OpenStack和Kubernetes集群的API的一致性和互操作性是此方案成功的主要原因。例如，Kubernetes可以直接連接到OpenStack Cinder託管卷，使用OpenStack Keystone作為授權和身份驗證後端，或者連接到OpenStack Neutron作為OpenStack Kuryr的網絡覆蓋。相反，OpenStack雲可能與Kubernetes集群共享相同的網絡覆蓋，其中包含用於Calico等項目的Neutron驅動程序。第三種場景不太關注如何託管雲服務（無論是Kubernetes還是OpenStack），而是更關注獨立服務如何交互。
II OpenStack容器集成點
在容器上部署OpenStack基礎設施
如引言中所述，OpenStack的部署和管理隨著容器的出現而發生了顯著變化，因為容器帶來了管理基礎設施代碼的新方法。以前的管理策略要麼需要創建和維護重量級的黃金級機器鏡像，要麼使用脆弱的狀態維護配置管理系統。每種方法都有其複雜性和限制。難上加難的是管理一系列服務——這些服務都需要自己的依賴關係，這些依賴關係隨發布版本的變化而變。如果沒有某種形式的應用程式隔離，解決依賴關係的問題會很困難甚至不可能。
基礎設施容器使新的OpenStack部署項目能夠在兩者之間取得平衡，同時很好地解決依賴關係問題。使用輕量級、獨立、自包含且通常無狀態的應用程式容器，雲運維人員在部署複雜控制平面時可獲得極大的靈活性。結合容器運行時和編排引擎，基礎設施容器可以快速部署、維護和升級複雜且高度可用的基礎設施。
在構建OpenStack集群時，選擇部署技術有幾個方面。運維人員可以為其基本容器選擇Linux Containers（LXC）或Docker，使用預構建或定製的應用程式容器，並選擇傳統的配置管理系統進行編排或更現代的方法（如Kubernetes）。表1總結了現有的OpenStack部署項目及其基礎技術。
每個部署系統的基礎是為OpenStack代碼和支持服務構建一組容器的不同方法。 OpenStack Ansible（OSA）和Kolla項目提供它們自己的項目管理構建系統，而LOCI專注於構建項目應用程式容器，而不管特定的編排系統。在更高的層次上，它們之間的差異是：
OSA的獨特之處在於它依賴於較低級別的LXC容器，並且具有用於創建LXC應用程式容器的自定義構建系統。
Kolla構建系統生成Docker容器（每個服務一個），以及用於初始化和管理OpenStack部署的支持容器。 Kolla容器具有高度可配置性，可選擇基本作業系統、源或包安裝，以及用於進一步定製的模板引擎。
構建OpenStack應用程式容器的最後一個選選擇是LOCI。LOCI還構建了一個Docker容器，並為每個項目提供了一個容器。LOCI專注於為所有常見版本快速生成緊湊且安全的容器，並期望它們可用作部署系統構建的基礎。
裸機基礎設施——OpenStack和解決Bootstrap問題
在每個雲的基礎上，都有一個託管基礎設施服務的裸機伺服器數據中心。甚至「無伺服器計算」也在數據中心的硬體上運行雲上的軟體。如何引導硬體基礎設施是一個關鍵問題，OpenStack軟體在這一點上很獨特，可為裸機管理提供類似雲的質量。
OpenStack Ironic提供裸機即服務。作為一項獨立服務，它可以發現裸機節點，在管理資料庫中對它們進行編目，並管理整個伺服器生命周期，包括註冊、配置、維護和退役。當用作OpenStack Nova的驅動程序並與OpenStack服務套件結合使用時，它為管理整個裸機基礎設施提供了強大的類似雲的服務。
這提出了一個問題：引導OpenStack服務如何管理裸機基礎設施？典型的解決方案是使用上一節中描述的基於容器的安裝工具創建種子安裝。這種種子通常被稱為「undercloud」，可用於完全自動化裸機集群的管理，就像它是虛擬化雲一樣。
這不僅可以在裸機雲上運行OpenStack虛擬化，還可以運行裸機Kubernetes安裝，從而利用OpenStack服務提供的身份、存儲、網絡和其他雲API。 。
在OpenStack上提供基於容器的應用程式
基礎設施容器和裸機基礎設施很重要，但當大多數人想到容器時，他們會想到應用容器。容器提供的隔離、包裝和易維護性使其成為交付應用的理想解決方案。但是，無論是裸機、公有雲還是私有雲，容器仍然需要主機平臺來提供服務。
Kubernetes是一個提供最適合雲API的應用程式的平臺，可以自動交付關鍵基礎設施，如永久存儲、負載均衡器、網絡和計算節點的動態分配。OpenStack提供雲基礎設施，可以是本地私有雲，也可以是任何公有或託管的OpenStack雲。
OpenStack是Kubernetes的第一個上遊雲提供商之一，擁有一個活躍的開發團隊，負責維護「Kubernetes / Cloud Provider OpenStack」插件。該插件允許Kubernetes利用Cinder塊存儲、Neutron和Octavia負載均衡器，並使用Nova直接管理計算資源。使用provider就像將驅動程序部署到Kubernetes安裝，設置標誌以加載驅動程序並提供本地用戶雲憑證一樣簡單。
有許多解決方案可以在OpenStack上安裝Kubernetes和其他應用程式框架。提供容器框架的最簡單方法之一是使用Magnum——這是一個OpenStack項目，提供一個簡單的API來部署完全託管的集群（有多個應用程式平臺可以，包括Kubernetes）。這是Kubernetes部署系統的一個例子，它依賴於OpenStack API和雲提供程序插件。例如，現在它被用於在CERN的OpenStack現場雲以及合作夥伴雲上，管理200多個獨立和聯合的Kubernetes安裝。如果你在首選的OpenStack雲中沒有可用的Magnum API，則可以使用任何其他Kubernetes安裝工具（如kubeadm、Kubernetes Anywhere、Cross-Cloud或Kubespray）在OpenStack上安裝和管理Kubernetes集群。由於每個都使用標準Kubernetes，因此很容易使雲provider接口能夠利用存儲和負載均衡。
另一個OpenStack項目Zun提供了一個輕量級的容器服務API，用於管理單個容器，而無需管理伺服器或集群。OpenStack託管的Kubernetes集群具有彈性，因為可以通過Nova API直接向集群添加或刪除雲資源來動態調整大小。或者，Kubernetes可以作為OpenStack Zun的容器後端，將pod基礎設施的管理權轉交給Zun。它為運行容器提供了輕量級和多租戶容器服務API，無需直接創建伺服器。與Neutron和Cinder的直接集成用於為各個容器提供網絡和卷。
最後，Qinling項目提供「功能即服務」，旨在提供支持無伺服器功能的平臺，類似於Lambda、Azure Functions和Google Cloud Functions。它進一步抽象了容器的管理，並允許用戶通過按需擴展的事件驅動、無伺服器計算體驗來加速開發。Qinling支持不同的容器編排後端（如Kubernetes和Docker swarm）、各種流行的功能包存儲後端（如本地存儲和OpenStack Swift）。
原文連結：
https://www.openstack.org/containers/leveraging-containers-and-openstack/
獲取更多開源雲技術資訊&大咖交流&免費活動，歡迎添加開源雲中文社區小助手，備註開源雲！
（長按識別二維碼添加）