【云计算】OpenShift和Kubernetes：过去、现在与未来、2019 Kubernetes 六大趋势预测

2019 年 2 月 17 日 产业智能官

原创：山金孝翻译 OpenShift开源社区

译者注：对企业客户而言，容器云平台选择OpenShift还是Kubernetes，二者究竟是什么关系，红帽VP乔·费尔南德斯对二者做了总结、回顾与展望，看完这两篇文章，也许你对越来越多的企业客户为何选择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（乔·费尔南德斯，红帽云平台业务部产品副总裁）

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

译者注：OpenShift 4.0迟而未来，背后究竟在憋什么大招？江山易打不易守，K8S平台搭建简单，运营却不易。Prometheus、Grafana、Operators &CRDs、K8S部署更新K8S、主打CoreOS、Over the Air Updates、Istio、Serverless、Knative，这些都要在OpenShift4.0中问世！又是一个大改版本即将到来！

自四年前首次问世以来，Kubernetes项目的发展和创新就一直备受瞩目。本系列第一篇文章中，我们谈到了自Kubernetes项目启动以来，红帽是如何成为Kubernetes的主要贡献者，同时详细介绍了我们所投入的资源以及内部推动这些决策的因素。今天，这样的创新仍在继续，我们对未来依然翘首期盼。在这篇文章中，我将谈一下我们下一步的目标和关注的重点，因为我们还将继续推动Kubernetes和更广泛的云原生生态系统创新，并构建下一代OpenShift容器平台。

1.从构建平台到运营平台

在最初的几年，Red Hat对Kubernetes的目标，就是构建一个生产级的新一代Linux容器平台，这本身也是对Linux的扩展。正如我们打造了世界领先的企业级Linux平台RedHat Enterprise Linux一样，我们致力于将RedHat OpenShift打造成为企业Kubernetes的标准。我们还专注于建立开放的社区容器标准，并通过协助发起CNCF、Open Container Initiative，提出供应商中立治理理念来保护这些标准。

虽然Kubernetes平台仍然在持续发展，但在过去的一年中，我们的关注点更多的在于如何在整个堆栈中运营平台，从底层基础架构到上层应用程序。再一次，我们从企业客户那里找到了方向，这些客户安装、升级和管理着很多OpenShift Kubernetes集群，并依赖这些集群运行着关键任务生产应用。这也是我们今年早些时候决定收购CoreOS的主要动因，我通常将这次收购看成是红帽针对Kubernetes，在运维管理和自动化操作方面做出的2.5亿美元投资。从构建平台到运营平台，这一关注点一直是我们在2018年、2019年及以后多年中OpenShift产品路线图的重心。

2.使用Prometheus和Grafana进行管理和监控

对平台管理员而言，对Kubernetes集群进行监控并在出现故障时发出预警，这是一个极为关键的需求，监控和预警有助于确保平台及应用程序健康运行。虽然红帽早先已决定采用Prometheus，但是CoreOS的加入还是为红帽带来了极为可贵的专业技能，因为CoreOS在Prometheus社区本身有着领导性地位，在今年秋天发布的OpenShift 3.11中，我们推出了原生Prometheus监控、警报和Grafana集成仪表板。这些功能包括默认的Grafana仪表板、对Kubernetes的Prometheus警报定义、安装预配置，这部分功能由Prometheus 监控项目 mixin 开发而来。最后，我们将CoreOS Tectonic控制台与OpenShift控制台进行了集成，旨在为集群管理员提供全面的原生Kubernetes管理体验，从而对OpenShift现有的服务目录（Service Catalog）和以开发人员为中心的界面进行有力补充。

3.使用Kubernetes Operators & CRDs管理服务

CoreOS推出的另一项创新，是在2016年发布的用于管理在Kubernetes集群服务的Operator 模式。正如Brandon Phillips所描述的那样，Operator 是“一个特定于应用的控制器，它扩展了Kubernetes API，代表Kubernetes用户创建、配置和管理复杂有状态应用实例”。今年早些时候，在KubeCon Europe大会上，Red Hat和CoreOS推出了Operator 框架，以加速和标准化Kubernetes Operator 的发展。在OpenShift 3.11中，我们针对Red Hat和ISV合作伙伴的应用服务，首次推出了基于Operator 服务预览。

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

Operator 充分利用了Kubernetes Custom Resource Definitions （CRDs）的优势，CRDs是由RedHat主导开发的一项重要功能。自定义资源是Kubernetes API的扩展，CRD允许你定义这些资源。作为Kubernetes API自身的扩展，RedHat推动并引领着CRD的开发，以便在OpenShift中构建更多集成扩展功能。上一篇文章中我们对部分扩展功能进行了介绍。这一功能还允许其他贡献者构建他们自己的Kubernetes扩展，同时这有助于保持Kubernetes内核的精简。借助利用CRDs的Operator ，在Kubernetes上运行的复杂有状态服务同样成为了Kubernetes API的扩展，这为Kubernetes服务自动化管理开辟了一系列新可能，而这一切正是我们所期盼的。

