OpenShift总体架构设计 介绍

熄灯勿语
474 阅读11分钟

持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第16天

OpenShift是由RedHat公司推出的企业级容器云PaaS平台，2015年，RedHat推出完全重构后基于Docker和Kubernetes的OpenShift 3.0，完善了强大的用户界面，以及诸如源代码到镜像和构建管道等OpenShift独有组件，极大简化了云原生应用的构建部署和DevOps理念文化的落地实践。2019年，RedHat推出了OpenShift v4，集成了CoreOS、Istio、Knative、Kubernetes Operator等技术，将OpenShift推向了全栈融合云和应用全生命周期自动化管理时代。可见，作为当今最为成熟和主流的容器云PaaS平台，OpenShift的架构也一直在演进。本文将基于OpenShift当前最为成熟稳定的3.11版本，介绍其设计理念和总体架构，并深入介绍和分析OpenShift网络、存储、权限控制、服务目录等核心功能，在部署实践OpenShift云原生PaaS平台前，为读者建立起完备扎实的理论基础。

OpenShift设计哲学

容器平台（Container Platform）是一种使用容器去构建、部署和编排应用的应用平台。OpenShift是一种新型容器云PaaS平台，其使用两种主要工具在容器中运行应用，即以Docker作为容器运行时（Container runtime）在Linux环境中创建容器，以Kubernetes为容器编排引擎（Container Orchestration Engine）在平台中编排容器。OpenShift在架构上具有以分层、应用为中心和功能模块解耦等主要特点。

OpenShift设计哲学

容器平台（Container Platform）是一种使用容器去构建、部署和编排应用的应用平台。OpenShift是一种新型容器云PaaS平台，其使用两种主要工具在容器中运行应用，即以Docker作为容器运行时（Container runtime）在Linux环境中创建容器，以Kubernetes为容器编排引擎（Container Orchestration Engine）在平台中编排容器。OpenShift在架构上具有以分层、应用为中心和功能模块解耦等主要特点。

分层架构

OpenShift采用分层架构，利用Docker、Kubernetes及其他开源技术构建起一个PaaS云计算平台。其中，Docker用于基于Linux的轻量容器镜像的打包和创建，Kubernetes 提供了集群管理和在多台宿主机上的容器编排能力。

图片

从技术堆栈的角度分析，OpenShift自下而上包含了以下几个层次：

  • 基础架构层：提供计算、网络、存储、安全等基础设施，支持在物理机、虚拟化、私有云和公有云等环境上部署OpenShift。

  • 容器引擎层：采用Docker镜像为应用打包方式，采用Docker作为容器运行时，负责容器的创建和管理。Docker利用各种Linux内核资源，为每个Docker容器中的应用提供一个隔离的运行环境。

  • 容器编排和集群管理层：为部署高可用、可扩展的应用，容器云平台需要具有跨多台服务器部署应用容器的能力。OpenShift采用Kubernetes作为其容器编排引擎，同时负责管理集群。事实上，Kuberbnetes正是OpenShift的内核。

  • PaaS服务层：OpenShift在PaaS服务层提供了丰富的开发语言、开发框架、数据库、中间件及应用支持，支持构建自动化（Build Automation）、部署自动化（Deployment Automation）、应用生命周期管理（Application Lifecycle Management，CI/CD）、服务目录（Service Catalog，包括各种语言运行时、中间件、数据库等）、内置镜像仓库等，以构建一个以应用为中心的、更加高效的容器平台。

  • 界面及工具层：向用户提供Web Console、API及命令行工具等，以便于用户使用OpenShift容器云平台。

以应用为中心

下图显示了OpenShift和Kubernetes的主要功能差异。

图片

OpenShift与Kubernetes组件对比

