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架起一座桥梁！
本文转移开源中国-Cloud Foundry 与Kubernetes: CF/K8s结合简史
