OpenStack Liberty版本新特性探究

CloudComputing OpenStack

版本控制

@Title          OpenStack Liberty版本新特性探究
@Version        v1.0
@Timestamp      2016-01-06 14：18
@Author         Nicholas
@Mail           redskirt@outlook.com

浅谈OpenStack与虚拟机的区别与联系

以KVM为例，谈谈OpenStack与虚拟化的区别和联系

开源管理项目OpenStack是一个旨在为公共及私有云的建设与管理提供软件的开源项目。它不是一个软件，而是由几个主要的组件组合起来完成一些具体的工作。OpenStack由以下五个相对独立的组件构成：

• OpenStack Compute(Nova)是一套控制器，用于虚拟机计算或使用群组启动虚拟机实例;
• OpenStack镜像服务(Glance)是一套虚拟机镜像查找及检索系统，实现虚拟机镜像管理;
• OpenStack对象存储(Swift)是一套用于在大规模可扩展系统中通过内置冗余及容错机制，以对象为单位的存储系统，类似于Amazon S3;
• OpenStack Keystone，用于用户身份服务与资源管理以及
• OpenStack Horizon，基于Django的仪表板接口，是个图形化管理前端。
  这个起初由美国国家航空航天局和Rackspace在2010年末合作研发的开源项目，旨在打造易于部署、功能丰富且易于扩展的云计算平台。OpenStack项目的首要任务是简化云的部署过程并为其带来良好的可扩展性，企图成为数据中心的操作系统，即云操作系统。

KVM：开放虚拟化技术
KVM(Kernel-based Virtual Machine)是一个开源的系统虚拟化模块，它需要硬件支持，如Intel VT技术或者AMD V技术，是基于硬件的完全虚拟化，完全内置于Linux。
2008年，红帽收购Qumranet获得了KVM技术，并将其作为虚拟化战略的一部分大力推广，在2011年发布RHEL6时支持KVM作为唯一的hypervisor。KVM主打的就是高性能、扩展性、高安全，以及低成本。

OpenStack与KVM的解决方案
在去年9月22日发布Diablo之后，OpenStack社区随即开始着手新版本的设计和开发，新版本开发代号为Essex。此前发布有四个版本：Austin、Bexar、Cactus与Diablo。新版本发布包含云计算控制中心Nova、镜像服务Glance、认证服务Keystone和Dashboard项目Horizon，也包括对象存储项目Swift。
由此可以看出，OpenStack是一个框架，一个可以建立公有云和私有云的基础架构。它并不是一个现成的产品，要想开展基础架构方面的工作，企业需要顾问和开发人员。很多时候还需要第三方的集成工具。
KVM可通过购买Linux版本获得，或作为独立hypervisor单独购买。最近，IBM KVM(北京)卓越中心落户北京，展示IBM及合作伙伴基于KVM的产品，包括IBM SmartCloud Entry、IBM System Director VMControl、Red Hat Enterprise Virtualization及SUSE云。

OpenStack与KVM相互辉映
OpenStack几乎支持所有的虚拟化管理程序，不论是开源的(Xen与KVM)还是厂商的(Hyper-V与VMware)。但在以前，OpenStack是基于KVM开发的，KVM常常成为默认的虚拟机管理程序。两者都使用相同的开放源理念与开发方法。
如今，多数企业用户在IT环境中使用了超过一种的虚拟化软件，有一半的用户选择将开源产品作为性价比更高的虚拟化替代方案。IDC报道中指出，OpenStack是KVM增长的一个巨大机会。OpenStack是一个具有巨大的行业发展动力，并拥有一个充满活力的社区的云计算平台，有95%的OpenStack平台由KVM驱动。因此，随着OpenStack的增长，KVM也会相应增长。

OpenStack最新版本Liberty是第12个版本。

OpenStack Liberty 版本功能有哪些新突破

更强的可管理性
　　更细化的访问控制和更简单的管理功能在Liberty中首次亮相。作为对运营商需求的直接回应, OpenStack云平台添加了诸如公共库采用以及优化配置管理等新功能。新版还添加了基于用户角色的访问控制(RBAC)，以用于Heat编排和Neutron网络项目。这些控制功能可以让运营商在网络和编排功能以及API的不同层级上对安全设置进行微调。

简化的可扩展性
　　在公共与私有领域中，部署OpenStack的生产环境的规模和范围均不断增加，因此，用户要求改善对大型部署的支持。在Liberty版本中，这些用户可以获得性能与可靠性的诸多改善，其中初版Nova Cells v2便提供了能够支持规模庞大的多点计算部署的新模式。此外，Liberty用户可以在Horizon面板、Neutron网络Cinder块存储服务，以及系统升级至Nova计算服务期间，获得可扩展性与性能方面的提升。

