http://www.360doc.com/content/18/0420/21/54736834_747381488.shtml
OpenStack和Docker之間是很好的互補關系。Docker的出現能讓IaaS層的資源使用得更加充分，因為Docker相對虛拟機來說更輕量，對資源的使用率會更加充分。如圖1所示。
圖1OpenStack和Docker的關系
從圖1可以看出，Docker主要針對Paas平台，是以應用為中心。OpenStack主要針對Iaas平台，以資源為中心，可以為上層的PaaS平台提供存儲、網絡、計算等資源。
圖2OpenStack項目的層級關系
OpenStack中按照層來分級的一些項目，如圖2所示。圖2從下往上看：
第一層是基礎設施層，這一層主要包含Nova、Glance和Keystone，如果我們要想得到最基本的基礎設施的服務，必須安裝部署這三個項目。
第二層是擴充基礎設施層，這一層可以讓我們得到更多跟基礎設施相關的進階服務，主要包含Cinder、Swift、Neutron、Designate和Ironic等，其中Cinder提供塊存儲，Swift提供對象存儲，Neutron提供網絡服務，Designate提供DNS服務，Ironic提供裸機服務。
第三層是可選的增強特性，幫使用者提供一些更加進階的功能，主要包含Ceilometer、Horizon和Barbican，其中Ceilometer提供監控、計量服務，Horizon提供使用者界面，Barbican提供秘鑰管理服務。
第四層主要是消費型服務，所謂的消費型服務，主要是指第四層的服務都需要通過使用前三層的服務來工作。
第四層主要有Heat、Magnum、Sahara、Solum和Murano等，其中Heat主要提供orchestration服務，Magnum主要提供容器服務，Sahara主要提供大資料服務，我們可以通過Sahara很友善地部署Hadoop、Spark叢集。Solum主要提供應用開發的服務，并且可以提供一些類似于CI/CD的功能。Muarno主要提供應用目錄的服務，類似于App Store，就是使用者可以把一些常用的應用釋出出來供其他使用者去使用。最右邊是Kolla，Kolla的主要功能是容器化所有的OpenStack服務，便于OpenStack安裝部署和更新。
OpenStack中和Docker有關系的項目如圖3所示。
圖3OpenStack中和Docker有關系的項目
主要包括Nova、Heat、Magnum、Sahara、Solum、Murano和Kolla等。由圖3得知，和Docker相關的大部分項目都在PaaS和SaaS層。以下主要分别說明Nova、Heat、Magnum、Murano和Kolla。
Nova Docker Driver
如圖4所示，這個Driver是OpenStack和Docker的第一次內建，主要是把Docker作為一種新的Hypervisor來處理，把所有的Container當成VM來處理。提供了一個Docker的Nova Compute Driver，內建很簡單，通過Docker REST API來操作Container。
圖4Nova Compute Driver，OpenStack和Docker的第一次內建
這個Driver的優點是實作比較簡單，隻需要把Nova Compute中的一些對虛拟機操作的常用接口實作就可以，現在主要支援建立、啟動、停止、Pause、Unpause等虛拟機的基本操作。因為Nova Docker Driver也是一個Nova的Compute Driver，是以它可以像其他的Compute Driver一樣使用OpenStack中的所有服務，包括使用Novascheduler來做資源排程，用Heat來做應用部署、服務發現、擴容縮容等，同時也可以通過和Neutron內建來管理Docker網絡。也支援多租戶，為不同的租戶設定不同的Quota，做資源隔離。
它的缺點也很明顯，因為Docker和虛拟機差别也挺大的，Docker還有一些很進階的功能是VM所沒有的，像容器關聯，就是使不同容器之間能夠共享一些環境變量，來實作一些服務發現的功能，例如K8S的Pod就是通過容器關聯來實作的。另外一個是端口映射，K8S的Pod也使用了端口映射的功能，可以把一個Pod中的所有Container的Port都通過Net Container Export出去，便于和外界通信。還有一個是不同網絡模式的配置，因為Docker的網絡模式很多，包括Host模式、Container模式等等，以上的所有功能都是Nova Docker Driver不能實作的。
Heat Docker Driver
因為Nova Docker Driver不能使用Docker的一些進階功能，是以社群就想了另一個方法，和Heat去內建，如圖5所示。
圖5Heat Docker Driver
因為Heat采用的也是插件模式，是以就在Heat實作了一個新的Resource，專門來和Docker內建。這個Heat插件是直接通過REST API和Docker互動的，不需要和Nova、Cinder和Neutron等來進行互動。
這個Driver的一個優點首先是它完全相容Docker的API，因為我們可以在Heat Template裡邊去定義我們關心的參數，可以實作Docker的所有進階功能。另外因為和Heat內建了，是以預設就有了Multi-Tenant的功能，可以實作不同Docker應用之間的隔離。
但它的缺點也非常明顯，因為它是Heat直接通過REST API和Docker互動的，是以Heat Docker Driver沒有資源排程，使用者需要在Template中指定需要在哪一台Docker伺服器上去部署，是以這個Driver不适合大規模應用，因為沒有資源排程。另外因為沒有和Neutron去互動，是以網絡管理也隻能用Docker本身的網絡管理功能來實作。
圖6是使用Heat Docker Driver的一個很典型的應用場景。主要是通過Heat在虛拟機部署一個小規模的Docker Container應用，這個例子主要是一個Web Server的應用。
圖6Heat Docker Driver的一個很典型的應用場景
它的方法是在Heat Tempalte定義兩種類型的Resource，一種是Nova Server，一種是Docker Container，Docker Container需要依賴Nova Server，就是必須Nova Server建立完後才能開始建立Docker Container。當使用者在建立Nova Server的時候，需要在Nova Server上通過User Data安裝Docker，Docker Container需要等Nova Server啟動後，在Nova Server上建立Docker Container。這裡有一個詳細的例子，大家可以參考：http://techs.eNovance.com/7104/multi-tenant-Docker-with-openstack-heat
Magnum
在OpenStack和Docker內建的過程中，我們發現從OpenStack現有的項目中，找不到一個很好的內建點，雖然和Nova、Heat都做了內建的嘗試，但缺點很明顯，是以社群就開始了一個新的專門針對Docker和OpenStack內建的項目Magnum，用來提供容器服務。Magnum是2014年在巴黎峰會後從11月開始做的，到現在5個月時間有27個Contributor，有700多個Commit，發展速度還可以。
Mangum的主要目的是提供Container服務的，它同時還可以和多個Docker叢集管理系統內建，包括K8S、Swarm、CoreOS等。和這幾個平台內建的主要原因是能讓使用者可以很友善地通過OpenStack雲平台來內建K8S、CoreOS、Swarm這些已經很成型的Docker叢集管理系統，促進Docker和OpenStack生态系統的融合。
首先來看Magnum的主要概念，如圖7所示。
圖7Magnum的主要概念
在這個圖的右邊，主要有：Bay、Baymodel、Node、Pod、Service、Replication Controller和Container。
Bay在Magnum主要表示一個叢集，現在通過Magnum可以建立K8S和Swarm的bay，也就是K8S和Swarm的叢集。
Baymodel是Flavor的一個擴充，Flavor主要是定義虛拟機的規格，Baymodel主要是定義一個Docker叢集的一些規格，例如這個叢集的管理節點的Flavor、計算節點的Flavor、叢集使用的Image等。
Node主要是指Bay中的某個節點。
Pod、Replication Controller和Service的意思和在K8S的意思是一樣的，使用者可以通過Magnum來和K8S內建，通過Magnum API來操作K8S叢集。
Pod是Kubernetes最基本的部署排程單元，可以包含多個Container，邏輯上表示某種應用的一個執行個體。比如一個Web站點應用由前端、後端及資料庫建構而成，這三個元件将運作在各自的容器中，那麼我們可以建立三Pod，每個Pod運作一個服務。或者也可以将三個服務建立在一個Pod，這取決于使用者的應用需求。
Service是Pod的路由代理抽象，用于解決Pod的高可用的問題。Service因為Pod的運作狀态可動态變化(比如Pod的IP變了或者某個Pod被删除了等)，是以通路端不能以寫死IP的方式去通路該Pod提供的服務。Service的引入旨在保證Pod的動态變化對通路端透明，通路端隻需要知道Service的位址，由Service來提供代理。
Replication Controller是Pod的複制抽象，用于解決Pod的擴容縮容問題。通常，分布式應用為了性能或高可用性的考慮，需要複制多份資源，并且根據負載情況動态伸縮。通過Replication Controller，我們可以指定一個應用需要幾份複制，Kubernetes将為每份複制建立一個Pod，并且保證明際運作Pod數量總是與該複制數量相等（例如，目前某個Pod當機時，自動建立新的Pod來替換）。
Container就是某個Docker容器。
Magnum中的主要服務有兩個，一個是Magnum API，一個是Magnum Conductor。
Magnum API和其他項目的API的功能是一樣的，主要是處理Client的請求，将請求通過消息隊列發送到backend，Magnum現在支援的backend有K8S、CoreOS、Swarm、Docker等，未來還會支援Rocket等Docker叢集管理工具。
在Magnum，背景處理主要是通過Magnum Conductor來做的。Magnum Conductor的主要作用是将Client的請求轉發到對應的Backend，通過對使用者請求的解析，幫使用者找到最合适的Backend，是以Magnum Conductor需要為每個API的請求找到合适的Backend處理Client的Request。
Magnum其實和Nova的架構很像，Nova主要提供IaaS服務，Magnum主要提供CaaS，Nova可以管理不同類型的Hypervisor，包括VMware、KVM、PowerVM等，Magnum也一樣，它可以管理不同的Docker叢集管理工具，包括K8S、Swarm、CoreOS等。最終目标是期望和Nova一樣，能夠讓使用者不用關心背景的Docker叢集管理工具到底是什麼，隻管提請求，最終通過Magnum獲得自己需要的Container。
從圖7來看，Magnum很簡單，主要是做了些內建工作，但其實Magnum對開發人員的要求也很高，因為Magnum需要和Heat、Ironic、Nova、K8S、CoreOS和Swarm等內建，是以需要開發人員對這些項目都有一定的了解，至少需要對這些項目的概念和主要特性都很清楚。
Magnum現在的一些主要特性，包括K8S as a Service、CoreOS as a Service、Swarm as a Service等。是以有這些功能，主要是因為有的客戶已經有OpenStack叢集了，現在想在OpenStack上運作一些以應用為中心的系統，像K8S、Swarm、Mesos等，通過這些系統為使用者提供應用服務，是以使用者就可以通過Magnum來實作它的需求，通過OpenStack提供Iaas服務，上層的K8S、Swarm等來提供Container服務。
另外，Magnum還實作了多租戶的功能，可以将不同租戶之間的Resouce隔離，每個租戶可以用自己的Baymodel、Bay等對象，實作安全隔離。Magnum準備和K8S的開發人員合作，打造一個最好的OpenStack和K8S結合的項目。
Magnum Roadmap如圖8所示。
圖8Magnum Roadmap
第一個是Magnum Conductor的水準擴充，Magnum服務也是無狀态的，是以可以水準擴充，一旦發現Conductor性能存在瓶頸時，可以通過啟動一個新的Conductor來分擔系統負載。
第二個是原生Docker叢集的排程問題，Magnum現在隻能管理單個的Docker的伺服器，因為還沒有一個原生的排程器能夠讓Magnum管理一個Docker叢集，但可以和Swarm、Gantt或Mesos內建實作Docker叢集資源排程的功能。現在經過讨論，可能會使用Swarm來做排程，因為通過Magnum部署完Swarm叢集後，預設就可以通過Swarm來管理Docker叢集了。
第三個是原生Docker叢集的網絡管理，現在大家的一緻想法是在Docker server上通過Host模式來部署一個Container的l2 agent來管理Docker Server的網絡。
第四個是Notification，其主要作用是便于追蹤Magnum中所有對象的狀态，尤其是當第三方和Magnum內建的時候，可以通過Notification來監控Magnum中的操作的對象。
最後一個是K8S深度內建，現在Magnum和K8S的內建是Magnum通過調用K8S指令行kubectl和K8S互動，這樣做比較簡單，但受到的限制很大，因為Magnum需要通過解析Kubectl的輸出來判斷每個調用是不是成功，但有時Kubectl并不能輸出某個API的所有Output，是以Magnum關心的一些值通過Kubectl可能拿不到。現在有個BluePrint就是想通過K8Sclient使用REST API來和K8S互動，這樣就可以拿到每個調用的全部輸出，Magnum可以很友善地取得自己關心的輸出，來做相應的操作。圖8下面的Link是Magnum現在的所有的BluePrint。
Murano
Murano是Mirantis貢獻的，并且也進了OpenStack Namespace。也和K8S內建了，使用者可以通過Murano使用K8S的功能，可以通過Murano部署Pod、Service、Replication Controller等。Murano主要是在OpenStack基礎上提供應用目錄服務。Muarno和Solum之間其實是有關系的，Solum主要是用來開發應用的，Solum把應用開發完後，可以通過Murano來釋出。使用者可以通過Murano挑選自己需要的應用服務，通過應用服務組合建構自己的應用。
Murano也是通過Heat部署應用，Kubernetes和Murano內建之後，現在K8S也已經成為Murano的一個應用服務了。
圖9所示是Murano的一個工作流，可以看到它的使用很簡單。首先建立使用者的應用環境，然後為應用環境添加應用服務，接下來部署應用環境，應用環境會通過OpenStack的Heat來部署。
圖9 Murano的一個工作流
圖10主要是說明怎樣通過Murano部署一個K8S的Pod。
圖10 通過Murano部署一個K8S的Pod
Murano和K8S的內建主要在前三步，第一步是先建立一個K8S的環境；然後在第二步需要為我們建立的K8S環境添加一個應用服務，首先需要添加一個K8S的叢集應用模闆，然後在K8S叢集的基礎上添加一個Pod的應用；第三步是在第二步Pod的基礎上，為Pod添加Container。這三步做完後，就可以部署環境了，最終Murano會調用Heat首先建立一個K8S的叢集，然後K8S叢集根據使用者的需求建立Pod。所有的這些操作都可以在Murano的GUI上操作，非常簡單。
OpenStack Deployment With Docker
OpenStack現在的部署工具很多，包括RDO、Fuel、Chef、Triple-O等，但這些工具對OpenStack更新的支援不是很好。想在OpenStack更新的話，主要有兩種方式：基于Image與基于Package 。
基于Package的更新方式通常不是原子的，更新過程中存在很多導緻失敗的原因，尤其是一些公共包依賴的問題，可能導緻部分package更新失敗的可能。基于Image的方式，更新是原子的。
Triple-O是一個很典型的通過鏡像部署的例子，但是Triple-O更新OpenStack叢集時，粒度太大，它通常情況下是同時對OpenStack多個服務去更新，這樣對OpenStack叢集影響比較大，會導緻某些服務在一定時間段内不能被通路。
是以就有Kolla這樣一個項目，來解決快速更新和復原的問題。
Kolla：Docker+OpenStack
Kolla的主要功能是使用Docker容器快速部署更新OpenStack服務。
Kolla的最終目标是為OpenStack的每一個服務都建立一個對應的Docker Image，通過Docker Image将更新的粒度減小到Service級别，進而使更新時，對OpenStack影響能達到最小，并且一旦更新失敗，也很容易復原。更新隻需要三步：Pull新版本的容器鏡像，停止老版本的容器服務，然後啟動新版本容器。復原也不需要重新安裝包了，直接啟動老版本容器服務就行，非常友善。
Kolla是通過Docker Compose來部署OpenStack叢集的，現在主要是針對裸機部署的，是以在部署Docker Container時，預設的網絡配置都是Host模式。是以Kolla的好處就非常明顯了，将OpenStack更新的粒度細化到了Service級别，更新失敗時，可以很容易復原。
圖11展示怎樣通過Kolla去部署一個OpenStack叢集。
圖11通過Kolla去部署一個OpenStack叢集
可以看到首先需要啟動一個管理節點，隻需要通過一個指令就可以把管理節點部署完成，這個指令是調用Docker Compose來部署OpenStack的所有服務，然後我們可以在每一個計算節點上通過Docker Compose安裝計算節點需要的服務，就能部署一個OpenStack叢集。因為Kolla的Docker Image粒度很小，它針對每個OpenStack服務都有特定的Image，是以我們也可以通過Docker Run來操作某個具體的OpenStack服務。這個例子是通過Docker Image啟動了Glance API。
圖12是一個OpenStack compute的一個例子。
圖12OpenStack compute的一個例子
這是一個簡單的YML檔案，我們可以通過Docker compose使用這些YML檔案部署OpenStack節點，可以看到這個YML檔案包含Compute Data Image、Libvirt Image、Network Image、Nova API Image和Compute Image等。第一個Compute Data主要是為其他Container提供存儲服務的，可以看到Libvirt和Novacompute的Container的存儲都是從Compute Data來的，因為它們都有一個字段voluemes_from指向Compute Data這個Container。
如何選擇？
OpenStack和Docker相關的項目這麼多，該怎麼去選擇呢？簡單說明如下。
如果使用者隻是想将以前的VM Workload遷移到Docker Container，那麼它可以使用Nova Docker Driver，一個很典型的例子是Sahara通過Heat調用Nova Docker Driver來建立Hadoop叢集。
如果使用者想使用Docker的一些進階功能來部署一個小規模叢集，那就可以考慮Heat Docker Driver。
如果使用者想通過OpenStack內建現有的一些Docker叢集管理工具像K8S、Swarm來管理大規模的Docker叢集，建議使用Magnum。另外因為Magnum也是基于Heat做的，是以預設也支援混合雲的功能。
Murano和Docker的內建，主要展現在它提供了一個K8S的應用，使用者可以通過這個K8S應用來管理Docker叢集。但Murano和Docker的焦點不一樣，Magnum主要提供容器服務，Murano主要提供應用目錄服務。
最後的Kolla，主要是簡化OpenStack的安裝部署和更新的。
Kilo的層級多租戶管理
因為Docker的出現，使得IaaS層的計算密度進一步提升，這種密集型的計算對資源排程和運維的要求很高，需要一些比較進階的資源排程政策來提高資源使用率。Docker Container和虛拟機的最大差別是它輕量的特性，對于這種輕量性的容器技術，可以通過在資源排程中加入不同租戶之間資源共享的機制來提高資源使用率。是以OpenStack在Kilo新加的層級租戶的管理，這個功能可以了解為一種基本的資源共享，因為這個功能允許父賬戶和子賬戶之間共享資源。
圖13是一個例子。
圖13 層級的多租戶管理
我們可以看到每個租戶的旁邊都有一些值，以最頂層的租戶為例，這個租戶hard_limit=1000，used=100，reserved=100，allocated=70，它們的意思分别為：hard_limit是這個租戶的資源上限；used是目前這個租戶已經使用的資源；reserved是被這個租戶預定的資源，即使目前的租戶不用，也不能分給别的租戶；allocated是目前租戶分給子賬戶的資源，它的值是直接子賬戶的hard_limit的總和。我們可以看到ORG這個租戶的直接子賬戶兩個部門1和部門2，兩個的hard_limt分别為300和400，是以ORG的allocated值是700，這四個值還隐藏了一個值，那就是free，目前賬戶的空閑資源，free是hard_limit減掉used、reserved和allocated，空閑資源有兩個作用，一個是可以供本賬戶使用，還有一個是供子賬戶使用。我們可以看到ORG的空閑資源為1000-100-100-700=100，就是說它現在有100個空閑的資源，可以供自己或者子賬戶使用，就是給Dept-1或者Dept-2去用。這樣就為OpenStack增加了不同層級租戶之間的資源共享的功能。
這種形式有什麼缺點呢？我們可以看到賬戶之間的關系隻局限于父子賬戶，同一層級的賬戶之間還是沒有關系，它們的資源也不能互相共享。我們看team11和team12，它們之間的資源不能共享，就是即使team11的資源都用完了，team12的資源一點沒用，team11也不能從team12那邊借資源過來，這樣反映到企業就是，同一層級的部門之間資源不能共享，這是一個很大的短闆，會導緻資源不能被充分利用。我們可以把目前Kilo的這種層級租戶資源共享了解為獨占模式。
圖14是目前Kilo的層級租戶模式，現在共16個資源，T1和T2各獨占8個，我們可以把每個資源看成是一個Docker Container，假定所有的Container規格都是一樣的。就是說T1和T2最多可以建立8個Container。
圖14目前Kilo的層級租戶模式
T1要4個資源，因為它有8個，是以可以拿到4個，剩下4個空閑的；T2要12個資源，因為它隻有8個，是以隻能拿到8個資源。最終結果是T1有4個空閑的資源，T2缺少4個資源，這種獨占政策的缺點就是資源不能共享，假如能把T1的這4個空閑的資源給T2用，就能達到最優的資源使用率。
針對Kilo即将實作的層級賬戶的缺點，有人正在建議OpenStack社群作出改進增加同一層級租戶之間的資源共享，主要有兩種形式：同一層級資源借入/借出和同一層級資源資源共享。
圖15是同一層級的租戶之間資源共享改進的第一個模式：同一層級租戶間資源借入借出。
圖15同一層級租戶間資源借入借出
借入借出是基于獨占政策來改進的。這個例子和剛才的獨占政策很像，從這個例子我們可以看到，租戶T1和T2個獨占8個資源，租戶T2可以從租戶T1借入4個資源。現在T1要4個，我有8個，可以拿到4個用着，然後有4個是空閑的，T2來了，要12個，先拿到自己獨占的那8個，還需要4個，然後發現可以從T1那借4個，正好滿足T2的請求。再進一步，就是假如這時候T1又來資源請求了，T1可以通過某種政策将借給T2的那4個要回來。
圖16是同一層級的租戶之間資源共享改進另一種模式：同一層級租戶之間資源共享。
圖16同一層級租戶之間資源共享
現在同一層的租戶之間的資源是不能共享的，是以我們需要讓同一層級租戶之間的資源能夠共享來提升系統的資源使用率。是以我們現在可以引入同一層級的租戶之間的共享模式。
舉例來說，現在有兩個租戶，T1和T2，都不獨占任何資源，共享所有資源，并且T1和T2的共享比例為1:1，現在一共有16個資源，這16個資源都是共享的，T1和T2的共享比例為1:1，是以T1和T2都deserve 8個資源，但這8個并不是被T1或者T2獨占的，而是共享的。
也就是說，現在T1和T2都有資源請求了，T1要4個，T1現在deserve 8個，那就可以直接去拿4個資源。T2來了，T2要12個，但是T2隻deserve 8個，那T2就先拿到deserve的這8個，然後它發現share pool裡邊還有4個資源沒人用，那它就可以把這4個再拿過來，這樣T1和T2的請求就都滿足了。
這種借入借出模式和共享模式也可以同時去使用，我們可以把一部分資源設定成獨占的，一部分設定為共享的，給使用者更大的空間來配置它的資源規劃。