产品分类
您现在的位置: > k8凯发网站 > K8s 编排一切:数据中心已征服虚拟机、大数据、机器学习将俯首称

K8s 编排一切:数据中心已征服虚拟机、大数据、机器学习将俯首称

时间:2019-10-29 02:55 来源:未知 作者:admin 点击:

  原标题:K8s 编排一切:数据中心已征服,虚拟机、大数据、机器学习将俯首称臣

  作者:Scott Fulton III是一名资深科技记者、编辑、作家和教育家,先后出过17本书,写过无数文章。

  自定义资源定义(Custom Resource Definitions,CRD)听起来不仅平淡无奇,还像是地下城主给角色扮演派对带来的角色。但是如果CRD能够吸引数据中心,虚拟机、大数据和机器学习可能很快会发现它们在这个新的开源霸主面前俯首称臣。

  2019年第三个官方版本Kubernetes版本1.16的正式版已于周三晚上发布。一个引人入胜的新问题随之而来:企业数据中心基础设施的每一个部分(不仅仅是那些新颖的容器,还有虚拟机、“大数据”平台以及机器学习框架)都最终会变成由Kubernetes加以编排吗?Kubernetes这个产品最初起源于谷歌需要整治混乱局面。

  我们已经看到Kubernetes迅速干掉了Docker公司。自这家公司力求在开源社区夯实其江湖地位那一天起,Linux基金会旗下的合作机构云原生计算基金会(CNCF)就为自己搭了一个更大的舞台,积极引领容器浪潮。

  在这期间的几个月里,Kubernetes融入到了涉及服务器端软件部署和管理的几乎每个开源和商业平台项目。Red Hat被IBM斥资340亿美元收购之前,重新调整了OpenShift平台。(Red Hat生产一款知名的企业级Linux平台,但IBM已经有一款。)Mesosphere自家的DC/OS平台是围绕老牌的Apache Mesos工作负载编排平台构建的,与微软建立了强大的合作伙伴关系,但它迅速远离Mesos,甚至将公司改名为D2IQ。

  本月早些时候,VMware宣布它已开始启动一个项目,将全球最知名的虚拟化平台vSphere改造为一种基于Kubernetes的另外托管Kubernetes环境的系统,对Kubernetes而言这在其历史上也许可以视作伟大事业的结局。1998年,在Oracle宣布获得Red Hat的认证、成为Red Hat企业操作系统软件供应商的那一刻,Linux的几位开发者就知道自己的项目迎来了转折点。就现在而言,Kubernetes也许早已迎来了属于它的转折点。

  Kubernetes在数据中心站稳了脚跟,它果真会从数据中心扩大到其他领域吗?有了版本1.16,这款编排系统的一个颇具影响力的新组件已正式告别开发阶段。该组件很快让用户需要从公共云获得的服务(数据库、个人定位器、流媒体、汽车驱动程序和跨国公司的会计系统)可以自动自行组装,可能用户甚至浑然不觉。虽然Kubernetes现在已牢牢确立了作为使用“容器”的环境的编排系统这个地位,一项最近备受重视的功能将使Kubernetes有能力编排几乎其余一切资源。容器是在服务器集群中加以处理的紧缩套装功能单位,不过名字取得很差。

  CNCF的执行董事Dan Kohn在接受IT外媒ZDNet采访时说:“我认为,Kubernetes渴望会变得无聊乏味(言外之意:遍地开花),因为它会融入到各个地方,有点像假定的默认技术,就像Linux那样,我觉得这个愿景多半会实现。”

  本月早些时候VMware的工程师们提到了这种新的能力,他们宣布了一个项目,将Kubernetes作为其vSphere虚拟化平台的核心。自定义资源定义(CRD)使Kubernetes能够充当其他资源的编排系统,包括面向Apache Big和Hadoop等“大数据”环境的作业。(的确?6?7?6?7,去年就冒出了一家名为BlueData的初创公司。其目的是配置Kubernetes,以管理Hadoop集群和Spark集群。)

  Jared Rosoff是VMware最近宣布的Project Pacific的产品管理高级主管,他在本月初的VMworld 2019大会期间解释:“Kubernetes拥有自定义资源定义、控制器和operator等概念,这些概念让我们得以为Kubernetes添加新的对象类型。于是我们想,如果我们使用Kubernetes的这个方面来构建一种新的云平台,将会怎么样?如果我们使用同样这种预期状态模式来管理Kubernetes集群、虚拟机[VM]、Serverless应用程序和数据库,将会怎么样?”

  Rosoff在这里谈论的是什么?Kubernetes编排系统已经从配置管理领域借鉴了一个关键部分,具体来说是像Puppet和Ansible这样的声明式风格:它让应用程序可以指定需要从托管它的数据中心基础设施获得什么样的资源。这个规范是一种声明,这就是为什么我们说Puppet及其他工具使用声明式风格。它只需列出需求,把提供尽可能多的那些资源这项任务交给编排系统,而不是像传统脚本通常所做的那样,编写一套明确的指令来规定如何组装和配置这些资源。

  以Kubernetes为例,这就如同只要为其编写脚本,就能够创建整个服务器网络。设想一下:编剧只需编写剧本,把按剧本拍电影这项任务交给某家后端服务提供商。

  但这是Kubernetes一开始(不是很久以前)就拥有的一项功能。CRD今天已成为官方组件,它清楚地表明了这整个概念:Kubernetes组装的是什么、用于何种目的。它使得Kubernetes编排系统可以配置第一代虚拟机,取代了传统vSphere控制台上涉及众多步骤的流程,还通常需要拥有通过VMware官方认证的技能的IT操作人员。

  Rosoff继续说:“如果我想要一个Kubernetes集群,编写了Kubernetes风格的声明性状态文档,文档称‘我想要有一个拥有五个节点的Kubernetes集群,运行版本1.15,将会怎么样?如果我想要一个虚拟机,编写了Kubernetes风格的声明性状态文档,文档称‘我想要运行拥有这么多CPU和这么多内存的这个设备映像,将会怎么样?如果我想要一个数据库,可以说‘我想要有一个MySQL数据库实例,有这么多内存和这个版本的MySQL,将会怎么样?’我们可以在Kubernetes中做到这一点,我们已经做到了。”

  对于为Kubernetes项目贡献代码的开源开发人员而言,CRD概念存在已有一段时间。就在两年前,CRD作为1.7版本中的一个beta测试版组件,首次在公众面前亮相。那时候,谷歌工程师Tim Hockin在接受IT外媒The New Stack采访时向我解释,他和其他贡献者认为Kubernetes正在演变成一个“生态系统中心”。换句话说,它没必要总是关注Docker式样的容器,只要“资源”被抽象地定义,更是如此。Kubernetes可能会成为“资源编排系统”,每个数据中心的职责就是确定这个资源在各自独特的环境下的具体含义。

  从Jared Rosoff的描述来看,这似乎几乎就是正变成现实的一幕,至少在VMware是这样。在Kubernetes的架构中,一个名为控制器的组件监控系统的活动状态,并负责确保该状态尽可能接近每个运行中工作负载的“预期状态”。换句话说,控制器负责满足每个工作负载的要求。这些要求通常按照可用资源来加以指定——工作负载需要履行其功能的组件。如果Kubernetes在管理Hadoop集群而不是容器集群,它就需要为新的环境重新定义“资源”。这就是CRD的作用。

  自定义资源要在这个新的环境下可供使用,必须添加自定义控制器。Kubernetes称这些专用组件为operator;是的,这个名称让人一头雾水,因为IT部门的人员也叫“operator”。但正如最近更新的Kubernetes文档表明,这正是问题的关键。编排系统中的operator在非自动化环境下实际上做的是要求人员做的工作。

  CNCF的Dan Kohn提到Kubernetes变得无处不在、无聊乏味后会发生什么这个问题时说:“我认为,大家可能期望,上游会出现创新和令人兴奋的动向。可能是服务网格,也可能是一些身份验证技术,或者是人们为之兴奋的operator这整个方面——数据库管理员做的许多事情,比如升级、安全和调优,你可以把这些做入到软件中,让operator为你运行数据库,几乎就像以前雇用DBA一样。”

  Kubernetes使这项任务:将容器部署到托管平台上实现自动化后,手动部署那些容器的工作几乎不存在。在CoreOS(现在隶属IBM旗下的Red Hat)和Pivotal(现在隶属Dell旗下的VMware)等供应商为自己实现自动化之前,IT部门还不得不全面了解这项技能。但数据库管理员对于日常工作中相对缺乏自动化再熟悉不过了,这可能是近几个月对大数据的热情暂时消失的一部分原因。Kohn表示,在CRD的帮助下,被视作针对数据中心一个方面的出色升级的这同一项新功能可能会在其他地方掀起革命,包括企业管理员为员工配置服务的方式。

  在6月于上海举行的CNCF赞助的一次大会上,Pivotal的两位工程师Ed King和Sam Gunaratne上台描绘了一个虚构的、不过令人印象深刻的画面:Kubernetes借助CRD使它通常无法实现自动化的某些东西实现自动化:家里的灯、锁和恒温器。不,这不是基于容器的物联网控制器的编排,而是使用Kubernetes API来实现夜间自动开灯、锁门以及调高或调低温度。这并非不可能——如果自定义控制器(其他Kubernetes工程师称之为“operator”)与这些家用电器直接联系起来,并非不可能。

  在这个假想的世界中,清单(manifest)可以声明房主希望管理两只灯泡的亮度状态。专用于灯光的控制器可以将当前状态与期望状态进行比较,如果这是清单为这些灯泡声明的状态,它就会激活让灭掉的灯泡亮起来所必需的一系列事件。

  这时候变得有意思起来:如果这个假设系统中的控制器有办法彼此联系,针对恒温器的控制器也许能够与控制器共享详细信息,比如一天中的时间。然后可以使用灯光控制器,而决策工具表明何时运用该预期状态最合适。不像物联网中控制器和设备之间典型的一对一关系,编排系统将充当智能中心。

  如果这一切听起来让科技出版物觉得太过乏味、激动不起来,不妨设想一下两只家用灯泡与整座城市的交通信号灯系统之间在规模上的差异。自定义控制器的自动化包括共享状态的功能,它会带来更智能、更顺畅的交通模式。简化诺基亚电话平台的同一逻辑可以用来简化市中心的交通流量。

  VMware的Rosoff说:“这样一来,我们对于开发人员/用户与我们的云进行交互的体验的认识完全发生了改变。如果你想想这方面有什么替代方法,有OpenStack之类的替代方法。OpenStack给人的感觉不像是我们数据中心的未来。”

  如果你稍加留意的话,会发现你听到的为OpenStack混合云平台所敲的那口钟(Jared Rosoff刚敲响了这口钟)正是为Mesos所敲的同一口钟。

  k8s 技术社群欢迎加入,群主微信:guanhongyan1023(备注任职单位+职位,否则不予通过)返回搜狐,查看更多