|
|
51CTO旗下网站
|
|
移动端

Cloud Foundry和Kubernetes结合的过去与未来,融合是市场发展趋势

本文将从Cloud Foundry部署的层面,来介绍业界和我们如何去把两套系统进行整合的。当然任何整合方案都会有各自的优缺点,而且所有的整合还在一个快速发展的阶段,所以在这里算是给大家抛砖引玉,为以后的工作和学习提供一些帮助。

作者:佚名来源:Dockone.io|2018-10-20 16:19

过去的几年中,在云计算领域的开源社区中最有争议的话题莫过于Cloud Foundry和Kubernetes的关系。大家的疑问紧紧围绕着三个问题:“它们会互相取代对方吗?”,“它们是互斥的吗?” ,“还是说它们是可以融合的?”。放眼望去在目前的商业产品中,两者几乎没什么关联和集成,都可以运行在各种IaaS之上。

多年以来,我们一直从事Cloud Foundry部署的相关工作,从原来传统的BOSH CPI到现在的容器化Cloud Foundry的工作。在这期间,我们对两者结合的多种技术选型的进行探索,包括可行性分析、最佳实践、经验总结和价值意义等方面,旨在最大程度上利用和发挥两者的优势,并提升开发者体验。

本文将从Cloud Foundry部署的层面,来介绍业界和我们如何去把两套系统进行整合的。当然任何整合方案都会有各自的优缺点,而且所有的整合还在一个快速发展的阶段,所以在这里算是给大家抛砖引玉,为以后的工作和学习提供一些帮助。

Cloud Foundry和Kubernetes简介

Cloud Foundry

Cloud Foundry是一个独立于云的平台即服务解决方案,也是业界最成功的PaaS平台。Cloud Foundry提供了一个可轻松运行、扩展和维护应用程序的环境和快速便捷的开发者体验。Cloud Foundry支持Java、NodeJS、Ruby、Python等大多数语言和环境。

开源的Cloud Foundry由Cloud Foundry基金会开发并支持,基金会包括Pivotal、IBM、VMware以及其它许多厂商。商业版本的Cloud Foundry,如IBM Bluemix和Pivotal Cloud Foundry,是基于开源的Cloud Foundry项目并在其基础上提供企业级的支持。

Kubernetes

Kubernetes是一个来源于谷歌Borg项目的开源云平台。它由Cloud Native Computing Foundation发起,该基金会的成员包括了许多行业巨头,如AWS、Azure、Intel、IBM、RedHat、Pivotal等许多公司。

Kubernetes首要的功能是一个容器编排和容器生命周期的管理。尽管不限于此,但它通常是被用来运行Docker容器,它的受众人群更广泛一些,比如想要构建在容器服务之上的应用和服务开发人员。有一些解决方案基于Kubernetes提供了PaaS体验,比如IBM的Container Service和RedHat的OpenShift等。

两个平台的比较

两个平台都很成熟和完整,而且随着不断的开发和改进,所以两个平台的相同和不同之处也会随之变。当然两大项目有很多相似之处,包括容器化,命名空间和身份验证等机制。而两者也有各自的优势:

Cloud Foundry的优势在于:

  • 成熟的身份验证系统UAA,用户组和multi-tenancy的支持
  • 方便快捷的cf push
  • 自带负载均衡Router
  • 强大的日志和metrics整合
  • 成熟的部署工具BOSH

Kubernetes的优势在于:

  • 大量社区和第三方支持,提供强大的扩展性
  • 完善的容器生命周期和自动伸缩管理
  • 方便快捷的容器化应用部署
  • 良好、多样的持久层支持
  • 多种开源UI支持

现阶段两者的关系及结合情况

从上面的比较,我们可以看到,两大平台各有各的优势及强大之处。所以业界有很多厂商都想尝试将两者融合,从而将优势发挥到最大化。从现在来看两者整合主要有以下三种方式:

Kubernetes CPI

我们知道BOSH是Cloud Foundry官方指定的部署工具,它是一个针对大规模分布式系统的部署和生命周期管理的开源工具。但是BOSH不仅仅局限于部署Cloud Foundry,也可以应用于别的分布式系统,只需要其提供符合要求的Release即可。CPI全称Cloud Provider Interface,是BOSH用来与IaaS通信完成虚拟机实例和模板的创建和管理的一个API接口,CPI目前能够支持Amazon的AWS、微软的Azure、IBM的SoftLayer等IaaS平台,国内阿里云也提供了CPI的支持。BOSH的主控制器Director通过CPI与底层的IaaS层交互,将BOSH manifest.yaml 文件定义任务及组件部署到IaaS层的VM上,如下图所示:

1.png

所以,第一种整合,也就是开发一套Kubernetes的CPI,通过BOSH和manifest.yaml的配置将Cloud Foundry部署到Kubernetes上。现在有一些大的厂商如IBM、SAP在开发相应的Kubernetes CPI,大家可以在GitHub中搜索到。我个人觉得,这种方式虽然容易上手,但还是以IaaS的角度来看待Kubernetes,底层还是通过BOSH来管理的,没能最大地发挥Kubernetes平台的优势的。

Cloud Foundry Container Runtime(CFCR)

