Cloud Foundry 与Kubernetes: CF/K8s结合简史

翻译 2018年04月15日 13:48:21

【编者的话】本文翻译自IBM 公司Simon MoserSTSMSenior Technical Staff MemberIBM
 
Cloud部门Cloud Foundry方向首席架构师)的一篇技术博客。在这篇博客中,Simon分享了将Cloud FoundryKubernetes结合的多种技术选型的探索历程,包括可行性分析、最佳实践、经验总结和价值意义等话题,旨在最大程度上利用和发挥两者的优势,并提升开发者体验。

同时,在即将到来的Cloud Foundry Summit North America2018418-420日),Simon会在现场与大家分享最新进展DemoTheater: IBM Cloud Foundry Enterprise Environment ,敬请关注!

原文链接: Cloud Foundry andKubernetes: A brief history of CF/K8s (翻译:张龚)

【译者介绍】

张龚,IBM高级软件工程师,参与了文中提及的BOSHKubernetes CPI以及CFEE 等相关项目的开发。

 【正文

在过去中几年,在云计算领域的开源社区中最有争议的话题莫过于CloudFoundry(CF)和Kubernetes(K8s)的关系。大家的疑问紧紧围绕在三个问题:“它们会互相取代对方吗?”,“它们是互斥的吗?” ,“还是说它们是可以融合的?”。

放眼望去在目前的商业产品中,两者几乎没什么关联——两个技术栈(stack)是分离的,都可以运行在各种IaaS之上, 几乎没有集成,就算是有也仅仅是在“CF和K8s共享一个服务目录(ServiceCatalog)”这种级别,而没有更深层的系统级别集成 。

浅显的分析两者的关系并没有特别大的意义。当然了,这两种技术有一定程度的重叠,同时在一些关键领域是互相补充的——下面的表格是一个简单的总结:

 

                                                              表格1:CF和K8s对比

“容器运行时”(Container Runtime)绝对是CF和K8s有巨大重叠的部分,但是它在两者中分别基于不同的实现方式(尽管最终都是基于runc/containerd实现的)。这导致了一些后果,比如K8s引入了一个新的功能(比如需要容器组(ContainerGroup)的边车(Sidecar)),CF也紧随其后开始实现类似的功能,反之亦然。

但另一方面,开发人员在K8s的体验比较糟糕,毕竟通常K8s被认为更像是“IaaS+”而不是一个“PaaS”。

                                                              图片1:开发者体验

但如果K8s就是“IaaS+”而不是一个“PaaS”,那是不是可以将CF运行在K8s之上?我的意思是CF一个核心主张就是“IaaS”无关,所以这可能是可行的?于是我们进行了一项尝试。

可能很多人已经有所了解,CF通常是由BOSH这个工具来负责部署和生命周期管理的。BOSH通常会负责搭建一个CF的环境,并且它通过CPI(Cloud Provider Interface)的机制屏蔽了底层基础设施的差异。假设您说“我想要一个虚拟机”,这时CPI会将这个请求转换成适用于不同底层基础设施提供商的API调用,比如AWS,IBM,Google或者VMWare等等。

所以我们第一个尝试就是基于这个原则,也就是编写一个支持Kubernetes的CPI。但是最初的尝试却以失败告终。

视频1: 使用Kubernetes作为Cloud Foundry的IaaS

具体的细节详见上面视频中Sandy和Monika在CF峰会的演讲,总体可以归结为:CPI认为IaaS层是“无知的”并且CPI掌握最高控制权,但在K8s的世界里并不是这样。K8s是个智能的“IaaS+”,比如CF的一个组件崩溃了并且需要恢复,那么应该谁来负责?BOSH还是K8s?答案并不是显而易见的,我们把这种情形称之为“编排者脑裂”,这也给第一次尝试判了死刑。

