Openshift入门：核心流程及服务部署/发现/发布/治理详解

╰+攻爆jí腚メ 2023-05-29 03:55 8阅读 0赞

>        OpenShift 容器云提供了众多基础设施和工具，承载了众多功能和特性，帮助用户通过这个平台提升企业 IT 的效率和敏捷度。 纵观 OpenShift 容器云项目，其中最重要的核心流程是将应用从静态的源代码变成动态的应用服务的过程 。

![Openshift 核心组建及流程][Openshift]

### 1、应用构建 ###

第 1 步，部署应用。流程的开始是用户通过 OpenShift 的 Web 控制台或命令行 oc new- app 创建应用。根据用户提供的源代码仓库地址及 Builder 镜像，平台将生成构建配置(BuildConfig)、部署配置(DeploymentConfig)、 Service 及 Route 等对象。

第 2 步，触发构建。应用相关的对象创建完毕后平台将触发一次 S2I 构建。

第 3 步，实例化构建。平台依据应用的 Build Config 实例化一次构建，生成一个 Build 对象。 Build对象生成后，平台将执行具体的构建操作，包括下载源代码、实例化Builder镜像、 执行编译和构建脚本等。

第 4 步，生成镜像。构建成功后将生成一个可供部署的应用容器镜像。平台将把此镜像推送到内部的镜像仓库组件 Registry 中 。

第 5 步，更新 Image Stream。 镜像推送至内部的仓库后，平台将创建或更新应用的 Image Stream 的镜像信息，使之指向最新的镜像 。

### 2、应用部署 ###

第 6 步，触发镜像部署。当 Image Stream 的镜像信息更新后，将触发平台部署 S2I 构建生成的镜像 。

第 7 步，实例化镜像部署。 Deployment Config 对象记录了部署的定义，平台将依据此配置实例化一次部署，生成一个 Deploy 对象跟踪当次部署的状态 。

第 8步，生成 Replication Controller。平台部署将实例化一个 Replication Controller, 用以调度应用容器的部署。

第 9步，部署容器。通过 Replication Controller, OpenShift 将 Pod 及应用容器部署到集群的计算节点中。

### 3、请求处理 ###

第 10 步，用户访问。 用户通过浏览器访问 Route 对象中定义的应用域名 。

第 11 步，请求处理并返回。 请求到 Router 组件后，Router 根据 Route 定义的规则，找到请求所含域名相关联的 Service 的容器，并将请求转发给容器实例。容器实例除了请求后返回数据，还会通过 Router 将数据返回给调用的客户端。

### 4、应用更新 ###

在应用更新时，平台将重复上述流程的第 1 步至第 9 步 。 平台将用下载更新后的代码构建应用，生成新的镜像，并将镜像部署至集群中。值得注意的是，OpenShift 支持滚动更新。在第 9步时，平台将通过滚动更新的方式，保证应用在新老实例交替时服务不间断。

# Learn More #

### 1、服务部署 ###

**1.1 单个微服务的部署：**通过deployment config定义部署容器的行为特性。

**    1.2 多个微服务的部署：**通过template为不同的微服务定义各自的Deployment Config、 Service 及Route等资源对象。（通过 oc export 命令，可以导出 OpenShift中指定的对象 。 加上 --as-template 参数使导出的内容以模板的形式展现）

### 2、服务发现 ###

当容器启动时，Openshift会根据当前项目的Service信息自动生成一些环境变量，比如Service\_Host和Service\_Port，并注入到容器内部。所以我们在容器内部可以直接根据这些环境变量进行服务发现。

使用命令：oc rsh <pod-name> 进入到容器内部。然后使用命令：env | grep SERVICE 来查看跟Service有关的环境变量。

**服务目录与链接**：在 OpenShift 的项目路线图中，将会实现 Service Catalog (服务目录) 和 Service Linking (服务链接)功能，进一步加强集群内 Service 的发现和调用。简单来说，通过 Service Catalog 实现全局的服务目录，可以在这个全局的目录发布服务和选取服务。通过 Service Linking功能，可以将需要的服务和容器应用对接 。

### 3、健康检查 ###

因为每个微服务必须为它自身的状态负责，所以每个微服务都应提供一个健康检查的接口。 通过调用这个健康检查接口，外界可以判断这个服务当前的状态。一般情况下，并不是容器启动后容器中的应用就马上就绪了，应用一般还有一个启动或初始化的过程。因此，必须有一种手段让平台检查微服务应用的就绪状态 。

*  Readiness Probe：检查应用是否已经就绪。OpenShift通过检查 Readiness Probe 接口，只有在确认服务就绪后，才会将外界的流量转发至服务。
 *  Liveness Probe：检查容器是否在正常运行。如果一个服务的 Liveness Probe 探测结果返回失败，平台就会判定这个容器实例出现了问题，相应的容器会被停止 。

健康检查类型：

*  HTTP Get请求：通过调用用户指定的URL判别容器应用的状态。如果返回200或399，则表示成功，否则认为失败。
 *  执行容器命令：用户可以通过执行容器中的某个命令来确认容器的状态。如果程序的返回值为0则表示成功，否则为失败。
 *  TCP socket：TCP socket检查访问容器的某一个TCP端口，如果成功建立连接则认为检查成功。

### 4、更新发布 ###

如上一篇文章所诉，deploy类型有两种：rolling update和recreate。[Openshift入门：基本概念解析][Openshift 1]

**发布回滚：**通过oc rollback 命令进行发布回滚

**灰度发布/蓝绿发布/AB测试：**根据容器/Router的label和标签选择器实现。

### 5、服务治理 ###

大家对微服务的一个很大的关注点在于微服务的治理。 用户希望能够清晰地掌握微服务的性能、调用分析及依赖关系等数据。这些数据的获取一般有两种方式:

*  通过设置API网关（API gateway）进行微服务访问的转发，实现对调用的度量统计、流量控制和安全管控。
 *  借助微服务框架，在应用服务的代码或运行环境中加入探针，进行度量收集和行为控制。

[Openshift]: https://img-blog.csdnimg.cn/20191104094159775.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3NzcxNDc1,size_16,color_FFFFFF,t_70
[Openshift 1]: https://blog.csdn.net/qq_37771475/article/details/102851578