4.用Kubernetes安装升级Kubernetes

Kubernetes通过强大的声明性语言自动化管理容器化应用。不幸的是，Kubernetes没法以相同的方式管理自己以及自身所依赖的底层基础架构。 OpenShift上游OKD社区正在开发OpenShift installer ，在OpenShift 4中将会推出，其主要目的在于将与集群相关的各个方面都置于Operator 控制之下，包括控制平面及其底层基础架构。

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

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

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

OpenShift 4 installer将会管理由RedHat CoreOS提供的不可变Linux容器主机，同时还会管理运行OpenShift的底层云或数据中心基础架构配置。我们将在Kubecon和OpenShift Commons Gathering for AWS会议上展示这项功能，然后将全栈自动化管理推广到基于OpenStack、Azure、Google云平台、裸机环境、VMWare、红帽虚拟化的Openshift平台，以及其他供应商提供的可运行OpenShift Kubernetes集群的基础设施上。

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

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

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

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

7.多集群管理与联合

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

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

8.使用Istio在Kubernetes上继续创新

Istio service-mesh是云原生生态系统中基于Kubernetes上面的一个伟大创新。Red Hat也正在为Istio上游做贡献，并会将这项功能带给OpenShift用户。Istio为微服务中基于Envoy的分布式数据平面添加了一个分布式控制平面，Envoy通过轻量级分布式代理路由和管理微服务请求。部分OpenShift客户已经在OpenShift上试用了Istio，在最新的OpenShift 3.11中我也推出了Istio的预览版，同时我们正在为更多的用户提供这个功能。随着用户持续对性能和多租户等核心领域的关注，上游社区还有更多的工作要做，另外，通过Jaeger和Kiali等相关项目，红帽正在推动ServiceMesh的监控和可观察性能力。

9.从 Microservices到Serverless

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

10.提供更多的Kubernetes服务

当然，FaaS和Serverless依赖于访问后端服务，这些服务由你的应用函数自动触发。我们看到客户在Kubernetes上运行着各种应用和扩服务，包括数据库、分析、机器学习等。最近一个例子，就是Red Hat与Nvidia等合作伙伴共同展开了合作，以便在Kubernetes中提供基于GPU的服务。这部分工作由Kubernetes资源管理工作组和各种社区SIGs来实现，目的是支持性能敏感的工作负载、新的硬件设备，同时将Kubernetes带入更广泛的应用场景。另一个例子，就是Red Hat正在推动Kubevirt项目的工作，使Kubernetes能够将基于传统虚拟机的服务和基于容器的服务进行协调管理。

通过支持混合云基础架构、混合服务以及无服务器和FaaS等新的开发范例，用户应该能够利用函数和服务来构建跨数据中心和多个公有云环境的应用程序。通过OpenShift，Red Hat致力于与我们自己的开发人员、合作伙伴ISV和公有云供应商合作，从而为用户提供最为广泛服务选择。

结论

一些研究员认为，经过4年多的努力，Kubernetes的创新步伐将放缓。事实上，我相信创新正在加速，正如我在这里所描述的一样。红帽将继续致力于推动Kubernetes和Cloud Native生态系统的创新，与客户和开源社区合作，通过OpenShift，以开放、混合、更安全和全支持的方式带来创新。

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

2019 Kubernetes 六大趋势预测

展望2019年，Kubernetes、容器和云平台行业将何去何从。以下是我们对未来的几个预测。

1、Kubernetes和容器走向应用普及。与底层云供应商无关的自动化操作时代正在到来

Kubernetes于2014年开源并被企业团队用于生产环境中，现在已被普遍接受和认可。Kubernetes正在进入第三个发展阶段，这也意味着，用户正在寻求各种方法来实现Kubernetes在生产环境中的自动化运维操作。运维团队将会寻求实现服务供应商级别的服务质量，例如自动更新、自动备份、自动扩展和自我调节，以便在任何环境中都可以实现高可用，而不管是在云供应商的基础架构设施上，还是在他自己们的私有环境中。

在2019年，针对Kubernetes的自动化运维管理操作将会越来越多的表现为Operators ：Operators 将工程师对特定应用或服务的操作、知识和理念组织为代码软件。这种方式有助于将操作流程以代码方式编入Kubernetes原生基础架构和在其上运行的服务中，从而提供一种更为有效的方式来管理大规模的Kubernetes原生应用。更重要的是，操作流程的编码工作由特定领域的资深专家实现，他们对这些基础设施和服务本身具有丰富的实践经验。

在OpenShift 3.11中，我们已经逐步看到了这种趋势，在3.11中，我们为MongoDB、Redis、PostgreSQL、Couchbase、etcd和Prometheus实现了第一版Operators 。这些Operators 中包含着来自各个厂商及其背后的专家们多年来辛苦积累的操作使用经验。2019年，随着RedHat OpenShift 4.0的潮流引领，我们将看到这种模式会不断扩展到Kubernetes各个领域和数百种不同的服务中，归功于Operators ，这些服务将可以实现横跨不同基础架构的自动化操作。

