1.1Kolla使命

1.1.1Kolla的使命

Kolla的使命是：为运行OpenStack云提供生产就绪的容器和部署工具。

注：Kolla具有开箱即用的基本部署设置，并且还实现了完整的定制。这种模式允许使用者以最少的经验快速部署OpenStack，并且随着使用者经验的不断增加，逐步修改OpenStack配置来适应生产环境实际需求。

1.1.2 Kolla架构

• • Kolla 负责Docker的镜像制作
  • Kolla-Ansible 负责容器的配置管理

Kolla是把OpenStack放到Docker容器里，部署OpenStack的一个工具。

• Kolla的目标

（1）利用Docker产生生产级别的镜像加速OpenStack部署。

（2）简化OpenStack部署和运维操作。

Kolla提供出两个东西，一是生产级别的Docker镜像，另一个是基于Ansible的部署工具，这两个产出是可以分别独立开来的。

• Kolla的基本原则

说到Kolla的一些基本原则，首先不得不提它的“Open”，Kolla不是被某一家公司所独占，其开发人员来自于各个公司，其中包括思科、英特尔、IBM等。其次还有Kolla所部署出来的集群基本上是一个“开箱即用”的状态。

例如在Kolla上直接使用100个节点的机器，可以实现“直接、批量地创建机器”。Kolla优化了一些功能参数，可以做到批量起动五、六百台机器在100个节点中，是没有问题的。

再有，Kolla在不同的环境里面，打破了“只能用OVS”的问题，Kolla可以是不限定的，可以供用户自由选择。

最后，Kolla本身项目开发的validation（验证），即保证Kolla代码的质量。也就是OpenStack的标准流程。在CI的测试中，包括构建所有的容器镜像，并进行部署，随后运行一个虚拟机，来检测Kolla是不是真的可以正常工作，不仅如此，在Newton周期里可以把多机节点附加进去，这样一来，测试Kolla能力会更大一些。

• Kolla的功能

（1）在Liberty中，Kolla的功能如下：

首先所有服务HA都已具备，包括API、storage在L版都已经完成。不仅如此，Kolla支持多后端存储，比如是不是开启 Ceph 存储，如果是便可以自动将Ceph部署出来，并自动把Glance、Nova、Cinder配置好。

Kolla还具备既可以通过RDO打包，也可以从二进制包安装OpenStack，还支持从源代码安装，这样可以保持我们使用的，是OpenStack的最新代码。还有上述提到的Kolla被验证的基本原则中，其默认支持100个节点的部署。

另外，Kolla对物理机的依赖很小，宿主机只要装 kolla-py 和docker-engine中，便都可以部署OpenStack。

补充：在L版中，Kolla支持的服务是包含mariabd、rabbitmq、memcached等，并支持原子性升级。

（2）在刚刚发布的M版中，Kolla的功能如下：

针对安全性，所有在容器里面的服务都不是在root中运行的。并添加了upgrade actian，即OpenStack可以升级。同时增加了ELK，用来做日志的收集和展示。

补充：M版中，Kolla的部署时间大大缩短；使用了Namde volume 进行存储；使用官方的 qemu 源，使用了qemu 2.3 版本，有一定性能的提升；MariaDB增加了一个新的actian叫做 mariadb-recovery。

与此同时，Kolla社区是比较活跃的，各大公司在Kolla里面代码贡献数量非常多，且数量比较均等。

• Kolla的结构

Kolla通过CD/CI后会生成Ansible和Image两个产出。宿主机上安装一个Docker Registry服务，并将镜像上传上去，便可以部署OpenStack，结构非常简单，且Kolla的代码量也很少。

在Image Dependency中，有一个base项会根据需要安装组建，Nova把所有的子服务拆开，以容器的方式运行。

同时还有Dockerfile本身的描述能力有限，只可顺序。Kolla增加了描述能力。可以增加一些变量和一些逻辑判断实现一些复杂功能。

同Kolla的功能描述，其支持多个版本，并支持两种安装方式。

Kolla的部署基本是基于社区的最佳实践，比如一个LoadBalance负载所有API服务，然后是消息队列及数据库，随后是调试器，这就是它的架构。Kolla的部署非常简单，基于Ansible，做了kolla-ansible脚本，这个脚本可以做一些与部署相关的工作，比如前期检查等。

第二是基于 Ansible Inventory，它是一个组的概念，通过它，我们可以知道哪个机器在运行哪个服务。现在支持单机的部署，其实单机跟多机是一样的，只是 Inventory 的文件内部不一样，不仅如此，还支持MariaDB和RabbitMQ集群，同样是自动创建的。

在第二点上，我们比较关心网络问题，因为Docker网络默认是用 Linux Bridge，如果需要在外面访问需要通过port map的方式，但OpenStack有Newton网络的模式，往往会非常慢，等于网络会有许多层。所以，我们选用最简单的：host网络，同在物理机起是一样的。

值得一提的是，它完全尊崇Docker的理念，一个容器一个进程。

• Kolla的特性

第一，Kolla将所有东西都容器化了，包括libvirt和ovs这种比较复杂的应用进行容器化。

第二，严格遵守了一个容器只有一个进程的Docker原则，包括Neutron。这点在Docker1.10是做不到的，因为在里面会创建 namespace ，在其他容器中是看不到的。

第三，物理机不会受到任何“污染”，部署完成之后，如果不想使用了，可以直接把所有的container清楚掉，便可以重新回到原始的、干净的状态。

当然，在整个过程中也会遇到一些问题，比如Docker的timzone，在其他的部署方式下是遇不到的，只能把容器外的时区文件映射到容器里面来实现，否则的话如果改掉外面，容器内部的时区不变，会发生时间跳过几个小时的情况，这个时候Ceph会崩掉。

同时还有ulimit，因为一旦运行到容器里面，ulimit的数值不够大，导致它打开文件太多出错。还有Docker的storage有比较多的选择，现在看来devicemapper比较慢的。

值得一提的是：插件，Kolla缺少的是插件技术，因为OpenStack项目太多，而且每个项目有不同的插件(驱动)，实现起来不一样，不可能依靠Kolla社区来维护，如果真的实现的话，那么会大大加大它的灵活性，实现插件机制就是做集成，即将自身产品相集成。

还有它的配置文件，包括puppet、ansible部署时是把配置项变成上层的一个变量，Kolla与其不同，它是将原始配置文件写好，不会增加用户额外的学习成本，但这个机制暂时只能支持OpenStack的项目，使用对Apache的配置文件尚支持不了。

最后是监控问题，现在虽然有ELK做日志收集和展示，但是没有监控，所以周期内需要做监控的事情，比如zabbix等。