OpenShift 的架构设计

目录

前言

从 红帽云平台业务部产品副总裁 Joe Fernandes（乔·费尔南德斯）的访谈回顾 OpenShift 的发展历程。

OpenShift v3 — 将 Kubernetes “企业” 化

选择 Kubernetes

2011 年 Redhat 首次推出 OpenShift 产品，OpenShift v1、v2 都依赖 Linux 原生的 Container 技术来部署用户应用。2013 年，红帽做出了一项决定，支持 Docker 开源项目，帮助推动容器运行时和容器镜像包装格式的标准，这成为 OpenShift v3 的基础。

但是，Redhat 一直很清楚，OpenShift 不仅仅需要一个容器运行时。真正的生产业务应用不是运行在单个容器中，也不会部署在单个主机上。能够在多个主机之间协调多个容器，即容器的编排是 OpenShift 的一个关键要求。

在 2013-2014 年间，Redhat 调研了一些方案，最终选中了 Kubernete，它具有非凡的技术魅力 —— 针对容器编排和管理的强大基元（Primitive）。

• Pod：将若干个 Containers 抽象为单个原子单元，同一 Pod 下属的 Containers 共享网络资源，并且基于 DNS 的 Service Discovery 可以将这些服务链接在一起。
• ReplicaSet Controller：保证了 “Pod 是脆弱的，但服务是健壮的”，并且使用了灵活的 Label 来识别 Kubernetes 资源对象。
• 强大的网络模型，用于管理跨多个主机的容器。
• 能够协调 Storage Provider 创建 Volume 和 Persistent Volume，从而让容器中可以运行无状态和有状态的服务。
• 简化的编排模型，能够快速让多个应用投入运行，而无需复杂的双层调度器
• 认识到开发人员（Dev）和操作人员（Ops）的需求是不同的，并将这两种需求统筹考虑，而无需对这两项重要的功能做出妥协。

以 Kubernetes 为标准这个决定完全改变了 OpenShift 的游戏规则。在 2015 年 6 月 OpenShift v3 推出一年后，OpenShift 明确了 3 个核心基础：

1. Linux：OpenShift v3 构建在极具可靠性的 RHEL 之上。
2. Container：容器旨在提供高效、标准化的应用程序打包机制，以及不可变基础设施（无论部署什么应用，基础设施始终不变，这得益于容器技术的自包含特性），从而实现应用程序在多云环境中的移植性。
3. Kubernetes：提供强大的容器编排和管理功能。

今天的 OpenShift 仍然以这三大核心为基础，但是在企业环境中使用 Kubernetes，需要用到的远不仅这些。企业通常对安全性、互操作性和兼容性等有着更复杂的要求，他们需要一个平台，以便在构建新的云原生应用同时，对现有应用和服务进行改造。

单集群实现多用户、多应用

最初，企业用户在使用 Kubernetes 时，只能在一个 Cluster 中运行属于一个用户的应用程序。他们不希望为每个开发人员或每个应用程序部署运行一个单独的 Kubernetes Cluster。所以在 OpenShift 中，实现了一个很普遍的需求：Kubernetes Cluster 的多用户功能。

为解决这个问题，Redhat 推动了 Kubernetes 中 Namespace 和 Resource Quota（资源配额）功能的开发，以便多个用户可以共用一个 Kubernetes Cluster，同时限制用户在集群上使用的资源数量。此外，还推动了 Kubernetes 的 RBAC（基于角色的访问控制）功能的开发，以便为 Cluster 中不同的角色用户分配不同的执行权限，而不是所有用户都作为 Cluster Admin。

在今天看来，RBAC 最初就是个赌注，直到 Kubernetes 1.6 版本才得以发布。而 OpenShift 在 Kubernetes 1.0 时代就开始提供 RBAC 功能了，并且 RedHat 提出的这个功能最终能够被 Kubernetes 上游社区接受，主要还是归功于其在 OpenShift 中的实现及需求验证。

