从威胁到整合,容器将改变openstack的未来?

原创
2016/10/21 07:19
阅读数 4.5K

分享嘉宾简介:九州云99Cloud副总裁陈沙克,多年深耕于开源云计算平台Openstack技术,目前主要负责九州云99Cloud的产品、社区和研发。

从2010年发布到现在,就IaaS层面在目前的开源领域,Openstack已然成为一个代名词。在这期间,Openstack也曾因为种种原因发生过一些调整和改变,而容器的出现,也对Openstack造成了革命性的影响。

一、OpenStack 重要发展历程

在2013年基金会成立的时候, Rackspace将OpenStack的控制权交给基金会负责,OpenStack把自己定位为一个“可以做私有云、公有云的平台”。 当Docker出来时,Openstack已然经过两年的磨练,也考虑到市场环境因素,将定位调整为一款“管理引擎”,可以管理虚拟化、物理机、虚拟机、容器等等存储网络。就目前来讲,它被赋予的使命非常多,但同时也饱受Docker的威胁。而且由于Openstack什么都要管,它的功能模块非常多,基本上每个模块都要实现一个功能,目前除了基本功能以外,已有三四十个大项目,每个大项目下面还有好几个子项目。所以如果去GitHup上浏览,会发现Openstack的项目列表里面包含有几百个项目。实际上,对用户有用的或者说跟用户实际功能相关的项目数量,大概在三四十个左右。

在2015年,Openstack 引入了“大帐篷”策略。这个策略是指先定义出来一些必须用到的核心模块,像Nova、Glance、Swift这些,剩下的再根据用户实际需求选用。采用大帐篷策略以后,项目爆长,为了应对用户对虚拟机、容器、物理机等等上面的需求,Openstack变得越来越复杂。

二、OpenStack搭建流程

对企业来说,要将Openstack引入,首先要准备硬件,把存储准备好,然后要装操作系统。目前很多厂商已经对安装操作系统那一块做了自动化,减轻用户部署的痛苦。再就是安装Openstack的各种服务,配置Openstack各个节点的高可用。

安装完这些还不够,还需配置整个平台,做日志的收集和监控。后续还需要对整个Openstack平台进行运维和升级。下图基本上就是企业在引入Openstack的时候,必须要做的一些过程。

三、OpenStack的痛点和难点

1、安装和部署困难

在安装Openstack的时候,可能自己在测试的时候都很顺,但在实际的企业环境中就会面对各种的挑战。比如,国内有很多企业是完全是不能联网的,怎么在网络不通的情况下完成安装部署?实际上非常具有挑战。而且有的企业在联网情况下安装完可以很好的运行,一旦网络不好或者断网,效率可能变得很低。这些问题如果没有在实际安装过程中亲身经历过,很难提前想象。

2、维护更加困难

当Openstack节点数量大的时候,靠传统的人工维护方式是非常麻烦的。在几十个节点上面,如果想要去查看日志或者修改配置,都是很难做的事情。

3、升级难上加难

Openstack进入企业面临最大的挑战,就是升级。2016年是国内企业采纳Openstack最多的一年,也是发展最好的一年,但同时升级的问题也被不断提出。当企业有了新功能、新特性,希望升级的时候,会面临这样一个问题:

以往软件升级都是采用发行版、安装包的方式实现,像红帽采用的Yum,乌班图的 apt-get 。但Openstack不行,因为Openstack现在一年两个版本,中间只有半年的时间,厂商要对其进行打包和测试,加上Openstack现在的组件有几十个那么多,厂商根本无法在那么短的时间内完成那么多的工作。而且当某次升级你没跟上,时间就会越拖越长。

在之前,很多厂商都只能通过手动操作熬夜通宵来给企业升级,因为只有这种办法才能完成。Openstack可以在不宕机、影响很小的情况下完成升级,但是这个过程是很长很累的,需要手动一点点地更新,而且每个客户的情况都不太一样,只能区别对待。而且不同的版本需要处理的问题是不一样的,经验的积累也是不一样的。所以,对厂商来说,升级是件很痛苦的事。

四、容器给Openstack带来新突破

那么,究竟要怎么帮助企业去解决这个问题呢?

