13518219792
谈到云计算技术发展，首先会想到是三种云服务模型：基础设施即服务（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的深度融合。
