Cloud Foundry 与Kubernetes: CF/K8s结合简史
Cloud部门Cloud Foundry方向首席架构师)的一篇技术博客。在这篇博客中,Simon分享了将Cloud Foundry与Kubernetes结合的多种技术选型的探索历程,包括可行性分析、最佳实践、经验总结和价值意义等话题,旨在最大程度上利用和发挥两者的优势,并提升开发者体验。
同时,在即将到来的Cloud Foundry Summit North America 2018(4月18日-4月20日),Simon会在现场与大家分享最新进展Demo Theater: IBM Cloud Foundry Enterprise Environment ,敬请关注!
原文链接: Cloud Foundry and Kubernetes: A brief history of CF/K8s (翻译:张龚)
【译者介绍】
张龚,IBM高级软件工程师,参与了文中提及的BOSH、 Kubernetes CPI以及CFEE 等相关项目的开发。
【正文 】
在过去中几年,在云计算领域的开源社区中最有争议的话题莫过于Cloud Foundry(CF)和Kubernetes(K8s)的关系。大家的疑问紧紧围绕在三个问题:“它们会互相取代对方吗?”,“它们是互斥的吗?” ,“还是说它们是可以融合的?”。
放眼望去在目前的商业产品中,两者几乎没什么关联——两个技术栈(stack)是分离的,都可以运行在各种IaaS之上, 几乎没有集成,就算是有也仅仅是在“CF和K8s共享一个服务目录(Service Catalog)”这种级别,而没有更深层的系统级别集成 。
浅显的分析两者的关系并没有特别大的意义。当然了,这两种技术有一定程度的重叠,同时在一些关键领域是互相补充的——下面的表格是一个简单的总结:
表格1:CF和K8s对比
“容器运行时”(Container Runtime)绝对是CF和K8s有巨大重叠的部分,但是它在两者中分别基于不同的实现方式(尽管最终都是基于 runc/containerd实现的)。这导致了一些后果,比如K8s引入了一个新的功能(比如需要容器组(Container Group)的边车(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。但是最初的尝试却以失败告终。
http://v.youku.com/v_show/id_XMzUzODc0Nzk5Mg==.html?spm=a2h3j.8428770.3416059.1
视频1: 使用 Kubernetes作为Cloud Foundry的IaaS
具体的细节详见上面视频中Sandy和Monika在CF峰会的演讲,总体可以归结为:CPI认为IaaS层是“无知的”并且CPI掌握最高控制权,但在K8s的世界里并不是这样。K8s是个智能的“IaaS+”,比如CF的一个组件崩溃了并且需要恢复,那么应该谁来负责?BOSH还是K8s?答案并不是显而易见的,我们把这种情形称之为“编排者脑裂”,这也给第一次尝试判了死刑。
幸运的是,我们的合作伙伴SUSE已经开发了两个项目Fissile和SCF ,他们采取了一种更加彻底的方式,将BOSH运行时全部移除了。显然这对CF的部署和运维是有一定影响的,但优点是这种方式是真正的K8s原生部署方式。所以结论是:我们开始了新的尝试,做了一定的调整,尝试部署后效果很满意!如果你想要进一步了解最新进展,比如理想情况下把现有的方案最终与BOSH相集成,请参考这里 (Google doc)。
尽管如此,上面这种方式还是有一定缺陷,正如表格1所示,CF有一个原生的容器运行时叫Garden,Fissile将它转化成为Docker镜像的一部分,所以最终CF的App是运行在Garden容器中,而Garden容器又运行在一个Kubernetes Pod中的Docker容器里,听起来很不优雅,对吧?
如果您有一点虚拟化嵌套的经验,很有可能都不想再读下去了,但请继续坚持一下。确实,从概念上来讲这种情况是“嵌套的容器”,但是事实上情况并没有听起来那么糟。因为“容器的嵌套”并不是真的嵌套,它们更像是同个级别的概念。 根据容器的基本定义,一个容器只是隔离起来的操作系统进程。操作系统进程不可能嵌套, 容器也就不可能嵌套。从调用的层次结构来看,它们的关系是父子关系,但是事实上这两个容器是并列运行的。
尽管刚才我说这种方式不错,但是也并不是那么理想。问题倒不是在性能方面,而是在用户以及运维体验方面。比如我使用“cf push myApp”部署一个应用,之后使用kubectl去查看我的K8s集群,我预期看到的是已经生成一个名为“myApp”的POD 。而以前面这种方式,我只会看到一个名为“garden”的POD,进入“garden”后才能找到我的应用“myApp”。这样是非常冗余的——我们能不能结合CF和K8s两者,并把K8s作为CF里的容器运行时呢?这样不就解决了我们所有的问题并且能够汲取两个平台的精华?道阻且长,但值得一试。
我们进行了新的尝试。本质上,我们想要在部署Cloud Foundry的应用时使用其它的容器调度者。 这种方式利用其它调度者的优势并且可以保留Cloud Foundry的用户体验(“cf push”)和抽象层。如果您想了解的话,我们的Cube代码原型可以在这里找到——您也可以通过下面的视频立即体验!
http://v.youku.com/v_show/id_XMzUzODc2Mzc4NA==.html?spm=a2h3j.8428770.3416059.1
视频2:CF push to K8s
我们称之为“Cube”的原型主要包括四个部分:
· Sink会从CF Cloud Controller拿到目标app并且建立相应的Kubernetes资源。它依赖于Registry来获取droplet需要的OCI镜像,也依赖于 OPI来抽象与K8s的交互。
· Registry是一个根据CF droplet来提供镜像的OCI registry。最终这部分会被移到Bits-service。
· St8ge通过运行Kubernetes/OPI 一次性的任务实现了Staging。
· OPI 或者“orchestrator provider interface”提供了在多个调度者之上的抽象层,灵感来源于Diego的LRP/Task模型以及BOSH CPI的概念。
不言而喻,这个项目仅仅是这段旅程的一个开始,而这段旅程也并不会是一帆风顺的,但是我们相信我们一定可以取得成功并为CF和K8s架起一座桥梁!
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
基于Helm和Operator的K8S应用管理的分享
本文由3月7日晚李平辉,Rancher Labs 研发工程师所做的技术分享整理而成。 李平辉熟悉应用容器化解决方案设计和实施,熟悉持续集成方案,关注并参与K8S生态的发展,负责Rancher中国区持续集成服务研发。 搜索微信号RancherLabsChina,添加Rancher小助手为好友,可加入官方技术交流群,实时参加下一次分享~ 大家好,今天我们分享的内容是基于Helm和Operator的K8S应用管理。我们知道,Kubernetes基于服务粒度提供了多种资源描述类型。描述一个应用系统尤其是微服务架构系统,需要组合使用大量的Kubernetes资源。针对有状态应用,常常还需要复杂的运维管理操作以及更多的领域知识。 今晚的分享就将介绍如何用Helm这一Kubernetes应用包管理的社区主导方案来简化应用的部署管理,如何制作应用模板以及打造Kubernetes版应用商店,以及如何利用operator自动化应用的运维。 我们知道在K8S社区里面,根据不同的领域,分成了不同的兴趣小组,英文叫SIG。今晚的话题属于APP这个领域。它们是为了解决K8S的应用管理里面的一些问题而生的。 一、H...
- 下一篇
k8s手工安装
k8s节点介绍 master:主要负责管理k8s的所有node etcd:保存了整个集群的状态 apiserver:提供了资源操作的唯一入口,并且提供认证、授权、访问控制、api注册和发现等机制 scheduler负责资源的调度,按照预定的调度策略将pod调度到相应的机器上 controller manager负责维护集群的状态,比如故障检测,自动扩展,滚动更新等 node:主要执行容器实例的节点,可视为工作节点。 kubelet: 负责维护容器的生命周期,同时也负责Volume(CVI)和网络(CNI)的管理; kube-proxy负责为Service提供cluster内部的服务发现和负载均衡; 安装前 k8s在网上有许多的云端平台与操作系统的安装方式。如果通过手工安装来部署,将有利于我们更加了解k8s的流程。 IP address Role CPU Memory 192.168.0.102 master 1 2G 192.168.0.103 node1 1 2G 192.168.0.104 node2 1 2G 这边master节点为主要的控制节点,同时它也是部署节点 node为应...
相关文章
文章评论
共有0条评论来说两句吧...