[[133846]]

容器技術目前在計算領域可謂炙手可熱。它們能夠以高效而切實的方式幫助我們完成應用程序部署工作。不過當復雜性較高的應用程序被拆分至多種容器當中時，情況將因此而變得更加復雜。面對這種情況，容器機制往往需要能夠更為有效地彼此協作，而這也正是容器編排方案的誕生意義。編排機制能夠簡化容器體系的管理難度，從而確保不同容器之間能夠順暢對接并以適當的方式實現協作，從而最終達成我們為其賦予的功能預期。

云環境之下的容器編排類工具可謂多種多樣，那么問題來了——管理員應該如何從中挑選出最適合自己的解決方案?Gigaspaces公司創始人兼CTO Nati Shalom和他的幾位同事就這一話題展開了探討，希望能夠幫助管理員們通過本次OpenStack溫哥華峰會找到上述問題的答案。他們的對話將主要圍繞幾款不同容器編排工具之間的差異而展開，其中包括Kubernetes、Heat、Fleet、MaestroNG以及TOSCA。除此之外，他們還將提供適用于不同用例的、能夠切實幫助各位挑選出理想解決方案的***實踐。

Nati將在本次OpenStack溫哥華峰會上以主題演講的形式帶來更多信息，我們的關注重點則集中在他如何看待容器、編排機制以及OpenStack的未來發展方向層面。

Q：如何從最簡潔的表達出發，您希望各位與會者能夠在此次OpenStack峰會當中獲得怎樣的啟示?

A：本次對話主要關注各類熱門編排方案，旨在勾勒出各方案之間的主要差異以及潛在協同疚——而后深入剖析***實踐，探討如何針對特定任務選擇正確的工具。由于我們的時間有限，因此我們恐怕無法為每款工具提供現場示例或者從整體用戶體驗層面作出比較，不過專注于解決各類編排方案之間、經常導致語義區別的差異之處。

為了回答這個問題——云管理員需要首先整理出幾個關鍵性的待驗證問題。其中每一個問題可能都會為當前任務帶來某種***工具/解決方案。我會根據大家的具體環境將這些問題進行分類，而后參考大家在管理這些環境時所使用的具體工具，***是考量各位需要的編排機制屬于哪種層級——到底是面向特定項目的一次性方案還是面向長期或者全局的通用型方案，再將其與應用程序堆棧結合并進行綜合評估。

因此作為***步，大家需要考慮自己的運行環境到底屬于純OpenStack、純容器還是可能包含有傳統基礎設施的混合型模式(例如vSphere或者物理硬件)。

如果大家選擇的是純OpenStack環境，那么各位的***選項肯定是Heat。將其與其它互補性堆棧相結合能夠很好地完成軟件配置、監控、任務流程以及管理政策等日常工作。其中一部分可能由OpenStack下轄的項目直接提供，而某些情況下大家可能應該更傾向于使用其它相關開源項目。如果各位有計劃遷移至純容器環境，那么***方案很可能會是Docker。就目前的情況看，我們需要整合一大堆互補性堆棧才能實現常見的日志、監控以及任務流程管理工作——舉例來講，Kubernetes能夠提供一套專門面向微服務架構的高級編排方案。如果大家的環境屬于包含有容器、配置管理工具(例如Puppet、Chef以及SaltStack)、私有云(例如OpenStack以及VMware)或者公有云(例如Amazon以及谷歌)的混合型體系，那么最理想的選擇應該是基于TOSCA的編排方案——其同時不會對基礎設施以及工具鏈的具體類型提出任何限制。很明顯，上述結論并不包括已經在Chef或者Puppet等工具身上投入了重金的現有客戶，在這種情況下我們的***方案是選擇那些能夠以內置方式支持此類框架的編排工具——毫無疑問。

接下來的問題在于，大家到底是希望這套編排方案僅僅針對單一產品/項目，還是要選擇一套適用于多數應用程序的通用型機制，而后者的具體效果當然會更好一些。

