核心服务就是如果没有它，OpenStack 就跑不起来。很显然
作为openStack的基础服务，Keystone主要做下面这3件事情
要弄懂Keystone就得理解下面这些概念
User指代任何使用openStack的实体
可以是真正的用户，也可以是某个程序，openStack为每一个组件都会创建对应的用户，当User访问openStack时，Keystone会对其验证身份
Credentials是User用来证明自己身份的信息
它可以是:
Authentication是Keystone验证User身份的过程
User访问openStack时向Keystone提交用户名和密码形式的Credentials，Keystone验证通过后会给User签发一个Token作为后续访问的Credentials
Token是由数字和字母组成的字符串，User成功Authentication后由Keystone分配给user
Project用于将openStack的资源(计算，存储，网络)进行分组，隔离
根据openStack服务的对象不同，Project可以是一个客户、部门或者项目组
这里请注意：
OpenStack 的 Service 包括 Compute (Nova)、Block Storage (Cinder)、Object Storage (Swift)、Image Service (Glance) 、Networking Service (Neutron) 等。
每个 Service 都会提供若干个 Endpoint，User 通过 Endpoint 访问资源和执行操作。
Endpoint是一个网络上可访问的地址，通常是一个URL，Service通过Endpoint来暴露自己的API
Keystone负责维护管理每个Service的Endpoint
安全包含2个部分，一个是认证(Authentication)，另一个是鉴权(Authorization)
Authentication解决的是你是谁的问题
Authorization解决的是你能干什么的问题
Keystone是借助Role来实现Authorization的，也就是给Role定义好权限之后将Role绑定用User，那么User就拥有这个Role下定义的权限了
所以Keystone的工作流程就是这样的
这个就是keystone的工作流程了，所有的组件和用户都需要经过keystone，这也证实了openStack没有Keystone转不了的说法
Glance为虚拟机提供镜像服务，这里不过多赘述组件的功能，glance有2个服务进程
glance-api 是系统后台运行的服务进程。 对外提供 REST API，响应 image 查询、获取和存储的调用。
glance-api 不会真正处理请求。
如果是与 image metadata（元数据）相关的操作，glance-api 会把请求转发给 glance-registry；
如果是与 image 自身存取相关的操作，glance-api 会把请求转发给该 image 的 store backend。
glance-registry 是系统后台运行的服务进程。负责处理和存取 image 的 metadata，例如 image 的大小和类型。
glance本地并不存储image，真正的image存储是放在backend中的，默认是本地的文件系统
当用户请求到达glance-api时，glance-api会将请求转发给对应的服务进程，如：当用户想要查询有哪些镜像存在时，glance-api就会将请求给到glance-registry处理，处理完成之后再由glance-api将结果返回给到用户，同样，存储的请求就会交给backend去处理，至于你存储到哪，glance-api是不管的，这个就是glance的工作流程
这个组件以前集成在nova之中，现在独立出来了，他的作用的用来跟踪硬件的利用率，将收集到的数据提供给后续的nova使用，这个没啥多说的
Compute Service, Nova 是 OpenStack 最核心的服务，负责维护和管理云环境的计算资源。OpenStack 作为 IaaS 的云操作系统，虚拟机生命周期管理也就是通过 Nova 来实现的。
nova有很多子组件，分别是
数据库和消息队列这也是nova所依赖的，但是他们俩并不是nova独享的。
与glance-api一样，只负责接受请求，不处理请求，只会将请求接受然后发布到消息队列当中
虚拟机调度服务，通过placement提供的各项数据再结合各种算法，打分机制来决定虚拟机最终运行在哪个计算节点上，并将消息通过消息队列发布出去
管理虚拟机的核心服务，运行在每个计算节点上，nova-compute是实际工作者，他会从消息队列中拿到nova-scheduler发布的消息，然后来创建虚拟机，每个虚拟机的状态都是需要写入数据库的，也就是说nova-compute需要经常更新数据库，但是nova-compute并不能直接操作数据库，为了安全考虑，由另外一个组件来操作数据库。
nova-compute 经常需要更新数据库，比如更新虚机的状态。
出于安全性和伸缩性的考虑，nova-compute 并不会直接访问数据库，而是将这个任务委托给 nova-conductor，为什么说为了安全考虑呢？我们不妨设想一下，现在集群内有100个计算节点，他们如果能够直接操作数据库的话，那么只有要其中的一台服务器被侵入，那么他是可以直接拿到数据库操作的权限的，这样做风险太大了，所以将更新数据库的操作交给了nova-conductor这个进程来处理
现在虚拟机创建好了，我们是不是需要使用虚拟机呢？假设现在网络不通，无法通过ssh或者RDP连接到虚拟机，那我们如何去管理呢？也就是通过nova-console为我们提供的控制台，nova-console是一个统称，并不是某一个服务。
它包含3种方式的控制台：
当有一个创建虚拟机的请求到达nova-api时，nova-api会将请求发送到消息队列，此时nova-scheduler从消息队列读取消息，然后选举一个最适合创建虚拟机的节点，然后将结果再通过消息队列发布出去，nova-compute从消息队列中读取到了消息之后开始干活，并将虚拟机的状态信息发布到消息队列，然后nova-conductor读取到了nova-compute发布的消息之后去操作数据库修改对应的数据
Neutron 为整个 OpenStack 环境提供网络支持，包括二层交换，三层路由，负载均衡，防火墙和 VPN 等。
Neutron 提供了一个灵活的框架，通过配置，无论是开源还是商业软件都可以被用来实现这些功能。
关于网络的话我们就不讨论他的工作流程了。我们来聊聊他的实现方式
neutron通过在每个节点上模拟一个软路由出来，跑在该节点上的虚拟机都接到这个软路由上，这样同节点的虚拟机网络就实现了互通，那不同节点之间呢？模拟出来的软路由也不能够直接跨主机通信吧，这个时候就需要借助到物理网卡了，我们配置neutron的时候，有一个配置是将某个网卡给neutron去使用的，所以，在同一节点内，所有的虚拟机都连接上这个软路由实现互联，不同节点之间通过配置的物理网卡来实现互联，这样一套操作下来，所有的网络就都能打通了。这也就是neutron的实现方式，但是neutron又提供了好种网络类型，接下来我们来一个个看
Neutron提供的网络有这几种：
local类型的网络与其他节点的网络隔离，也就是说local类型的网络只能够与跑在同一节点上的虚拟机进行通信，无法跨主机通信，这种网络是没有意义的，实验环境都没有太大的意义。
flat网络是无vlan tag的网络，能够与其他节点的虚拟机互联，但是无法实现隔离，如果集群内节点过多，那么相应的，广播域也就越大，这种类型的网络在local网络之上做到了与其他节点互联
这个网络类型就是网络里的Vlan，交换机可以通过不同的Vlan ID来实现隔离，可以这样去理解，Vlan就是在flat网络之上给每个人分一个组，只有在同一个组里面的虚拟机才可以互相访问，在不同的组就访问不到，这样就解决了flat网络的广播域过大的问题。最多可以支持4094个分组
VLAN有4096个ID，而VXLAN有1600万个ID。这也就意味着vxlan支持隔离更多的区域，但是vxlan是工作在三层的，使用upd协议进行传输，而vlan是一个二层的，由于需要进行封装和解封装操作，性能开销比VLAN高，但可以通过硬件卸载来优化性能。
gre 是与 vxlan 类似的一种 overlay 网络。主要区别在于使用 IP 包而非 UDP 进行封装。