Jul 272017
 

目前OpenStack项目里,目前我看到的最成功的项目,在最近2年里,应该就是kolla。我有幸在过去的1年半里参加了整个社区的开发过程。

Docker是一个革命性的东西。kolla作为一个用Dcoker来部署OpenStack的工具,其实也把其他的部署工具的命给革了。

 

Kolla介绍

Kolla,就是把OpenStack放到Docker里,部署OpenStack的一个工具。这其实也是目前为止,唯一一个没有厂商背景的部署工具

  1. 红帽的Tripleo,RDO,使用puppet,部署在CentOS 红帽系列
  2. Ubuntu的Juju,使用自己的配置管理工具,Juju,go语言开发,部署Ubuntu系统,
  3. Suse的Crowbar,使用Chef来部署,Suse企业版本
  4. Rackspace的OpenStack-ansible,通过LXC或者部署到物理机器上,利用ansible来管理,目前支持Ubuntu和CentOS
  5. Mirantis的Fuel,利用puppet,部署到Ubuntu操作系统上
  6. HPE的helion,使用ansible,部署在Debian 8
  7. TCPCloud搞的Salt,部署OpenStack。我没玩过,我的理解应该是在Ubuntu的系统上。

上面七个工具,基本可以囊括所有的OpenStack部署项目,每个都要他的好处,也是有他的不足的。他们的一个共同特点,基本都是单一厂商主导。

2017年,算是Kolla发展最猛的一年,一个没有厂商主导的部署工具,目前已经具备投入到生产使用。Kolla目前支持的操作系统

  1. CentOS和红帽系列
  2. Ubuntu16.04
  3. Oracle linux

我们自己也给客户做过很变态的测试,在Suse的企业版本上,跑一个CentOS的Docker镜像的OpenStack,完全没任何压力,并且还是多节点。

Kolla解决了一个困惑OpenStack长期的问题,升级,upgrade。通过Docker,可以很优雅的解决到OpenStack的升级的问题,现在已经可以实现业务跑着,进行升级。

这次OpenStack China Day,用kolla演示升级和集群掉电后,自动修复。把OpenStack做到可以让用户自己升级,这背后的故事,其实真的不少。

很多朋友对Docker不熟悉,以为把OpenStack放到Docker里,虚拟机也是跑在Docker里。其实这是误解。Kolla仅仅是吧OpenStack各个服务的进程,放到Docker里而已。以前的vm怎么运行,现在还是怎么运行,没做任何的改变。

Steven Dake

2014年,大概是下半年的时候,OpenStack基金会,已经意识到Docker对OpenStack可能造成的威胁,那么这个时候,就组成了一个小team,研究OpenStack和Docker如何并存,其实也都很容易想到,在2105年温哥华峰会上,推出3个项目

  1. Kolla,把OpenStack放到容器里,部署OpenStack
  2. Magnum,在OpenStack上面部署容器,后来改成COE(k8s,swarm,等)
  3. Solum,利用Docker来实现CI CD

这就当初基金会的设想,经过了2年的发展,大家其实已经发现,目前就kolla项目是最靠谱的。Magnum修改了自己的方向,并且带来的价值不大,仅仅是部署K8s。Solum,已经快要死掉。

Steven Dake,是以前的Heat的PTL,前红帽的工程师,评论技术多高已经没啥意义,这位哥们最厉害的地方,就是情商特高,能带动一堆人一起干活,我底下的弟兄,对他的也是赞口不绝,跟他干活,是一种享受,不拼命干好,对不起他的培养。

当时Steven Dake面临一个选择,是搞Kolla还是Magnum,那么他最终选择的Kolla,全力以赴搞好这个项目。

Kolla项目的活跃度,可以说在过去两年里,OpenStack各个项目排名,应该是在前五名以内。也是目前我看到,在过去两年里,唯一一个算是活跃的新项目。

目前Steven Dake还是基金会独立董事。https://sdake.io/  他的blog

把OpenStack放到容器里,其实当时面临的技术挑战是很多的,没有我在外面吹的那么轻松。现在Docker的很多分享,还在讨论数据库是否放在容器里,容器的日志如何收集。对于Kolla来说,要做到100%容器化,他要付出的代价就更大,Qemu,Libvirt容器化,OVS容器化,这些都是没人玩过的。