很多產品本身就自帶編排方案，而且其針對該應用程序的特定用例進行了量身訂做——最明顯的例子就是Cloud Foundry/Bosh以及Hadoop/Yarn這兩套組合。其它編排工具則通常屬于通用型解決方案，其中內置在面向各類應用程序的模板，它們在某些情況下也能帶來良好的表現。舉例來說，一部分編排工具專門針對NFV等網絡應用程序進行了優化與調整，其它一些則主要面向大數據類用例，因此在這方面即使我個人更傾向于選擇省力省心的通用型編排工具、但必須承認專用方案才最破例我自己的目標工作負載。

另一大重要考量標準就是可嵌入能力，將編排工具作為另一款產品的組成部分可不像為自己的數據中心運營體系選擇編排工具那么簡單。在這種情況下，我一般會考慮那些能夠將運行時負擔控制在***程度的輕量級解決方案，其往往只屬于一套代碼庫。大家也許還需要決定自己到底是要選擇一套能夠面向整個生命周期內各個后部署層面(包括監控、自我修復以及自動規模伸縮)的編排工具，還是單純強調安裝或者配置流程。

一部分編排工具將自身限定為了主要用于處理安裝流程，但也有一些編排工具能夠涵蓋應用程序整個生命周期當中更為廣泛的后部署管理任務——其中包括監控、更新政策、規模伸縮以及自我修復等等。

***，很重要的一點就是了解自己的堆棧在網絡、DevOps工具鏈、監控以及語言等層面到底表現出什么樣的面貌。很多DevOps環境都是由一系列開源項目所構成，這些項目各自負責日志、監控以及生命周期中的其它各方面工作。這類工具組合的發展變化速度很快。一部分編排工具當中內置有用于此類工具的整合機制，但其實際效果在將新型工具納入整個體系時仍然比較有限。這種情況在此類工具恰好屬于其自有集群的一部分時表現得尤為突出，因此我們需要在應用程序編排與特定工具編排之間找到更為明確且可行的高級關系。考慮到這一情況，我們最終需要編排領域中的編排工具——最明顯的例子就是應用程序編排與網絡編排，或者應用程序編排與大數據編排，其中應用程序編排機制需要與工具編排進行交互并將一部分職責分配給后者。

#p#

Q:您認為不同格式之間正在出現匯聚趨勢?或者說，其中一到兩種最終是否會在云環境下壓倒其它備選方案?

A:從我的角度來看，我敢說未來很可能形成三大陣營并立的局面：

1.純Docker(或者大部分由Docker構成)——此類工具將由Go語言編寫而成，且將作為現有Docker項目的擴展成果出現。在這一陣營中，大部分占主導地位的框架可能都將由Docker自身所提供(例如Swarm、Compose或者Machine等)。

2.特定基礎設施——這些工具將大部分負責提供映射至特定基礎設施的核心功能，此陣營的主要目標面向那些有意將應用程序單純部署在特定環境下的受眾群體。Amazon Cloud Formation以及OpenStack Heat正是這一類別中的典型代表。

3.混合型——對于各類環境而言，其編排機制天然擁有混合屬性，其中包含有大量除Docker之外的其它技術堆棧，例如Chef、Puppet或者Ansible，又或者VMware、OpenStack以及AWS等云方案。我認為在這一陣營當中，TOSCA很有可能成為其最為重要的特定編排選項，這也是由其內置中立性所決定的。

Q:縱觀這次涉及范疇極廣的OpenStack溫哥華峰會，其中最令您感到興奮的內容是什么?您認為未來我們面前又會出現哪些重大的發展議題?

A:在NFV(即網絡功能虛擬化)以及客戶用例范疇，我們了解到客戶們如何實際使用OpenStack，這一點非常令人興奮。我當然也希望聽到更多與OpenStack發展路線圖相關的消息——只有對未來版本內正處于規劃中的內容有所了解，才能作出更有針對性的探討。***一個問題的答案是，網絡：峰會一直是與開發人員及決策制定者們進行交流的一片獨特舞臺，我們也能在這里了解到與人們接觸并為OpenStack項目作出貢獻相關的令人振奮的消息。

