《开源容器云OpenShift：构建基于Kubernetes的企业应用云平台》一3.2 核心组件详解

本节书摘来自华章出版社《开源容器云openshift：构建基于kubernetes的企业应用云平台》一书中的第3章，第3.2节，作者 陈耿 ，更多章节内容可以访问云栖社区“华章计算机”公众号查看

openshift的核心组件及其之间的关联关系如图3-2所示。openshift在容器编排层使用了kubernetes，所以openshift在架构上和kubernetes十分接近。其内部的许多组件和概念是从kubernetes衍生而来，但是也存在一些在容器编排层之上，openshift特有的组件和概念。下面将详细介绍openshift内部的核心组件和概念。

在介绍master节点前，我们先补充一些内容。openshift集群可以由一台或多台主机组成。这些主机可以是物理机或虚拟机，同时可以运行在私有云、公有云，或混合云上。在openshift的集群成员有两种角色。

master节点：即主控节点。集群内的管理组件均运行于master节点之上。master节点负责管理和维护openshift集群的状态。

node节点：即计算节点。集群内的容器实例均运行于node节点之上。

如图3-2所示，在master节点上运行了众多集群的服务组件：

api server。负责提供集群的web console以及restful api服务。集群内的所有node节点都会访问api server更新各节点的状态及其上运行的容器的状态。

数据源（data store）。集群所有动态的状态信息都会存储在后端的一个etcd分布式数据库中。默认的etcd实例安装在master节点上。如有需要，也可以将etcd节点部署在集群之外。

调度控制器（scheduler）。调度控制器在容器部署时负责按照用户输入的要求寻找合适的计算节点。例如，在前面章节我们部署的router组件需要占用计算节点主机的80、443及1936端口。部署router时，调度控制器会寻找端口没有被占用的计算节点并分配给router进行部署。除了端口外，用户还能指定如cpu、内存及标签匹配等多种调度条件。

复制控制器（replication controller）。对容器云而言，一个很重要的特性是异常自恢复。复制控制器负责监控当前容器实例的数量和用户部署指定的数量是否匹配。如果容器异常退出，复制控制器将会发现实际的容器实例数少于部署定义的数量，从而触发部署新的容器实例，以恢复原有的状态。

在node节点上没有这么多系统组件，其主要职责就是接收master节点的指令，运行和维护docker容器。

这里要指出的是，master节点本身也是一个node节点，只是在一般环境中会将其运行容器的功能关闭。但是在我们这个实验集群中，由于只有一个节点，所以这个master节点也必须承担运行容器的责任。

通过执行oc get node命令可以查看系统中的所有节点。

查看集群信息需要集群管理员的权限，请先登录为system:admin。具体方法请查看之前的章节介绍。

可以看到，目前集群中只有一个节点，状态是ready。通过oc describe node master.example.com命令查看节点的详细信息。

从上面的输出可以看到该节点详细的系统信息、节点上运行的容器资源使用情况、网络地址等。

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

通过oc project命令可以查看用户当前所在的project。

通过oc project 可以切换到指定的项目。现在请切换到上一章创建的helloworld-php项目，接下来我们会以这个项目为基础进行讲解。

在openshift上运行的容器会被一种叫pod的对象所“包裹”，用户不会直接看到docker容器本身。从技术上来说，pod其实也是一种特殊的容器。执行oc get pods命令可以看到当前所在项目的pod。

执行oc describe pod命令可以查看容器的详细信息，如pod部署的node节点名、所处的project、ip地址等。

用户可以近似认为实际部署的容器会运行在pod内部。一个pod内部可以运行一个或多个容器，运行在一个pod内的多个容器共享这个pod的网络及存储资源。从这个层面上，可以将pod理解为一个虚拟主机，在这个虚拟主机中，用户可以运行一个或多个容器。虽然一个pod内可以有多个容器，但是在绝大多数情况下，一个pod内部只运行一个容器实例。pod其实也是一个docker容器，通过dockerps命令可以查看pod的实例信息。

因为大多数情况下都是一个容器运行在一个pod内，很多时候可以将pod等同于我们所要运行的容器本身。

