Cloud Foundry和Kubernetes结合的过去与未来
多年以来,我们一直从事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上,如下图所示: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版本:
在部署页面中,用户可以配置CFEE的域名,Diego-cell的个数以及CF版本等信息,然后CFEE可以实现全自动化一键部署,大概1个小时左右,一个企业级的CF环境就部署成功了:
未来两者结合的发展方向
当然两者结合的探索工作不止于此,现在越来越多的厂商和开发者加入到两者整合的研究中。其中比较火的有IBM主导的Cloud Foundry孵化项目Eirini,其想法是想将Cloud Foundry中的Diego-cell容器Garden替换成Kubernetes的容器,从而将两者更紧密地连接在一起:总结
综上所述,Kubernetes之于Cloud Foundry的关系不是挑战也不是竞争关系,Cloud Foundry希望与其更好地融合,就像Cloud Foundry Foundation执行董事Abby Kearns说的:“Cloud Foundry是结构化的PaaS平台,其他平台是非结构化的,用户的需求是多元化的,并不是一定要如何容器化,而是希望平台能够更开放、支持更多的类型。”不管未来两者怎么发展,两者的结合绝对是适应市场的趋势,同时又能给用户带来多方面的价值提升。未来两者还能碰撞出什么样的火花?让我们拭目以待!
本文转自DockOne-Cloud Foundry和Kubernetes结合的过去与未来
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Kubernetes 网络基础介绍
如果你读过该系列的 前一篇文章 ,那么在你的集群里应该已经成功运行着Gitea的deployment了。下一步是能够通过Web浏览器访问它。本文会介绍一些Kubernetes的网络基础知识,并且可以让外部网络可以访问Gitea容器。 打开容器端口 Pod默认是和外部隔离的。为了能够将流量导入应用程序,我们需要打开该容器计划使用的一系列端口。 Gitea容器内的软件会监听3000端口上的http请求,以及22端口上的SSH链接。可以通过如下YAML文件打开这些端口: apiVersion: extensions/v1beta1 kind: Deployment metadata: name: gitea-deployment spec: replicas: 1 selector: matchLabels: app: gitea template: metadata: labels: app: gitea spec: containers: - name: gitea-container image: gitea/gitea:1.4 ports: #+ - containerPort: 3...
- 下一篇
Kubernetes-项目中pod调度使用法则
前言 kubernetes中部署的pod默认根据资源使用情况自动调度到某个节点。可在实际项目的使用场景中都会有更细粒度的调度需求,比如:某些pod调度到指定主机、某几个相关的服务的pod最好调度到一个节点上、Master节点不允许某些pod调度等。使用kubernetes中的节点调度、节点亲和性、pod亲和性、污点与容忍可以灵活的完成pod调度,从而满足项目中较为复杂的调度需求。下面用一些项目中的使用场景聊聊pod调度使用法则。 原创作者:钟亮 pod调度主要包含以下内容 nodeSelector nodeAffinity podAffinityz Taints 指定节点调度 kubectl get nodes #获取当前Kubernetes集群全部节点 NAME STATUS ROLES AGE VERSION dev-10 Ready <none> 45d v1.8.6 dev-7 Ready master 45d v1.8.6 dev-8 Ready <none> 45d v1.8.6 dev-9 Ready <none> 45d v1.8.6...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS8编译安装MySQL8.0.19
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS7,CentOS8安装Elasticsearch6.8.6
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果