• <dl id="n7sq3"></dl>

        1. 资讯中心

          百度熊掌号

          2019年的云原生市场:K8s周边创新不断,技术生态得到完善

          2019-03-18 09:07:17来源:至顶网 阅读量:20819

          导读:Operator是基于Kubernetes扩展机制,将运维知识编写成“面向应用的Kubernetes原生控制器“,从而将一个应用的整体状态作为API对象通过Kubernetes进行自动化管理。
            【中国智能制造网 市场分析】历史进入2019年,放眼望去,今天的整个技术大环境和生态都发生了很大的变化。在己亥猪年?#33322;?#21018;刚过去的早春时节,我们来梳理和展望一下整个云原生技术趋势的发展,是一件很有意义的事情,这其中?#34892;?#21464;化在不可避免地影响着我们身处其中的每一家企业。
          2019年的云原生市场:K8s周边创新不断,技术生态得到完善
           
            如果说云原生在2017年还仅仅是冒出了一些苗头,那么2018可?#36816;?#26159;普及之年,云原生变成了一个成熟的、被普遍接受的理念。
           
            早在1991年Jeffery Moore针对高科技行业和高科技企业生命周期的特点,提出了著名的“鸿沟理论”。这个理论基于“创新传播学”,将创新性技术和产品的生命周期分为五个阶段:创新者(Innovator)、早期使用者(Early adopters)、早期大众(Early majority)、晚期大众(Late majority)、落后者(Laggard)。
           
            在Early adopters和Early majority之间有个巨大的鸿沟(Chasm),每个新技术都会经历鸿沟,大多数失败的产品也都是在鸿沟里结束了其整个生命周期,能否顺利跨越“鸿沟”,决定了创新性技术的成败。今天我们尝试以鸿沟理论为基础来分析云原生领域颠覆性的创新技术。
           
            Kubernetes:边缘创新有亮点
           
            Kubernetes在2017年底成为容器编排事?#24403;?#20934;,之后?#20113;?#20026;核心的生态?#20013;?#29190;发,在传播周期上可?#36816;?#24050;经跨过鸿沟了,进入Early majority早期大众阶段,开始占领潜力巨大的主流市场。
           
            根据CNCF在2018年8月进行的第六次测量容器管理市场的温度,83%的受访者更?#19981;禟ubernetes的容器管理工具,58%的受访者在生产中使用Kubernetes,42%的受访者正在进行评估以备将来使用,40%的企业(员工规模在5000+)正在使用Kubernetes。Kubernetes在开发人员中已经变得非常流行。
           
            进入主流市场的Kubernetes开始变得“Boring”,这很正常,甚至是一个好的现象。核心项目的创新速度会减慢,最新的版本中主要关注点聚焦在稳定性、可扩展性这些方面,尽可能把代码从主库往外推,让它的主库变得干净,其他功能通过一些扩展机制来做,同时开始关注安全性。
           
            Kubernetes项目本身已经过了现象级创新爆发的阶段,但由Kubernetes独特的架构属性催生出的周边生态的二次创新仍然在高速发展,例如诸多与Kubernetes集成或者基于Kubernetes框架开发的上层服务与平台。这个话题我们下次讨论,今天还是主要关注与Kubernetes项目关联最紧密的创新亮点:
           
            早期容器化workload大多聚焦在无状态服务,跑的最多的是Nginx,而对有状态应用避讳不谈。现在Kubernetes进入主流市场,显然需要对“现实中的应用”,包括有状态服务提供?#24049;?#30340;支持。2019年,对于复杂应用的管理以及Kubernetes本身的自动化运维将会更多的表现为Operator。
           
            Operator是基于Kubernetes扩展机制,将运维知识编写成“面向应用的Kubernetes原生控制器“,从而将一个应用的整体状态作为API对象通过Kubernetes进行自动化管理。这个应用通常?#27492;?#26159;比较复杂的有状态应用,如MySQL数据库、Redis集群、Prometheus等?#21462;?#29616;在基本上常见的有状态应用都有自己相对应的Operator,这是一种更为?#34892;?#30340;管理分布式应用的方式。
           
            其次是应用跨集群部署与管理。早期社区里有Federation联邦集群的方案。不少大金融客户都有跨集群部署、管理业务的需求。当时深入研究Federation v1之后,觉得这个方案复杂度高,观点性强,对于?#23548;?#30340;需求灵活度不足而又不够成熟。所以最终选择自研跨集群部署。后来出现的Federation v2在设计方向上有不小改观,是需要?#20013;?#20851;注的项目。
           
            早期采用容器技术的用户都会尽可能兼容企业原有的IT基础设施,比如底层物理机,保留物理机之上的虚拟层,虚拟机之上再跑容器。当然,面向资源管理的硬件虚拟化和面向应用的容器化本质上没有冲突。随着Kubernetes的普及并且在应用上超越了容器编排的范畴,后Kubernetes时代如何搭建管理基础设施是值得思考的。我们也观察到一些有意思的趋势,比如在Kubernetes上同时管理容器和虚拟机(所谓的“容器原生虚拟化”),或是使用Kubernetes来管理OpenStack。
           
            总之,Kubernetes在云计算领域成为既定标准,会越来越多的往下管理所有种类的基础设施,往上管理所有种类的应用。这类标准的形成对于技术社区有很大的益处,会大大降低围绕Kubernetes技术投入的风险。因此,我们会看到越来越多的周边技术向它靠拢,在Kubernetes之上催化出一个庞大的云原生技术生态。
           
            DevOps:开放式工具链集成与编排
           
            DevOps理念、方法论和?#23548;?#24050;经走到了Early Majority早期大众阶段,是已被?#23548;?#35777;实的高效开发运维方法。做容器的厂商都经历过用容器搞CI/CD,CI/CD是容易发挥容器优势的显而易见的使用场景。
           
            DevOps包含好?#35206;?#27010;念,首先是组织?#24149;?#30340;转变,然后涉及到一系列最佳?#23548;?#26368;终这些最佳?#23548;?#38656;要用工具去落地。我们在帮助很多大型企业客户落地DevOps的过程中发现:
           
            1. 在DevOps的整个流程里涉及到很多类别的工具,每一个类别都会有大量的选择;2. 每个客户的工具选型多少会?#34892;?#19981;同,并不存在一个固定的、完全标准的工具组合;
           
            3. 随着时间的推移工具选择会发生变化,多数客户意识到目前使用中的工具在未来很可能会被替代。
           
            基于这些观察,DevOps有一种做法是,打造开放式的DevOps工具链集成与编排平台。这个平台可以灵活的兼容客户的工具选型,通过集成将各类工具串联起来,形成一套工具链,通过编排让DevOps工具?#20174;?#23481;器平台联动,形成一个完整?#20302;场?#21516;?#20445;?#19981;断结合自身的经验,提炼DevOps落地的最佳?#23548;?#24179;台将这些最佳?#23548;?#33258;动化,作为服务进行输出。
           
            同?#20445;珼evOps工具链的编排也最好基于Kubernetes来实现。Kubernetes不仅是出色的容器编排工具,扩展之后也很适合编排DevOps工具。换句话说,可以打造一套“Kubernetes原生的DevOps平台”。
           
            微服务:落地需要一套完整的基础设施
           
            提起微服务治理,很多人会条件反射般的联想到某些特定的技术,例如Spring Cloud,或者Service Mesh。我们不妨先退后一步,?#20302;晨?#34385;下企业微服务架构改造和落地所需要的完整的基础设施。
           
            首先,在微服务应用的底层需要一个应用管理平台,这在今天毋庸置疑是一个基于Kubernetes的容器平台。微服务本质上是分布式应用,在我们获取敏捷性的同时不可避免的增加了运维和管理的?#35759;取?#24494;服务对自动化运维,尤其是可观测性的要求很高。支持微服务架构的基础设施必须具备完善的监控、告警、日?#23613;?#20998;布?#38454;?#36394;等能力。
           
            在微服务应用的前方,通常需要一个API网关,来管理对外暴露的API。API治理策略,包括安全、路由、流控、遥测、集成等对于任何应用平台都重要,但在微服务架构下尤为关键。我们需要通过定义、封装对外API来屏蔽应用内微服务组件结构细节,将客户端与微服务解耦,甚至为不同客户端提供个性化的API。
           
            云原生应用的一大准则是应用与状态分离。在微服务架构下,每个微服务组件更是应该完全掌控自己的数据。所以,云原生应用通常依赖外部数据服务(Backing Services),而在微服务架构下,多元化持久性(Polyglot Persistence)是常态,也就是说一个微服务架构的应用会依赖非常多种类的 Backing Services。面向微服务架构的基础设施需要将这些外部服务暴露给微服务应用消费,甚至直接支撑各类Backing Services 的部署和管理。
           
            一个团队之所以采用微服务架构,一定有敏捷性的诉求。所以通常微服务团队?#19981;嵊当evOps理念。一个完善的面向微服务架构的基础设施需要考虑 DevOps 流程以及工具链的自动化。
           
            最后,我们回到狭义的微服务治理,这里关注的是微服务组件之间的连接与通讯,例如服务注册发现、东西向路由流控、负载均衡、熔断?#23548;丁?#36965;测追踪?#21462;?#29616;在有个时髦的术语来描述这类功能,就是大家熟悉的Service Mesh。其实早期 Sping Cloud 之类的框架解决的是类似的问题,但在实现的方式上,尤其是mesh 和业务代码的耦合度上,有本质的区别。
           
            当我们考虑一个平台如何支撑微服务架构的时候,需要涵盖上述提及的方方面面,从产品的角度我们会保持一个开放的态?#21462;?#36825;其中一部?#20013;?#35201;我们自己去做,其他一些可以借助生态合作伙伴的能力去补全完善。
           
            此外,微服务架构也进入到了后Kubernetes时代,早期基本上是微服务作为用例推动容器技术的发展。今天已经反过来了,成为标准的Kubernetes其实在驱动和重新定义微服务的最佳?#23548;?#23481;器和Kubernetes为微服务架构的落地提供了绝佳的客观条件。
           
            Service Mesh:下一个亟待爆发的现象级技术创新
           
            ?#21040;?#23545;于Service Mesh的布道已经?#20013;?#20102;一段时间,我们今天不再重复基本的概念。当我?#21069;裇ervice Mesh和上一代以Spring Cloud为代表的微服务治理框架以及更早的Service Oriented Architecture (SOA) 作比较的时候,会看到一个有意思的演化。
           
            我们知道,SOA有企业服务总线(ESB)的概念,ESB重且复杂,其实会混杂很多业务逻辑。SOA架构下,ESB最终容易变成架构以及敏捷性的瓶颈。早期推广微服务架构的时候,一个重要的概念就是“Smart Endpoints and Dumb Pipes”,针对的就是SOA下ESB的痛点,从而每个微服务能?#27426;?#31435;、自治、松耦合。
           
            但是仔细去想的话,就会发现它其?#24213;?#21040;了另一个极端?#26680;?#25226;一些基础设施提供的能力放到微服务的业务组件里面了,通常每个组件需要加载一些治理框架提供的库,或是调用特定的API,其实就是在业务组件里内置了基础设施的功能。到了Service Mesh其实又把它们分开了,从架构角度这样也比较合理,应用是纯业务的东西,里面没有任?#20301;?#30784;设施,而提供微服务治理的基础设施,要么在Mesh里面,要?#20174;?#24213;层的Kubernetes平台来提供,对应用是?#35813;?#30340;。
           
            Istio的出现促使?#21040;?#23545;于Service Mesh的架构有了新的共识:控制平面(Control Plane)与数据平面(Data Plane)解耦。通过独立的控制平面可以对Mesh获得全?#20013;?#30340;可观测性(Observability)和可控制性(Controllability),让Service Mesh有机会上升到平台的高?#21462;?#30456;对于需要在业务代码层面使用的上一代微服务治理框架,这点对于希望提供面向微服务架构基础设施的厂商,或是企?#30340;?#37096;需要赋能业务团队的平台部门都具有相当大的吸引力。
           
            在Data Plane,Envoy的领导者地位毫无争议。Envoy使用C++开发,在资源使用效率和性能上(尤其是长尾性能差异)相较早期主要竞争对手Linkerd有明显优势。Envoy提供基于filter chain的扩展机制,从Kubernetes的成功当中我们已经学习到,可扩展性对于大规模采用十分关键。
           
            Envoy定义了一套“通用数据平面API”(Universal Data Plane API),也就是它的xDS协议。不仅确保了Envoy本身的动态可配置性,更重要的是为Service Mesh中Control Plane和Data Plane解耦提供了一个标准的接口。由于主流Control Plane(例如Istio)对Envoy以及xDS的采纳,xDS成为Service Mesh Data Plane API的事?#24403;?#20934;,Envoy也成为无可争议的Data Plane领导者。
           
            在Control Plane,Istio是最具光环的明星?#26029;?#30446;。它正在引领Service Mesh创造出一个全新的市场,不过从传播周期看现在还没有跨过技术鸿沟,处于Early adopters阶段。
           
            过去一年中,Istio项目在技术上的表现并不完全令人满意,主要体现在?#20113;?#22797;杂度的?#35206;。?#20197;及稳定性和性能的质疑。1.0版本的推出并没有完全令人信服。不过,这些似乎并不影响Istio在社区获得的巨大成功。在开源领域,并不存在对Istio有实?#24066;?#23041;胁的竞品。可能在经历了Kubernetes之后,以及Istio早期?#35813;?#30340;发展和在社区中巨大的影响力之下,很少有开源项目愿意在Control Plane和Istio正面?#29615;妗?br /> 
            长远来讲,Data Plane会慢慢变成commodity,尤其在有了Universal Data Plane API之后。我们有理?#19978;?#20449;成熟稳健的Envoy会保?#33267;?#20808;,但最终多数用户会越来越少去关心具体的Data Plane技术。这个情境似曾相识,和当初Docker与Kubernetes的关系有点类似。
           
            下个阶段Service Mesh的赋能和创新会更多聚焦在Control Plane。AWS在Data Plane选择成熟的Envoy,而自己开发App Mesh的Control Plane,就很容易理解。灵雀云已经在ACE/ACP两条产品线中集成了Istio,提供企业就绪的Service Mesh。
           
            云原生为机器学习输出工程化最佳?#23548;?/strong>
           
            云原生的理念与相关技术对于应用开发与交付的巨大价值已经被普遍接受。但云原生不仅仅可以作用在普通的应用开发上。站在容器平台的角度看,机器学习毫无疑问是一类极为重要新兴工作负载。在未来,可能所有的公司都会是AI公司,所有的应用都会是智能应用,使用算法、模型就像今天应用会依赖数据库一样普遍。
           
            如果我们分析数据科学家的工作流,会发现和传统应用开发有很多相似的挑?#20581;?#22914;何方便的获取实验环境;如何让实验可重复;如何将数据处理、特征提取、模?#33073;?#32451;、模?#33073;?#35777;、模型发布这些步骤自动化,并且可重复;如何让研究和生产环境保持一?#25314;?#22914;何在生产环境做模型变更、AB测试、灰度发布;如何在生产环境运维模?#22836;?#21153;;如何将模?#22836;?#21153;化,等?#21462;?br /> 
            在软件工程领域,云原生的理念、方法论和最佳?#23548;?#24050;经为类似问题找到了?#24049;?#30340;解决方案。这些方案其实非常适合应用在机器学习场景。换句话说,我们需要“云原生机器学习”。这仍然是一个相对早期的概念,从鸿沟理论的周期来看,云原生机器学习大致还处在Innovators创新者尝鲜的阶段。
           
            进入2019年,巨大的增长空间和发展势头等待着已成事?#24403;?#20934;的Kubernetes和容器技术继续开疆拓土,落地到各种业务场景中;DevOps一片蓬勃人气不减,通过打造开放式DevOps工具链集成与编排平台,形成完整的工具链,将最佳?#23548;?#36755;出给客户;微服务进入到后Kubernetes时代,Service Mesh技术日渐成熟,落地将成为新的重点。
           
            云原生技术不再曲高和寡,高处不胜寒,成为?#30340;?#20027;流标准取舍的关键。今天我们提到的上述云原生技术都是有创新性、颠覆性的技术,有希望顺利跨越鸿沟(Chasm)进入主流市场。2019年的云原生技术将实现实实在在的升级、成熟与落地。
           
            (原标题:2019年的云原生市场:K8s周边创新不断,技术生态得到完善)

          我要评论

          所有评论仅代表网友意见,与本站立场无关。

          相关新闻

          IBM发布Q1财报营收182亿美元 2019-04-17 15:31:10
          IBM专注于其云业务的性能。该公司表示,在过去12个月里,云计算销售额达到195亿美元,同?#20173;?#38271;10%。
          战略升级!百度智能云推14款ABC新产品 2019-04-15 08:57:01
          百度智能云推出了智能视频平台三大能力:1)视频AI生产?#20302;砎ideoMind;智感超清技术;3)视频互动产品,通过SLAM同步定位与地图构建实现AR头像、指间作画、环境特效。
          一周精选:国家鼓励AI发展 海洋机器人专业开设 2019-04-12 17:41:54
          聚焦时事要闻,追踪智造动态,中国智能制造网为您带来4月8日-4月12?#25214;?#21608;新闻精选。

          版权与免责声明:凡本网注明“来源:智能制造网”的所有作品,均为浙江兴旺宝明通网络有限公司-智能制造网合法拥有版权或有权使用的作品,未经本网授权不得转载、摘编或利用其它方式使用上述作品。已经本网授权使用作品的,应在授权?#27573;?#20869;使用,并注明“来源:智能制造网”。违反上述声明者,本网将追究其相关法律责任。

          本网转载并注明?#20113;?#23427;来源(非智能制造网)的作品,目的在于传递更多信息,并不代表本网赞同其观点或和?#20113;?#30495;实性负责,不承担此类作品侵权行为的直接责任及连带责任。其他媒体、网站或个人从本网转载?#20445;?#24517;须保留本网注明的作品第一来源,并自负版权等法律责任。

          如涉及作品内容、版权等问题,请在作品发表之?#25484;?#19968;周内与本网联系,否则视为放弃相关权利。

          不想错过最新资讯?

          下载智能制造APP

          一键筛选来订阅

          信息更精准


          关于我们|本站服务|会员服务|商站通服务|旗下网站|友情链接|诚聘英才|意见反馈|热词搜索|频道

          智能制造网 - 中国工业4.0时代智能制造领域“互联网+”服务平台

          Copyright 2019 gkzhan.comAll Rights Reserved法律顾问:浙江天册律师事务所 ?#27835;?#26126;律师

          ?#22836;?#28909;线:0571-87756395采购热线:0571-87759926媒体合作:0571-89719789

          ?#22836;?#37096;:采购部:编辑部:展会合作:市场一组:市场二组:


          关闭
          北京赛车稳赢方法

        2. <dl id="n7sq3"></dl>
              1. <dl id="n7sq3"></dl>
                    1. 福彩3d带坐标走势图带连线走势图 湖北快三开奖结果今天一 东方网彩票平台 乒乓球女单决赛 平特三连肖怎么算中奖 快乐十分走 福建快3预测推荐号码今天 三d连线带坐标走势图 澳洲幸运10开奖平台 羽毛球双打比赛规则 114期→(江南一肖)公式规律 江苏体彩e球彩 韦博线上娱乐城 时时彩五星分布图技巧 黑龙江十一选五第20期的中奖号码