Q:作為OpenStack這樣一個項目，在未來的發展過程中需要關注哪些重點內容?Liberty版本會帶來哪些新特性，特別是在編排方面?

A:我個人認為，OpenStack如果能夠能夠找到正確的途徑、引導更多云服務供應商為其提供或者添加支持，那么這一項目的未來成功將更有保障，其中包括那些被廣泛視為OpenStack競爭對手的AWS、谷歌以及微軟Azure。同樣的，如果OpenStack項目能夠以類似于其它高人氣開源項目的方式激勵人們為其提供原生支持，那么其未來同樣會更加光芒四射。

我認為到目前為止，人們的大多數關注重點還集中在OpenStack作為Amazon替代方案的可能性層面。就我個人看來，這樣的戰略思路可能會導致OpenStack在大多數實踐項目中缺乏施展空間。我覺得VMware為OpenStack提供支持就是個很好的例子，它證明了潛在競爭對手的基礎設施同樣可以與OpenStack相對接、相兼容。如果我們能夠簡化其中的流程及難度，引導其它基礎設施供應商將OpenStack兼容能力并入OpenStack API，那么我們所獲得的成就將遠遠超過單純將OpenStack作為一套可行的競爭性替代方案。基本上，我認為包容性而非排他性才是至關重要的，這也正是開源的基本原則。

如果從編排機制的角度思考，我認為***的方式就是讓Heat能夠成為其它編排框架與OpenStack相融合的集成點，也就是我們之前談到過的那些框架方案。在這種情況下，將TOSCA支持能力添加到Heat當中也將成為正確的發展步調，從而通過Heat翻譯器項目為OpenStack帶來明確的下一步發展方向。

在我看來，OpenStack Kilo與Liberty所帶來的各類令人興奮的功能特性都是在納入眾多最適合私有云環境或者NFV的獨特能力。其中包括對裸機的支持能力(Ironic)，即將推出的共享文件系統(Manila)再加上允許用戶對資源利用進行進一步控制的高級調度規則等。我個人覺得，Ironic出現在容器體系當中將把性能表現與資源利用水平提升到新的量級，而且這樣一來企業客戶在針對OpenStack項目進行投資回報討論時、也能得到更有說服力的分析結論。

必須強調的是，我認為Kilo發布所透露的核心消息在于，如今OpenStack已經沒那么多新消息可曝光了。很明顯，這一跡象證明了OpenStack項目已經最終走向穩定，其目前追求的是核心業務的完整性、而非不斷向其它新型領域擴展。

Q:您還有什么要補充的內容嗎?

A:由于這次對話的主題可以非常寬泛，因此我歡迎大家通過評論觀點或者建議告訴我們更多探討哪些各位感興趣的領域。我也樂于看到大家在使用過程中就OpenStack本身或者相關工具所總結出的經驗，各位可以點擊此處訪問我的Twitter。總而言之，我希望自己的對話能夠盡可能多地涵蓋聽眾朋友們感興趣的內容。

除此之外，我也要借此機會提醒各位，接下來世界范圍內還將陸續召開一系列其它OpenStack活動，因此沒能來到溫哥華的朋友們也不必灰心。而且我強烈建議各位沒能到場的朋友點擊此處查看相關日程安排，就在本次峰會結束后一場激動人心的OpenStack Days秀也將馬上開始自己的歐洲、非洲與中東地區旅程。我個人將參與到OpenStack以色列大會中去，在那里將有來自世界各地的宣講人分享自己的真知灼見——其中最值得一提的就是來自德國電信公司的Axel Clauberg，在我心目中他所主持的OpenStack項目可謂迄今為止***野心的發展成果。

原文標題：How to orchestrate containers in OpenStack