OpenShift&Kubernetes：过去、现在与未来（一）

乔·费尔南德斯      山金孝 译

                                                 

译者注：对企业客户而言，容器云平台选择OpenShift还是Kubernetes，二者究竟是什么关系，红帽云平台业务部产品副总裁，乔·费尔南德斯对二者做了总结、回顾与展望，看完这两篇文章，也许你对越来越多的企业客户为什么选择OpenShift，而不是Kubernetes会有自己的理解。

RedHat OpenShift与Kubernetes辉煌的一年即将结束（本文写于2018年12月），比以往都要火热的Kubecon大会也即将到来，现在正是思考我们的过往和未来的好时机。在这个系列文章的第一部分中，我们将回顾红帽第一次参与Kubernetes项目4年多来所做的事情，在这4年多的时间里面，我们集中做过的贡献以及做出的一些关键决策。然后，在第二部分中，将对我们的现在和未来关注的领域进行展望。  

写在前面

OpenShift是领先的企业Kubernetes容器平台。在数以百计的客户中，OpenShift 被应用于不同的垂直细分行业中，并部署在企业数据中心和主流公有云平台上，OpenShift正在赋能客户应用、基础架构的演变，并最终赋能业务的革新发展。  

虽然OpenShift在2011年就问世并一直在发展，但是以Kubernetes为标准的决定是在2014年，这个决定完全改变了OpenShift和RedHat的游戏规则。在2015年6月OpenShift3.0推出一年后，OpenShift被明确构建在3个核心基础上：

1、Linux，这是RedHat最传统、最擅长、也是技术积累最深厚的领域，OpenShift3构建在极具可靠性的Red Hat Enterprise Linux操作系统之上。

2、Container，容器旨在提供高效、不可变和标准化的应用程序打包机制，从而实现应用程序在多云环境中的移植性。

3、Kubernetes，K8S提供了强大的容器编排和管理功能，并且是过去十年中发展最快的开源项目之一。

今天的OpenShift仍然以这三大核心为基础，但是在企业环境中使用Kubernetes，需要用到的远不仅这些。企业通常对安全性、互操作性和兼容性等有着更复杂的要求，他们需要一个平台，以便在构建新的云原生应用同时，对现有应用和服务进行改造。在过去4年多的时间里，红帽在构建平台能力上投入了很多，包括在Kubernetes项目中以及围绕Kubernetes的生态圈中，而这些都是由客户和社区需求驱动的。之前我们曾写过一篇文章介绍过RedHat选择Kubernetes的原因，这里我们想再次强调，OpenShift团队在Kubernetes上的投入，为什么这些投入很重要，然后才展望下一步。

一、单集群下的多用户、多应用

目前，在使用大多数Kubernetes云服务时，在你的集群中只能运行你自己的应用程序。而在OpenShift中，我们实现了一个很普遍的需求：在一个Kubernetes集群中使用多个用户运行多个应用。多租户一直是Kubernetes社区中备受争议的话题，至今仍然争论不休。在我们看来，需求是由我们的企业客户提出的，他们不希望为每个开发人员或每个应用程序部署运行一个单独的Kubernetes集群。另外，这样的需求本身也是由我们自己的OpenShift 运维团队提出的，他们在Red Hat OpenShift Online Starter中维护着一个供开发人员使用的免费云平台，这个平台要求每个Kubernetes集群都能支持数千个用户和应用程序。

