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

过去的几年中，在云计算领域的开源社区中最有争议的话题莫过于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上，如下图所示：

所以，第一种整合，也就是开发一套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将两者连接起来，如下图所示：

容器化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强大的管理和扩展能力：

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版本：

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

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

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

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

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

未来两者结合的发展方向

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

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

总结