001.OpenShift介绍

一 OpenShift特性

1.1 OpenShift概述

Red Hat OpenShijft Container Platform (OpenShift)是一个容器应用程序平台，它为开发人员和IT组织提供了一个云应用程序平台，用于在安全的、可伸缩的资源上部署新应用程序，而配置和管理开销最小。

OpenShift构建于Red Hat Enterprise Linux、Docker和Kubernetes之上，为当今的企业级应用程序提供了一个安全且可伸缩的多租户操作系统，同时还提供了集成的应用程序运行时和库。

OpenShift带来了健壮、灵活和可伸缩的特性。容器平台到客户数据中心，使组织能够实现满足安全性、隐私性、遵从性和治理需求的平台。不愿意管理自己的OpenShift集群的客户可以使用Red Hat提供的公共云平台OpenShift Online。

1.2 OpenShift特性

OpenShift容器平台和OpenShift Online都是基于OpenShift Origin开源软件项目的，该项目本身使用了许多其他开源项目，如Docker和Kubernetes。

应用程序作为容器运行，容器是单个操作系统内的隔离分区。容器提供了许多与虚拟机相同的好处，比如安全性、存储和网络隔离，同时需要的硬件资源要少得多，启动和终止也更快。OpenShift使用容器有助于提高平台本身及其承载的应用程序的效率、灵活性和可移植性。

OpenShift的主要特性如下:

• 自助服务平台：OpenShift允许开发人员使用Source-to-Image(S21)从模板或自己的源代码管理存储库创建应用程序。系统管理员可以为用户和项目定义资源配额和限制，以控制系统资源的使用。
• 多语言支持：OpenShift支持Java、Node.js、PHP、Perl以及直接来自Red Hat的Ruby。同时也包括来自合作伙伴和更大的Docker社区的许多其他代码。MySQL、PostgreSQL和MongoDB数据库。Red Hat还支持在OpenShift上本地运行的中间件产品，如Apache httpd、Apache Tomcat、JBoss EAP、ActiveMQ和Fuse。
• 自动化：OpenShift提供应用程序生命周期管理功能，当上游源或容器映像发生更改时，可以自动重新构建和重新部署容器。根据调度和策略扩展或故障转移应用程序。
• 用户界面：OpenShift提供用于部署和监视应用程序的web UI，以及用于远程管理应用程序和资源的CLi。它支持Eclipse IDE和JBoss Developer Studio插件，以便开发人员可以继续使用熟悉的工具，并支持REST APl与第三方或内部工具集成。
• 协作：OpenShift允许在组织内或与更大的社区共享项目。
• 可伸缩性和高可用性：OpenShift提供了容器多租户和一个分布式应用程序平台，其中包括弹性，以处理随需增加的流量。它提供了高可用性，以便应用程序能够在物理机器宕机等事件中存活下来。OpenShift提供了对容器健康状况的自动发现和自动重新部署。
• 容器可移植性：在OpenShift中，应用程序和服务使用标准容器映像进行打包，组合应用程序使用Kubernetes进行管理。这些映像可以部署到基于这些基础技术的其他平台上。
• 开源：没有厂商锁定。
• 安全性：OpenShift使用SELinux提供多层安全性、基于角色的访问控制以及与外部身份验证系统(如LDAP和OAuth)集成的能力。
• 动态存储管理：OpenShift使用Kubernetes持久卷和持久卷声明的方式为容器数据提供静态和动态存储管理
• 基于云(或不基于云)：可以在裸机服务器、活来自多个供应商的hypervisor和大多数IaaS云提供商上部署OpenShift容器平台。
• 企业级：Red Hat支持OpenShift、选定的容器映像和应用程序运行时。可信的第三方容器映像、运行时和应用程序由Red Hat认证。可以在OpenShift提供的高可用性的强化安全环境中运行内部或第三方应用程序。
• 日志聚合和metrics：可以在中心节点收集、聚合和分析部署在OpenShift上的应用程序的日志信息。OpenShift能够实时收集关于应用程序的度量和运行时信息，并帮助不断优化性能。
• 其他特性：OpenShift支持微服务体系结构，OpenShift的本地特性足以支持DevOps流程，很容易与标准和定制的持续集成/持续部署工具集成。

二 OpenShift架构

2.1 OpenShift架构概述

OpenShift容器平台是一组构建在Red Hat Enterprise Linux、Docker和Kubernetes之上的模块化组件和服务。OpenShift增加了远程管理、多租户、增强的安全性、应用程序生命周期管理和面向开发人员的自服务接口。

OpenShift的架构：

• RHEL：基本操作系统是Red Hat Enterprise Linux；
• Docker：提供基本的容器管理API和容器image文件格式；
• Kubernetes：管理运行容器的主机集群(物理或虚拟主机)。它处理描述由多个资源组成的多容器应用程序的资源，以及它们如何互连；
• Etcd：一个分布式键值存储，Kubernetes使用它来存储OpenShift集群中容器和其他资源的配置和状态信息。