虽然像命名空间、配额和 RBAC 等功能可能并不是公有云服务的首选，因为在公有云服务中每个用户都可以独立拥有自己的 Kubernetes Cluster，但是在企业用户环境中，情况并非这样。在企业 Kubernetes 环境中，通常数百个开发人员共用着一个集群，而这个集群上通常也运行着多个应用程序。因此，如果没有 Redhat 贡献的这些核心功能，OpenShift 的许多企业客户将没法使用 Kubernetes。

应用部署更简单、更安全

虽然 Kubernetes 为应用部署、运行和更新提供了诸如 Pod、Services、Controllers 等资源对象，但是在 Kubernetes 1.0 中使用这些功能远没有想象中的简单。而这些正是红帽大力投入的另一个领域，在OpenShift 3.0（Kubernetes 1.0）中开发了 Deployment Configurations，用以提供参数化部署输入的模板、执行滚动部署、部署状态回滚，以及用于响应事件驱动的自动部署触发器。这其中的很多功能最终成为了 Kubernetes 中的 Deployments 功能。

现在，OpenShift 仍然支持 Deployment Configurations 功能，因为客户仍然存在生命周期钩子（Lifecycle hooks）等关键功能的需求，这个功能允许在预定义位置将用户行为注入应用的部署过程中，而 Kubernetes Deployments 并不支持这个功能。OpenShift 企业客户可以选择使用 Deployment Configurations ，也可以选择使用标准的 Kubernetes Deployments。直观的，企业用户可以选择使用 OpenShift Console（oc CLI，一个 kubectl CLI 的扩展），或者直接使用 kubectl CLI 来部署他们的应用。

此外，对于企业客户而言，还需要更多的安全工具，例如：镜像扫描、证书签名等安全解决方案，用于部署他们的应用。Kubernetes Pod 的 Security Policy 功能旨在定义一组 Pod 在加入 Cluster 之前必须执行的条件过滤集合，从而提供另一层面的安全性。例如：要求 Container 必须以 Non-Root 账户运行。Kubernetes Pod Security Policy 的灵感来自 OpenShift SecurityContextConstraints。

当然，安全并不是开发人员在使用 Kubernetes 时需要优先考虑的方面，但是这是企业管理员需要考虑的，尤其是在生产环境中，可以为企业保障 Kubernetes Cluster 的安全性。 这种对安全性和标准的关注，也推动了 Redhat 在 Linux 容器运行时这一领域上的工作，Redhat 在 Open Container Initiative 中的工作帮助推动了容器运行时和镜像格式的标准化，这些镜像格式无法被单一供应商控制。

也就是在那个时候，Redhat 为 Kubernetes 开发了 CRI-O，一个轻量级、稳定且更安全的容器运行时实现，基于 OCI 规范并通过 Kubernetes Container Runtime Interface（CRI）与 Kubernetes Cluster 进行集成。

运行多类型的应用负载

事实上，企业中普遍存在着更复杂的有状态服务。如果没有持久存储卷，就很难运行有状态服务。

于是，Redhat 成立了 OpenShift Storage Scrum 团队，专注于这个领域，并向上游的 Kubernetes 存储卷插件贡献代码，致力于实现有状态服务的不同存储后端。之后，红帽推动了动态存储配置等增强功能，推出了 OpenShift Container Storage 等创新解决方案，通过 Kubernetes CSI 的引入，进一步对 Kubernetes 存储供应商的集成进行了标准化。

StatefulSets 功能也是来自客户交流，因为我们看到那些想要运行有状态服务的客户，他们所需要的不仅仅是存储后端。对于传统的有状态服务而言，还需要保证 Service 中 Pod 实例化的顺序和唯一性。与 cattle-like（牲口一样的）服务完全不同，后者的每个 Pod 实例都是相同的，并且可以在故障后随意地重新部署。例如：SQL 数据库集群，数据库集群中的每个实例可能具有不同的标识和角色，现在可以由 StatefulSets 来实现了。

