《OpenstackCompute逻辑架构》.ppt

Pod：是Kubernetes最基本的部署调度单元，可以包含Container，逻辑上表示某种应用的一个实例。比如一个web站点应用由前端、后端及数据库构建而成，这三个组件将运行在各自的容器中，那么我们可以创建包含三个Container的Pod。 Service： 也是Kubernetes的基本操作单元，是真实应用服务的抽象，每一个服务后面都有很多对应的容器来支持，通过Proxy的port和服务selector决定服务请求传递给后端提供服务的容器，对外表现为一个单一访问接口，外部不需要了解后端如何运行，这给扩展或维护后端带来很大的好处。 ReplicationController：是Pod的复制抽象，用于解决Pod的扩容缩容问题。通常，分布式应用为了性能或高可用性的考虑，需要复制多份资源，并且根据负载情况动态伸缩。通过ReplicationController，我们可以指定一个应用需要几份复制，Kubernetes将为每份复制创建一个Pod，并且保证实际运行Pod数量总是与该复制数量相等(例如，当前某个Pod宕机时，自动创建新的Pod来替换)。 相关概念 容器集合调度部署的基本单元 Pod的访问代理抽象 Pod的复制抽象 Kubernetes层次图 Labels：Labels是用于区分Pod、Service、Replication Controller的key/value键值对，仅使用在Pod、Service、 Replication Controller之间的关系识别，但对这些单元本身进行操作时得使用name标签。 Kubernetes架构图 master运行三个组件： apiserver：作为kubernetes系统的入口，封装了核心对象的增删改查操作，以RESTFul接口方式提供给外部客户和内部组件调用。它维护的REST对象将持久化到etcd（一个分布式强一致性的key/value存储）。 scheduler：负责集群的资源调度，为新建的pod分配机器。这部分工作分出来变成一个组件，意味着可以很方便地替换成其他的调度器。 controller-manager：负责执行各种控制器，目前有两类： endpoint-controller：定期关联service和pod(关联信息由endpoint对象维护)，保证service到pod的映射总是最新的。 replication-controller：定期关联replicationController和pod，保证replicationController定义的复制数量与实际运行pod的数量总是一致的。 slave(称作minion)运行两个组件： kubelet：负责管控docker容器，如启动/停止、监控运行状态等。它会定期从etcd获取分配到本机的pod，并根据pod信息启动或停止相应的容器。同时，它也会接收apiserver的HTTP请求，汇报pod的运行状态。 proxy：负责为pod提供代理。它会定期从etcd获取所有的service，并根据service信息创建代理。当某个客户pod要访问其他pod时，访问请求会经过本机proxy做转发。 Kubernetes时序图 云计算框架图 * 对于云计算,从存储层的搭建来说，关系型数据库，nosql数据库和hdfs分布式文件系统三种存储方式都支持。 而hadoop中hive，pig和hadoop-mapreduce框架相关的技术内容全部划入到云计算数据处理层, mapreduce只是实现了一个分布式计算的框架和逻辑 * OpenStack 虚拟网络 Neutron 把部分传统网络管理的功能推到了租户方，租户通过它可以创建一个自己专属的虚拟网络及其子网，创建路由器等等，在虚拟网络功能的帮助下，基础物理网络就可以向外提供额外的网络服务了，比如租户完全可以创建一个属于自己的类似于数据中心网络的虚拟网络。Neutron 提供了比较完善的多租户环境下的虚拟网络模型以及 API。像部署物理网络一样，使用 Neutron 创建虚拟网络时也需要做一些基本的规划和设计。 * a) 终端用户(DevOps, Developers 和其他的 OpenStack 组件)通过和nova-api对话来与OpenStack Compute交互。 b) OpenStack Compute守护进程之间通过队列(行为)和数据库(信息)来交换信息，以执行API请求。 c) OpenStack Glance基本上是独立的基础架构，OpenStack Compute通过Glance API来和它交互。 * * PackStack是Red Hat推出的协助安装openstack的工具软件，PackStack 取代了手动搭建OpenStack的过程 puppet