PaaS将吞噬云计算?Kubernetes的市场冲击波

Kubernetes PaaS   2018-05-02 12:33:48 发布
您的评价:
     
0.0
收藏     1收藏
文件夹
标签
(多个标签用逗号分隔)

2017年是Kubernetes的胜利之年,很多人还不明白这意味着什么。但如果看一下云计算业界的动向,你会发现,Kubernetes的影响正在扩散。

在本文中我将分享我们的发现,并试图说服你:基于容器+Kubernetes的新型PaaS将会成为云计算的主流。

我将引用很多内容,包含国内外专家的真知灼见,让你看到专家是如何看待此事的,以及分享我们自己做的调研和采访,看看业界实际在发生什么。

Kubernetes(k8s)在很短的一段时间内走过了很长的一段路。仅仅两年以前,它还需要与CoreOS的Fleet、Docker Swarm、Cloud Foundry Diego、HashiCorp的Nomad、Kontena、Rancher的Cattle、Apache Mesos、Amazon ECS等进行竞争,来证明自己比那些产品都要优秀。而现如今已经是完全不同的一幅景象了。其中的一些公司公开宣布了项目的终止并且开始加入到Kubernetes阵营中,还有一些公司没有公开宣布自己项目的失败,而是在战略上宣布了对Kubernetes的部分支持或者完全整合,这也就意味着他们的容器编排工具将会安静而缓慢地死掉。不论是哪一种情况,k8s都是最后一个活下来的平台。除此之外,不仅仅是用户和白金赞助商们,越来越多的大公司都将继续加入到Kubernetes的生态系统中,将自己的业务完全押注于Kubernetes的成功。我们首先能想到的有Google的Kubernetes Engine、Red Hat的OpenShift、Microsoft的Azure Container Service、IBM的 Cloud Container Service、Oracle的Container Engine。

但是这些意味着什么呢?首先,这意味着开发人员必须要掌握一个与90%的容器工作相关的容器编排平台。这是一个学习Kubernetes很好的理由。同时这还意味着我们已经深深地依赖于Kubernetes,Kubernetes就像容器领域中的Amazon。在Kubernetes上进行设计、实现和运行应用程序可以让你在不同的云提供商、Kubernetes发行版和服务提供商之间自由地对应用程序进行迁移。它能让你有机会找到Kubernetes认证的开发人员,让他们来开发项目并且在以后持续提供支持。Kubernetes不是VM,也不是JVM,它是全新的应用程序可移植层,它是大家共同的选择。

——Bilgin Ibryam,Red Hat首席架构师(Source)

基于“容器+k8s”的新型PaaS

Kubernetes并不是传统意义上的PaaS,事实上,传统PaaS可以基于Kubernetes构建。

在过去,PaaS经历了这样的发展:

  • 第一代:如最早的Heroku,严格限定的运行时,不可修改的环境。对于Ruby on Rails这种小型单体应用来说很合适。
  • 第二代:Cloud Foundry (DEA版本) ,可以简单的自定义环境,包括云端构建。也开始对多服务的应用有所支持。
  • 第三代:Cloud Foundry (Diego版本),如当前版本的GAE和AWS Elastic Beanstalk,它们都经过之前两代PaaS迭代而来。在这个版本里增加了对容器的支持,更自由的环境配置,对微服务的支持更强大。
  • 第四代:Kubernetes以及其它容器编排引擎。这一代的平台变成了Kubernetes本身,它是面向云原生应用计算的、彻底基于分布式和容器的计算平台。

第四代PaaS的关注点也和之前不一样,我们可以把前三代PaaS称为应用级PaaS(Application PaaS),它们关注的是应用的运行,第四代称为容器PaaS,或者CaaS、KaaS,它们关注的是应用的打包和分发。

第四代PaaS当然也可以使用其它的技术达到类似的效果,但就像前面所说的,Kubernetes赢得了这场竞争。

从下面的PaaS平台架构图中可以看到,我用了 Docker+Kubernetes 层来做了一个“技术缓冲层”。也就是说,如果没有 Docker 和 Kubernetes,构建 PaaS 将会复杂很多。当然,如果你正在开发一个类似 PaaS 的平台,那么你会发现自己开发出来的东西会跟 Docker 和 Kubernetes 非常像。相信我,最终你还是会放弃自己的轮子而采用 Docker+Kubernetes 的。

——陈皓 《洞悉PaaS平台的本质》

PaaS将吞噬云计算?Kubernetes的市场冲击波

这是一个大而全的PaaS平台架构,实际中可以根据需求进行裁剪。

业界趋势:全在做PaaS

如果我们看一下业界,会发现,从公有云到私有云,从传统企业到互联网新贵,都在拥抱Kubernetes,都在做PaaS。

