一 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。