可以说,在容器出现之前,这个问题是无解的。容器出现后,看到了希望,把Openstack放在容器里面进行升级。接触过容器的应该知道,在容器里面没有安装的过程,它已经提前把安装文件录入到file里面。只需将Docker放到相应的机器上面,启动起来,再把配置文件放回去,就可以把Openstack装起来。这样,整个过程能减少很多问题。至少,之前很容易遇到的语言冲突、包冲突的问题可以解决掉。

而且,随着容器化的使用,厂商的配置管理也启用了专门的工具。在Openstack升级上有个很大的问题,就是升级导致的冲突问题,这个非常不好解决,解决起来也没有任何的意义,完全是拼体力。但用Docker隔开以后,已经可以完全避免这个问题了。还有之前当操作系统跟Openstack不是同一个语言的时候,也很容易导致它的依赖关系有冲突,解决起来不但没有任何意义,还没完没了,容器化后同样能进行规避。

更多好处可以参考"容器化 OpenStack 的10个好处"一文。试想,把Openstack容器化,整个安装过程(不包括安装操作系统)可能只需要20分钟。在生产环境中,装20分钟和装2个小时甚至一天的区别并不太大,但是在开发测试和验证环境里面,20分钟和2个小时存在很大差异。Openstack里面有许多功能需要反复的测试和操作,当时间减少至20分钟的时候,将带来极大的好处。

五、Openstack容器化的成熟项目——Kolla

对于Openstack的厂商来说,都曾体会过前面提到的痛点和难点,所以也都在很积极地解决这些问题。Rackspace乌班图的Canonical、 TCB Cloud 、Mirantis都做了相应的解决办法去推动容器化,只是做法各有差异。除了厂商,社区也在努力,Kolla就是Openstack社区里推出的一个专门做Openstack容器化的项目。

目前来说,Kolla已经非常成熟,可以投入使用。Kolla不仅仅是把Openstack的组件容器化,还把周围的所有的组件也容器化。简单点说,一台机器如果把容器删掉,那么这台机器将不会有任何剩留。因为它做得非常彻底,把所有的东西都放在了容器里面。这样做的好处也显而易见,这台机器不管做什么东西,迭代都会非常快。

Kolla之所以能迅速成熟是因为它有个理念——“怎么简单怎么来”。它可以通过源码或发行版的RTM发安装包完成安装,也能通过镜像去配置文件,再放到相应的节点上去完成配置。当然,这个非常理想的状况,因为在实际部署中,会面临很多的东西。

没有用过Kolla,或对Docker不是很熟悉的,只要了解Docker的理念,就会发现这种方式非常理想化,只需要在这台机器以前的Docker file或master文件里面,不断在相应的节点上放进去你想要达到的目标,启动起来就可以了。这种灵活性也的确能给实际操作带来很多好处。

下图是Kolla的工作流程。一个Docker装Openstack,Openstack在容器里跑。Docker在现在的企业使用中会遇到很多挑战性的问题,比如说安全的问题,比如说网络性能的问题。但是,Kolla的使用没有面临性能的问题,也没有面临安全的问题,因为它是内部的使用Docker,它的网络直接是通过网桥出去的,就没有网络、性能的问题。所以说,Kolla利用了Docker非常稳定的部分,帮助Openstack实现了容器化。

目前来说,容器化给Openstack带来了许多革命性的变化。未来有一种趋势,它会自己容器化,也会管理容器,会用容器给用户提供一些终端的服务。从今年的发展趋势也能看到,未来很多东西会通过容器来启动,Openstack上面有很多的服务,以前都是要很重地往里面装一些东西,以后则可以直接放入Docker file启动。下面列了几个Openstack里面容器相关的项目,到目前来讲,Kolla是最成熟的,剩下的几个也都在发展中。

六、结语

本文内容整理自10月15日、16日的OSC成都、重庆源创会上陈沙克老师的演讲,主要对Openstack和容器化进行介绍,想了解更多Openstack关于容器的技术,可以关注沙克老师的博客。源创君也将不断推出更多更精彩的内容,敬请期待!

展开阅读全文
加载中
点击加入讨论🔥(9) 发布并加入讨论🔥
打赏
9 评论
35 收藏
5
分享
返回顶部
顶部