上述代码是查找php的容器实例。一共有两个输出，一个是实际的php应用的容器实例，另一个是镜像类型为openshift/origin-pod:v1.3.0的容器，即pod容器实例。

容器像盒子一样为应用提供一个独立的运行环境，但它并不是一个黑盒子。用户可以实时地查看容器的输出，也可以进入容器内部执行操作。

执行oc logs 命令，可以查看pod的输出。

执行ocrsh命令，可以进入容器内部执行命令进行调试。

oc logs及ocrsh是两个非常有用的命令，是排查容器相关问题的重要手段。

容器是一个一个非持久化的对象。所有对容器的更改在容器销毁后默认都会丢失。同一个docker镜像实例化形成容器后，会恢复到这个镜像定义的状态，并且获取一个新的ip地址。容器的这种特性在某些场景下非常难能可贵，但是每个新容器的ip地址都在不断变化，这对应用来说不是一件好事。拿前文部署的php和mysql应用来说，后端mysql容器在重启后ip地址改变了，就意味着必须更新php应用的数据库地址指向。如果不修改应用地址指向，就需要有一种机制使得前端的php应用总是能连接到后端的mysql数据库。

为了克服容器变化引发的连接信息的变化，kubernetes提供了一种叫service（服务）的组件。当部署某个应用时，我们会为该应用创建一个service对象。service对象会与该应用的一个或多个pod关联。同时每个service会被分配到一个ip地址，这个ip地址是相对恒定的。通过访问这个ip地址及相应的端口，请求就会被转发到对应pod的相应端口。这意味着，无论后端的pod实例的数量或地址如何变化，前端的应用只需要访问service的ip地址，就能连接到正确的后端容器实例。service起到了代理的作用，在相互依赖的容器应用之间实现了解耦。

通过oc get svc命令，可以获取当前项目下所有service对象的列表。

通过cakephp的service的ip地址加端口172.30.1.84:8080，可以访问到cake-php的服务。

如果尝试ping一下service的ip地址，结果是不会成功的。因为service的ip地址是虚拟的ip地址，而且这个地址只有集群内的节点和容器可以识别。

除了通过ip地址访问service所指向的服务外，还可以通过域名访问某一个service。监听在master上的集群内置dns服务器会负责解析这个dns请求。service域名的格式是..svc.cluster.local。比如上面例子中的php应用的service域名将会是cakephp-mysql-example.helloworld-ng.svc.cluster.local:8080。可以在master节点上用ping检查域名解析。

如果发现内部域名解析失败，可以在/etc/resolve.conf中添加一条指向本机的域名服务器的记录。

service提供了一个通往后端pod集群的稳定的入口，但是service的ip地址只是集群内部的节点及容器可见。对于外部的应用或者用户来说，这个地址是不可达的。那么外面的用户想要访问service指向的服务应该怎么办呢？openshift提供了router（路由器）来解决这个问题。上一章中介绍了router组件的部署。其实router组件就是一个运行在容器内的haproxy，是一个特殊定制的haproxy。用户可以创建一种叫route的对象，笔者称为路由规则。一个route会与一个service相关联，并且绑定一个域名。route规则会被router加载。当用户通过指定域名访问应用时，域名会被解析并指向router所在的计算节点上。router获取这个请求，然后根据route规则定义转发给与这个域名对应的service后端所关联的pod容器实例。在上一章部署cakephp应用时，我们将route域名修改为php.apps.example.com。当访问域php.apps.example.com时，请求到达router，并由其向后端分发。当pod的数量或者状态变化时，openshift负责更新router内的配置，确保请求总是能被正确路由到对应的pod。

通过命令oc get routes，可以查看项目中的所有route。

经常会有用户混淆了router和service的作用。router负责将集群外的请求转发到集群的容器。service则负责把来自集群内部的请求转发到指定的容器中。一个是对外，一个是对内。