此外，OpenShift 3.0 还为 Kubernetes Jobs 和 CronJob Controller 的开发做出了贡献，使 Kubernetes 具备了批处理服务，以便其上的应用程序可以实现多次运行或单次运行。而 Replication Controllers 并不适合做这个事情，它是为服务的长时间运行而设计的。

应用程序外部访问

在 Kubernetes 中部署应用程序的目的是为了对外提供服务，但在最初，外部客户端要能访问到这些服务也并非易事。在 Kubernetes 1.0 中，并没有 Ingress 的概念，因此将入站流量路由到 Kubernetes Pod 或 Service 是一项需要人工参与的工作。在 OpenShift 3.0 中，Redhat 开发了 Routes 的概念，以实现针对特定应用请求的自动分发。Routes 就是 Kubernetes Ingress Controller 的前身。今天 OpenShift 也完全支持了 Ingress Controller。使用 OpenShift Routes 或 Ingress，你可以将来自 Cluster 外部的 HTTP/HTTPS 访问路由到 Services 中。

在共享群集的环境中，企业用户还希望每个应用程序只能看到针对它的访问流量。在诸如 Flannel 这类基本网络解决方案实现了应用程序无隔离扁平网络的同时，OpenShift 还实现了支持 multi-tenant 的 SDN 方案。在以多租户模式部署时，基于 OpenvSwitch 的 OpenShift SDN 会限制应用程序仅查看到其 Namespace 内的网络流量或来自其他特定 Namespace 的流量。

此外，Redhat 还帮助推动 Kubernetes Container Networking Interface（CNI）的实现，以支持丰富的第三方 SDN 插件生态系统。从那时起，Redhat 为社区开发出了 Network Policy。今天 OpenShift 完全支持这个功能，同时还将多租户网络隔离功能提高到了一个新的层次，在命名空间、特定服务、端口之间提供了更高级的隔离功能。

OpenShift v4.0 — 从构建平台到运营平台

在最初的几年，Red Hat 对 Kubernetes 的期望，就是构建一个生产级的新一代 Linux 容器平台，这本身也是对 Linux 的扩展，致力于将 RedHat OpenShift 打造成为企业级 Kubernetes 的标准。

但 OpenShift v4.0 中，Redhat 更关注如何在整个堆栈中运营平台。这也是 Redhat 决定收购 CoreOS 的主要动因，Redhat 将这次收购看成是针对 Kubernetes 在运维管理和自动化操作方面做出的 2.5 亿美元投资。从构建平台到运营平台，这一关注点一直是我们在 2018、2019 年及以后多年中 OpenShift 产品路线图的重心。

使用 Prometheus + Grafana 进行管理和监控

对平台管理员而言，对 Kubernetes Cluster 进行监控并在出现故障时发出预警，这是一个极为关键的需求。监控和预警有助于确保平台及应用程序健康运行。

在 OpenShift v3.11 中，Redhat 就推出了原生 Prometheus 监控、警报和 Grafana 集成仪表板。这些功能包括默认的 Grafana 仪表板、对 Kubernetes 的 Prometheus 警报定义、安装预配置，这部分功能由 Prometheus 监控项目 mixin 开发而来。

CoreOS 在 Prometheus 社区有着领导性地位，将 CoreOS Tectonic 控制台与 OpenShift 控制台进行了集成之后，旨在为集群管理员提供全面的原生 Kubernetes 管理体验，从而对 OpenShift 现有的服务目录（Service Catalog）和以开发人员为中心的界面进行有力补充。

使用 Kubernetes Operators & CRDs 管理服务

