微软公司重组加码云计算 浪潮信
云计算

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

  随着ELK技术的普及,Elasticsearch所提供的强大搜索、分析功能给大家处理各种类型的海量数据提供了可能。随之而来的是如何将各种类型的海量数据以一种通用、便捷、高效的方式进入到ES供其使用。我们迫切需要一种通用的数据处理方式,实现从数据源到ES的全流程处理。本文选用几种数据通用处理方法进行测试,对比各自的优缺点,发现他们所适应的场景。

  随着ELK技术的普及,Elasticsearch所提供的强大搜索、分析功能给大家处理各种类型的海量数据提供了可能。随之而来的是如何将各种类型的海量数据以一种通用、便捷、高效的方式进入到ES供其使用。我们迫切需要一种通用的数据处理方式,实现从数据源到ES的全流程处理。本文选用几种数据通用处理方法进行测试,对比各自的优缺点,发现他们所适应的场景。

  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,它是全新的应用程序可移植层,它是大家共同的选择。

  第一代:如最早的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仍可构建于k8s之上,并且不少云计算厂商已经采用这种方案。另外,由KataContainer技术逐渐应用到生产环境,带来将无服务器概念和容器结合的Serverless Container Cloud理念,让容器也能兼具传统虚拟化的优点,让这类服务的未来充满了想象空间。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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