談到云計算技術發展，首先會想到是三種云服務模型：基礎設施即服務（IaaS），平臺即服務（PaaS）和軟件即服務（SaaS）。縱觀當下云計算的發展現狀，繼Openstack成為私有云IaaS層的標準之后，容器技術憑借其極其輕量、秒級部署、一次構建，隨處部署的特點正成為一股新的浪潮。目前已發展出三種主流的COEs（Container Orchestration Engines）容器編排引擎：原生的Docker Swarm、Google的Kubernetes（K8S）以及Apache的Mesos。基于容器技術的先天優勢，Openstack開源社區增加了很多關于容器技術的新方案及新項目，如何結合Openstack和容器技術已然成為Openstack社區以及業界積極探索的熱點方向。現階段OpenStack 社區涌現出許多與容器相關的案例，例如：Kolla、Magnum及Kuryr等等。然而，容器技術在發展過程中存在著缺乏集群調度、管理、監控和服務注冊等容器集群化運行管理能力方面的問題，需要在該容器技術架構上進行添加容器編排管理系統，其中Kubernetes憑借其自身活躍的社區，完整和強大的功能以及社區領導者富有遠見的設計得到越來越多的企業青睞。Kubernetes的發展速度遠遠超過了其他兩個，成為當前容器編排引擎的首選。在容器技術及其編排引擎的推動下，Openstack的主流部署模式也在發生變化，Openstack、容器技術以及Kubernetes已然形成了一種你中有我，虛擬主機，我中有你的局面。
Openstack定位于底層，在云服務模型中處于IaaS層，擅長管理底層資源；Kubernetes的定位處于上層，在云服務模型的PaaS層，更多關注的是應用的交付及管理。在網絡方面，兩者之間在存在各自的解決方案，通信過程中存在多重網絡問題，增加了運維的復雜度且降低系統網絡性能。而Openstack社區中的Kuryr項目便是解決該現狀的基石，采用Neutron構建統一的網絡管理，實現了容器與虛擬機之間的直接通信，完成了OpenStack與 Kubernetes 的網絡集成。在存儲方面，容器內部并不能實現存儲，Kubernetes直接將第三方的存儲應用在容器上，云主機，這將不是很方便的，相比于Openstack中的Cinder而言，在存儲能力上存在較大的差距。所以，為了解決網絡性能損失、集中式存儲需求、多租戶的安全隔離等問題，Openstack和Kubernetes即是最佳的選擇。
烽火云平臺邏輯架構圖
目前，在眾多云平臺架構中，烽火云平臺采用優化的Openstack與Kubernetes對接的云平臺架構。Kubernetes容器管理工具為基礎，構建于Docker等容器技術之上，為容器化的應用提供資源調度、部署運行、服務發現、擴容縮容等一整套功能，底層采用FitOS企業級Openstack平臺，管理底層資源，從而將該資源形成池化，池化后的資源交給核心的容器管理集群，這樣可以在Openstack管理的資源上進行容器云平臺的部署。兩者的整合充分發揮各自優勢，實現優勢互補，有效解決異構平臺的資源管理、容器安全性等問題。同時構建的一體化支撐平臺將有助于降低虛擬化開銷，增強容器隔離性等。現有的兩種部署方式是在虛擬機上部署容器或者在裸機上直接部署容器，有利于Kubernetes平臺、容器平臺和Openstack平臺采用統一網絡、統一存儲。現階段烽火云平臺對其多項功能進行改進和優化，并且集成應用商店、容器監控、日志收集、用戶管理、鏡像倉庫等多項功能，實現了一體化的解決方案。采用Cinder進行統一的存儲管理，作為Kubernetes的持久化存儲驅動，這樣Kubernetes直接可以調用底層的存儲資源，后端對接著Ceph分布式存儲或者本地存儲，支持有狀態服務，同時也彌補了Kubernetes對商業存儲支持力度不足的問題。通過Openstack中的Magnum項目調用Openstack Heat編輯工具來快速部署Kubernetes集群，實現了集群的快速自動化部署。另外，該平臺還使用業界先進的Prometheus+Grafana開源解決方案提供容器集群的監控告警，并且與自動化運維過程整合，按照用戶習慣提供了FitContainer UI，呈現集群到應用的各層內容，同時融合容器云業務與現有云平臺操作，深度整合相關業務流程。
近年來，隨著云計算技術的快速發展，Openstack與Kubernetes的對接成為必然趨勢。統一的資源管理與調度極大方便了開發者的訴求，并降低底層異構資源對上層開發的限制，提高開發的靈活性。目前烽火云平臺已在存儲、監控等方面提供自己的行業解決方案，推動了業界容器云平臺的發展，未來將在多租戶隔離、容器集群節點物理層面的網絡隔離等方面提出自身的見解，真正實現Openstack與Kubernetes的深度融合。