支持全新技术的可延伸性
　　作为一个开源平台，OpenStack用于管理三大主要云计算技术：虚拟机、容器以及裸机实例，同时也是企业在其网络拓扑结构中实施NFV(网络功能虚拟化)的理想平台。Liberty凭借可延伸的Nova计算调度器、网络QoS框架以及增强的LBaaS(负载平衡即服务)等新特性，进一步提升了OpenStack在上述三大领域的功能。
　　除此之外，Liberty还带来了首个完整版的Magnum容器管理项目。Magnum自开始就支持包括Kubernetes、Mesos和Docker Swarm在内的多个目前流行的容器集群管理工具。由于Magnum集成在Nova、Ironic和Neutron等OpenStack的现有服务之中，因此更利于使用者采用容器技术。名为Kuryr的新项目则计划直接集成libnetwork等原生的容器网络组件，从而带来进一步的改善。
　　为了能够在Liberty中对更强大的功能进行管理、自动处理和组织编排，OpenStack特意在Heat编排项目中新增了数十种资源。新版本还包含管理和等级方面的改善，包括经RBAC过滤的可揭示资源和行动可用状况的API。
　

依靠可选功能，关注核心服务
　　在Liberty版本发行周期内，开源社区改变了组织和确认上游项目的方式，这被社区成员称为“大帐篷(big tent)”。最终，这些变化促使开源社区能够专注于规模较小的核心服务，同时在更为广阔的上游生态系统中鼓励更多的创新。
　　这些核心服务可以在所有OpenStack驱动的产品或公共云、中央计算(包括虚拟化和裸机)、存储(块和对象)以及网络连接中获得。
　　最近六个月新增的项目则提供可选功能，例如通过Magnum实现容器管理(支持Kubernetes、Mesos以及Docker Swarm)，通过Astara实现网络编排，通过Kuryr实现容器联网，通过CloudKitty实现账单支付，以及利用多种流行的应用模板生成的社区App目录。这些加入到已有项目的新功能能够支持大数据分析、数据库管理、编排等应用。
　　OpenStack基金会执行总监Jonathan Bryce 表示：“Liberty是一个具有里程碑意义的版本，因为它增强了Openstack作为一个多元的全球开源社区的能力，使其在技术决策层面达成一致，同时修正项目管理以完善软件并回应市场需求，最终设计出用户和运营商所需的软件。在这个实现人人参与的开源社区的基础上，Openstack搭建了一个整合当前和未来技术的可延伸平台。”

OpenStack Kolla

Kolla聚焦于如何使用Docker容器部署 OpenStack服务。在裸机上部署OpenStack是一个复杂的事 情，这也不是Kolla项目当前的目标。实际工作中，我们需要一个可以简化单节点或者多节点的Kolla集群环境，所以，我们就创建了一个可以向已经存在的OpenStack云平台部署Kolla集群的模板。

当前，使用heat模板在已经存在的openstack cloud上部署一个Kolla cluster。

当前Kolla项目在Kollaglue repo提供了以下服务的docker镜像。
$ sudo docker search kollaglue

当前的问题
当前升级和降级openstack主要有两种方式，基于image与基于package。基于image的方式，更新是原子的。基于package的更新方式通常不是原子的，升级过程中存在很多导致失败的原因，可能存在部分package更新失败的可能。

使用场景

• 原子性的升级或者回退openstack部署。
• 基于组件升级openstack。
• 基于组件回退openstack。

安全与其他
某些容器可能需要privileged，某些可能需要host相同的namespace。安全加强可以使用Selinux或者AppArmor。

Kolla项目利用Docker、Docker-Compose、Asinble来完成部署OpenStack,目前Kolla已经能够完成一个all-in-one的开发环境的部署。从Kolla项目spec中的描述来看，主要是利用Docker容器的隔离性来达到OpenStack的原子升级、回退在升级。整个升级、回退的过程更容易控制影响范围，降低整个OpenStack的运维复杂度。

Kolla定义了容器集合及容器两个概念。

容器集合具有以下属性

• 容器集由一个或多个容器子集或者一个或多个容器组成；
• 一个容器集提供一个逻辑上的的服务；
• 启动、停止和版本的控制以容器集为粒度；
• 以容器集的粒度来完成安装；
• 包含容器子集的容器集也以一个独立单元启动，包含所有的容器子集及容器子集内的所有容器；
• 容器集合并不是原子的管理单位；
• 容器集必须提供进行服务状态监控的钩子；

容器具有以下属性

• 容器集能够原子的升级和回退；
• 容器包含一个单调增长的计数器，用来标志容器的存活时间；
• 容器的职责是单一的；
• 只赋予容器刚刚好的权限；
• 需要包含检查容器健康状态的脚本；

• 必须包含pid为1的进程用来回收推出的子进程；

  Kolla的容器集集包含的容器
  Database control

  galera
  mariadb
  mongodb

Messaging control

rabbitmq

High availability control

HAProxy keepalived
OpenStack interface

keystone
glance-api
nova-api
ceilometer-api
heat-api

OpenStack control

glance-controller
glance-registry
nova-controller
nova-conductor
nova-scheduler
metadata-service
cinder-controller
neutron-controller
neutron-server
ceilometer-controller
ceilometer-alarm
ceilometer-base
ceilometer-central
ceilometer-collector
ceilometer-notification
heat-controller
heat-engine

