一、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 底层的支持
mportant;">OpenShift 底层以 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 安全性
九、为什么要用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集群的状态。它的服务组件如下:
API Server
负责提供集群的Web Console以及RESTful API服务。集群内所有Node节点都会访问API Server更新各节点的状态及其上运行的容器状态。
数据源(Data Store)
集群内所有动态的状态信息都会存储在后端一的一个etcd分布式数据库中。默认的etcd实例安装在Master节点上,如有需要,也可以将etcd节点部署在集群之外。
调度控制器(Scheduler)
负责按照用户输入的要求合适的计算节点。
复制控制器(Replication Controller)
负责监控当前容器实例的数量和用户部署指定的数量是否匹配,保证实际的容器实例数量等于部署定义的数量。
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地址。
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 镜像)。
用户或系统触发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://www.hqyman.cn/post/7625.html 非本站原创文章欢迎转载,原创文章需保留本站地址!
打赏微信支付宝扫一扫,打赏作者吧~
休息一下~~