参考文章: OpenShift简介_虹科云科技的博客-CSDN博客_openshift架构详解
参考文章：什么是openshift
OpenShift简介_虹科云科技的博客-CSDN博客_openshift架构详解
Openshift是一个开源的容器云平台，底层基于当前容器的事实标准编排系统Kubernetes和docker引擎，企业可以基于此平台搭建内部Paas平台，贯穿CI/CD流程，提高企业IT效率，拥抱DevOps和敏捷开发。
- Kubernetes 是 OpenShift Container Platform 的核心组件。
- 使用 OpenShift Container Platform 开发和运行容器化应用程序。
- OpenShift Container Platform 以 Kubernetes 为基础，为大规模电信、流视频、游戏、银行和其他应用提供引擎技术。
- 使用 OpenShift Container Platform 可以将容器化应用程序扩展至内部和多云环境中的容器化应用程序。
什么是Paas
PaaS（Platform as a Service，平台即服务）最早是在云计算领域被提出。如下图所示，将企业IT服务分为九层，传统自建数据中心九层设施都需要企业自己维护，成本极高。而云计算架构就相当于把九层架构中的底层一部分外包给云计算服务提供商，根据外包的层次不同，分为IaaS(Infrastructure as a Service，基础设施即服务)，PaaS，SaaS（Software as a Service）三层。
- IaaS 层为基础设施运维人员服务、提供计算、存储、网络以及其他硬件资源，云平台使用者可以在上面部署和运行包括操作系统和应用程序在内的任意软件，无需再为基础设施的管理而分心。
- PaaS 层为应用开发人员服务，提供支撑应用运行所需的软件运行时环境，相关的工具与服务，如数据库服务、日志服务、监控服务等，让应用开发者可以专注于交付业务价值的代码而无需关心应用所需的基础环境与工具。
- SaaS 层为一般用户（最终用户）服务，提供了一套完整可用的软件系统，让一般用户无需关心技术细节，只需通过浏览器、应用客户端的方式就能使用部署在云上的应用服务。SaaS 产品比如客户关系管理系统、邮件、虚拟桌面、通信、游戏等。
什么是Kubernetes
Kubernetes是一个开源容器编排引擎，用于自动化容器化应用程序的部署，扩展和管理。 Kubernetes的基本概念包括：
- 一个或多个工作节点（worker node）负责工作负载
- 一个或多个管理节点（master node）负责管理工作负载
- 将容器封装在名为Pod的部署单元，使用Pod为容器提供额外的元数据并且提供在单个部署实体中对多个容器进行分组的功能
- 创建特殊的资源。例如，服务表示一组Pod和访问策略，该访问策略允许容器没有特定的ip地址也能连接服务。复制控制器（Replication controllers）是另一种用于控制同一时间的Pod副本数量的特殊资源，可以使用此功能自动扩展应用程序以适应其当前需求。
什么是OKD
OKD是Kubernetes的发行版，针对持续应用程序开发和多租户部署进行了优化。OKD在Kubernetes之上添加了开发人员和运营工具，以便为小型和大型团队实现快速的应用程序开发，轻松部署和扩展以及长期生命周期维护。
OKD是嵌入了Red Hat OpenShift中的上游Kubernetes发行版，并通过安全性和其他集成概念进行扩展。 OKD在github和文档中也称为Origin。
openshift层次结构
OpenShift v3是一个分层系统，旨在尽可能准确地公开底层Docker格式的容器镜像和Kubernetes概念，重点是帮助开发人员轻松组合应用程序。例如，安装Ruby，推送代码和添加MySQL。
其中，docker提供了打包和创建基于linux的轻量容器镜像的抽象；Kubernetes提供了集群管理以及在多台主机上编排容器的功能。OKD提供了以下功能 ：
- 帮助开发人员管理、构建和部署源代码
- 管理和推广大规模的流进系统的镜像
- 大规模的应用管理
- 组织大型开发人员组织的团队和用户跟踪
- 支持群集的网络基础结构
Openshift 实际上由三部分组成，核心部分实现容器的调度是封装的 Kubernetes， 除此之外还有一个内置的镜像仓库（Image Registry），这个仓库是可选的，Openshift 也可以配置使用 Dockerhub 或者企业自己的镜像仓库，最外层部分是一个友好的 Web 界面，用于展示和操作 Openshift 的资源。
如下图所示，Openshift 要成为一个完整的数字化平台需要依赖于两个外部系统，一个代码库，一个是持续集成服务，事实上这两个外部服务也是可以跑在 Openshift 里面的。右边的灰色矩形就是 Openshift 的主要架构了，它的上层是一个路由（Router），用于 DNS 解析和转发，确保用户能够调用到 Openshift 集群中的服务。中间部分是跑在 RHEL 操作系统上的 Kubernetes 集群，侧面是外部存储服务，因为集群里的计算单元是漂浮的，所以通常 Kubernetes 集群只提供计算能力，数据持久外需要依赖外部的比如说 S3，EBS 等云服务商提供的存储服务。最下层同样也是由云服务商提供的基础设施服务。
Pods
okd引用了kubernetes的pods概念。pods是指在同一台主机上运行的一个或多个容器，它是定义、开发和部署的最小单位。 每个pod都分配有自己的内部IP地址，因此拥有其整个端口空间，pod中的容器可以共享其本地存储和网络。
pod的生命周期可以在容器退出时结束，也可以在容器退出后保留pods以方便访问容器日志。
pod在运行过程中无法被修改，当需要修改时，需要先停止pod再根据修改后的配置文件和镜像重新创建pod。pod退出时不会保留状态，因此一般通过更高级的控制器管理pods而不是用户直接管理。
参考资料
PaaS 平台（一） — Openshift 介绍 | 杜屹东的博客
官网链接:
Red Hat OpenShift makes container orchestration easier
Chapter 1. OpenShift Container Platform architecture OpenShift Container Platform 4.1 | Red Hat Customer Portal
https://docs.okd.io/latest/architecture/index.html
一、OpenShift是什么？
- OpenShift 是红帽 Red Hat 公司基于开源的云平台，是平台即服务（PaaS），是一种容器应用平台。允许开发人员构建、测试和部署云应用。该系统是在 K8S 核心之上添加工具，从而实现更快的应用开发、部署及扩展。
- 在 OpenShift 上可以进行开发、测试、部署、运维全流程，实现高度的自动化，满足企业中的应用持续集成和交付及部署的需求，同时也满足企业对于容器管理（Docker）、容器编排（K8S）的需求。
- Openshift 是首个支持企业级 Java 的 PaaS 平台，支持 JEE6 与 JBoss 和其 Eclipse 集成开发环境以及 Maven 和 Jenkins 自动化。
- OKD是 Kubernetes 的一个发行版，针对持续应用程序开发和多租户部署进行了优化。OKD 还充当上游代码库，红帽 OpenShift Online和红帽 OpenShift 容器平台基于这些代码库构建。
- OCP即Openshift Container Platform
二、Openshift 底层的支持
- OpenShift 是基于主流的容器技术 Docker 和 K8S 构建的开源云平台。
- OpenShift 是 PaaS（平台即服务），
- K8S是 CaaS（容器即服务）。
- OpenShift 内置了Kubernetes。
OpenShift 底层以 Docker 作为容器引擎驱动，以Kubernetes 作为容器编排引擎组件。
- 容器引擎：Docker 提供了稳定、可靠及高效的运行环境。
- 容器编排：Kubernetes 提供了集群管理、高可用、安全、持续集成等容器编排组件，满足容器集群所需的调度、网络、存储、性能及安全等需求。
三、OpenShift版本
主要有三个版本：
- OpenShift Origin : OKD, 这是OpenShift的社区添加或开源版本.它也被称为其他两个版本的上游项目；仅限于维护openshift测试二进制文件。维护hyperkube的责任已转移到openshift/kubernetes仓库。
- OpenShift Online : 它是一个公共PaaS作为在AWS上托管的服务。（目前不再用）
- OpenShift Enterprise : 是具有ISV和供应商许可证的OpenShift的强化版本。
OpenShift Online和OpenShift Enterprise ：
- 红帽OpenShift的开源社区版本称为OKD（The Origin Community Distribution of Kubernetes，或OpenShift Kubernetes Distribution的缩写，原名OpenShift Origin），是 Red Hat OpenShift Container Platform (OCP) 的上游和社区支持版本。
- 红帽OpenShift的企业版本称为OCP（Red Hat OpenShift Container Platform ），OpenShift 的私有云产品，不购买订阅也可以安装使用，只是不提供技术支持。
四、OpenShift功能
- 容器引擎：docker；
- 容器编排：kubernetes；
- 应用开发框架及中间件：Java、Python、Tomcat、MySQL、PHP、Ruby、MongoDB和JBoss等中间件；
- 应用及服务目录：用户可一键部署各类应用及服务；
- 自动化流程及工具：内置自动化流程工具S2I（Source to Image），用户可完成代码编译、构建和镜像发布；
- 软件定义网络：提供 OpenVSwitch，实现跨主机共享网络及多租户隔离网络模式；
- 性能监控及日志管理：内置 Prometheus 监控功能，用户可以通过 Grafana 仪表板上实时显示应用；
- 多用户接口：提供友好的 UI、命令行工具（oc，类似于 K8S 的 kubectl 以及 RESTful API，基本与 K8S 兼容）；
- 自动化集群部署及管理：通过 Ansible 实现集群的自动化部署，为集群的自动化扩容提供接口。
五、OpenShift与K8S的区别
概念：OpenShift 是 PaaS（平台即服务），K8S 是 CaaS（容器即服务），OpenShift 内置了Kubernetes。OpenShift 底层以 Docker 作为容器引擎驱动，以 Kubernetes 作为容器编排引擎组件。
部署：OpenShift 可以安装在 RHEL（Red Hat Enterprise Linux）和 RHELAH（Red Hat Eneterprise Linux Atomic Host）、CentOS 和 Fedora上；K8S 最好在 Unbuntu、Fedora 和 Debian上运行，可部署在任何主要的 IaaS 上，如 IBM、AWS、Azure、GCP 和阿里云等云平台上。
Web Ul：OpenShift 的 Web UI 有一个登录页面，这个 UI 不可以管理集群，但是可以可视化服务器、项目和集群角色；K8S 的可视化界面需要单独安装，需要通过 kube proxy 访问，将本地机器的端口转发到集群的管理服务器，没有登录页面，需要手动创建承载令牌从而提供身份验证和授权。
网络：OpenShift 提供了开箱即用的本机网络解决方案，即 OpenvSwitch，它提供三种不同的插件；K8S 没有本机网络解决方案，但提供可供第三方网络插件使用的接口
六、OpenShift 与K8S的相同点
OpenShift 集成了原生的 K8S 作为容器编排组件，提供容器集群的管理，为业务应用可以提供：
- 容器调度：根据业务的要求，快速部署容器到达指定的目标转态；
- 弹性伸缩：应用可以快速的扩缩容pod的实例数量；
- 异常修复：在容器实例发生异常时，集群可以自动发现问题、处理并恢复应用服务的状态；
- 持久化卷：为集群中的不同机器上的容器提供持久化卷的对接功能；
- 服务发现：可以提供负载均衡及服务发现功能；
- 配置管理：为业务应用提供灵活的配置管理和分发规则。
七、OpenShift v4 的新特性
7.1 集群安装改动
OpenShift 4 提供了一个安装程序配置的基础设施，允许安装程序控制 AWS 安装过程的所有区域。此功能可在几分钟内从头开始配置集群。
用户配置的环境使管理员能够通过填写清单文件简单地在任何平台上进行部署。它还为安装程序提供用户配置环境中所有主机的所有连接凭据。
7.2 操作系统内核改变
在 OpenShift v3.x 中，使用了 Red Hat Atomic OS，它本质上是一个不可变的 Red Hat 安装，安装了最少的工具，为基于容器的工作负载提供了一个理想的平台。但仍然需要单独修补和管理到集群。在 v4 中，选择的操作系统将是 Red Hat CoreOS，它与 Atomic 有许多相似之处，因为它是不可变的并且面向容器，但是它与集群紧密耦合，并且主机操作系统的所有配置都通过集群进行管理，包括版本它运行的 RHCOS。这消除了单独管理底层主机的开销，并使集群管理员能够在需要时使用集群中称为 MachineConfigs 的资源类型配置主机操作系统。
7.3 增加了Kubernetes Operators
Operators 指的是部署、打包和管理 Kubernetes 应用程序的方法。操作符是 OpenShift 4 的新功能之一，有助于管理 Kubernetes 上的应用程序。通过允许代码直接与 Kubernetes 系统接口，它有助于更动态、更高效地执行工作。
7.4 Web 界面变化
新的 Web 界面，它分为两个部分：开发人员和管理员。集群配置现在都保存在集群中并由集群管理员管理。
八、OpenShift与K8S管理与配置差异
8.1 应用部署
K8S的应用程序部署过程较为灵活，用户有很多需要选择的地方；openshift提供的自动化流程多一些，为其提供了DevOps和管道方法，用户只需要创建一个应用程序和一个项目。
8.2 应用管理
对于大多数运营团队来说，K8S默认的仪表盘界面无法满足他们的需求，也许他们会使用ELK堆栈之类的；OpenShift的web控制台建立在Kubernetes API基础上，并具有许多不同的功能。让SRE和运营团队管理其工作负载。如果想使用istio等功能，可以采用多种方式集成。再利用一些自动安装程序和Ansible playbook，管理应用程序会简单一些。
8.3 节点配置
Kubernetes将VM加入集群的方式会比较耗时，并且需要开发脚本，OpenShift有Ansible playbook和安装程序，将新的虚拟机引入集群。
8.4 安全性
- Kubernetes通过企业客户合作，从头开始创建最佳安全实践，能够解决客户的一些问题，才能安全使用，K8S对于团队成员的权限管理不是那么方便。
- 而对于OpenShift，只需要添加用户就可以处理类似命名空间的隔离空间，根据最佳做法创建不同的安全策略，并且某些容器的运行需要root用户权限才可以。
九、为什么要用OpenShift？
- 通过 Openshift这个平台，企业可以快速在内部网络中构建出一个多租户的云平台，
- Openshift云平台集成开发、测试、部署、运维等流程服务，实现高度的自动化，满足应用持续集成及持续交付和部署的需求；
- 通过 Openshift的灵活架构，企业可以以 Openshift作为核心，在其上搭建一个企业的 Devops引擎，推动企业的 Devops变革和转型，满足企业及组织对容器管理、容器编排的需求。
- 测试和部署自动化，开发人员只需关注开发即可。
- OpenShift提供Web控制台和CIL，以及各种不同类型的源代码的模板。
- OpenShift提供Jenkins和管道功能，创建镜像，并推送到Registry，再利用Image Stream部署镜像到集群中。
十、 OpenShift架构概览
从技术堆栈的角度分析，作为一个容器云， Openshift自底而上包含了以下几个层次基础架构层、容器引擎层、容器编排层、PaaS服务层、界面及工具层，如下图所示。
10.1 基础架构层
基础架构层为 Openshift平台的运行提供了基础的运行环境。 OpenShift支持运行在物理机、虚拟机、基础架构云(如 OpenStack、 Amazon Web Service、 Microsoft Azure等)或混合云上。在操作系统层面， Openshift支持多种不同的 Linux操作系统，如企业级的RedHat Enterprise Linux、社区的 Centos。
10.2 容器引擎层
目前以Docker（原生）作为容器引擎。
10.3 容器编排层
目前以Kubernetes作为容器编排引擎。
10.4 PaaS服务层
OpenShift在PaaS服务层默认提供了丰富的开发语言、开发框架、数据库以及中间件的支持。用户可以在OpenShift平台上快速部署和获取一个数据库、分布式缓存或者业务规则引擎的服务。
10.5 界面及工具层
- OpenShift提供了自动化流程Source to Image，即S2I，帮助用户容器化用各种编程语言开发的应用源代码。用户可以直接使用S2I或者把现有的流程与S2I整合，从而实现开发流程的持绫集成和持续交付。提升开发、测试和部署的自动化程度，最终提高开发、测试及部署的效率，缩短上市时间。 Openshift提供了多种用户的接入渠道：Web控制台、命令行、IDE集成及 RESTFUL编程接口。这些都是一个完善的企业级平台必不可少的组件。
- 针对容器应用的运维及集群的运维， Openshift提供了性能度量采集、日志聚合模块及运维管理套件，帮助运维用户完成日常的应用及集群运维任务。
十一、核心组件详解
OpenShift的核心组件及其之间的关联关系如图所示。Openshift集群可以由一台或多台主机组成。这些主机可以是物理机或虚拟机，同时可以运行在私有云、公有云，或混合云上。在OpenShift的集群成员有两种角色：Master节点和Node节点。
11.1 Master
主控节点。集群内的管理组件均匀性在Master节点上，它主要负责管理和维护OpenShift集群的状态。它的服务组件如下：
负责提供集群的Web Console以及RESTful API服务。集群内所有Node节点都会访问API Server更新各节点的状态及其上运行的容器状态。
集群内所有动态的状态信息都会存储在后端一的一个etcd分布式数据库中。默认的etcd实例安装在Master节点上，如有需要，也可以将etcd节点部署在集群之外。
调度控制器（Scheduler）
负责按照用户输入的要求合适的计算节点。
负责监控当前容器实例的数量和用户部署指定的数量是否匹配，保证实际的容器实例数量等于部署定义的数量。
11.2 Node节点
计算节点，集群内的容器实例均运行在Node节点之上。负责接受Master结点的指令，运行和维护Docker容器。
11.3 Project和Namespace
在同一个命名空间中，某一个对象的名称在其分类中必须是唯一的，但是分布在不同命名空间中的对象则可以同名。每一个Project会和一个Namespace相关联，也可以简单理解为Project就是Namespace，所以在OpenShift中进行操作时，要确认当前执行的上下文是哪一个Project。
查看当前用户所在的Project
- [lab-user@bastion ~]$ oc project
- Using project “myproject” on server “https://api.cluster-v47h4.dynamic.opentlc.com:6443”.
11.4 Pod
Pod相当于豌豆的豆荚，容器相当于豌豆。和K8S中的概念相同。
11.5 Service
为了克服容器变化引发的连接信息变化，K8S提供了Service。当部署某个应用时，我们会为该应用创建一个Service对象。它会与该应用的一个或多个Pod相关联，它会被分配一个相对恒定的IP地址。
- 通过访问这个IP地址以及对应的端口，请求就会被转发到Pod对应的端口上。Service起到了代理作用。
- 可以通过域名访问某一个Service。监听在Master上的集群内置DNS服务器会负责解析这个DSN请求。
- Service域名的格式为：..svc.cluster.local.
11.6 Router与Route
Router（路由器）：一个运行在容器内特殊定制的Haproxy。用户可以创建一个Route，一个Route会与一个Service相关联，并且绑定一个域名。Route规则会被Router加载。当用户通过指定域名访问应用时，域名会被解析并指向Router所在的计算节点上。Router 取这个请求，然后根据 Route 规则定义转发给与这个域名对应的 Service 后端所关联的 Pod 容器实例。
Router与Service的区别：
Router是将集群外的请求转发到集群的容器；Service是把集群内的请求转发到指定的容器中。
11.7 Persistent Storage
容器默认非持久化，容器云平台必须为容器提供持久化存储（Persistent Storage）。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 云硬盘等。
11.8 Registry
OpenShift提供了一个内部的 Docker 镜像仓库（ Registry ），该镜像仓库用于存放用户通过内置的Source to Image 镜像构建流程所产生的镜像Registry组件默认以容器的方式提供。
每当S2I 完成镜像构建，就会向内部的镜像仓库推送构建完成的镜像 。
是不是 OpenShift用 到的镜像都要存放到内置的仓库？
不是的，内部的镜像仓库存放的只是S2I 产生的镜像。其他镜像可以存放在集群外部 的镜像仓库，如企业的镜像仓库或社区的镜像仓库。只要保证 OpenShift的节点可以 访问到这些镜像所在的镜像仓库即可。
11.9 Source to Image
S2I即Source to Image， 是OpenShift的一个重要功能。容器镜像是容器云的应用交付格式。容器镜像中包含了应用及其所依赖的运行环境。可以从社区或者第三方厂商获取基础的操作系统或者中间件的镜像。但是这些外部获取的操作系统或中间件的镜像并不包含企业内部开发制的应用。企业内部的开发人员必须自行基于外部的基础镜像构建包含企业自身开发的应用。这个镜像的构建过程是必须的，要么由企业的 IT人员手工完成，要么使用某种工具实现自动化。
作为一个面向应用的平台， OpenShift 提供了S2I 的流程，使得企业内容器的构建变得标准化和自动化，从而提高了软件从开发到上线的效率。一个典型的S2I 流程包含了以下几个 步骤。
- 用户输入源代码仓库的地址。
- 用户选择S2I 构建的基础镜像（又称为 Builder 镜像）。
- Builder镜像中包含了操作系统、编程语言、框架等应用所需的软件及配置 。OpenShift默认提供了多种编程语言的Builder镜像，如Java、PHP、Ruby、Python Perl 等。用户也可以根据自身需求定制自己的Builder镜像，并发布到服务目录中供用户选用。
- 用户或系统触发S2I构建。OpenShift将实例化S2I构建执行器。
- S2I 构建执行器将从用户指定的代码仓库下载源代码。
- S2I 构建执行器实例化Builder镜像。代码将会被注入Builder镜像中 。
- Builder 镜像将根据预定义的逻辑执行源代码的编译、构建并完成部署 。
- S2I构建执行器将完成操作的Builder镜像并生成新的Docker镜像 。
- S2I构建执行器将新的镜像推送到OpenShift内部的镜像仓库 。
- S2I构建执行器更新该次构建相关的Image Stream信息 。
S2I构建完成后，根据用户定义的部署逻辑，OpenShift将把镜像实例化部署到集群中 。
除了接受源代码仓库地址作为输入外，S2I还接受Dockerfile以及二进制文件作为构建 的输入。 用户甚至可以完全自定义构建逻辑来满足特殊的需求。
11.10 开发及管理工具集
OpenShift位提供了不同的工具集为开发和运维的用户提供良好的体验，也为持续集成和打通DevOps流程提供便利。例如，OpenShift提供了 Eclipse插件，开发程师可以在Eclipse中完成应用及服务的创建和部署、远程调试、实时日志查询等功能。
原创文章，作者：奋斗，如若转载，请注明出处：https://blog.ytso.com/309336.html