幸运的是,我们的合作伙伴SUSE已经开发了两个项目FissileSCF ,他们采取了一种更加彻底的方式,将BOSH运行时全部移除了。显然这对CF的部署和运维是有一定影响的,但优点是这种方式是真正的K8s原生部署方式。所以结论是:我们开始了新的尝试,做了一定的调整,尝试部署后效果很满意!如果你想要进一步了解最新进展,比如理想情况下把现有的方案最终与BOSH相集成,请参考这里 (Googledoc)。

尽管如此,上面这种方式还是有一定缺陷,正如表格1所示,CF有一个原生的容器运行时叫Garden,Fissile将它转化成为Docker镜像的一部分,所以最终CF的App是运行在Garden容器中,而Garden容器又运行在一个Kubernetes Pod中的Docker容器里,听起来很不优雅,对吧?

如果您有一点虚拟化嵌套的经验,很有可能都不想再读下去了,但请继续坚持一下。确实,从概念上来讲这种情况是“嵌套的容器”,但是事实上情况并没有听起来那么糟。因为“容器的嵌套”并不是真的嵌套,它们更像是同个级别的概念。 根据容器的基本定义,一个容器只是隔离起来的操作系统进程。操作系统进程不可能嵌套, 容器也就不可能嵌套。从调用的层次结构来看,它们的关系是父子关系,但是事实上这两个容器是并列运行的。

尽管刚才我说这种方式不错,但是也并不是那么理想。问题倒不是在性能方面,而是在用户以及运维体验方面。比如我使用“cfpush myApp”部署一个应用,之后使用kubectl去查看我的K8s集群,我预期看到的是已经生成一个名为“myApp”的POD 。而以前面这种方式,我只会看到一个名为“garden”的POD,进入“garden”后才能找到我的应用“myApp”。这样是非常冗余的——我们能不能结合CF和K8s两者,并把K8s作为CF里的容器运行时呢?这样不就解决了我们所有的问题并且能够汲取两个平台的精华?道阻且长,但值得一试。

我们进行了新的尝试。本质上,我们想要在部署CloudFoundry的应用时使用其它的容器调度者。 这种方式利用其它调度者的优势并且可以保留CloudFoundry的用户体验(“cf push”)和抽象层。如果您想了解的话,我们的Cube代码原型可以在这里找到——您也可以通过下面的视频立即体验!

CF push to K8s

我们称之为“Cube”的原型主要包括四个部分:

· Sink会从CF CloudController拿到目标app并且建立相应的Kubernetes资源。它依赖于Registry来获取droplet需要的OCI镜像,也依赖于OPI来抽象与K8s的交互。

· Registry是一个根据CFdroplet来提供镜像的OCIregistry。最终这部分会被移到Bits-service。

· St8ge通过运行Kubernetes/OPI一次性的任务实现了Staging。

· OPI 或者“orchestrator provider interface”提供了在多个调度者之上的抽象层,灵感来源于Diego的LRP/Task模型以及BOSH CPI的概念。

不言而喻,这个项目仅仅是这段旅程的一个开始,而这段旅程也并不会是一帆风顺的,但是我们相信我们一定可以取得成功并为CF和K8s架起一座桥梁!

如果您会参加即将在波士顿举行的CF峰会,敬请关注以下演讲http://sched.co/DdZl.

希望您能喜欢这篇文章,敬请继续关注!

 

 

【译者注】

CFEE:Cloud Foundry Enterprise Environment

IaaS:Infrastructure as a service,即基础设施即服务。

PaaS:Platform as a service,即平台即服务。

BOSH:BOSH是一个针对大规模分布式系统的部署和生命周期管理的开源工具。

CPI:CPI封装了一套IaaS的API,它使得BOSH能够通过对CPI的调用从而实际调用IaaS的API。

Fissile:可以将BOSH 的release转化为Docker镜像,https://github.com/SUSE/fissile

SCF:SUSE Cloud Foundry,https://github.com/SUSE/scf

