OpenStack概述
OpenStack是一个开源的云计算管理平台项目，是一系列软件开源项目的组合，自2010年6月首次发布以来，OpenStack已经受到了IT业界几乎所有主流厂商的关注与支持，并催生出大量提供相关产品和服务的创业企业，在事实上成为了开源云计算领域的主流标准。
我的新书《LangChain编程从入门到实践》 已经开售！推荐正在学习AI应用开发的朋友购买阅读！
OpenStack社区
OpenStack社区以每6个月为一个版本开发与发布周期，分别于每年4月和10月发布新的OpenStack版本。每个新版本发布之后约三周，社区会举行一次OpenStack设计峰会，以便开发者集中讨论新版本应优先引入的特性，或应集中解决的问题。其后，社区将进入为期约5个月的开发和测试阶段，直至新的版本发布。OpenStack各个项目统一遵循Apache 2.0开源许可证，对于商业应用非常友好，各个项目的核心代码均使用Python语言实现，OpenStack社区目前已经成为了仅次于Linux的世界第二大开源软件社区。
灵活
OpenStack非常灵活，最为突出的体现就在于OpenStack采用插件化的方式实现不同类型计算、存储、网络资源的接入，由此实现OpenStack对于不同类型资源的灵活接入与管理，用一套架构实现了对于不同厂商、不同类型设备的资源池化。例如，在计算领域，可以以插件化的形式接入KVM、Xen等不同的Hypervisor；在存储领域，可以以插件化的形式实现对不同厂商的存储设备，以及Ceph、FusionStorage、vSAN等不同的软件定义存储的管理；在网络领域，可以实现对不同的网络硬件设备，OVS、Liunx-bridge、HAProxy等开源网络组件，以及多种SDN控制器的接入。这些接入都是通过可配置的方式加以选择。
OpenStack的灵活还体现在不依赖于任何特定的商用软硬件。任何商用软硬件产品在OpenStack中一定是可选、可替换的，从而严格保证用户可以使用完全开源、开放的方案来构建基于OpenStack的云计算系统，而完全不必担心被锁定在某些特定厂商的产品之上。
协作方式
OpenStack社区是一个大型的开源合作项目，系统中的代码的流向：从贡献者提交代码的补丁(Pacth)到Gerrit，然后是准备测试环境资源，准备测试系统并运行Tempest测试套(OpenStack社区规定的门槛用例集)，最终报告测试结果并归档测试结果(TestArtifacts)。当贡献者提交补丁给OpenStack的一个项目，他将推送代码给Git服务器，该服务器被Gerrit管理。代码要进入到OpenStack的社区主干，需要经过代码检视和测试的活动。通常情况下，贡献者使用一个叫Git-review的Git插件提交检视。Gerrit控制哪些用户或群组可以提交代码、合并代码和管理代码库。当贡献者推送代码到review.OpenStack.org，Gerrit会创建一个变更设施并放入所提交的补丁。补丁提交者和其他贡献者都可以向变更设施添加新的修改，Gerrit收集并记录补丁所有的变化。
OpenStack架构
在2010年OpenStack社区首次发布其第一个发行版——Austin时，OpenStack仅包含两个项目Nova和Swift，仅能实现非常简单和基础的功能。如今OpenStack已经日渐成熟和强大，其组成项目也已经大大增多，仅包含在Train版本release notes中的服务项目就多达45个，各个项目各司其责，分工合作，共同形成了一个架构灵活、功能丰富、扩展性强的云管理平台。
OpenStack（部分）组件之间的交互
Nova：计算服务
向用户按需提供不同规格的虚拟机，是任何一个云操作系统最为基础的功能。而Nova就是OpenStack中负责提供此类计算服务的项目。Nova的核心功能，是将大量部署了计算虚拟化软件(即Hypervisor)的物理服务器统一纳入管理之下，组成一个具有完整资源视图的逻辑资源池。在此基础上，Nova通过接收不同用户发起的请求，对资源池中的资源进行生命周期管理操作。其中最为核心的，就是虚拟机的创建、删除、启动、停止等操作。通过执行客户发起的虚拟机创建操作，Nova将逻辑资源池中的CPU、内存、本地存储、IO设备等资源，组装成不同规格的虚拟机，再安装上不同类型的操作系统，最终提供给用户进行使用，由此满足用户对于计算资源的需求。除了虚拟机资源管理服务能力之外，Nova还通过与Ironic项目配合，共同为用户提供裸机资源管理服务能力。具体而言，Nova可以接收用户发起的裸机资源申请，然后调用Ironic项目的对应功能，实现对裸机的自动化选择、分配与操作系统安装部署，从而使得用户可以获得与虚拟机资源使用体验相当的物理机资源使用体验。
Ironice：裸机管理
Ironic通过与Nova相配合，共同为用户提供裸机服务能力。在实际工作时，Ironic直接负责对物理服务器的管理操作。一方面，在物理服务器被纳入到资源池之中时，Ironic负责记录物理服务器的硬件规格信息，并向Nova上报；另一方面，在用户发起裸机管理操作时，Ironic负责根据Nova的指令，对相应的物理服务器执行具体的管理操作动作。例如，当用户发起一个创建裸机操作时，Ironic需要根据Nova调度的结果，对选定的物理服务器执行硬件初始化配置、操作系统安装等一系列具体操作，以完成裸机创建动作。
Magnum：容器服务
Magnum是OpenStack社区推出的用于部署和管理容器集群的项目（Liberty 2015.10）。用户可以很方便地通过Magnum来部署和管理Kubernetes。Magnum由Magnum API和Magnum Conductor两个部件构成。Magnum API负责处理用户的请求。一些繁重的任务，比如与Heat进行交互创建集群、则由Magnum Conductor来执行。MagnumAPI和Magnum Conductor之间通过消息队列进行通信。数据库中保存着Bay和BayModel的状态信息。Magnum创建集群的过程是通过Heat模板来完成的，不同的集群对应着不同的模板。
Magnum包括两个对象，即BayModel和Bay。BayModel：BayModel主要定义了容器集群的一些规格，例如这个集群有多少个控制节点，多少个计算节点，以及控制节点和计算节点使用的镜像和资源规格等。Bay：Bay代表一个容器集群。目前可以通过Magnum创建Kubernetes、Swarm、Mesos三种类型的Bay。每一个Bay关联着一个BayModel。
Magnum希望将OpenStack提供的I层能力与容器进行深度结合，为容器提供网络、存储等能力。Magnum功能还在持续开发中，当前支持的主要功能如下：Magnum目前能部署Kubernetes、Swarm、Mesos三种类型的容器集群；支持容器集群的自动伸缩；支持本地Docker镜像仓库。
Murano
Murano是OpenStack的Application Catalog服务（Kilo2015.04），推崇AaaS(Anything-as-a-Service)的概念，通过统一的框架和API实现应用程序快速部署和应用程序生命周期管理的功能，降低应用程序对底层平台(OpenStack层和虚拟化层)的依赖。Murano包括以下几个部分：
murano核心服务：包含了Murano APIserver、Murano engine和MuranoPL。
murano-agent：运行在客户虚拟机并执行部署计划。
murano-dashboard：Murano UI提供了OpenStack的仪表板插件。
murano-client CLI：即Murano的客户端库和命令行。
Murano使用OpenStack的服务，使用REST API和OpenStack服务交互，Murano通过AMQP队列，远程操作部署在用户服务器上的Murano agent，确保基础设施和服务器被隔离。Murano的主要特性概况如下：
(1) 应用程序目录
以图标的方式显示应用程序，并支持拖放选择和部署；应用可以分类，可以定制配置界面；自动生成应用的网络拓扑图。
(2) 应用程序目录管理
上传应用提供了UI和命令行方式，支持本地zip文件、URL和包名称多种方式；分类组织应用，可以更新应用的名称、描述和标签。
(3) 应用程序生命周期管理
简化配置和应用集成，可以定义应用之间的依赖关系，新的应用可以使用已经存在的服务；支持HA和自动缩放；相同环境的应用之间可以交互，不同租户之间的应用隔离。
Kuryr
Kuryr实现了Docker网络组件Libnetwork的一个远程网络插件，Kuryr通过把Libnetwork的调用映射到OpenStack Neutron网络上，实现了
Libnetowrk CNM(容器网络模型)和Neutron网络模型之间的转换，从而让容器可以使用OpenStackNeutron网络。
Kuryr一词来自捷克语，意思是“信使”，旨在成为连接Docker和Neutron两个社区的信使和桥梁，从而弥补当前容器网络方案不成熟，快速利用Neutron能力提供容器网络方案。
当前容器生态中，Docker和Kubernetes分别抽象了不同的网络模型，即CNM(ContainerNetwork Model)网络模型和CNI(Container Network
Interface)网络模型。Kuryr分别提供给了接入两种网络模型的能力。如图5-14所示，Kuryr当前实现了Libnetwork网络插件和IPAM(IP地址管理)插件，从而可以实现用Kuryr支持Docker或者Docker Swarm的网络能力。
Kuryr正在开发接入Kubernetes网络的能力。Kuryr Raven通过向Kubernetes中API服务订阅事件变化，获取网络相关的状态变化，并把这些状态变化转化成对Neutron API的调用，从而构建基于Neutron的虚拟网络。当获取Neutron相应后，Raven负责把返回的信息添加到Kubernetes对象上，如把IP、端口信息添加到Kubernetes Pod对象上。
Kuryr同时实现了Kubernetes CNI驱动，从而实现为每个Kubernetes工作节点上面的Pod设置网络信息。
Kuryr通过Neutron Client实现对Neutron API的调用。Kuryr通过Keystone Client调用Keystone实现请求认证。
Fuxi
Fuxi项目旨在将OpenStack Cinder卷存储、Manila文件存储、Swift/S3提供给Docker容器使用，作为容器的持久化存储，使Docker可以重用Cinder和Manila提供的高级功能(如快照、备份)和丰富的第三方厂商设备接入。
Fuxi实现标准Docker remote volume pluginAPI，便于Docker deamon/Swarm接入，同时提供Fuxi Client插件接入Kubernetes。
Tricircle
OpenStack级联是一个开放的社区项目，项目名称是Tricircle。基于OpenStack级联的混合云采用的是云中介加上云网关的架构模式，这个OpenStack级联就是云中介的核心服务，它起到了拉通底层各个不同云的资源池的作用。云网关则是注入到底层不同的云中来拉通各个云的资源，包括AWS公有云、Azure公有云、VMware私有云、第三方OpenStack公有云、华为OpenStack公有云和私有云等。
云中介内部是标准的OpenStack模块，包括负责计算的Nova，负责存储的Cinder，负责网络的Neutron，负责资源编排的Heat，负责认证的Keystone等。这里的计算、存储、网络虽然完全兼容OpenStack的标准API，但云中介内部其实并没有任何真实的资源，只是通过简单的调度算法找到合适的Proxy，通过Proxy找到合适的底层云来进行真正的资源分配，资源分配完成后，云中介要负责登记注册这些资源信息，为后续的跨云网络互通、跨云迁移和跨云容灾提供管理。
OpenStack的作用
典型的IaaS平台数据中心管理过程中OpenStack的作用
- 服务区域（Region）内各可用性区域（AZ）间的网络传输时延迟一般控制在10ms的范围内，一个可用性区域一般由一个多个物理数据中心构成，物理数据中心仅对运维管理员可见，对普通租户/用户不可见。
- 数据中心内物理网络传输时延一般在1ms范围以内，每个物理数据中心内可以部署一个或多个资源池集群（POD），每个资源池集群（POD）对应一个云资源池调度管理系统实例（如 OpenStack），每个资源池集群包含的服务器规模一般是数千到数万台，其中包含了用于承载租户业务应用负载的计算集群，以及用来承载租户数据的存储集群。
- 在同一物理资源池集群范围内，考虑到云租户对服务器硬件需求的特殊性（比如对于GPU加速硬件、不同工作频率和数量的CPU、不同容量的内存），所以需要对同一资源选择属性的服务器打标签，这些资源属性标签相同的服务器构成一个“主机集合”，同一服务器主机可被标记为多个资源属性标签，即可以隶属于多个“主机集合”。
- “主机集合”是一个基于特定资源池属性维护来划分的“逻辑资源池”概念，该“主机集合”的标签条件，将与云资源池调度管理软件API入口制定的动态调度参数进行匹配，从而决定当前的资源发放申请被调度到哪些“主机集合”内。（即异构适配多种Hypervisor
类型，由于OpenStack的架构支持不同Hypervisor类型的虚拟机/物理机同时发放。因此可以通过配置实现在同一个OpenStack中进行各个不同类型的Hypervisor的虚拟机/物理机混合发放，其也可以用于异构不同虚拟化厂商的虚拟化软件，前提是该虚拟化软件需要在OpenStack中有对应的Driver。
参考链接
OpenStack概述