CoreOS 推出的另一项创新，是在 2016 年发布的 Kubernetes Operator。正如 Brandon Phillips 所描述的那样，Operator 是 “一个特定于应用的控制器，它扩展了 Kubernetes API，代表 Kubernetes 用户创建、配置和管理复杂有状态应用实例”。在 KubeCon Europe 大会上，Redhat 和 CoreOS 推出了Operator 框架，以加速和标准化 Kubernetes Operator 的发展。

为什么 Operator 很重要？因为运行复杂有状态应用，如：数据库、中间件和其他服务，通常需要特定于该服务领域的运维专业知识。Operator 允许将专业领域知识编程到软件服务中，以便实现每个服务的自我管理，要实现这点，利用 Kubernetes API 和声明性管理功能即可。通过为应用构建 Operator ，ISV（软件开发商）和服务拥有者即可实现服务的自我管理，从而实现与公有云 “as-a-Service” 类似的功能，并且在数据中心或多云 Kubernetes 平台上提供了更具一致性的交付能力。不论是对于应用发布者，还是对于应用用户而言，这都是一个伟大的进步，因为他们可以在开放混合云环境中实现更为简化的操作。

Operator 充分利用了 Kubernetes Custom Resource Definitions（CRDs）的优势，CRDs 是由 Redhat 主导开发的一项重要功能。CRD 允许你定义这些资源，作为 Kubernetes API 自身的扩展，同时这有助于保持 Kubernetes 内核的精简。Redhat 推动并引领着 CRD 的开发，以便 在OpenShift 中构建更多集成扩展功能。

借助基于 CRDs 的 Operator，在 Kubernetes 上运行的复杂的有状态服务同样成为了 Kubernetes API 的扩展，这为 Kubernetes 服务自动化管理开辟了一系列新可能。

用 Kubernetes 安装升级 Kubernetes

OpenShift 上游社区 OKD 开发的 OpenShift installer，在 OpenShift 4 中推出，其主要目的在于将与集群相关的各个方面都置于 Operator 控制之下，包括控制平面及其底层基础架构 。

为了管理底层基础架构，OpenShift 采用由 Cluster API 项目引入的 Machine API，这个项目主要由 Cluster Lifecycle SIG（集群生命周期特别兴趣小组）维护。将节点和相关基础设施表示为 Kubernetes 风格的 API 资源对象，在运行 Kubernetes 集群服务的不同公有云或数据中心服务器组成的脚本中，定义服务器的预期状态并最终调节实现该状态，通过这种方式，社区开发出了控制器来管理 Kubernetes 集群服务器。

从最初的 Kubernetes 单节点（部署域）开始，企业用户可以在几分钟之内引导启动他们的 Kubernetes Cluster（生产域），并且还能够随着时间推移对集群容量进行扩缩容。基于 Operator 的平台服务将用于部署自托管平台组件，如：Kubernetes、etcd、Prometheus、Grafana、Elasticsearch、Kibana、SDN、存储、镜像仓库和其他 OpenShift 平台组件。

在不可变基础架构上部署 Kubernetes

OpenShift 4 installer 会管理由 RedHat CoreOS 提供的不可变 Linux 容器主机（CoreOS 操作系统），然后将全栈自动化管理推广到基于 OpenStack、Azure、Google 云平台、裸机环境、VMware、红帽虚拟化的 OpenShift 平台，以及其他供应商提供的可运行 OpenShift Kubernetes Cluster 的基础设施上。

尽管 RedHat CoreOS 是一种基于 RHEL Kernel 和核心库（RHEL core）的不可变容器主机，但是在传统基于 RPM 包的 RHEL 容器主机环境中，OpenShift 也将继续得到支持。在传统 RHEL 环境中，OpenShift Ansible Installer 负责引导和初始化 Kubernetes 环境，用户负责管理 RHEL 主机的配置和升级，同时自行管理底层基础架构配置。基于这种策略，用户具有很大灵活性，他们可以选择不可变和全堆栈管理的 OpenShift 环境（RedHat CoreOS），也可以选择在他们自己管理的传统 RHEL 基础架构环境中运行 OpenShift。