容器默认是非持久化的，所有的修改在容器销毁时都会丢失。但现实是传统的应用大多都是有状态的，因此要求某些容器内的数据必须持久化，容器云平台必须为容器提供持久化储存（persistent storage）。docker本身提供了持久化卷挂载的能力。相对于单机容器的场景，在容器云集群的场景中，持久化的实现有更多细节需要考虑。openshift除了支持docker持久化卷的挂载方式外，还提供了一种持久化供给模型，即persistent volume（持久化卷，pv）及persistent volume claim（持久化卷请求，pvc）模型。在pv和pvc模型中，集群管理员会创建大量不同大小和不同特性的pv。用户在部署应用时，显式声明对持久化的需求，创建pvc。用户在pvc中定义所需存储的大小、访问方式（只读或可读可写；独占或共享）。openshift集群会自动寻找符合要求的pv与pvc自动对接。通过pv和pvc模型，openshift为用户提供了一种灵活的方式来消费存储资源。

openshift对持久化后端的支持比较广泛，除了nfs及iscsi外，还支持如ceph、gluterfs等的分布式储存，以及amazon webservice和google compute engine的云硬盘。关于存储相关的话题，在后续章节会有更详细的探讨。

openshift提供了一个内部的docker镜像仓库（registry），该镜像仓库用于存放用户通过内置的source to image镜像构建流程所产生的镜像。registry组件默认以容器的方式提供，在上一章中，我们手工部署了registry组件。

通过oc get pod -n default命令可以查看registry容器的状态。

通过oc get svc -n default命令可以查看registry容器对应的service信息。

每当s2i完成镜像构建，就会向内部的镜像仓库推送构建完成的镜像。在上面的输出示例中，镜像仓库的访问点为172.30.73.49:5000。如果查看上一章cakephp的s2i构建日志，就会看到最后有成功推送镜像的日志输出：push successful。

一个常见的疑问是“是不是openshift用到的镜像都要存放到内置的仓库？”答案是否定的。内部的镜像仓库存放的只是s2i产生的镜像。其他镜像可以存放在集群外部的镜像仓库，如企业的镜像仓库或社区的镜像仓库。只要保证openshift的节点可以访问到这些镜像所在的镜像仓库即可。

前文多次提及source to image（s2i），因为s2i的确是openshit的一个重要功能。容器镜像是容器云的应用交付格式。容器镜像中包含了应用及其所依赖的运行环境。可以从社区或者第三方厂商获取基础的操作系统或者中间件的镜像。但是这些外部获取的操作系统或中间件的镜像并不包含企业内部开发和定制的应用。企业内部的开发人员必须自行基于外部的基础镜像构建包含企业自身开发的应用。这个镜像的构建过程是必须的，要么由企业的it人员手工完成，要么使用某种工具实现自动化。

作为一个面向应用的平台，openshift提供了s2i的流程，使得企业内容器的构建变得标准化和自动化，从而提高了软件从开发到上线的效率。一个典型的s2i流程包含了以下几个步骤。

1）用户输入源代码仓库的地址。

2）用户选择s2i构建的基础镜像（又称为builder镜像）。builder镜像中包含了操作系统、编程语言、框架等应用所需的软件及配置。openshift默认提供了多种编程语言的builder镜像，如java、php、ruby、python、perl等。用户也可以根据自身需求定制自己的builder镜像，并发布到服务目录中供用户选用。

3）用户或系统触发s2i构建。openshift将实例化s2i构建执行器。

4）s2i构建执行器将从用户指定的代码仓库下载源代码。

5）s2i构建执行器实例化builder镜像。代码将会被注入builder镜像中。

6）builder镜像将根据预定义的逻辑执行源代码的编译、构建并完成部署。

7）s2i构建执行器将完成操作的builder镜像并生成新的docker镜像。

8）s2i构建执行器将新的镜像推送到openshift内部的镜像仓库。

9）s2i构建执行器更新该次构建相关的image stream信息。

s2i构建完成后，根据用户定义的部署逻辑，openshift将把镜像实例化部署到集群中。

除了接受源代码仓库地址作为输入外，s2i还接受dockerf?ile以及二进制文件作为构建的输入。用户甚至可以完全自定义构建逻辑来满足特殊的需求。

openshift提供了不同的工具集为开发和运维的用户提供良好的体验，也为持续集成和打通devops流程提供便利。例如，openshift提供了eclipse插件，开发工程师可以在eclipse中完成应用及服务的创建和部署、远程调试、实时日志查询等功能。