云计算与云原生—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 个核心基础：

Linux：OpenShift v3 构建在极具可靠性的 RHEL 之上。

Container：容器旨在提供高效、标准化的应用程序打包机制，以及不可变基础设施（无论部署什么应用，基础设施始终不变，这得益于容器技术的自包含特性），从而实现应用程序在多云环境中的移植性。

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&#x