集群版本隔空更新（Over the Air Updates）

Kubernetes Cluster 安装部署后，面临的下一个重大挑战就是集群升级更新。CoreOS 率先推出了用于 Tectonic 和Container Linux 的 “隔空更新（over the air updates）” 概念，RedHat 在 OpenShift v4 中引入了这个功能。客户可以把他们的 OpenShift 集群连接到 RedHat，然后接收到有关新版本和关键补丁的通知，最终客户可以将新版本和补丁自动应用到他们的 OpenShift 集群中。对于在离线环境运行 OpenShift 集群的客户，仍然需要从本地镜像仓库中下载镜像并更新集群，不一定需要联网到 RedHat。

“隔空更新” 通过基于 Prometheus 的自动遥测技术实现，遥测会对用户每个群集的状态和 RedHat 远程更新服务器进行报告，更新服务器会在用户集群版本过期时通知用户，就像你的手机或笔记本电脑在后端有新的 OS 版本可用时候会接收到通知一样。通过 Operator ，“隔空更新” 技术可以应用到群集上所有基于 Operator 的 OpenShift 平台服务。我们的最终目标，是向所有部署了 RedHat 认证 Operator 的所有 ISV 推广 “隔空更新”，以便你的群集及其所有内容能够更安全，同时保证集群版本的持续更新。

多集群管理与联合

组织机构一旦考虑开始使用 Kubernetes，我们的经验就是，他们的使用量在不断增长，然后会部署多个集群。我们确实看到了这样的情况，随着用户 OpenShift 集群使用者的增加，他们就会创建新生命周期环境，并在新的数据中心或公有云上部署集群，集群规模从几个到数十个不等。这就是为什么我们一直在多集群（Multi-Cluster）管理和集群联合（Cluster Federation）上加大投入的原因。基于我们在 Prometheus 和 Grafana 上所做的集群管理工作，RedHat 致力于将其扩展到多集群环境，多集群可以运行在不同的公有云、私有云、虚拟化平台和裸机环境中。

作为 Multi-Cluster SIG 的一部分，RedHat 正在贡献的 Kubernetes Federation v2 项目，就专注于提供跨多集群管理应用部署的功能。这些组件包括一个集群注册表，用于存储和访问所有集群的元数据信息，以及多集群入口、部署和其他相关信息。通过我们在多集群管理和 Federation 方面的努力，我们的目标是提供更好的工具来实现跨多集群和多云环境的应用运营、管理和部署。

使用 Istio 在 Kubernetes 上继续创新

Istio Service Mesh 是云原生生态系统中基于 Kubernetes 上面的一个伟大创新。RedHat 也正在为 Istio 上游做贡献，并会将这项功能带给 OpenShift 用户。Istio 为微服务中基于 Envoy 的分布式数据平面添加了一个分布式控制平面，Envoy 通过轻量级分布式代理路由和管理微服务请求。

从 Microservices 到 Serverless

Knative 是另一个构建在 Kubernetes 上的创新。RedHat 希望通过 Knative 为 OpenShift 带来开放混合的 Serverless 功能，并实现 Function as a Service （FaaS）。目前，AWS Lambda 等 FaaS 解决方案通常受限于单一云环境。我们的目标是与 Knative、Kubernetes 社区以及不同的 FaaS 供应商合作，为在混合、多云环境中构建应用的开发者提供 Serverless 和 FaaS 功能。

OpenShift v4.3

RHEL 7.6（Red Hat Enterprise Linux）以及 RHCOS 4.3 （Red Hat Enterprise Linux CoreOS）支持部署 OpenShift v4.3，基于实现了 CRI-O 运行时的 Kubernetes 1.16。

注：Controller 节点必须使用 RHEL CoreOS，而 Worker 节点则可以将 RHCOS 或 RHCL。