从图中可以看出，相对于Kubernetes，OpenShift新增的全部内容几乎都是以应用为中心来展开的，这些新增功能模块说明如下：

  • Souce to Image（S2I，源代码到镜像）：OpenShift新增的一种构建方式，直接从项目源代码和基础镜像自动构建出应用镜像。

  • 内置镜像仓库：用于保存S2I生成的镜像。

  • 构建配置（BuildConfig）：构建的静态定义，定义构建的源代码来源、基础镜像、生产镜像等。每次执行即开始一次构建过程。

  • 镜像流（ImageStream）：镜像流中包括一个或多个标签，每个标签指向一个镜像。镜像流可用于自动执行某些操作，比如将设定DeploymentConfig的触发器为某镜像流标签，当该标签所指镜像发生变化时，即可自动触发一次部署过程。

  • 部署配置（DeploymentConfig）：部署的静态定义，除了定义待部署的Pod外，还定义了自动触发部署的触发器、更新部署的策略等。

  • 路由规则（Route）：将部署好的应用服务通过域名发布到集群外供用户访问。

基于上述新增功能，OpenShift支持如图所示的应用从构建到发布的全自动化的过程。

图片

OpenShift 中的应用生命周期

下面介绍在OpenShift平台上创建应用的简要步骤。

1、创建应用。用户通过OpenShift的Web控制台或命令行oc new-app创建应用，根据用户提供的源代码仓库地址及Builder镜像，平台将生成构建配置、部署配置、镜像流和服务（Service）等对象。下面是通过命令行进行应用创建的过程：

[root@master1 ~]# oc new-app \
openshift/wildfly:13.0~https://github.com/sammyliush/myapp-demo \
--name mywebapp4
--> Found image af69006 (4 months old) in image stream "openshift/wildfly"
under tag "13.0" for "openshift/wildfly:13.0" 
* A source build using source code from https://github.com/sammyliush/myapp-demo will be created  
* The resulting image will be pushed to image stream tag"mywebapp4:latest"  * Use \'start-build\' to trigger a new build  
* This image will be deployed in deployment config "mywebapp4"  
* Port 8080/tcp will be load balanced by service "mywebapp4"  
* Other containers can access this service through the hostname"mywebapp4"
--> Creating resources ...  
imagestream.image.openshift.io "mywebapp4" created  
buildconfig.build.openshift.io "mywebapp4" created  
deploymentconfig.apps.openshift.io "mywebapp4" created  
service "mywebapp4" created
--> Success  Build scheduled, use \'oc logs -f bc/mywebapp4\' to track its progress.  
Application is not exposed. You can expose services to the outsideworld by executing one or more of the commands below:    
\'oc expose svc/mywebapp4\'   
Run \'oc status\' to view your app.

2、触发构建。平台实例化BuildConfig的一次构建，生成一个Build对象。Build对象生成后，平台将执行具体的S2I构建操作，包括下载源代码、实例化Builder镜像、执行编译和构建脚本等。

3、生成镜像。构建成功后将生成一个可部署的应用容器镜像，平台将把此镜像推送到内部的镜像仓库中。

4、更新镜像流。镜像推送至内部的镜像仓库后，平台将更新应用的ImageStream中的镜像流标签，使之指向最新的镜像。

5、触发部署。当ImageStream的镜像信息更新后，将触发DeploymentConfig对象进行一次部署操作，生成一个ReplicationController对象来控制和跟踪所需部署的Pod的状态。

6、部署容器。部署操作生成的ReplicationController对象会负责调度应用容器的部署，将Pod及应用容器部署到集群的计算节点中。

7、发布应用。运行oc expose svc/mywebapp4命令，生成用户通过浏览器可访问的应用域名。之后用户即可通过该域名访问应用。

8、应用更新。当更新应用时，平台将重复上述步骤。平台将用下载更新后的代码构建应用，生成新的镜像，并将镜像部署至集群中。OpenShit支持滚动更新，以保证在进行新旧实例交替时应用服务不会间断。

解耦式高扩展架构

一方面，OpenShift利用API Server（API服务器）和各种Controller（控制器）实现了控制层面的解耦。API Server充当了消息总线角色，提供REST API，这是客户端对各资源类型（Resource Type）的对象进行操作的唯一入口。它的REST API支持对各类资源进行增删改查监控等操作，提供认证、授权、访问控制、API注册和发现等机制，并将资源对象的Spec（定义）和状态（State）等元数据保存到etcd中。各控制器使用Watch（监视）机制通过API Server来感知自己所监视的资源对象的状态变化，并在变化发生时进行相应处理，处理完成后会更新被处理对象的状态，必要时还会调用API来写入新资源的Spec。下图展示了OpenShift控制平面中的各组件。

