相比于K8S，OpenShift在帮助客户构建PaaS平台的优势在哪？

优势其他专家已经说得很清楚了。这里我补充一下OpenShift对K8S的扩展，以方便理解。

2.1.1 OpenShift 对 Kubernetes 的增强

早期的 Kubernetes 功能尚弱，红帽的 OpenShift 补充了大量的企业级功能，并逐渐将这些功能贡献给上游 Kubernetes 社区，此时， Kubernetes 和 OpenShift 共同成长。随着纳入了 CoreOS 优秀基因的 OpenShift 的发布，其功能特性和健壮性大胜往昔，并进一步推动 Kubernetes 社区的发展。所以说， OpenShift 和 Kubernetes 是相互推动、相互促进的。接下来，我们具体看一下 OpenShift 对 Kubernetes 的一些关键性增强。

1. 稳定性的提升 **

Kubernetes 是一个开源项目，面向容器调度； OpenShift 是企业级软件，面向于企业 PaaS 平台。 OpenShift 除了包含 Kubernetes ，还包含很多其他企业级组件，如认证集成、日志监控等。

OpenShift 提供企业版和社区版，红帽订阅客户可以使用企业版并获得 OpenShift 企业级支持。 Kubernetes 有很多发行版，但由于它是一个开源项目，如果遇到技术问题，主要依靠社区或外部专家来解决。

Kubernetes 每年发布 4 个版本， OpenShift 通常使用次新版本的 Kubernetes 为最新版本产品的组件，这样保证客户企业级 PaaS 产品的稳定性。

2. OpenShift 实现了一个集群承载多租户和多应用

企业客户通常需要 PaaS 集群具备租户隔离能力，以支持多应用和多租户。多租户是 Kubernetes 社区中一个备受争议的话题，也是当时 Kubernetes 早期版本所欠缺的。

为解决这个问题，红帽在许多关键领域投入了大量资源。红帽推动了 Kubernetes Namespaces 和资源限制 Quota 的开发，以便多个租户可以共享一个 Kubernetes 集群，并可以做资源限制。红帽推动了基于 Kubernetes 角色的访问控制（ RBAC ）的开发，以便可以为用户分配具有不同权限级别的角色。 2015 年发布的 OpenShift 3.0( 基于 Kubernetes 1.0) 就已经提供了 RBAC 的功能；而 Kubernetes 直到 1.6 版本，才正式提供 RBAC 功能。当年没有 RBAC 、 Namespaces 、 Qouta 这些功能的 Kubernetes 是无法满足企业客户的需求的。

3. OpenShift 实现了应用程序的简单和安全部署

Kubernetes 为应用程序提供了诸如 Pod ， Service 和 Controller 等功能组件，但在 Kubernetes 1.0 中部署应用程序并实现应用程序版本管理并不是一件简单的事情。红帽在 OpenShift 3.0 （基于 Kubernetes 1.0 ）中开发了 DeploymentConfig ，以提供参数化部署输入、执行滚动部署、启用回滚到先前部署状态，以及通过触发器驱动自动部署（ BuildConfig 执行完毕后触发 DeploymentConfig ）。红帽 OpenShift DeploymentConfig 中许多功能最终将成为 Kubernetes Deployments 功能集的一部分，目前 OpenShift 也完全支持 Kubernetes Deployments 。

企业客户需要更多安全工具，来处理正在部署的应用程序。容器生态系统在容器镜像扫描、签名等解决方案方面已经走过了漫长的道路。但是，开发人员常常仍在寻找和部署缺乏任何来源且可能不太安全的 Image 。 Kubernetes 通过 Pod 安全策略来提升安全性。例如我们可以设置 Pod 以非 root 用户方式运行。 Pod 安全策略是 Kubernetes 中的较新的功能，这也是受 OpenShift SCC （安全上下文约束）的启发。

为了真正实现容器镜像的安全，红帽致力于消除单一厂商控制的容器镜像格式和运行时（即 Docker ）。红帽为 Kubernetes 开发了 CRI-O ，这是一个轻量级、稳定且更安全的容器运行时，基于 OCI 规范并通过 Kubernetes Container Runtime Interface 集成。目前已经在 OpenShift 中正式发布。

4. OpenShift 帮助 Kubernetes 运行更多类型的应用负载

Kubernetes 本身适合无状态的应用运行。但如果企业中大量有状态的应用都无法运行在 Kubernetes 上的话， Kubernetes 的使用场景终将有限。有状态应用在 Kubernetes 上运行的最基本要求就是数据持久化。为此，红帽创建了 OpenShift 存储 Scrum 团队，专注于此领域，并为上游的 Kubernetes 存储卷插件做出贡献，为这些有状态服务启用不同的存储后端。随后，红帽推动了动态存储配置的诞生，并推出了 OpenShift Container Storage 等创新解决方案。红帽还参与了 Kubernetes 容器存储接口（ CSI ）开源项目，以实现 Pod 与后端存储的松耦合。