OpenStack compute operation

nova-compute
nova-libvirt
neutron-agents-linux-bridge
neutron-agents-ovs

OpenStack network operation

dhcp-agent
l3-agent
metadata-agent
lbaas-agent
fwaas-agent

OpenStack storage operation

Cinder
Swift
swift-account
swift-base
swift-container
swift-object
swift-proxy-server

Kuryr项目简介
http://blog.csdn.net/canxinghen/article/details/50153221

Kuryr旨在成为一座连接Docker和Neutron两个社区的“整合桥梁”，将Neutron（或Docker）中的建议与实际变化结合在一起，让它们能够满足容器网络所需的使用案例。

Kuryr本身并不是一个网络解决方案，同时它也没有尝试成为一个网络解决方案。Kuryr将重点放在了“信使”功能上，以向Docker 传递Neutron网络和服务。

Kuryr映射了libnetwork API，并在Neutron中创建了一个适当的对象。这意味着每个执行NeutronAPI的解决方案都能够被用于容器网络。Neutron的所有附加功能都可以应用至容器端口，例如安全群组、NAT服务和浮动IP的端口处。

不过，Kuryr的潜力并不止步于核心API和基本的扩展，它还能够利用网络服务和LBaaS等功能，从而为执行Kubernetes服务提供抽象层。

当API的映射并不明显，或是所需驱动在Neutron社区中发生了变化时，Kuryr还可以用于弥补这些问题。最近的一个例子是，除了Neutron资源外的标签允许Kuryr这样的API客户端存储映射数据和端口转发，并且可以提供Docker类型的端口（当然，所有的这些仍处于评估和批准流程中）。

OpenStack发展趋势

OpenStack软件推出的许多新项目或组件已经被融合到Liberty版本中。其中包括：基于Magnum的容器管理项目（对Kubernetes、Mesos和Docker Swarm提供支持）；网络编排项目Astara；容器网络项目Kuryr；计费项目CloudKitty；以及汇集了许多流行的应用模板的社区服务目录（Community App Catalog）。这些新服务的加入证明，OpenStack已经在大数据分析、数据集群管理、资源编排等领域不断扩展与完善。

Kuryr实现容器联网，增加对厂商硬件Driver的支持。

Kuryr是一个Docker网络插件，其通过Neutron为Docker容器提供网络服务。Kuryr可以单独或以容器化的方式使用，这使得它们可以使用通用Neutron插件将容器插入到Neutron网络中。

Kuryr项目是想把neutron的网络给容器用。

一、docker那边需要先挖好坑，把网络部分的接口暴露出来。

docker把网络部分提取成了libnetwork，并为此实现了几个driver，host、overlay、null和remote，其中remote就是为用其他项目来管理docker的网络留的接口。remote采用rpc的方式将参数通过网络发给外部管理程序，外部程序处理好了后通过json返回结果给remote。

libnetwork的remote driver定义了基本的创建网络、创建port的接口，只要对应的REST Server实现了这些接口，就可以提供整套docker的网络。这些接口有：Create network、Delete network、Create endpoint、Delete endpoint、Join（绑定）、Leave（去绑定）。

remote driver的接口定义在 https://github.com/docker/libnetwork/blob/master/docs/remote.md

用remote driver分配了设备一般是不带IP的，libnetwork使用ipam driver来管理ip。这些接口有：GetDefaultAddressSpaces 获取保留IP，RequestPool获取IP地址池，ReleasePool释放IP地址池，RequestAddress获取IP地址，ReleaseAddress释放IP地址。

ipam driver的接口定义在 https://github.com/docker/libnetwork/blob/master/docs/ipam.md
libnetwork的插件发现机制在 https://github.com/docker/docker/blob/master/docs/extend/plugin_api.md#plugin-discovery

二、kuryr这边就按照docker给的接口转为neutron的操作。

1. 配置文件里面定义好参数，以便能连上neutron。
2. 使用Flask（而不是wsgi）实现一个REST Server，以便接收remote driver传过来的参数。
3. 使用libnetwork的插件机制，在 /usr/lib/docker/plugins/ 目录下建立kuryr的插件描述的json文件。
4. docker daemon启动的时候，libnetwork发现kuryr这个新插件，并且通过 /Plugin.Active 验证这个插件可用。
5. 使用docker network create --driver=kuryr foo 在docker中创建一个网络
6. 用户使用docker创建一个容器的时候，指定网络为 foo
7. kuryr从libnetwork接收到请求，并用很多硬编码的schemata来验证用户输入的参数对不对，然后把创建 Network/Sandbox/Endpoint转为对应neutron的资源，发送给neutron。
8. kuryr接收neutron的结果，再用pyroute2创建veth pair，一个bind到neutron的port，一个以给veth设置netns的方式给容器。
9. kuryr把neutron返回的结果包装成libnetwork的样式，转发给libnetwork。

这样容器就能用neutron的网络了，并且可以使用因此而来的附加功能：安全组、租户网络。

kuryr类似ovs-agent，也需要每个计算节点安装一个。