OpenShift在Docker + Kubernetes基础设施之上添加了提供容器应用程序平台所需的更富丰的功能：

OpenShift-Kubernetes extensions：其它资源类型存储在Etcd中，由Kubernetes管理。这些额外的资源类型形成OpenShift内部状态和配置，以及由标准 Kubernetes管理的应用程序资源；

Containerized services：完成许多基础设施功能，如网络和授权。其中一些一直运行，另一些则按需启动。OpenShift使用Docker和Kubernetes来实现大多数内部功能。即大多数OpenShift内部服务作为由Kubernetes管理的容器；

Runtimes and xPaaS：供开发人员使用的 base image，每个image都预配置了特定的runtime或db。xPaaS提供了一组用于JBoss中间件产品（如JBoss EAP和ActiveMQ）的 base image；

DevOps tools and user experience：OpenShift提供了Web UI和CLI管理工具，从而实现配置和监视应用程序、OpenShift服务和资源。Web和CLI工具都是由相同的REST api构建的，可供IDE和CI平台等外部工具使用。OpenShift 还可以访问外部SCM存储库和容器registry，并将它们的构件引入OpenShift Cloud。

OpenShift不会向开发人员和系统管理员屏蔽Docker和Kubernetes的核心基础设施。相反，它将它们用于内部服务，并允许将Docker和Kubernetes资源导入OpenShift集群，同时原始Docker和资源可以从OpenShift集群导出，并导入到其他基于docker的基础设施中。

OpenShift添加到Docker + Kubernetes的主要价值是自动化开发工作流，因此应用程序的构建和部署在OpenShift集群中按照标准流程进行。开发者不需要知道底层Docker的细节。OpenShift接受应用程序，打包它，并将其作为容器启动。

2.2 Master和nodes

OpenShift集群是一组节点服务器，它们运行容器，并由一组主服务器集中管理。服务器可以同时充当master和node，但是为了增加稳定性，这些角色通常是分开的。

OpenShift工作原理和交互视图：

master节点运行OpenShift核心服务，如身份验证，并未管理员提供API入口。

nodes节点运行包含应用程序的容器，容器又被分组成pod。

OpenShift master运行Kubernetes master服务和Etcd守护进程；

node运行Kubernetes kubelet和kube-proxy守护进程。

虽然在描述中通常没有声明，但实际上master本身也是node。

scheduler和management/replication是Kubernetes主服务，而Data Store是Etcd守护进程。

Kubernetes的调度单元是pod，它是一组共享虚拟网络设备、内部IP地址、TCP/UDP端口和持久存储的容器。pod可以是任何东西，从完整的企业应用程序(包括作为不同容器的每一层)到单个容器中的单个微服务。例如，一个pod，一个容器在Apache下运行PHP，另一个容器运行MySQL。

Kubernetes管理replicas来缩放pods。副本是一组共享相同定义的pod。

三 管理OpenShift

3.1 OpenShift项目及应用

除了Kubernetes的资源(如pods和services)之外，OpenShift还管理projects和users。一个projects对Kubernetes资源进行分组，以便用户可以使用访问权限。还可以为projects分配配额，从而限制了已定义的pod、volumes、services和其他资源。

OpenShift中没有application的概念，OpenShift client提供了一个new-app命令。此命令在projects中创建资源，但它们都不是应用程序资源。这个命令是为标准开发人员工作流配置带有公共资源的proiect的快捷方式。

OpenShift使用lables(标签)对集群中的资源进行分类。默认情况下，OpenShift使用app标签将相关资源分组到应用程序中。

3.2 使用Source-to-image构建映像

OpenShift允许开发人员使用标准源代码管理仓库(SCM)和集成开发环境(ide)来发布应用。

OpenShift中的source -to-lmage (S2I)流程从SCM仓库中提取代码，自动判断所需的runtime，基于runtime启动一个pod，在pod中编译应用。

当编译成功时，将在runtime image中添加层并形成新的image，推送进入OpenShift internal registry仓库，接着基于这个image将创建新的pod，运行应用程序。

S2I可被视为已经内置到OpenShift中的完整的CI/CD管道。

CI/CD有不同的形式，根据具体场景表现不同。例如，可以使用外部CI工具(如Jenkins)启动构建并运行测试，然后将新构建的映像标记为成功或失败，将其推送到QA或生产。

3.2 管理OpenShift资源

OpenShift资源定义,如image、container、pod、service、builder、template等，都存储在Etcd中，可以由OpenShift CLI, web控制台或REST API进行管理。

OpenShift的资源科通过JSON或YAML文件查看，并且在类似Git或版本控制的SCM中共享。OpenShift甚至可以直接从外部SCM检索这些资源定义。

大多数OpenShift操作不需要实时响应，OpenShift命令和APIs通常创建或修改存储在Etcd中的资源描述。Etcd然后通知OpenShift控制器，OpenShift控制器会就更改警告这些资源。