Kubenetes CPI 项目: https://github.com/cfibmers/kubernetes-cpi

Cube 项目:https://github.com/julz/cube


OpenShift负责人谈PaaS、Docker、Kubernetes及与CloudFoundry的竞争

http://www.csdn.net/article/2015-09-28/2825811 OpenShift负责人谈PaaS、Docker、Kubernetes及与CloudFoundry的竞争...
  • hshl1214
  • hshl1214
  • 2017-08-21 18:32:24
  • 1360

如何利用Helm在Kubernetes上快速部署Cloud Foundry?

Cloud Foundry是业界领先的PaaS云平台,可以为应用提供高可用的运行平台,现在很多运行商都在使用Cloud Foundry为用户提供应用服务,如IBM、AWS等。自Cloud Foundr...
  • M2l0ZgSsVc7r69eFdTj
  • M2l0ZgSsVc7r69eFdTj
  • 2017-10-12 00:00:00
  • 285

Kubernetes和Spring Cloud哪个部署微服务更好?

Spring Cloud 和Kubernetes都自称自己是部署和运行微服务的最好环境,但是它们在本质上和解决不同问题上是有很大差异的。在本文中,我们将看到每个平台如何帮助交付基于微服务的架构(MSA...
  • qq_34463875
  • qq_34463875
  • 2016-12-22 16:53:26
  • 8897

基于kubernetes和SpringCloud微服务构建方案

很久没有写博客了,不是因为最近学习松懈,而是因为发现自己以前写的博客大多都比较水,真正有意义、有价值的文章需要大量的学习与时间去积淀。以后尽量提高自己博客的质量,走的再远,工作再忙,也要坚持看书,坚持...
  • qq_32971807
  • qq_32971807
  • 2017-02-22 17:26:57
  • 8882

Cloud Foundry service broker开发部署实例解析(上)

Cloud Foundry(CF)通过buildpack扩展运行不同语言应用的能力,通过service broker(SB)扩展支持应用所需的各种关系数据库、中间件、缓存、云存储、内存数据库等各种服务...
  • cloudguru
  • cloudguru
  • 2015-03-26 17:02:21
  • 2597

Cloud Foundry v2 部署及入门运维

之前写过一个Guide for Cloud Foundry New Teamer。不过似乎已经有些过时,那会实验室主要是针对的CF v1进行的研究,现在已经全面进入V2时代了。所以更新一下关于Cl...
  • yangcs2009
  • yangcs2009
  • 2014-07-31 17:05:29
  • 9759

Spring Cloud + Kubernetes 微服务框架原理和实践

早在半年前,公司开始推行容器化部署方案 AppOS,虽然发布界面过于极客,十分晦涩,不过仔细研究起来真的觉得十分强大,容器化推行后,计算资源(CPU、内存)的利用率可以极大提高,降低服务器数量,从而节...
  • hopeztm
  • hopeztm
  • 2017-12-06 16:08:39
  • 1578

openshift和Docker和kubernetes的关系

  • wuxiaobingandbob
  • wuxiaobingandbob
  • 2017-12-14 13:00:34
  • 1239

CloudFoundry CLI CF 解析

cf push    CLI 中的cf push 命令,需要调用cloud controller的6次rest接口       app = create_app(get_inputs)//app的...
  • wangdk789
  • wangdk789
  • 2013-12-16 22:03:35
  • 2259

Cloud Foundry 快速入门 (cf工具)

Cloud Foundry 快速入门 (cf工具) Cloud Foundry(简称CF)是一个大型可扩展性的APP引擎平台。CF可以帮助开发者快速的运行并延展新创建的APP,缩短与用户的反...
  • u014571113
  • u014571113
  • 2014-04-08 13:43:58
  • 2848
收藏助手
不良信息举报
您举报文章:Cloud Foundry 与Kubernetes: CF/K8s结合简史
举报原因:
原因补充:

(最多只允许输入30个字)