5. OpenShift 实现应用的快速访问

Kubernetes 1.0 中没有 Ingress 的概念，因此将入站流量路由到 Kubernetes Pod 和 Service 是一项非常复杂、需要手工配置的任务。 在 OpenShift 3.0 中，红帽开发了 Router ，以提供入口请求的自动负载平衡。 Router 是现在 Kubernetes Ingress 控制器的前身，当然， OpenShift 也支持 Kubernetes Ingress 。

Kubernetes 本身不包含 SDN 和虚拟网络隔离。而 OpenShift 包括集成了 OVS 的 SDN ，并实现虚拟网络隔离。此外， 红帽还帮助推动了 Kubernetes 容器网络接口开发、为 Kubernetes 集群提供了丰富的第三方 SDN 插件生态系统 。目前， OpenShift 的 OVS 支持 Network Policy 模式 ，其网络隔离性更强，而且默认使用 Network Policy 模式，极大提升了容器的网络安全。

6. OpenShift 实现了容器镜像的便捷管理

OpenShift 使用 ImageStreams 管理容器镜像。一个 ImageStream 是一类应用镜像的集合，而 ImageStreams Tag 则指向实际的镜像。

对于一个已经有的镜像，如 Docker.io 上的 Docker Image ，如果 OpenShift 想使用，则可以通过将 Image 导入 ImageStream 中。需要注意的是，我们在将 Image 导入 ImageStream 的时候，可以加上 --scheduled=true 参数，它的作用是当 ImageStream 创建好以后， ImageStream 会定期检查镜像库的更新，然后保持指向最新的 Image 。

在介绍 OpenShift 对 Kubernetes 的增强以后，接下来我们介绍 OpenShift 对 Kubernetes 生态的延伸。

2.1.2 OpenShift 对 Kubernetes 生态的延伸 **

OpenShift 对 Kubernetes 生态的延伸，主要体现在七个方面，我们将分别进行介绍。

1. OpenShift 实现了与 CI/CD 工具的完美集成

目前 OpenShift Pipeline 默认使用 Tekton 。 Tekton 是一个功能强大且灵活的 Kubernetes 原生开源框架，用于创建持续集成和交付（ CI/CD ）。通过抽象底层实现细节，用户可以跨多云平台和本地系统进行构建、测试和部署。

Tekton 将许多 Kubernetes 自定义资源（ CR ）定义为构建块，这些自定义资源是 Kubernetes 的扩展，允许用户使用 Kubectl 和其他 Kubernetes 工具创建这些对象并与之交互。

Tekton 的自定义资源包括：

l Step ：在包含卷、环境变量等内容的容器中运行命令。

l Task ：执行特定 Task 的可重用、松散耦合的 Step （例如， building a container image ）。 Task 中的 Step 是串行执行的。

l Pipeline ： Pipeline 由多个 Tasks 组成，按照指定的顺序执行， Task 可以运行在不同的节点上，它们之间有相互的输入输出。

l PipelineResource ： Pipeline 的资源，如输入（例如， Git 存储库）和输出（例如， Image Registry ）。

l TaskRun ：是 CRDs 运行时，运行 Task 实例的结果。

l PipelineRun ：是 CRDs 运行时，运行 Pipeline 实例的结果，其中包含许多 TaskRuns 。

OpenShift Pipeline 的工作流程图如图 2-5 所示：通过 Task 定义 Pipeline , Tekton 执行 Pipeline ; Task 和 Pipeline 都 变成运行时状态，并在 OpenShift 中启动 Pod 来运行 Pipeline 。

在 OpenShift 的 Operator Hub 中，提供 OpenShift Pipeline Operator ，如图 2 - 6 所示

Tekton 部署成功以后， OpenShift Pipeline 的实现就无须借助于第三方工具（如 Jenkins ）。通过 Tekton 构建 Pipeline 的示例 如图 2 - 7 所示 ：

虽然 OpenShift 默认使用 Tekton 实现 Pipeline ，但 OpenShift 会继续发布并支持与 Jenkins 的集成。 OpenShift 与 Jenkins 的集成，体现在以下几个方面：

l 统一认证： OpenShift 和部署在 OpenShift 中的 Jenkins 实现了 SSO 。根据 OpenShift 用户在 Project 中的角色，可以自动映射与之匹配的 Jenkins 角色（ view 、 edit 或 admin ）。

