OpenShift&Kubernetes：过去、现在与未来（二）
OpenShift&Kubernetes：过去、现在与未来（二）
乔·费尔南德斯 山金孝 译
译者注：OpenShift4.0迟而未来，背后究竟在憋什么大招？江山易打不易守，K8S平台搭建简单，运营却不易。Prometheus、Grafana、Operators &CRDs、K8S部署更新K8S、主打CoreOS、Over the Air Updates、Istio、Serverless、Knative，这些都要在OpenShift4.0中问世！又是一个大改版本即将到来！
自四年前首次问世以来，Kubernetes项目的发展和创新就一直备受瞩目。本系列第一篇文章中，我们谈到了自Kubernetes项目启动以来，红帽是如何成为Kubernetes的主要贡献者，同时详细介绍了我们所投入的资源以及内部推动这些决策的因素。今天，这样的创新仍在继续，我们对未来依然翘首期盼。在这篇文章中，我将谈一下我们下一步的目标和关注的重点，因为我们还将继续推动Kubernetes和更广泛的云原生生态系统创新，并构建下一代OpenShift容器平台。
从构建平台到运营平台
在最初的几年，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产品路线图的重心。
使用Prometheus和Grafana进行管理和监控
对平台管理员而言，对Kubernetes集群进行监控并在出现故障时发出预警，这是一个极为关键的需求，监控和预警有助于确保平台及应用程序健康运行。虽然红帽早先已决定采用Prometheus，但是CoreOS的加入还是为红帽带来了极为可贵的专业技能，因为CoreOS在Prometheus社区本身有着领导性地位，在今年秋天发布的OpenShift 3.11中，我们推出了原生Prometheus监控、警报和Grafana集成仪表板。这些功能包括默认的Grafana仪表板、对Kubernetes的Prometheus警报定义、安装预配置，这部分功能由Prometheus 监控项目 mixin 开发而来。最后，我们将CoreOS Tectonic控制台与OpenShift控制台进行了集成，旨在为集群管理员提供全面的原生Kubernetes管理体验，从而对OpenShift现有的服务目录（Service Catalog）和以开发人员为中心的界面进行有力补充。
使用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服务自动化管理开辟了一系列新可能，而这一切正是我们所期盼的。
用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平台组件。
在不可变基础架构上部署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。
集群版本隔空更新（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推广“隔空更新”，以便你的群集及其所有内容能够更安全，同时保证集群版本的持续更新。
多集群管理与联合
组织机构一旦考虑开始使用Kubernetes，我们的经验就是，他们的使用量在不断增长，然后会部署多个集群。我们确实看到了这样的情况，随着用户OpenShift集群使用者的增加，他们就会创建新生命周期环境，并在新的数据中心或公有云上部署集群，集群规模从几个到数十个不等。这就是为什么我们一直在多集群（Multi-Cluster）管理和集群联合（Cluster Federation）上加大投入的原因。基于我们在Prometheus和Grafana上所做的集群管理工作，Red Hat致力于将其扩展到多集群环境，多集群可以运行在不同的公有云、私有云、虚拟化平台和裸机环境中。
作为Multi-Cluster SIG的一部分，Red Hat正在贡献的Kubernetes Federation v2项目，就专注于提供跨多集群管理应用部署的功能。这些组件包括一个集群注册表，用于存储和访问所有集群的元数据信息，以及多集群入口、部署和其他相关信息。通过我们在多集群管理和Federation方面的努力，我们的目标是提供更好的工具来实现跨多集群和多云环境的应用运营、管理和部署。
使用Istio在Kubernetes上继续创新
Istio service-mesh是云原生生态系统中基于Kubernetes上面的一个伟大创新。Red Hat也正在为Istio上游做贡献，并会将这项功能带给OpenShift用户。Istio为微服务中基于Envoy的分布式数据平面添加了一个分布式控制平面，Envoy通过轻量级分布式代理路由和管理微服务请求。部分OpenShift客户已经在OpenShift上试用了Istio，在最新的OpenShift 3.11中我也推出了Istio的预览版，同时我们正在为更多的用户提供这个功能。随着用户持续对性能和多租户等核心领域的关注，上游社区还有更多的工作要做，另外，通过Jaeger和Kiali等相关项目，红帽正在推动ServiceMesh的监控和可观察性能力。
从 Microservices到Serverless
今年早些时候推出的Knative，是另一个构建在Kubernetes上的创新。作为Knative工作的一部分，RedHat希望为OpenShift带来开放混合的Serverless功能，并实现Function as a Service （FaaS）。目前，AWS Lambda等FaaS解决方案通常受限于单一云环境。我们的目标是与Knative、Kubernetes社区以及不同的FaaS供应商合作，为在混合、多云环境中构建应用的开发者提供Serverless和FaaS功能。
提供更多的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（乔·费尔南德斯，红帽云平台业务部产品副总裁）