OpenShift4.3 整体更新包括以下三部分：

支持 SR-IOV

基于 Multus CNI，OpenShift 可以同时使用 OvS 和 SR-IOV CNI 多网络平面。其中。OvS 可以只作为 Pod 的管理网络，SR-IOV 作为数据网络。

支持 Istio

现在可以通过图形化配置应用不同版本（以前是修改 virtualservice）。

支持 Knative Operator

加密存储在 ETCD 中的数据

可以加密存储在 etcd 中的数据。为群集启用 etcd 加密可提供额外的数据安全层。启用 etcd 加密后，以下 OpenShift API 服务器和 Kubernetes API 服务器资源将被加密。

• Secrets
• ConfigMaps
• Routes
• OAuth access tokens
• OAuth authorize tokens

在 AWS，AZURE 或 GCP 上部署 dedicated 集群

以将专用群集安装到：

• Amazon Web Services（AWS）上的现有 VPC。
• Google Cloud Platform（GCP）上的现有 VPC。
• Microsoft Azure上 的现有 Azure 虚拟网络（VNet）。

要在这些云平台上创建 dedicated 集群，必须提供一个现有的私有 VPC/VNet 和子网来承载该集群。安装程序将 Ingress Operator 和 API 服务器配置为仅从专用网络进行访问。

OpenShift 4.5

支持 KubeVirt 虚拟机

OpenShift 4.5 的虚拟机功能，使 IT 团队能够将基于虚拟机的标准工作负载引入 Kubernetes 中，有助于消除传统和云原生应用堆栈之间的工作流与开发壁垒，并加强对分布式资源的控制。

OpenShift 虚拟化基于 KubeVirt 开源项目，使企业能够对由虚拟机、容器和无服务器功能构成的应用进行开发、部署和管理，全部在一个运行于裸机基础架构上的现代化 Kubernetes 平台上实现。通过 OpenShift 虚拟化，红帽推动了传统应用堆栈的开放创新，使客户能够真正按照自己的速度进行转型。

通过将新应用和现有应用引入到同一架构中，OpenShift 虚拟化提供了一致的开发体验，并加速了企业的创新进程。一旦虚拟机迁移到 OpenShift 并由其进行管理，这些虚拟机就可以逐步实现容器化，或者仍作为虚拟机进行维护。这样，用户就可以开发和交付基于容器和虚拟机而构建的混合应用，使其能够在同一平台上协同运行。

分层架构

OpenShift 采用分层架构，自下而上包含了以下几个层次：

1. 基础架构层
2. 容器引擎层
3. 容器编排层
4. PaaS 服务层
5. 界面及工具层

基础架构层

基础架构层提供计算、网络、存储、安全等基础设施，支持在物理机、虚拟化、私有云和公有云等环境上部署 OpenShift。

保证应用的一致性是容器的优点。在开发、测试和生产环境中运行的结果应该是一致的。但是容器的一致性和可移植性是有前提条件的，那就底层操作系统的内核及相关配置要一致。容器为应用提供了一个隔离的运行环境，这个隔离的实现依赖于底层 Linux 内核的系统调用。如果大量服务器的 Linux 内核及操作系统的配置不能保证一致，那么容器运行的最终结果的一致性也不可能有保障。

所以，在操作系统层面，最新的 OpenShift 仅支持 RHEL 和 RHCOS 操作系统，这是为了向容器引擎层提供一个不可变的操作系统基础设施环境，继而为顶层应用程序提供不可变的 PaaS 基础设施。

容器引擎层

容器引擎层采用 Docker 容器引擎，在最新的版本中，OpenShift 基于 RedHat 提出的 CRI-O 容器运行时实现。

Docker 是当前主流的容器引擎，已经在社区及许多企业的环境中进行了检验。事实证明 Docker 有能力为应用提供安全、稳定及高性能的运行环境。OpenShift 运行的所有容器应用最终落到最底层的实现，其实就是一个 Docker 容器实例。OpenShift 对 Docker 整合是开放式的，完全基于原生的 Docker。

