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

【编者的话】本文翻译自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)”这种级别,而没有更深层的系统级别集成 。

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

Cloud Foundry 与Kubernetes: CF/K8s结合简史_第1张图片

 

                                                              表格1:CF和K8s对比

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

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

Cloud Foundry 与Kubernetes: CF/K8s结合简史_第2张图片

                                                              图片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已经开发了两个项目Fissile和SCF ,他们采取了一种更加彻底的方式,将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。


你可能感兴趣的:(Cloud Foundry 与Kubernetes: CF/K8s结合简史)