OpenShift v3是一个基于Docker和Kubernetes的PaaS系统，提供应用源码管理、构建和部署功能。它在Kubernetes之上增加了镜像管理、大规模应用管理和用户跟踪等功能。OpenShift Origin基于微服务架构，通过REST APIs和控制器实现组件间的协同，使用OAuth和TLS确保安全性。其设计允许扩展和定制，以适应不同的应用场景。
Openshift Orgin 架构概览
概览
OpenShift v3是一个基于Docker容器技术与Kubernetes容器编排平台的PaaS系统，旨在尽可能准确地对使用者暴露底层Docker与Kubernetes的概念与能力，并着重于开发人员能够轻松地组合应用。例如，安装Ruby、推送源码并添加MySQL数据库。
与OpenShift v2不同，在对模型各个方面进行创立后，配置上更加灵活。 将应用作为单独对象的概念被取消，以支持更灵活的“服务（Service）”组合，允许两个web容器重用数据库或者将数据库服务暴露给外部使用。
架构分层构成
Docker服务提供了对打包和创建Linux-based轻量级容器镜像操作的抽象，使得我们很容易通过交互方式或者Dockerfile构建出容器镜像。Kubernetes提供了集群管理和在集群内多台主机上编排调度容器的能力。
OpenShif在Docker与Kubernetes之上增加了以下特性：
图1. OpenShift Origin架构概览
OpenShift Orgin架构是什么？
OpenShift基于微服务架构，由多个较小的、松耦合组件单元协同工作。运行于Kubernetes集群之上，相关对象数据存储于ectd（一种可靠Key-Value存储集群）。这些服务按照功能分为：
用户调用REST API来更改系统的状态，控制器使用REST API读取用户所需的状态，然后尝试使系统中其它部分达到状态同步。比如，当用户请求构建应用时，创建一个”build”对象。构建控制器看到一个新创建的”build”对象，就在集群上运行一个进程来执行此次应用构建。当构建完成，控制器通过REST API更新”build”对象，最终用户就看到构建完成了。
控制器模式意味着OpenShift Origin中很多功能都是可以被扩展的。构建的运行与启动可被独立客户化，并不影响到镜像是如何管理的或者部署是如何发生的。控制器执行系统的”业务逻辑“，将用户的操作转化为实现。通过定制这些控制器或用你自己的逻辑来替换它们，可以实现不同的行为效果。从系统管理的角度来看，这同样意味着可以使用调用API的脚本，来规范化管理操作并使其能被重复调度使用。这些脚本也可被看作监控状态变化并采用相应动作的控制器。OpenShift Origin使得这种客户化定制集群的能力成为一流行为。（ OpenShift Origin makes the ability to customize the cluster in this way a first-class behavior.）
为了实现这一目标，控制器利用可靠的系统变更事件流来同步系统视图，以求反映出用户正在进行的操作。事件流将变更从etcd推送到REST API，控制器尽快地处理这些更改，以便系统及时高效地反映出来。然而，由于任何时候都可能发生故障，因此控制器必须能够在启动时获取系统最新状态，并确认一切都处于正确状态。这种重同步机制很重要，意味着即使出现问题，运维人员可重启受影响的组件，并且系统会检查确认所有状态。系统能够最终与用户的意图达到一致，因为控制器始终使系统处于同步。
OpenShift Origin是如何保证安全的？
OpenShif Origin和Kubernetes API对用户提供的凭证进行身份认证，然后根据他们的角色对其授权。开发人员和管理员都可以通过多种方式进行身份认证，主要是OAuth令牌与X.509证书方式。OAuth令牌使用JSON Web RS256算法签名，RSA签名算法采用带SHA-256的PKCS#1 v1.5。
开发人员通常使用客户端程序（如：oc），或者通过浏览器使用Web控制台，来访问OpenShift Orgin系统REST API，并且大部分相互之间的通讯使用OAuth bearer令牌保证安全。基础架构组件（如：Node）使用由系统生成的证书访问API，证书中包含其身份证明。运行在容器中的基础架构组件使用与其service account（Kubenetes中的概念）关联的令牌连接API。
授权由OpenShift Origin策略引擎处理，该引擎定义诸如“create pod”、“list services”之类的操作并将其分组对应到策略文档中的角色。角色通过用户或组标识绑定到用户或组。当用户或Service Account尝试执行操作时，策略引擎检查分配给它们的角色（例如：集群管理员或者当前项目管理员），再根据角色权限允许或拒绝操作。
集群上运行的每个容器都与一个service account关联，也可向这些service account分配secret（Kubernetes概念），并自动分发到容器中。secret用来向系统API证明身份获得授权，使基础架构能摘取与推送镜像、构建应用镜像和部署组件，同时允许容器中的应用代码轻松使用secret。
TLS支持
所有与REST API连接的通讯信道，以及Master组件（比如：etcd和Api Server），都使用TLS加密。TLS通过X.509服务器证书和公钥基础设施，提供强大的加密、数据完整性和身份认定。默认情况下，会为每个OpenShift Origin部署创建一个新的内部PKI。内部PKI使用2048位RSA密钥和SHA-256签名。对外的公共主机（Public Hosts）支持使用自定义证书。
OpenShift Origin使用Go语言标准tls加密库实现crypto/tls，不依赖于任何外部加密和TLS库。此外，客户端依赖于外部GSSAPI身份认证和OpenPGP签名库。GSSAPI通常由MIT Kerberos或Heimdal Kerberos提供，这两个库都使用OpenSSL的libcrypto。OpenPGP签名验证由libgpgme和GnuPG处理。
不安全的版本SSL 2.0和SSL 3.0不被支持且不可用。OpenShift Origin服务端和oc客户端默认只提供TLS 1.2。TLS 1.0和TLS 1.1可通过服务端配置启用。服务端和客户端最好使用带有经认证加密算法和完美前向加密功能的现代密钥套件。具有不推荐和不安全算法（如RC4、3DES和MD5）的密钥套件已被禁用。某些内部客户端（例如：LADP身份认证）对TLS 1.0 - 1.2限制较少，有更多的密钥套件可用。
Table 1. Supported TLS Versions
| TLS版本 | OpenShift Origin服务端 | oc客户端 | 其它客户端 |
|---|---|---|---|
| SSL 2.0 | 不支持 | 不支持 | 不支持 |
| SSL 3.0 | 不支持 | 不支持 | 不支持 |
| TLS 1.0 | 否1 | 否1 | 可能2 |
| TLS 1.1 | 否1 | 否1 | 可能2 |
| TLS 1.2 | 是 | 是 | 是 |
| TLS 1.3 | N/A3 | N/A3 | N/A3 |
以下是OpenShift Origin和oc客户端支持的密钥套件列表，按照优先顺序排列：
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHATLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHATLS_ECDHE_RSA_WITH_AES_128_CBC_SHATLS_ECDHE_RSA_WITH_AES_256_CBC_SHATLS_RSA_WITH_AES_128_GCM_SHA256TLS_RSA_WITH_AES_256_GCM_SHA384TLS_RSA_WITH_AES_128_CBC_SHATLS_RSA_WITH_AES_256_CBC_SHA
1: 默认禁用，但可通过服务端配置启用。
2: 某些内部客户端，比如LDAP client。
3: TLS 1.3，还在开发中
1720
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