公有云全在做k8s和容器

从AWS到Google Cloud、微软Azure,到国内的阿里云、腾讯云、华为云等,都在提供k8s容器服务。如果一个公有云到现在还没有提供k8s服务,或者没有计划做,那么可以认为它的技术已经落后于时代了。

公有云提供的k8s和容器服务,具体来说分为两类:

一类是提供多租户的单容器实例,这种其实类似于上面提到的第三类PaaS,用户创建的是单个容器,值得一提的是,这类PaaS仍可构建于k8s之上,并且不少云计算厂商已经采用这种方案。另外,由KataContainer技术逐渐应用到生产环境,带来将无服务器概念和容器结合的Serverless Container Cloud理念,让容器也能兼具传统虚拟化的优点,让这类服务的未来充满了想象空间。

Kubernetes所要扮演的角色,乃是取代传统的Infrastructure Layer并鼓励技术人员进行上层的“二次创新”,而并不是直接面对最终用户。真正为最终用户提供云服务的,很大概率应该是构建于Kubernetes之上的、更加简洁高效的服务型API,而Serverless,尤其是Serverless Container Cloud的设计,正是这种需求下最为贴切的实现方式之一。

——张磊,浙江大学博士研究员,Hyper项目成员,Kubernetes项目资深成员与社区维护者。

另一类是提供Kubernetes引擎,这种情况下用户创建的是Kubernetes集群,如GKE、Azure AKS、腾讯云CCS等。

第二类服务是目前公有云研发的重点,发布的时间基本集中在去年下半年到现在,我们采访和调研了微软Azure、腾讯云、华为云,情况基本类似,具体内容可进一步阅读:

剑指Kubernetes 揭秘腾讯云的PaaS技术选型策略

华为云的Kubernetes实践之路

k8s将成私有云的标准解法

私有云的情况分为两类,一类是企业搭建数据中心和私有云自用,另一类是服务提供商,为客户提供私有云解决方案。在这两类情况中我们都看到Kubernetes被使用的越来越多,并且无论是企业、服务提供商,还是客户都尝到了Kubernetes PaaS的甜头。

对于自用型私有云来说,系统的演进是一个复杂的问题,盲目采用新技术有时不仅无助于业务,还造成资源浪费。k8s的表现如何呢?我们让京东的经验来说话吧:

(采用容器和Kubernetes的)JDOS 2.0接入了包含大数据、Web利用、深度学习等多种类型的利用,并为每一种利用依据类型采取了不同的资源限制方式,并打上了Kubernetes的不同标签。基于多样的标签,我们实现了更加多样和灵便的调度方式,并在部份IDC试验性地混合部署了在线任务和离线任务。相较于1.0,总体资源应用率提升了约30%。

——鲍永成,京东基础平台部技术总监

对于服务提供商来说,Kubernetes健康的生态可以保证它们有大量的第三方软件和工具使用,同时PaaS易于开发和代码/应用复用的特性,也降低了它们交付项目的成本,并缩短了交付周期。

对于客户来说,基于Kubernetes的PaaS可以实现应用自由迁移,这使企业可以采用多重云策略,并变相提升了对供应商的议价能力。

云计算经过了十多年的发展,已然进入的云原生的新阶段,企业应用优先考虑部署在云环境,如何顺应云原生的大潮,使用容器和Kubernetes构建云原生平台,践行DevOps理念和敏捷IT,开源软件和社区如何助力IT转型,所有这些问题的解决方案就是PaaS平台,其对于企业的重要性不言而喻。

——宋净超 TalkingData容器平台负责人(Source)

一些业界的经验可参考:

京东如何从OpenStack迁移至Kubernetes

你知道吗?传统企业已经在用最新互联网架构了

运维也需要PaaS

腾讯互娱的运维团队,需要为公司的在线游戏提供运维能力,这可能是中国挑战最大要求最高的运维服务,因此他们有数百人的研发团队,他们的做法可以很大程度上代表运维的发展方向,而不断思考和迭代的结果就是自研了一套PaaS平台蓝鲸。蓝鲸本身不使用Docker、Kubernetes等,完全自研,但我们可以看到,运维的发展方向就是PaaS。

PaaS将吞噬云计算?Kubernetes的市场冲击波

PaaS本身与DevOps的理念完全契合,它改变了传统运维的职责,让他们变成运维开发,为企业研发运维工具乃至是PaaS平台。而对于没有蓝鲸团队开发能力的人,容器和Kubernetes能为他们提供弯道超车的捷径。

京东金融的运维团队就采用了Kubernetes来搭建他们的PaaS平台:

PasS平台化将问题的关注点从基础资源上升到了应用层面,目标是提供一个帮助开发人员运行、管理应用的平台,让使用者更关注运行的代码(业务逻辑)。