l OpenShift 提供两个版本的 Jenkins ： Ephemeral 版本的 Jenkins （无持久存储）和具有持久存储的 Jenkins 。并提供了一键部署 Jenkins 的两个模板，如下图 2-8 所示：

图 2-8 两种类型的 Jenkins 模板

l 自动同步 Secret ：在同一个项目中， OpenShift 的 Secret 与 Jenkins 凭证自动同步，以便 Jenkins 可以使用用户名 / 密码、 SSH 密钥或 Secret 文本，不必在 Jenkins 中单独创建。

l Pipeline 的集成：我们可以在 Jenkins 中定义 Pipeline 去调用 OpenShift API ，完成一些应用构建和发布等操作。

2. OpenShift 实现从开发运维一体化

在 Kubernetes 刚发布时，红帽主要想借助于 Kubernetes 构建企业级开发平台。为了全面提升 OpenShift 的运维能力，红帽收购 CoreOS ，将其中优秀的运维工具纳入到 OpenShift 中。 CoreOS 麾下对 OpenShift 运维能力大幅提升的组件有：

l Tectonic ：企业级 Kubernetes 平台。

l Container Linux ：适合运行容器负载的 Linux 操作系统 CoreOS 。

l Quay ：企业级镜像仓库。

l Operator ：有状态应用的生命周期管理工具。

l Prometheus ：容器监控平台。

CoreOS 在 Prometheus 社区建立了领导地位，这为红帽带来了宝贵的专业知识。红帽 OpenShift 也逐步与 CoreOS 完成整合：

l 在监控方面， Prometheus 成为默认的监控工具，提供了原生的 Prometheus 监控、警报和集成的 Grafana 仪表板。

l 在运维管理方面， OpenShift 将 CoreOS Tectonic 控制台的功能完全融入到了 OpenShift 中，提供运维能力很强的 Cluster Console 。

l 操作系统 CoreOS 作为 OpenShift 的宿主机操作系统。

l 将 Operator 作为集群组件和容器应用的部署方式。

l Quay 正在与 OpenShift 进行最后的集成。后面 OpenShift 的 Docker Registry 可以由 Quay 替代。

3. OpenShift 实现有状态应用的全生命周期管理

CoreOS 开发了管理 Kubernetes 上运行的应用的 Operator 。 Operator 扩展了 KubernetesAPI ，它可以配置和管理复杂的、有状态应用程序的实例。如今， Operator 能够纳管的应用数量迅速增加。

Operator 为什么这么重要？因为我们在 Kubernetes 上运行复杂的有状态应用程序（如数据库，中间件和其他服务）通常需要特定于该服务的操作领域知识。 Operator 允许将领域知识编程到服务中，以便使每个服务自我管理，同时利用 Kubernetes API 和声明性管理功能来实现这一目标。 Operator 可以实现跨混合云的应用生命周期统一管理。而 Operator 会用到的 Kubernetes 中的 ** CRDs ，也是红帽推动开发的。

OpenShift 提供一个非常方便的“容器应用商店”： OperatorHub 。 OperatorHub 提供了一个 Web 界面，用于发现和发布遵循 Operator Framework 标准的 Operator 。开源 Operator 和商业 Operator 都可以发布到 OperatorHub 。截止到目前 OperatorHub 中的应用数量超过 200 个，如图 2-9 所示：

4. OpenShift 实现了对 IaaS 资源的管理

Kubernetes 虽然对运行在其上的容器化应用有较强的管理能力，但 Kubernetes 缺乏对 Kubernetes 下的基础设施进行管理的能力。为了实现 PaaS 对基础架构的纳管， OpenShift 引入 Machine API ，通过配置 MachineSet 实现 IaaS 和 PaaS 统一管理。也就是说，当 OpenShift 集群性能不足的时候，自动将基础架构资源加入到 OpenShift 集群中。目前 OpenShift 实现了对 AWS EC2 、微软 Azure 、 Red Hat OpenStack 等云平台的纳管。

5. OpenShift 实现集群实时更新

安装 Kubernetes 集群后，一个重大挑战是让它们保持最新状态。 CoreOS 率先推出了 Tectonic 和 Container Linux 的 “over the air updates” 概念。通过这个技术，客户能够将 OpenShift 集群连接到红帽官网，这样客户就可以收到有关新版本和关键更新的自动通知。如果客户的 OpenShift 集群不能连接红帽官网，客户仍然可以从本地镜像仓库下载和安装相同的更新。

OpenShift 的主机操作系统基于 CoreOS ，将提供平滑升级的能力。