Openshift 概述

---

简述

OpenShift v3是一种分层的系统，它的目的是尽可能准确地揭露底层的docker格式化的容器镜像和Kubernetes的概念，重点是开发人员可以轻松地组合应用程序。例如，安装Ruby、推代码和添加MySQL。

与OpenShift v2不同的是，在创建模型的所有方面后，配置的灵活性会被暴露出来。将应用程序作为独立对象的概念被移除了，以支持更灵活的“服务”组合，允许两个web容器重用数据库或直接将数据库公开到网络的边缘。

层是什么?

Docker服务提供了打包和创建基于linux的轻量级容器镜像的抽象。Kubernetes提供集群管理并在多个主机上协调容器。

OpenShift容器平台补充道:

• 为开发人员提供源代码管理、构建和部署
• 在你的系统中管理和提升镜像的规模
• 大规模应用程序管理
• *组织大型开发人员组织的团队和用户跟踪
• UML序列图和流程图

---

图1所示。OpenShift容器平台架构概述

什么是OpenShift容器平台架构?

OpenShift容器平台有一个基于微服务的架构，它是一个小型的、解耦的单元，可以协同工作。它运行在Kubernetes集群的顶部，有关于存储在etcd中的对象的数据，这是一个可靠的集群键值存储。这些服务被功能分解了:

• REST api，它公开了每个核心对象。
• 控制器读取这些api，对其他对象应用更改，并报告状态或写回对象。

用户对REST API进行调用，以更改系统的状态。控制器使用REST API来读取用户想要的状态，然后尝试将系统的其他部分进行同步。例如，当用户请求一个构建时，他们会创建一个“构建”对象。构建控制器看到已经创建了一个新的构建，并在集群上运行一个进程来执行该构建。当构建完成时，控制器将通过REST API更新构建对象，用户看到他们的构建完成了。

controller模式意味着OpenShift容器平台中的大部分功能都是可扩展的。构建和启动的方式可以独立于镜像是如何管理的，或者部署是如何进行的。控制器执行系统的“业务逻辑”，将用户的行为转化为现实。通过定制这些控制器或用您自己的逻辑来替换它们，可以实现不同的行为。从系统管理的角度来看，这也意味着API可以用来在重复的代码中编写通用的管理操作。

为了使这成为可能，控制器利用可靠的变更流到系统来同步他们对系统的看法和用户正在做的事情。此事件流将更改从etcd更改为REST API，然后在更改发生时将其更改为控制器，因此更改可以快速、有效地在系统中产生涟漪。然而，由于故障随时可能发生，控制器还必须能够在启动时获得系统的最新状态，并确认一切都处于正确的状态。这种重新同步很重要，因为它意味着即使有什么东西会发生。

如何确保OpenShift容器平台的安全?

OpenShift容器平台和Kubernetes api对提供凭证的用户进行身份验证，然后根据他们的角色授权他们。开发人员和管理员都可以通过多种方式进行身份验证，主要是OAuth标记和SSL证书授权。

开发人员(系统的客户端)通常会从一个客户端程序，比如oc或web控制台，通过他们的浏览器进行REST API调用，并使用OAuth传递器来进行大多数通信。基础设施组件(如节点)使用包含其标识的系统生成的客户端证书。在容器中运行的基础设施组件使用与它们的服务帐户相关联的令牌来连接到API。

授权是在OpenShift容器平台策略引擎中处理的，它定义了“创建pod”或“list服务”等操作，并将它们分组到策略文档中的角色中。角色通过用户或组标识符绑定到用户或组。当用户或服务帐户尝试操作时，策略引擎将检查分配给用户的一个或多个角色(例如:在允许它继续之前，集群管理员或当前项目的管理员)。

由于在集群上运行的每个容器都与服务帐户相关联，因此也可以将秘钥与这些服务帐户相关联，并将它们自动交付到容器中。这使得基础设施能够管理用于提取和推动镜像、构建和部署组件的秘钥，还允许应用程序代码轻松地使用这些秘钥。

---