Ansible

把OpenStack放到Docker里,那么用什么进行编排呢?这个决策,其实是PTL决定。k8s是否可行呢?

One thing we tried early on with Kolla was deploying OpenStack on top of Kubernetes 0.9.7;

Steven Dake在blog里提到,其实在k8s 0.9.7 的版本,就开始验证是否可行。如果当初kolla选择k8s作为编排引擎,作为重点开发,那么其实今天能做到什么程度,是非常不好预测。

为啥选择Ansible,当时其实红帽也没收购Ansible。那么一个八卦新闻就是:Steven Dake的太太是Ansible公司的。

从我看来如果不是选择ansible作为默认的编排引擎进行开发,kolla-ansible是不可能在短短1年内投入生产环境,Kolla真正可用放到生产的环境,是Mitaka版本。

经过了1年的完善,目前的Ocata版本,已经基本到了一个很完善的地步的。

Sam Yaple

Sam是Rackspace的员工,2015年,当时OpenStack各家公司社区贡献的环境,还是很宽松的时候,Sam参与的Kolla的开发,他一个人出活量,基本相当于其他人的总和。而且都是技术难点的活。

Neutron容器化,OVS容器化,libvirt,qemu容器化。都是他一个人完成的。而且是在一个周期L版本完成的。

而且Sam写的代码,你基本也发现不了bug。Sam已经在Mitaka版本发布后,退出kolla的社区。不过到现在为止,他的代码提交量,还是第一。

https://github.com/openstack/kolla-ansible/graphs/contributors

kolla今天能做到这个地步,Sam应该算是第二功臣。

Jeffrey Zhang

对于kolla来说,

  1. Steven Dake,规划了Kolla的技术方向
  2. Sam Yaple 解决了关键的技术难题
  3. Jeffrey Zhang,就是把Kolla推到生产中。

由于kolla是没有厂商主导的部署工具,那么他部署出来的环境,是否能满足生产需求,这是很多用户问的问题。这个问题靠拍胸口是没啥意义,还是要靠验证。

全球第一个Kolla的生产部署案例,出自Jeffrey Zhang, 53个节点,超过500个OSD的环境。Mitaka版本的Kolla,遇到的bug,都是Jeffrey Zhang一个一个去修复。

经过了1年的验证,Ocata版本的一个生产环境,在每个节点超过20个vm,压力负载很重的情况下,运行良好。期间我们已经把各种的问题,bug都修复。

http://stackalytics.com/?module=kolla-group&release=all&metric=resolved-bugs

不少于10个非常严重的bug,严重影响到生产运行的问题,都是Jeffrey Zhang同学修复的。

运气

kolla的运气,有时候好的令人难以置信。

  1. Steven Dake,选择了Kolla,选择了ansible.
  2. 2015年11月份,我选择了kolla,找到了Jeffrey Zhang一起玩
  3. 2016年2月,Docker发布了1.10版本,支持 mount propagation。解决了Kolla投入生产的关键技术问题。Neutron的各个服务,可以在单独的容器里。
  4. 2016年4月份,全球的第一个Kolla生产环境的客户,小白鼠产生,验证的Kolla的稳定性和可靠性。
  5. 2016年8月份,Intel给了130台机器进行kolla的规模测试。
  6. Ocata版本发布时间更改,从以前的4月份,改成2月份,就让kolla很多在Newton版本没完成的工作,可以在Ocata版本完成.
  7. Ocata版本,九州云加大Kolla的投入,根据公司产品的需求,不断完善Kolla。最后在OpenStack的5月份峰会前推出kolla的产品。
  8. 2017年五月份,一个OpenStack的深度使用用户,部署了kolla的Ocata版本,对Kolla的各种功能进行的检验。
  9. OpenStack China Day大会,演示Kolla的用户无感知升级,和群集掉电重启的功能。吸引了大量的眼球。这是在1年前还是无法实现的。

我的Team

这是一个最强的Kolla team。经常有朋友问我团队多少人。其实不多。

Snap1

必须强调,我是一行代码都不会写的。都是弟兄的努力。

 Leave a Reply

(required)

(required)