聲明：
本人瀏覽筆記，翻譯類文章僅作意譯。如有不對的地方，請指出。
需要更根源的理解，請自行瀏覽英文。

本博客歡迎轉發，但請保存原作者信息!
博客地址：http://blog.csdn.net/halcyonbaby   
新浪微博：尋覓神跡

內容系本人學習、研究和總結，如有雷同，實屬榮幸！

基于docker、kubernetes部署openstack到atomic系統上

openstack的服務定義，是否是看起來很簡潔？
openstack的實際組件構成，是否是看起來很復雜？
所有的openstack服務彼此依賴，帶來了服務生命周期管理的復雜性和低效。

比如openstack的鑒權服務keystone，在已有環境上部署1個新的keystone是不是會對其他服務帶來兼容性問題 是很難判斷的。用現在的工具，也是難以進行回退的。 事實上，并不是只有openstack是這樣的，很多基礎設施平臺或利用平臺都有類似的問題。

openstack生命周期管理的方式

主要分為兩類：基于包、基于image

• 基于包
  通常使用PXE，并搭配puppet、chef、Ansilbe這樣的配置工具。基于包的方式是低效的，緣由以下：

  • 操作系統、物理節點的差異性
  • 合布時服務間的沖突（ports，文件系統等）
  • 安裝速度（大范圍部署時，通過網絡下載包安裝）
    或許有人會提虛擬機+包的方式，但是：
  • 虛擬機比較重（內存、CPU、磁盤占用。啟動速度）
  • 虛擬機缺少metadata注入手段（或需要額外的組件和代理完成這個事情）

• 基于image
  解決了安裝速度慢的問題，通常會有倉庫寄存image，直接下載到物理硬件上。
  但是，由于image很大，基于image的方式，增量更新依然很緩慢。
  另外，基于iamge的方式并未解決opesntack服務間的復雜性問題。只是將問題提早到構建鏡像時。

除此以外，運維人員還會希望這個openstack生命周期管理系統，能夠跨bare metal、IaaS、乃至PaaS。

Atomic、Docker、Kubernetes帶來了甚么

如果有1個openstack服務的生命周期管理方案能帶來以下優點：

• 隔離、輕量、便攜、可分離
• 運行態的服務關系易于描寫
• 易于運行、易于更新
• 獨立于openstack以外管理服務的生命周期

這正是docker、atomic、kubernetes組合方案所能提供的。

Docker提供了對linux容器的抽象，并提供了1種鏡像格式。通過這類鏡像格式，可以方便的分享并提供鏡像間的層次關系。另外docker還提供了docker倉庫來分享docker鏡像。 這類方式很重要，由于開發者可以發布便攜的容器鏡像，保護人員將之部署在不同的平臺。
kubernetes是開源的容器集群管理平臺。它使用master/minion結構提供給了容器的調度能力。開發者可使用聲明式語法描寫容器間關系，并讓集群管理進行調度。
Atomic項目提供給了1個安全、穩定、高性能的容器運行環境。Atomic包括了kubernetes和docker，并運行用戶使用新的軟件更新機制ostree。

將以上3者結合起來的方案就像上圖。openstack開發者使用自己熟習的環境進行開發（linux/vagrant/libvirt),然后向倉庫提交服務鏡像。運維人員將kubernetes配置導入生命周期管理工具，然后啟動pods和services。容器鏡像會被下載到本地并部署這些openstack服務。由于服務是隔離的，我們可以在單臺機器上最大化密度地部署openstack服務。除此以外還有其他優點，比如回滾、部署、更新的速度等。

原文地址：
http://allthingsopen.com/2014/10/22/a-demonstration-of-kolla-docker-and-kubernetes-based-deployment-of-openstack-services-on-atomic/