打开《OpenStack 云平台-部署与高可用实战》_9.2.3.4.Op enShift 核心组件

【摘要】 本书摘自《OpenStack 云平台-部署与高可用实战》一书中第9.2.3.4.节，肖睿 雷宇飞主编。

9.2.3.4.Op enShift 核心组件

OpenShift 的核心组件及其之间的关联关系如图9.17所示。OpenShift 在容器编排层 使 用 了 Kubernetes, 所 以 OpenShift 在 架 构 上 和 Kubernetes 十 分 接 近 。 其 内 部 的 许 多 组 件 和概念都是从Kubernetes 衍生而来，但是也存在一些组件，在容器编排层之上。

(1)Master 节点

Master节点属于主控节点，集群内的管理组件都运行在Master节点上。Master节点 负责集群的配置管理并维护集群的状态。Master 节点上运行的服务组件有以下几个。

● API Server: 负责提供Web Console 和 RESTful API。集群内所有节点都会访问

API Server 来更新节点的状态及容器的状态。

● 数据源 (Data store): 负责存储信息。集群内所有的状态信息都会存储在后端的 一个名为 etcd 的分布式数据库中。

● 调度控制器 (Scheduler): 负责按用户输入的要求寻找合适的计算节点。

● 副本控制器 (Replication Controller): 负责监控当前容器实例的数量和用户部署 指定的数量是否匹配，若有容器异常退出，副本控制器会发现实际数量少于部署定义数， 从而触发部署新的实例。

(2)Node 节点

Node 节点是计算节点，用于接收 Master 节点的指令来运行和维护 Docker 容器。 Master 节点也可以是Node 节点，只是在一般环境中，其运行容器的功能是关闭的。

(3)Project 和 Namespace

在Kubernetes 中使用命名空间的概念来分隔资源。在同一个命名空间中，某一个对 象的名称在其分类中必须是唯一的，但是分布在不同命名空间的对象则可以同名。 OpenShift 继承了 Kubernetes 命名空间的概念，而且在其之上定义了 Project 对象的概念。 每一个 Project 会和一个 Namespace 相关联，甚至可以简单地认为， Project 就是 Namespace。所以在 OpenShift 中进行操作时，首先要确认当前执行的上下文是哪一个 Project。

(4)Pod

在 OpenShift 中运行的容器会被 Pod 所“包裹”,用户不会直接看到 Docker 容器本 身。从技术上来说，Pod 其实也是一种特殊的容器。

(5)Service

由于容器是一个非持久化的对象，所有对容器的修改在容器销毁后都会丢失，而且 每个容器的IP 地址会不断变化。Kubernetes 提供了 Service 组件，当部署某个应用时， 会创建一个Service 对象，该对象与一个或多个 Pod 关联，同时每个 Service 分配一个相 对恒定的 IP, 通过访问该IP 及相应的端口，请求就会转发到对应 Pod 端口。除了可通 过IP, 也可以通过域名访问 Service, 格式为： ..svc.cluster.local。

(6)Router 和 Route

Service 提供了一个通往后端 Pod 集群的稳定入口，但是 Service 的 IP 地址只对集群 内部的节点和容器可见，外部则需通过 Router (路由器)来转发。Router 是 OpenShift 集群中一个重要的组件，它是外界访问集群内容器应用的入口。用户可以创建Route (路 由规则)对象， 一个Route 对象会与一个Service 关联并绑定一个域名。Route 会被 Router 加载。当集群外部的请求通过指定域名访问应用时，域名被解析并指向Router 所在的计 算节点，Router 获取该请求，然后根据 Route 转发请求到与这个域名对应的 Service 后端 所关联的 Pod 容器实例。上述转发流程类似于Nginx 。即 Router 负责将集群外的请求转 发到集群的容器， Service 则负责把来自集群内部的请求转发到指定的容器中。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们 18664393530@aliyun.com 处理，核实后本网站将在24小时内删除侵权内容。