容器编排层

容器编排层，为部署高可用、可扩展的应用提供编排和管理能力，容器云平台需要具有跨多台服务器部署应用容器的能力。OpenShift 采用 Kubernetes 作为其容器编排与管理引擎。

Kubernetes 设计的目的是满足在大规模集群环境下对容器的调度和部署的需求，作为 OpenShift 的重要组件。同样的，OpenShift 完全基于原生的 Kubernetes，OpenShift 对 Kubernetes 的集成是叠加式的，在 OpenShift 集群上仍然可以通过 Kubernetes 的原生命令来操作 Kubernetes 的原生对象。

PaaS 服务层

OpenShift 在 PaaS 服务层提供了丰富的开发语言、开发框架、数据库、中间件及应用支持，支持构建自动化（Build Automation）、部署自动化（Deployment Automation）、应用生命周期管理（Application Lifecycle Management，CI/CD）、服务目录（Service Catalog，包括各种语言运行时、中间件、数据库等）、内置镜像仓库等。PaaS 平台最终的目的是构建一个以应用为中心的服务平台，加速应用开发、部署和运维的速度和效率。而这些 Platform 服务是作为 CaaS 的 Kubernets 所不具备的。。

用户可以在 OpenShift 平台上快速部署和获取一个数据库、分布式缓存或者业务规则引擎的服务。除了 Docker Hub 上的社区镜像外，OpenShift 还有一个重要的服务提供方 RedHat。RedHat 旗下的 JBoss 中间件系列几乎全线的产品都已经容器化。通过 OpenShift，可以快速搭建 DBaaS、BPMAAS 或 Redis-aaS 等。

界面及工具层

云平台一个很重要的特点是强调用户的自助服务，从而降低运维成本，提高服务效率。界面和工具是容器云平台上的最后一公里接入，好的界面和工具集合能帮助用户更高效地完成相关业务。

OpenShift 提供了自动化流程 Source to Image（S2I），帮助用户容器化用各种编程语言开发的应用源代码。用户可以直接使用 S2I 或者把现有的流程与 S2I 整合，从而实现开发流程的持续集成和持续交付。提升开发、测试和部署的自动化程度，最终提高开发、测试和部署的效率。OpenShift 提供了多种用户接入的渠道：Web 控制台、命令行、IDE 集成及 RESTful 编程接口。

针对容器应用的运维及集群的运维，OpenShift 提供了性能度量采集、日志聚合模块及运维管理套件，帮助运维用户完成日常的应用及集群运维任务。

核心组件

Master

Master 是 OpenShift 的 Controller 节点，运行控制平面所有组件，e.g. API Server、Scheduler、Controllers、ETCD。

Node

Node 是 OpenShift 的 Worker 节点，受 Master 节点管理，负责运行应用 Pod。

Infra

Infra 是 OpenShift 的基础设施节点，是一种具有特殊用途的 Node，专门用于运行 OpenShift 底层支撑应用服务 Pod。

Container Image Registry

Container Image Registry（容器镜像仓库），OpenShif 支持实现 Docker Registry API 的多种镜像仓库，包括 Docker Hub 或 Harbor 搭建的私有镜像仓库。还提供了名为 OpenShift Container Registry（OCR）的内置容器镜像仓库，OCR 用于存放用户通过内置的 S2I 镜像构建流程所产生的 Docker 镜像。每当 S2I 完成镜像构建后，它就会向内置镜像仓库推送构建好的镜像。

Service Layer

Service Layer（服务层）在 OpenShift 中，容器运行在 Pod 中，每个 Pod 都会被分配一个 IP 地址。当应用具有多个 Pod 时，在集群内部访问这些 Pod 是通过 Service 组件来实现的。Service 是一个代理，也是一个内部负载均衡，它连接多个后端 Pod，并将访问它的请求转发至这些 Pod。