这些控制器采取行动，以便使得资源的最终态反应达到更改效果。例如，如果创建了一个新的pod资源，Kubernetes将在node上调度并启动该pod，使用pod资源确定要使用哪个映像、要公开哪个端口，等等。或者一个模板被更改，从而指定应该有更多的pod来处理负载，OpenShift会安排额外的pod(副本)来满足更新后的模板定义。

注意：虽然Docker和Kubernetes是OpenShift的底层，但是必须主要使用OpenShift CLi和OpenShift APls来管理应用程序和基础设施。OpenShift增加了额外的安全和自动化功能，当直接使用Docker或Kubernetes命令和APls时，这些功能必须手动配置，或者根本不可用。因此强烈建议不要使用docker或Kubernetes的命令直接管理应用。

四 OpenShift网络

4.1 OpenShift网络概述

Docker网络相对简单，Docker创建一个虚拟内核桥接器（docker0网卡），并将每个容器网络接口连接到它。

Docker本身没有提供允许一个主机上的pod连接到另一个主机上的pod的方法。Docker也没有提供向应用程序分配公共固定IP地址的方法，以便外部用户可以访问它。

但Kubernetes提供service和route资源来管理pods之间的网络，以及从外部到pods的路由流量。service在不同pods之间提供负载均衡用于接收网络请求，同时为service的所有客户机(通常是其他pods)提供一个内部IP地址。

container和pods不需要知道其他pods在哪里，它们只连接到service。route为service提供一个固定的惟一DNS名称，使其对OpenShift集群之外的客户端可见。

Kubernetes service和route资源需要外部（功能）插件支持。service需要软件定义的网络(SDN)，它将在不同主机上的pod之间提供通信，route需要转发或重定向来自外部客户端的包到服务内部IP。

OpenShift提供了一个基于Open vSwitch的SDN，路由由分布式HAProxy farm提供。

五 OpenShift持久性存储

5.1 永久存储

pod可以在一个节点上停止，并随时在另一个节点上重新启动。同时pod的默认存储是临时存储，通过对于类似数据库需要永久保存数据的应用不适合。

Kubernetes为管理容器的外部持久存储提供了一个框架。Kubernetes提供了PersistentVolume资源，它可以在本地或网络中定义存储。pod资源可以使用PersistentVolumeClaim资源来访问对应的持久存储卷。

Kubernetes还指定了一个PersistentVolume资源是否可以在pod之间共享，或者每个pod是否需要具有独占访问权的自己PersistentVolume。当pod移动到另一个节点时，它将保持与相同的PersistentVolumeClaim和PersistentVolumne资源的关联。这意味着pod的持久存储数据跟随它，而不管它将在哪个节点上运行。

OpenShift向Kubernetes提供了多种VolumeProvider，如NFS、iSCSI、FC、Gluster或OpenStack Cinder。

OpenShift还通过StorageClass资源为应用程序提供动态存储。使用动态存储，可以选择不同类型的后端存储。后面存储根据应用程序的需要划分为不同的“tiers”。例如，可以定义一个名为“fast”的存储类和另一个名为“slow”的存储类，前者使用更高速的后端存储，后者提供普通的存储。当请求存储时，最终用户可以指定一个Persistentvolumeclaim，并使用一个注释指定他们所需的StorageClass。

六 OpenShift高可用

6.1 OpenShift高可用概述

OpenShift平台集群的高可用性(HA)有两个不同的方面：

OpenShift基础设施本身的HA(即主机)；

以及在OpenShift集群中运行的应用程序的HA。

默认情况下，OpenShift为master提供了完全支持的本机HA机制。

对于应用程序或“pods”，如果pod因任何原因丢失，Kubernetes将调度另一个副本，将其连接到服务层和持久存储。如果整个节点丢失，Kubernetes会为它所有的pod安排替换节点，最终所有的应用程序都会重新可用。pod中的应用程序负责它们自己的状态，因此它们需要自己维护应用程序状态(如HTTP会话复制或数据库复制)。

七 Image Streams

7.1 Image Streams

要在OpenShift中创建一个新的应用程序，除了应用程序源代码之外，还需要一个base image(S2I builder image)。如果源代码或image任何一个更新，就会生成一个新的image，并且基于此新image创建新的pod，同时替换旧的pod。

即当应用程序代码发生更改时，容器映像需要更新，但如果构建器映像发生更改，则部署的pod也需要更新。

Image Streams包括由tag标识的大量的image。应用程序是针对Image Streams构建的。Image Streams可用于在创建新image时自动执行操作。构建和部署可以监视Image Streams，以便在添加新image时接收通知，并分别执行构建或部署。

OpenShift默认情况下提供了几个Image Streams，包括许多流行的runtime和frameworks。

Image Streams tag是指向Image Streams中的image的别名。通常缩写为istag。它包含一个image历史记录，表示为tag曾经指向的所有images的堆栈。

每当使用特定的istag标记一个新的或现有的image时，它都会被放在历史堆栈的第一个位置(标记为latest)。之前tag再次指向旧的image。同时允许简单的回滚，使标签再次指向旧的image。