何處下手？OpenStack容器化實作參考

為什麼要進行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容器化實作參考