为解决这个问题，红帽在许多关键领域投入了很多资源。我们推动了Kubernetes项目中命名空间和资源配额功能的开发，以便多个用户可以共用一个Kubernetes集群，同时限制用户在集群上使用的资源数量。此外，我们还推动了Kubernetes项目中基于角色的访问控制（RBAC）功能的开发，以便为集群中不同角色的用户分配不同的执行权限，而不是所有用户都是群集管理员权限。在今天看来，RBAC最初就是个赌注，一直没在Kubernetes发行版本中出现，直到Kubernetes 1.6版本。OpenShift在Kubernetes 1.0时代就开始提供RBAC功能了，并且RedHat提出的这个功能最终能够被Kubernetes上游社区接受，主要还是归功于其在OpenShift中的实现。虽然像命名空间、配额和RBAC等功能可能并不是公有云服务的首选，因为在公有云服务中每个用户都独立拥有自己的Kubernetes集群，但是在企业用户环境中，情况并非这样，在企业Kubernetes环境中，通常数百个开发人员共用着一个集群，而这个集群上通常也运行着多个应用程序。因此，如果没有红帽贡献的这些核心功能，OpenShift的许多企业客户将没法使用Kubernetes。

 

二、应用部署更简单、更安全

虽然Kubernetes为应用部署、运行和更新提供了诸如pod、services和controllers之类的强大解决方案，但是在Kubernetes 1.0中使用这些功能远没有想象中的简单。而这些正是红帽大力投入的另一个领域。我们在OpenShift 3.0（Kubernetes 1.0）中开发了Deployment Configurations，用以提供参数化部署输入的模板、执行滚动部署、部署状态回滚，以及用于响应事件以驱动自动部署的触发器。这其中的很多功能最终成为了Kubernetes项目中Deployments功能集的一部分，今天的OpenShift也完全支持Kubernetes的这些功能集。现在，我们仍然保持着对Deployment Configurations功能的支持，因为今天仍然存生命周期钩子（lifecycle hooks）等关键功能的需求，这个功能允许在预定义位置将用户行为注入部署过程，而Kubernetes中的Deployments并不支持这个功能。这使得依赖这些功能或重视这种能力的OpenShift客户仍然可以使用这些功能，同时喜欢Deployments的客户也能够利用这些标准的Kubernetes功能。用户可以选择从OpenShift控制台、OpenShift的“oc”命令行（“kubectl”的扩展）或者Kubernetes的“kubectl”命令行来部署他们的应用，另外，客户还可以将它们集成到自己的部署工具中。

对于企业客户而言，他们还需要更多的安全工具来应对他们的应用部署。在镜像扫描、签名等安全解决方案方面，容器生态系统已经历了漫长的道路。但是，很多开发人员仍然在寻找和部署缺乏任何可靠来源、甚至是不安全的镜像，而且这种现象非常普遍。Kubernetes Pod的Security Policy功能旨在定义一组Pod在加入集群系统之前必须执行的条件集，从而提供另一层面的安全性。一个示例策略要求容器必须以非root身份运行，这点很明显，也就说不论你看到这个世上有多少个容器映像，这些映像都不必使用高级权限运行。Pod Security Policy是Kubernetes的新功能，它的灵感来自我们早期在OpenShift中开发的一个具有相同目标的功能，叫做SecurityContextConstraints 。当然，安全并不是开发人员在使用Kubernetes时优先考虑的功能，但是它会是企业管理员的有用工具，尤其是在生产环境中，可以为企业的Kubernetes集群提供更高的安全性。 

这种对安全性和标准的关注，也推动了我们在Linux容器运行时这一层上的工作。我们在Open Container Initiative中的工作帮助推动了容器运行时和镜像格式的标准化，这些镜像格式是无法被单一供应商控制。也就是在那个时候，我们为Kubernetes开发了CRI-O，一个轻量级、稳定且更安全的容器运行时，基于OCI规范并通过Kubernetes Container Runtime Interface集成。

三、在Kubernetes上运行更多的应用负载

我们还与很多企业客户进行了交流，这些客户想要的不仅仅是简单、无状态、云原生应用，而大多数PaaS平台把客户应用限制在了这个级别，事实上企业中普遍存在着更复杂的有状态服务。如果没有持久存储空间，就很难运行有状态服务。于是，我们成立了OpenShift Storage Scrum团队，专注于这个领域，并向上游的Kubernetes存储卷插件贡献代码，并致力于实现有状态服务的不同存储后端。之后，红帽推动了动态存储配置等增强功能，推出了OpenShift Container Storage等创新解决方案，通过Kubernetes容器存储接口（CSI）的引入，进一步对Kubernetes存储供应商的集成进行了标准化。  

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