Routing Layer

Routing Layer（路由层）为了让用户从 OpenShift 集群外部可以访问到部署在集群内部的应用，OpenShift 提供了内置的路由层。路由层是一个软件负载均衡器，包括一个路由器（Router）组件，用户可以为应用的服务定义路由规则（Route），每条路由规则将应用暴露为一个域名。访问这个域名时，路由器会将访问请求转发给服务的后端 Pod。

Web Console、CLI

Web Console 是从 Web 浏览器上访问的 OpenShift 的用户界面。Web Console 服务以 Pod 的形式运行在 Master 节点之上。OpenShift 还提供了命令行工具 oc CLI。用户可以从 Web Console 上直接下载该工具。

高度可扩展分布式架构

基于 API Server 的组件（控制面、数据面）解偶

一方面，OpenShift 利用 API Server 和各种 Controller 实现了控制层面的解耦。API Server 充当了消息总线角色，提供 REST API，这是客户端对各资源类型（Resource Type）对象进行操作的唯一入口。

API Server 的 REST API 支持对各类资源进行增删改查监控等操作，提供认证、授权、访问控制、API 注册和发现等机制，并将资源对象的Spec（定义）和 State（状态）等元数据保存到 etcd 中。各 Controller 使用 Watch（监视）机制通过 API Server 来感知自己所监视的资源对象的状态变化，并在变化发生时进行相应处理，处理完成后会更新被处理对象的状态，必要时还会调用 API 来写入新资源的 Spec。

OpenShift API Server 实现了简单可靠的消息总线的功能，利用基于消息的事件链，解耦了各组件之间的耦合关系，配合 Kubernetes 基于声明式的对象管理方式又确保了功能的稳定性。这个层面的架构解耦使得 OpenShfit 具有良好的规模扩展性。

基于 Plugin-Driver 的 Backend Provider（底层支撑）解偶

另一方面，OpenShift 采用各种插件来实现资源层面的解耦，这个层面的架构解耦使得 OpenShfit 具有良好的功能扩展性。下图展示了 OpenShift 所利用的各种资源。它采用身份认证程序（Identity Provider）来对接各种身份提供程序，完成身份保存和验证；

• 通过 CRI（Container Runtime Interface，容器运行时接口）实现 kubelet 器运行时的解耦，支持 Docker 和 CRI-O 等容器运行时；
• 通过 Docker Registry API，OpenShift 能与各种镜像仓库对接，实现镜像的上传、保存和拉取；
• 通过 CNI（Container Network Interface，容器网络接口）实现网络层面的解耦，支持多种网络插件实现 Pod 网络；
• 通过 CSI（Container Storage Interface，容器存储接口）实现存储层面的解耦，支持多种物理存储后端，为容器提供各种持久存储；
• 通过 OSB API（Open Service Broker API，开放服务中介 API）实现服务目录层面的解耦，支持各种不同的服务中介，来为容器云平台用户提供丰富的服务。

部署架构

OpenShift 可以在多种环境中部署，包括：物理机、私有云、虚拟化环境和公有云环境。下图是基于 RedHat Linux 虚拟机部署 OpenShift 容器云生产环境的示例架构图。

• 采用 3 台 VM 作为 Master 节点，每个节点上均运行 API、控制器、调度器、etcd 等集群管理服务。
• 采用 3 台 VM 作为 Infra 节点，每个节点上均运行路由器、内置镜像仓库、监控（Prometheus）和日志（EFK）等集群基础架构组件。
• 采用多台 VM 作为 Node 节点，每个节点上均运行应用 Pod。
• 采用外置存储作为持久存储，比如：GlusterFS、NFS、Ceph 或者 SAN 存储。
• 采用企业级负载均衡器为 Master 节点上的服务和 Infra 节点上的服务提供负载均衡。