Cloud Foundry基金会在2017年底宣布把Pivotal和谷歌捐献的Kubo项目改名为CFCR(Cloud Foundry Container Runtime)。总体来说是利用BOSH来部署Cloud Foundry和Kubernetes,并通过Application Runtime管理Cloud Foundry的Application Service;通过Container Runtime管理Kubernetes的Container Service,比如一些无法部署在Cloud Foundry内的服务,如数据库、监控等。然后通过Open Service Broker将两者连接起来,如下图所示:

2.png

容器化Cloud Foundry

将Cloud Foundry所有组件容器化,并部署到Kubernetes上是一种比较新型的整合方式。现在有一些大的厂商做这方面的工作,比如SUSE、IBM和SAP。其核心就是通过将Cloud Foundry的BOSH Release转化成Docker镜像,然后通过Kubernetes的部署工具Helm来将Cloud Foundry更加自然地部署到Kubernetes上。只有在生成Cloud Foundry组件的Docker镜像是需要用到BOSH Cli去转化BOSH release,部署及部署之后的管理,都不需要BOSH,而是交给Kubernetes来对所有Cloud Foundry组件的Pod、服务及相应配置资源的生命周期进行管理。这样既享受到了Cloud Foundry带来的良好的开发者体验,又用到了Kubernetes强大的管理和扩展能力:

3.png

IBM在两者结合上做的工作和成果

IBM主要是和SUSE合作,在上面第三种方案的基础上,创建一套可以在IBM Cloud上快速部署的企业级Cloud Foundry。这个新的服务名称叫做IBM Cloud Foundry Enterprise Environment(CFEE),他的主要构件流程如下:

  • 首先我们需要将BOSH的Release通过SUSE的转换工具Fissile将其编译并制作成CF组件相应的Docker镜像。
  • 之后我们需要通过Fissile将预设的参数转换成Helm或者Kubernetes的配置资源文件。
  • 利用IBM Cloud强大的服务资源,增加企业级服务的支持,比如数据库服务,安全服务和负载均衡服务。
  • 最后发布新的IBM CF版本,用户可以直接在IBM Cloud的Catalog里面找到并自动部署出一套CFEE环境。

和传统的BOSH CPI的部署方式的比较,新的Cloud Foundry版本发布后,管理员只需执行一次来构建任务来创建新版本Docker镜像和Helm配置,之后就可以重复使用了。这种部署Cloud Foundry的方式时间大概在15-20分钟,和之前BOSH部署4-6个小时相比,快了很多。

IBM已于2018上半年的Cloud Foundry Summit上发布了Experimental版本:

4.png

在刚过去的2018年10月初,IBM又发布了CFEE的GA版,主要为企业级客户提供更好的服务、带来更大的价值。部署出来的CFEE环境不但与其他环境是相互隔离的,而且CFEE环境中部署的Cloud Foundry应用还可以很轻松地使用IBM Cloud上丰富的服务资源,如AI,大数据,IoT和Blockchain等:

5.png

感兴趣的用户可以通过IBM Cloud的Catalog找到CFEE的介绍:

https://console.bluemix.net/do ... ating。

在部署页面中,用户可以配置CFEE的域名,Diego-cell的个数以及CF版本等信息,然后CFEE可以实现全自动化一键部署,大概1个小时左右,一个企业级的CF环境就部署成功了:

6.png

当然在部署完成后,CFEE还提供了强大的管理,监控和命令行等功能,如图所示,用户可以很轻松地在页面上查看Cloud Foundry和应用的使用情况,创建相应的资源或者绑定IBM的外部服务等:

7.png

未来两者结合的发展方向

当然两者结合的探索工作不止于此,现在越来越多的厂商和开发者加入到两者整合的研究中。其中比较火的有IBM主导的Cloud Foundry孵化项目Eirini,其想法是想将Cloud Foundry中的Diego-cell容器Garden替换成Kubernetes的容器,从而将两者更紧密地连接在一起:

8.png

还有像SUSE主导的Fissile项目,未来其想法是想通过BOSH命令可以直接生成CF的Docker镜像和Helm配置,从而可以更好地和社区融合到一起。

总结

综上所述,Kubernetes之于Cloud Foundry的关系不是挑战也不是竞争关系,Cloud Foundry希望与其更好地融合,就像Cloud Foundry Foundation执行董事Abby Kearns说的:“Cloud Foundry是结构化的PaaS平台,其他平台是非结构化的,用户的需求是多元化的,并不是一定要如何容器化,而是希望平台能够更开放、支持更多的类型。”

不管未来两者怎么发展,两者的结合绝对是适应市场的趋势,同时又能给用户带来多方面的价值提升。未来两者还能碰撞出什么样的火花?让我们拭目以待!

【编辑推荐】

  1. Kubernetes系统架构演进过程与背后驱动的原因
  2. 选择Serverless还是Kubernetes?这种争辩并没有意义
  3. 灵雀云CTO陈恺:后Kubernetes时代 云原生助力企业持续创新
  4. 2019年的云端:多云、无服务器计算和Kubernetes容器
  5. Kubernetes日志传输过程中面临的4个挑战
【责任编辑:未丽燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

'ASP.NET'程序设计教程

《ASP.NET程序设计教程》是在总结多年ASP.NET教学和应用项目开发经验基础上编写完成的,编写过程中充分吸取了其他畅销实用教程的成功经验。...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