越来越多的向自动化操作转变的需求，代表了容器原生基础架构服务的第三波浪潮，在这一阶段，运维团队开始考虑在一次变更中就实现跨群集的第三方工具部署，而不是通过配置扩展和随着时间推移的系统自定义来逐步滚动扩展服务。

2、Federation V2将使多云更容易。

云原生计算基金会（CNCF）内部关于Federation 的最新工作就是Federation V2，它解决了由于之前的集群编排问题遗留下来的许多用例挑战。其中一个挑战，就是与地理位置或底层基础架构无关的跨群集联合身份和工作负载。随着Federation V2的成熟和采用，在不同基础架构和云提供商之间运行多个集群将会变得更加容易。

3.Serverless与Kubernetes结合，2019年将成为Serverless混合元年。

2019年，将是Serverless，尤其是 Functions-as-a-Service（FaaS），摆脱单一云供应商并走向更广更深的一年。在广度上，由于开发人员不仅可以在他们选择的云供应商平台上使用他们的FaaS，而且还能够将Serverless范例扩展到函数之外和他们喜欢的堆栈中：例如，SpringBoot的API调用实现可以基于Serverless实现，以便它仅在其API调用时执行，否则缩放到零完全不执行。在深度上，Serverless函数和应用背后的事件源将扩展到产生各种服务的异构生态系统，而不是受限在今天的云服务供应商所提供的Serverless应用集中。

虽然FaaS已成为开发人员工具箱中的标准工具，但目前来看，每个Serverless环境本身仍然还是一个孤岛。另外，由于引入了允许在Kubernetes中执行无服务器计算的Knative，因此平台之间的巨大分歧将会开始减弱。

4. Kubernetes将实现容器和虚拟机的混合操作......它将采用裸机。

以前，我们认为虚拟机是“旧世界”，容器和Kubernetes原生应用才是“新世界”。2019年，这种看法将会发生变化，因为 Container-native Virtualization （由KubeVirt实现）等项目的出现，使得在以虚拟机为中心和以Kubernetes为中心的基础设施之间做出选择变得没多大意义。

随着Kubernetes在企业中占据一席之地，它为生产负载提供了更为灵活和可扩展的运行模式，但是要求应用运行在Linux容器中。在2015-2018年间，这意味着Kubernetes主要用于新开发的应用或者重新设计后的应用场景中。随着容器原生虚拟化的出现，情况将会有所改变，容器原生虚拟化使得虚拟机能够遵循与Kubernetes原生应用相同的工作流程。通过打破新旧应用之间的与运维管理隔阂，企业将能够更有效地整合运行管理，在保留现有的IT技能的同时，仍然可以去拥抱基于Kubernetes的现代基础设施。

此外，虚拟机和Linux容器之间的这种平衡创新将为裸机服务器做好准备。过去，虽然现代化的基础架构需要复杂的虚拟化堆栈，但是随着Kubernetes在裸机上运行的发展进步，企业将能够充分利用直接在裸机服务器上部署Kubernetes所带来的更高速度和效率。

5、开源社区开发人员将以Kubernetes为默认目标。

随着Kubernetes在很多主流云平台上开始变得可用，我们也慢慢看到开源社区的开发人员将他们的项目优先定向Kubernetes靠拢。虽然2018年的大部分时间里Kubernetes发展迅速并且看到了许多新的贡献者和项目，但2019年很可能会看到更多的整合以扩大Kubernetes周边生态系统。针对Kubernetes来进行项目开发的社区包括Trillian、Source Graph和GraphQL（Apollo和Hasura）。

6、我们将看到一些工作负载开始回到数据中心。

开发人员将能够利用来自广泛社区和供应商生态系统越来越多样化的服务，并通过自动化的操作，使得自身应用像任何云服务一样易于访问和操作。这种趋势，加上不断来自云供应商基础设施使用的账单压力，CIO们将不得不认真考虑他们在云上的工作负载，在某些情况下，甚至会考虑将在公有云上运行的工作负载迁回本地数据中心运行以减少成本，同时仍然能够保持自动化的好处。值得庆幸的是，Kubernetes原生基础架构给了CIO们一个选择，使得他们在优化云服务和资源使用的同时，仍然可以实现服务的可用性、弹性和安全的目标。

总而言之，看到Kubernetes和混合云生态系统将会发生的事情，我们对未来的发展感到很兴奋。作为基于Kubernetes的Red Hat OpenShift平台开发者，我们一直在与已经开始交付他们的下一代应用的早期用户进行合作。现在，是时候让更多人跨越鸿沟，使用Kubernetes、Operators等技术，在2019年让我们的创新更上一层楼！

工业互联网

产业智能官 AI-CPS

加入知识星球“产业智能研究院”：先进产业OT（工艺+自动化+机器人+新能源+精益）技术和新一代信息IT技术（云计算+大数据+物联网+区块链+人工智能）深度融合，在场景中构建状态感知-实时分析-自主决策-精准执行-学习提升的机器智能认知计算系统；实现产业转型升级、DT驱动业务、价值创新创造的产业互联生态链。