爲什麼要進行OpenStack容器化？
有哪些使用場景和實現參考？
爲何要進行OpenStack容器化？
在對OpenStack進行升級或降級時，通常有兩種方式可供選擇：基於Packages的管理方式和基於Images的管理方式。
容器化OpenStack的主要目的，在於優化基於鏡像的OpenStack管理方式。容器化OpenStack的管理方案解決了當前主流Openstack部署系統中最令人頭疼的Openstack可用性和管理維護難題。
已知問題描述
當前主流的OpenStack部署管理系統，或者使用基於Package的升級方式，或者使用基於Images的升級方式。
TripleO採用的便是基於鏡像的升級管理方式，TripleO在升級OpenStack時，其會構建整個磁盤系統鏡像並重新對其進行部署，而不是僅對組成OpenStack的部分服務進行鏡像構建，TripleO的這種升級方式顯得過於臃腫，並在可用性上存在很大缺陷。
此外，在TripleO的鏡像處理過程中，還需關閉運行中的虛擬機。不過，基於鏡像的管理方式卻是提供了管理維護的原子性，因爲通過系統鏡像的重新制作，所有與服務相關的軟件更新和升級只需一個完整的步驟即可實現(即升級操作的原子性)，而無需針對各個軟件包進行單獨升級。
對於其他基於Package的部署管理系統而言，由於各種零散軟件包的存在，OpenStack的升級過程通常需要針對一個或多個軟件包分別實現，這是一個極爲痛苦的過程。基於Package的升級過程通常會因爲各種各樣的原因失敗，但是又沒法取消已失敗的變更。
在OpenStack的部署和管理維護中，通常我們希望一次性便可升級全部與服務相關的軟件，如果升級不成功，則再通過一次性的操作即可回退到升級前的狀態，但是基於Package的方式顯然不能滿足這種原子性的操作。
要解決基於Package的非原子性操作和類似TripleO基於全鏡像方式所帶來的問題，容器可用來實現基於鏡像的管理方式，採用容器化的OpenStack部署方式，不僅可以實現實際操作的原子性，還可將升級過程對OpenStack服務的影響降至最低。
粗略的Nova計算節點升級測試表明[1]，在基於容器化的鏡像管理方式升級過程中，服務僅有接近10s的不可用時間，而且在升級過程中無需關閉虛擬機。
使用場景
原子性升級或回退整個OpenStack集羣。終端用戶可以通過這種方式將當前運行的軟件版本升級爲上游社區最新發行的版本，而在升級過程中服務不會終止較長時間，如果升級失敗，則可一次性回退至升級前狀態。
基於服務組件的OpenStack升級。用戶可通過這種方式對OpenStack進行細粒度服務組件級別的升級，從而限制全局升級失敗可能造成的影響。
基於服務組件的OpenStack回退。用戶在經歷了組件升級失敗之後，通過這種方式可以很方便的回退到已知的升級前正常運行版本。
容器化OpenStack實現參考
基於容器的OpenStack部署方式可通過樹形結構來呈現，樹形結構中的節點代表容器集，而每個葉子節點代表一個容器。在容器化過程中，容器集和容器應分別具備各自的屬性。關於OpenStack容器化的注意事項和參考實現可參考如下：
容器集屬性參考
容器集有一個或多個容器子集構成，後者由一個或多個獨立容器構成；
每個容器集提供一個獨立的邏輯服務，如Nova服務、Neutron服務等；
容器集被當成統一的單元進行管理，如startup、shutdown等操作時容器集被看成一個Unit進行處理；
每個容器集都被看成一個Unit進行Launch；
每個包含多個容器子集的容器集仍然被當成一個Unit進行處理；
對某個容器集的管理不是原子性的；
每個容器集均爲服務高可用監控提供接口。
容器屬性參考
可對單個容器進行原子性的升級和回退；
每個容器都包含有單向遞增的版本號以便在與其他容器比較時識別出容器的年齡；
每個容器應該獨立實現單一任務；
每個容器應該能夠對自身健康情況進行檢查；
容器存在一個能回收已退出子進程的PID 1；
無需對主機進行訪問的容器可能不會存在任何權限；
對於需要訪問主機的容器，可能存在超級權限。需要使用超級權限才能訪問的主機對象如下：
主機網絡命名空間；
主機UUID命名空間；
主機IPC命名空間；
主機持久性共享文件系統。
頂層容器集設計參考
database control。涉及服務有：galera/mariadb/mongodb
messaging control。涉及服務有：rabbitmq
high availability control。涉及服務有：HAProxy/keepalived
OpenStack interface。涉及服務有：keystone/glance-api/nova-api/ceilometer-api/heat-api
OpenStack control。涉及服務有：glance-controller(glance-registry)/nova-controller(nova-conductor/nova-scheduler/metadata-service)/cinder-controller/ neutron-controller(neutron-server)/ceilometer-controller(ceilometer-alarm/ceilometer-base/ceilometer-central/ ceilometer-collector/ceilometer-notification)/heat-controller(heat-engine)
OpenStack compute operation。涉及服務有：nova-compute/nova-libvirt/neutron-agents-linux-bridge/neutron-agents-ovs
OpenStack network operation。涉及服務有：dhcp-agent/l3-agent/metadata-agent/lbaas-agent/fwaas-agent
OpenStack storage operation。涉及服務有：Cinder/Swift(swift-account/swift-base/swift-container/swift-object/swift-proxy-server)
容器設計參考
爲了實現預期的目標，需要允許超級權限容器的存在，在docker中使用–privileged=true創建的容器被定義爲超級權限容器，超級權限容器在launch時使用-v參數掛載主機文件系統，並通過–ipc=host, –pid=host, or –net=host標誌共享主機全部命名空間。
由於使用了–net=host來共享主機網絡命名空間，因此在Dockerfile中不會使用到EXPOSE操作。使用–net=host的主要動機在於這種方法的簡單性，而不使用EXPOSE操作的原因，在於docker-proxy在轉發或返回每個數據包時都有20ms的延時。如果期望使用EXPOSE功能，則可以參考Openstack的默認端口列表[2]將其添加會回每個Dockerfile文件中。
在launch容器時，–restart=always標誌的使用可爲每個容器提供某些高可用功能的測量，並確保容器按當前設計正常運轉。
主機上應該可以運行特定的工具並監控容器健康狀況，如果容器未能通過健康檢查，則主機工具將重啓容器。
Docker容器編排引擎需要被實現，除了在單節點上進行簡單的容器編排之外，因爲容器被設計爲可在多節點上運行，因此編排工具也應該能夠應對多節點情況。
部署工具應能夠利用key-value鍵值對集合作爲輸入，並將其轉化到輸入環境中以傳遞給Docker，key-value對可以是文件，也可以是環境變量。
獨立容器中的日誌可通過某些一致方法進行提取。
本文轉移K8S技術社區-何處下手？OpenStack容器化實現參考