一旦发现Kubernetes可以为你的应用程序做很多事情，你就会希望把这个能力也用到其他地方。在OpenShift中，与客户直接合作并实现这一目标是我们的自豪。OpenShift 3.0的第一批客户为Kubernetes Jobs和CronJob控制器的开发做出了贡献。与很多创新一样，创新都是源自需求，这些客户要求Kubernetes实现批处理服务，以便其上的应用程序可以实现多次运行或单次运行。Replication Controllers不适合做这个事情，它是为服务的长时间运行而设计的，于是Kubernetes Job控制器应运而生。

开发新的负载功能，不仅推动了我们在过去4年多的时间里持续做出重要贡献，而且还激发了我们今天和未来所做的大量工作。在下一篇文章中，我们将介绍如何使用Kubernetes Operators来实现有状态服务的生命周期管理，以及我们如何为Kubernetes带来全新的功能。

 

四、应用程序外部访问

在Kubernetes中部署应用的目的是为你的用户提供服务，但是用户要能访问到这些应用程序也并非易事。在Kubernetes 1.0中，并没有Ingress的概念，因此如果你使用的是社区上游版本，则将入站流量路由到Kubernetes Pod和Service是一项需要人工参与的任务。在OpenShift 3.0中，我们开发了Routes的概念，以实现针对特定应用请求的自动负载均衡。Routes就是Kubernetes Ingress控制器的前身，今天OpenShift也完全支持Ingress控制器。  

使用Routes或Ingress，你可以将来自群集外部的HTTP和HTTPS访问路由到群集服务中。为什么OpenShift要同时支持两者呢？因为Routes中还有一些功能尚未添加到Ingress中，我们另外的文章已经做了详细介绍。另外，Ingress仍然是Kubernetes的Beta功能，并且可能存在关键性限制，具体取决于Ingress的实现。使客户能够及时访问核心功能，以及在关键任务环境中可靠的长期稳定性，是OpenShift价值主张的核心。

在共享群集环境中，你可能希望每个应用程序只能看到针对它的访问流量。在诸如Flannel这类基本网络解决方案实现了应用程序无隔离扁平网络的同时，OpenShift还实现了Openshift SDN，在我们最早的发布中就完全支持multi-tenant 的SDN。在以多租户模式部署时，基于OpenvSwitch的OpenShift SDN会限制应用程序仅查看其命名空间内的网络流量或来自其他特定命名空间的流量。此外，我们还帮助推动Kubernetes Container Networking Interface，以实现Kubernetes社区丰富的第三方SDN插件生态系统。从那时起，红帽工程师与Google、Tigera和其他的开发人员一起合作，为社区开发出了Network Policy，今天OpenShift完全支持这个功能，同时还将多租户网络隔离功能提高到了一个新的层次，在命名空间、特定服务、端口之间提供了更高级的隔离功能。

 

五、要做的工作还很多

虽然我们为Kubernetes做出了很多令人兴奋的创新，但是仍然有许多工作需要我们去做。尽管OpenShift和Kubernetes自从问世以来在诸多发行版本中得到了不断发展，并且可在生产环境中进行应用程序部署，但是在很多核心领域我们也只能算是初出茅庐，还有很多创新等着我们去做。目前来看，Kubernetes生态系统中还有很多新的供应商加入，我们经常被问到OpenShift有何与众不同，以及OpenShift如何脱颖而出。在这里，我想说的是，OpenShift团队将会一直坚持我们所做的事情：继续倾听我们的企业客户，继续投入Kubernetes社区及其生态系统，继续推动创新，让客户在开放的混合云环境中成功部署和管理应用。后文待续………

 

本文作者：Joe Fernandes，Vice President Of Products, Cloud Platforms Business Unit at Red Hat（乔·费尔南德斯，红帽云平台业务部产品副总裁）