图片

以创建一个Pod为例，图所示为该创建过程。

图片

创建Pod过程中OpenShift各组件之间的协作

  1. 客户端使用HTTP/HTTPS通过API向OpenShift API Server 发送（POST）YAML格式的Pod Spec。

  2. API Server在etcd中创建Pod对象并将Spec保存到其中。然后，API Server向客户端返回创建结果。

  3. Scheduler监控到这个Pod对象的创建事件，它根据调度算法决定把这个Pod绑定到节点1，然后调用API在etcd中写入该Pod对象与节点1的绑定关系。

  4. 节点1上的kubelet监控到有一个Pod被分配到它所在的节点上，于是调用Docker创建并运行一个Pod实例，然后调用API更新etcd中Pod对象的状态。

可见，OpenShift API Server实现了简单可靠的消息总线的功能，利用基于消息的事件链，解耦了各组件之间的耦合关系，配合Kubernetes基于声明式的对象管理方式又确保了功能的稳定性。这个层面的架构解耦使得OpenShfit具有良好的规模扩展性。

另外，OpenShift采用各种插件来实现资源层面的解耦。图2-6中展示了OpenShift所利用的各种资源。它采用身份认证程序（Identity Provider）来对接各种身份提供程序，完成身份保存和验证；通过CRI（Container Runtime Interface，容器运行时接口）实现kubelet与容器运行时的解耦，支持Docker和CRI-O等容器运行时；通过Docker Registry API，OpenShift能与各种镜像仓库对接，实现镜像的上传、保存和拉取；通过CNI（Container Network Interface）实现网络层面的解耦，支持多种网络插件实现Pod网络；通过存储插件实现存储层面的解耦，支持多种物理存储后端，为容器提供各种持久存储；通过OSB API（Open Service Broker API，开放服务中介API）实现服务目录层面的解耦，支持各种不同的服务中介，来为容器云平台用户提供丰富的服务。这个层面的架构解耦使得OpenShfit具有良好的功能扩展性。

图片

OpenShift核心组件

图片

OpenShift容器PaaS云平台的架构

Master节点

Master节点是OpenShift容器云平台的主控节点，由一台或多台主机组成，运行控制平面所有组件，比如API服务器（API Server）、各种控制器服务器（Controller Server）、etcd和Web Console等。Master节点负责管理集群状态以及集群内的所有节点，并将待创建的pod调度到合适的节点上。

Node节点

Node节点是OpenShift容器云平台的计算节点，受Master节点管理，负责运行应用容器。OpenShift支持在物理机环境、虚拟机环境和云环境中创建Node节点。

容器仓库（Container Registry）

OpenShift容器云平台支持实现Docker Registry API的多种镜像仓库，包括Docker Hub、利用第三方软件比如VMware Harbor搭建的私有镜像仓库，还提供了名为OpenShift Container Registry（OCR）的内置容器镜像仓库。OCR用于存放用户通过内置的S2I镜像构建流程所产生的Docker镜像。每当S2I完成镜像构建后，它就会向内置镜像仓库推送构建好的镜像。

路由层（Routing Layer）

为了让用户从OpenShift集群外访问部署在集群内的应用，OpenShift提供了内置的路由层。路由层是一个软件负载均衡器，包括一个路由器（Router）组件，用户可以为应用的服务定义路由规则（Route），每条路由规则将应用暴露为一个域名。访问这个域名时，路由器会将访问请求转发给服务的后端Pod。

服务层（Service Layer）

在OpenShift中，容器运行在Pod中，每个Pod都会被分配一个IP地址。当应用具有多个Pod时，在集群内部访问这些Pod是通过Service组件来实现的。Service是一个代理，也是一个内部负载均衡，它连接多个后端Pod，并将访问它的请求转发至这些Pod。

Web Console和CLI

Web Console 是从Web浏览器上访问的OpenShift容器云平台的用户界面。Web Console服务以Pod的形式运行在Master节点之上。OpenShift 还提供了命令行工具oc。用户可以从Web Console上直接下载该工具。

图片

avatar
文章
阅读
粉丝