PaaS能解决的问题:

  • 应用聚合:如开发需要一个Redis,直接启动一个Redis容器即可
  • 服务发现、快速伸缩、状态管理等
  • 服务监控、恢复、容灾
  • 费用统计:提供计算资源信息汇总,针对不同项目收费
  • 安全管控:不管什么平台,安全都非常重要,例如A应用可以访问B,B不允许访问A以及安全审计等。
  • 快速部署。

随着Docker容器技术的出现,让我们有了更合适的工具建设PaaS平台,具备了基于应用构建服务的能力。在Docker容器调度框架上,我们又选择了Kubernetes平台。

——张龙,京东金融PE

为什么PaaS会成为云计算主流?

除了上面的这些,我们还可以看到,PaaS是SaaS服务发展到一定程度后必然会做的事情,这么做不仅可以满足客户更全面、定制化的需求,也让SaaS厂商可以向更多领域拓展。如果要举一个例子的话,大家想想微信和小程序就能理解。

而为什么Kubernetes会成为PaaS的选择,为什么PaaS会成为云计算的主流,是因为容器和Kubernetes是今日云原生概念的核心和基础。云计算诞生到现在有十来年了,但云时代的应用应该长什么样子,过去一直没有人能说清楚,直到容器诞生后,我们终于离想象中的云时代稍微近了一些。

通过了解软件工程的这三个本质,你会发现,我们上面所说的那些分布式的技术点是高度一致的,也就是下面这三个方面的能力。

  • 分布式多层的系统架构。
  • 服务化的能力供应。
  • 自动化的运维能力。

只有做到了这些,我们才能够真正拥有云计算的威力。这就是所谓的 Cloud Native。而这些目标都完美地体现在 PaaS 平台上。前面讲述的分布式系统关键技术和软件工程的本质,都可以在 PaaS 平台上得到完全体现。

——陈皓 《洞悉PaaS平台的本质》

云计算的未来

过去几年云计算的发展令人眼花缭乱,想要预测它的未来无疑是极为困难的,但只要把握住Kubernetes这条主线,理解从虚拟化到容器再到两者融合的发展路线,在短期内我们还是能做一些预测。

这个问题(Kubernetes在五年后会变成怎样)很好。我希望,在接下来的五年中,我们对Kubernetes的讨论不比对Linux内核的讨论多。它真的应该成为所有工作的基础。如果我们接下来的行为正确,我认为,有些事情就会成真。

大多数开源和ISV(软件供应商)的安装指令都是始于“选择一个经过认证的Kubernetes集群”。第2步将是“运行这个kubectl命令”。Kubernetes将让第三方软件不再忧虑开发针对无数平台的版本,让那些供应商更容易提供云提供商托管服务之外的方案。在许多情况下,使用云服务并没什么不对,但是,你应该从你自己的基础设施上也能获得类似的体验。

我相信,对于开发流程,我们将从封闭的PaaS服务,转向企业可以使用一流组件组装类似PaaS功能。其中,有些可能是领域专属的,只在一个特定的行业里应用。企业能够快速组装一个完整的解决方案,提供从代码到有强大防护的生产环境的简单路径,也提供在需要时“打破玻璃”运行自定义功能的能力。

——Craig McLuckie,Kubernetes创始人

Kubernetes已经胜利,但基于Kubernetes的各类组件、工作流并不成熟,就像Kubernetes创始人McLuckie所说的,Kubernetes需要成为讨论的“背景”,我们讨论的将是基于容器编排的各种创新和应用,比如Service Mesh。

在我看来,在三到五年之后, Kubernetes 会成为服务器端的标准环境, 就像现在的Linux,而 Service Mesh 就是运行在 Kubernetes 上的分布式应用的动态链接器,届时开发一个分布式应用将会像开发单机程序一样简单,业界在分布式操作系统上长达三十多年的努力将以这种方式告一段落。

——宋潇男,普元信息云计算架构师(Source)

 

来自:http://www.infoq.com/cn/articles/kubernetes-and-pass

 

扩展阅读

DockOne技术分享(十九):畅谈PaaS
基于Docker的CaaS容器云平台架构设计及市场分析
Kubernetes技术分析之存储
对大规模容器进行监控所面临的挑战
Kubernetes技术分析之入门

为您推荐

基于Docker的CaaS容器云平台架构设计及市场分析
基于docker、kubernetes部署openstack到atomic系统上
Docker,云时代的程序交付方式
开源大数据处理工具汇总(下)
构建微服务的开源技术之 Docker

更多

Kubernetes
PaaS
相关文档  — 更多
相关经验  — 更多
相关讨论  — 更多