下一版本的CloudFoundry / Diego将为Docker容器提供原生支持,这些容器将在多个主机[link]之间进行编排。 这听起来与Kubernetes非常相似。
当然,Kubernetes试图解决的问题更为通用,其中CloudFoundry更专注于应用程序开发。然而,对我而言,听起来两者都朝着类似的方向发展,CloudFoundry正在简单的编排之上添加更多功能。
所以我想知道Kubernetes会比CloudFoundry增加更多价值的用例吗?
答案 0 :(得分:184)
作为CloudFoundry(过去)和Kubernetes(现在)的提交者,我可能有资格回答这个问题。
我喜欢将CloudFoundry称为“应用程序PaaS”,将Kubernetes称为“容器PaaS”,但鉴于两个项目都会随着时间的推移而在相同的市场中竞争,因此区别相当微妙和流畅。
两者之间的区别在于CF有一个暂存层,它采用(12因素)用户应用程序(例如jar或gem)和Heroku风格的buildpack(例如Java + Tomcat或Ruby)并生成一个droplet(类似于Docker图像)。 CF不会将容器化接口暴露给用户,但Kubernetes会这样做。
CloudFoundry的主要受众是想要使用Heroku风格的buildpack部署12因素无状态应用程序的企业应用程序开发人员。
Kubernetes的受众群体更广泛,包括无状态应用程序和提供自己容器的有状态服务开发人员。
这种区别可能会在未来发生变化:
随着两个项目的成熟和竞争,它们的异同将发生变化。因此,请将以下特征与一粒盐进行比较。
CF和K8共享许多类似的功能,如容器化,命名空间,身份验证,
Kubernetes的竞争优势:
CloudFoundry的竞争优势:
[x]这些功能不是Diego的一部分,也不包含在莱迪思中。
CloudFoundry的竞争优势之一是它拥有成熟的部署引擎BOSH,可以实现核心CF组件的扩展,复活和监控等功能。 BOSH还支持许多具有可插拔云提供程序抽象的IaaS层。不幸的是,BOSH的学习曲线和部署配置管理是噩梦。 (作为BOSH提交者,我想我可以准确地说出来。)
Kubernetes的部署抽象仍处于起步阶段。核心仓库中提供了多个目标环境,但它们并非全部正在运行,经过良好测试或得到主要开发人员的支持。这主要是成熟的事情。人们可能会期望这会随着时间的推移而改进并且会增加抽象。例如,Kubernetes on DCOS允许使用单个命令将Kubernetes部署到现有的DCOS集群。
迭戈是CF的Droplet执行代理的重写。它最初是在Kubernetes宣布之前开发的,随着竞争格局的演变,它已经具有更多的功能范围。它的最初目标是生成飞沫(用户应用程序+ CF buildpack)并在Warden(在Go中重写时重命名为Garden)容器中运行它们。自成立以来,它也被重新打包为Lattice,它有点像CloudFoundry-lite(虽然这个名字是由existing project拍摄的)。出于这个原因,莱迪思有点像玩具一样,因为它故意减少了用户的观众和范围,显然缺少使其“企业就绪”的功能。 CF已经提供的功能。这部分是因为莱迪思用于测试核心组件,而没有来自更复杂的CF的一些开销,但您也可以在内部高信任环境中使用莱迪思,其中安全性和多租户不是那么重要
值得一提的是,CloudFoundry和Warden(它的容器引擎)也早于Docker,差不多几年了。
另一方面,Kubernetes是一个相对较新的项目,由Google根据多年来与BORG和Omega的容器使用情况开发而成。 Kubernetes可以被认为是谷歌的第三代容器编排,就像迭戈是Pivotal / VMware的第三代容器编排一样(v1在VMware编写; v2在VMware与Pivotal Labs帮助; v3在Pivotal接管项目后)答案 1 :(得分:10)
Cloud Foundry是一个很好的工具,假设您愿意始终在产品的限制范围内工作,因为它非常固执/规定。 Web UI很容易在第一天查看,但在您开始使用客户端并配置了CI / CD管道后很少使用。我发现Cloud Foundry很棒,直到弹出的用例在Cloud Foundry中不能完全支持。当您尝试解决这些问题时,交付这些用例会延迟项目,因此您将失去对基础架构的可见性,并支持那些主要在Cloud Foundry之外运行的组件的好处(想想多个数据库,kafka,hadoop,cassandra ,等等)我怀疑随着时间的推移,Docker的动力和Cloud Foundry的不灵活性将把用户带到Kubernetes,Mesos或Docker Swarm / Datacenter。 Cloud Foundry有可能赶上这三个,但由于这些开源项目的普及,这似乎不太可能。
答案 2 :(得分:8)
很难回答为什么公司会制造出与其他产品大致相似的产品。有很多原因。也许他们已经开始使用它并投入其中。也许他们(CF)认为Kubernetes做得很差或者说API /模型/细节错了。也许他们认为如果他们控制整个产品而不是贡献,他们可以更快地行动。
当然,我说这是一个Kubernetes开发者 - 可能会问Kubernetes vs Mesos,Amazon ECS vs Kubernetes,Docker Swarm vs Kubernetes的相同问题。
我希望随着时间的推移,我们都朝着同一个方向发展,可以更多地合作,花更少的时间重新创造彼此的工作。
至于Kubernetes - 重点是应用程序开发人员:简单而强大的原语,可以让您非常快速地构建和部署应用程序。我们依靠我们的经验(好吧,谷歌)用类似的技术来规划我们的课程。其他人会有不同的经历或意见。
答案 3 :(得分:3)
在我看来,一个显着的差异是他们正在采取的方法:
CF自动从3个组件构建运行时:用户提供的应用程序二进制文件,buildpack包含运行应用程序所需的中间件和操作系统映像(stemcell)。 CF用户(开发人员)必须仅提供应用程序二进制文件(例如可执行jar文件)。 CF负责其余部分,即打包和运行应用程序。
Kubernetes希望开发人员Docker中包含已经内置并准备运行的中间件和操作系统的映像。 为此,Kubernetes“部署清单”(例如Helm图表)不仅描述了单个应用程序或服务,还描述了在运行时构成解决方案的所有[微]服务。 您提交运行时的单个声明性描述,Kubernetes会关注实际的运行时状态与您提供的描述的匹配。
因此,CF方法允许它解决诸如“在整个云中替换具有修补安全漏洞的操作系统而无需停机服务”的用例。 但它也侧重于每服务部署服务,而不是系统的目标“理想”运行时的声明性描述。
答案 4 :(得分:2)
Cloud Foundry是一个开源的平台即服务云计算系统。 Cloud Foundry允许将项目部署在不同的空间,并将任何云服务绑定到您的应用程序。
Kubernete更像是用于容器(pod)的装饰工具,它可以自动执行容器化应用程序的部署,扩展和管理。它使用术语“豆荚”来定义容器或一组容器。
任何kubernetes部署至少需要两个资源:
1)deployment.yaml:此资源定义需要从容器寄存器,副本集(pod副本),推出策略,缩放和探测等中获取图像的哪个版本。
2)service.yaml:它是内部Pod与外界之间的接口,所有外部流量都将侦听此资源中定义的端口,从此端口将负载分配给内部Pod。
kubernetes提供了更多的入口资源,用于管理对群集中服务的外部访问,通常是http。通过Ingress,您可以提供负载平衡,SSL终止和基于名称的虚拟主机。
有关kubernetes的更多信息,您可以在下面找到: https://kubernetes.io/docs/
答案 5 :(得分:1)
[pcf vs kubernetes] [1] pcf和kubernetes之间的区别
PCF
(应用程序级别的平台抽象) •Pivotal Cloud Foundry是云原生应用程序开发的高级抽象。
•我们在应用程序级别拥有平台抽象,构建和部署完全配置的应用程序
•PCF是“应用程序”PaaS(也称为Cloud Foundry应用程序运行时)的一个示例
•开发人员将来维护应用程序
•适用于新应用程序,云原生应用程序。对于从事短生命周期和频繁发布的团队,PCF提供了出色的产品。
Kubernetes
(容器级平台抽象) •Kubernetes是一个容器调度程序或协调程序。
•我们在容器级别拥有平台抽象,构建和部署容器作为完整应用程序的一部分。
•Kubernetes是一个“容器”PaaS(有时称为CaaS)。
•使用容器编排工具,Developer将来创建并维护容器。
•对于新应用程序,为您的工程团队开展更多工作并降低生产力
答案 6 :(得分:0)
KUBERNETES引擎
Kubernetes Engine是一个托管的,可用于生产环境的环境,用于部署容器化的应用程序。它带来了我们在开发人员生产力,资源效率,自动化操作和开源灵活性方面的最新创新,以加快您的上市时间。
Kubernetes Engine于2015年推出,基于Google在容器中运行Gmail和YouTube等服务超过12年的经验。 Kubernetes Engine完全不需要安装,管理和操作自己的Kubernetes集群,因此您可以立即使用Kubernetes进行启动和运行。
Kubernetes Engine通过轻松部署,更新和管理您的应用程序和服务来实现快速的应用程序开发和迭代。 Kubernetes Engine也不仅仅适用于无状态应用程序。您可以附加永久存储,甚至可以在集群中运行数据库。只需描述您的应用程序容器所需的计算,内存和存储资源,然后Kubernetes Engine即可自动配置和管理基础云资源。对硬件加速器的支持使运行机器学习,通用GPU,高性能计算以及受益于专用硬件加速器的其他工作负载变得容易。
通过Google Cloud控制台中的内置Kubernetes Engine仪表板控制您的环境。使用常规的运行状况检查来检测和替换部署中已挂起或崩溃的应用程序。容器复制策略,监视和自动修复有助于确保您的服务高度可用,并为用户提供无缝的体验。 Google Site Reliability Engineers(SRE)不断监视您的集群及其计算,网络和存储资源,因此您不必这样做,从而使您有更多时间专注于应用程序。
从一台机器扩展到成千上万台:Kubernetes Engine自动缩放使您可以处理用户对服务的不断增长的需求,并在最重要的时候保持可用。然后,在安静的时段进行缩减以节省资金,或安排低优先级的批处理作业以耗尽备用周期。 Kubernetes Engine可帮助您充分利用资源池。
无论您身在何处,都可以使用Google Cloud中的全局虚拟私有云(VPC)连接并隔离集群,无论您身在何处。在单个全局任播IP地址后面使用公共服务以实现无缝负载平衡。防御容器上的DOS和其他类型的边缘攻击。
Kubernetes引擎运行经过认证的Kubernetes,以确保跨云和本地的可移植性。没有供应商锁定:您可以自由地将应用程序从Kubernetes Engine中取出,并在支持Kubernetes的任何位置(包括在您自己的本地服务器上)运行它们。您可以使用Google Cloud Platform(GCP)和生态系统中的第三方解决方案来定制监视,日志记录和CI / CD等集成。
云计算基础
Cloud Foundry具有基于容器的体系结构,可以使用任何编程语言运行应用程序。使用您现有的工具并且零修改代码,将应用程序部署到CF。在任何云上使用CF BOSH实例化,部署和管理高可用性Kubernetes集群。
部署到Cloud Foundry的应用程序通过Open Service Broker API访问外部资源。查看The Foundry中可用的服务和集成。
Cloud Foundry具有高度的适应性,可以承受技术的变化,因此您可以采用新的工具,语言或平台。
通过将应用程序与基础架构分离,您可以在内部,公共云或托管基础架构中就托管工作负载的位置做出单独的决定,并在几分钟内根据需要移动这些工作负载,而无需更改应用程序。
Cloud Foundry不会中断您当前的工作流程。它与您当前使用的技术和工具兼容-无论是AWS还是Docker或Kubernetes还是Java或.NET-以及您当前环境中的几乎所有东西。
Cloud Foundry是一个具有开放贡献和开放治理模型的开源项目,可为用户提供最大的灵活性,以避免供应商锁定。我们帮助监督一个由多元思想组成的值得信赖的社区,他们齐心协力应对各种挑战。更多的观点和不同的想法意味着更强大的代码。
答案 7 :(得分:0)