CloudFoundry / Diego的下一个版本将提供原生支持Docker容器，这些容器会在多个主机上进行编排[链接]。这听起来与Kubernetes非常相似。
当然，Kubernetes试图解决的问题更加通用，而CloudFoundry更专注于应用程序开发。然而，对我而言，两者看起来都朝着类似的方向发展，并且CloudFoundry在纯编排之上增加了许多功能。
因此，我想知道Kubernetes相比CloudFoundry在哪些使用案例中能够提供更多的价值呢？
6个回答
207
作为CloudFoundry（过去）和Kubernetes（现在）的贡献者，我可能是唯一有资格回答这个问题的人。
我喜欢称CloudFoundry为“应用程序PaaS”，Kubernetes为“容器PaaS”，但由于两个项目随着时间的推移在同一市场上竞争而发生变化，所以区别相当微妙和流动。
两者之间的区别在于CF具有一个暂存层，它接收（12因素）用户应用程序（例如jar或gem）和一个Heroku风格的构建包（例如Java + Tomcat或Ruby），并生成一个droplet（类似于Docker镜像）。CF不向用户公开容器化界面，但Kubernetes则公开。
CloudFoundry的主要受众是企业应用程序开发人员，他们希望使用Heroku风格的构建包部署12因素无状态应用程序。
Kubernetes的受众范围更广，包括提供自己的容器的无状态应用程序和有状态服务开发人员。
这种区别未来可能会发生改变：
我喜欢称CloudFoundry为“应用程序PaaS”，Kubernetes为“容器PaaS”，但由于两个项目随着时间的推移在同一市场上竞争而发生变化，所以区别相当微妙和流动。
两者之间的区别在于CF具有一个暂存层，它接收（12因素）用户应用程序（例如jar或gem）和一个Heroku风格的构建包（例如Java + Tomcat或Ruby），并生成一个droplet（类似于Docker镜像）。CF不向用户公开容器化界面，但Kubernetes则公开。
CloudFoundry的主要受众是企业应用程序开发人员，他们希望使用Heroku风格的构建包部署12因素无状态应用程序。
Kubernetes的受众范围更广，包括提供自己的容器的无状态应用程序和有状态服务开发人员。
这种区别未来可能会发生改变：
- CloudFoundry可以开始接受Docker镜像（Lattice接受Docker镜像）。
- Kubernetes可以添加镜像生成层（OpenShift做了类似的事情）。
功能比较
随着两个项目的成熟和竞争，它们的相似之处和不同之处也会发生变化。因此，请谨慎参考以下功能比较。
CF和K8s都有许多相似的功能，例如容器化、命名空间、认证等。
Kubernetes的竞争优势：
- 分组和扩展共享网络堆栈的容器pod，而不仅是独立扩展
- 自带容器
- 有状态持久层
- 更大、更活跃的开源社区
- 更可扩展的架构，可替换组件和第三方插件
- 免费Web GUI
CloudFoundry的竞争优势：
- 成熟的身份验证、用户分组和多租户支持 [x]
- 自带应用程序
- 包含负载均衡器
- 通过BOSH进行部署、扩展和保持在线 [x]
- 强大的日志记录和指标聚合 [x]
- 企业级Web GUI [x]
[x] 这些功能不是Diego或Lattice的一部分。
部署
CloudFoundry的竞争优势之一是其有成熟的部署引擎BOSH，可以实现核心CF组件的扩展、恢复和监控等功能。BOSH还支持许多IaaS层次，具有可插拔的云提供商抽象层。不幸的是，BOSH的学习曲线和部署配置管理比较困难。(作为BOSH提交者，我认为我可以准确地说这个。)
Kubernetes的部署抽象仍处于萌芽阶段。核心库中提供了多个目标环境，但并非所有目标环境都经过良好测试或得到主要开发人员的支持。这主要是因为成熟度问题。随着时间的推移和抽象程度的提高，人们可以预期这种情况会有所改善。例如，在DCOS上运行Kubernetes 可以通过一个命令将Kubernetes部署到现有的DCOS集群中。历史背景
Diego是CF的Droplet Execution Agent的重写版本。它最初是在Kubernetes发布之前开发的，并随着竞争环境的演变而扩大了更多功能范围。它最初的目标是生成droplets（用户应用程序+CF构建包），并在Warden（在Go中重写时更名为Garden）容器中运行它们。自从它的诞生以来，它也被重新打包成Lattice，这有点像CloudFoundry-lite（虽然这个名字已经被一个现有项目所使用）。因此，Lattice有点像玩具，因为它有意缩小了用户受众和范围，明确地缺少使其“企业就绪”的功能。这部分原因是因为Lattice用于测试核心组件，没有一些来自更复杂的CF的额外负担，但您也可以在内部高信任环境中使用Lattice，其中安全性和多租户性不太值得关注。值得一提的是，CloudFoundry和Warden（其容器引擎）也比Docker早几年。
Kubernetes是一个相对较新的项目，由Google根据多年使用BORG和Omega容器的经验开发而来。在Google，Kubernetes可以被认为是第三代容器编排，就像Diego是Pivotal/VMware的第三代容器编排一样（v1由VMware编写；v2由VMware与Pivotal Labs合作编写；v3在Pivotal接管该项目后编写）。请注意保留HTML标签。- KarlKFI
9
1Kubernetes目前尚未包含负载均衡器实现，但在这方面的工作正在进行中。它提供了一种向云服务提供商请求提供负载均衡器的方式，但只有少数云服务提供商实际上会提供（我认为是GCE和AWS）。CF默认情况下会自动提供负载均衡器。 - KarlKFI
关于“强大的日志记录和指标聚合”，我认为这主要取决于成熟度。看起来两者都可以将日志与ElasticSearch和Kibana集成，但CF的解决方案完全支持提供的消息总线（NATS）上的日志和指标的高可用性。K8s公开了指标，但据我所知，没有包含或集成处理、存储、处理或聚合。 - KarlKFI
2从 Kubernetes 1.1 开始，Kubernetes 现在支持自动缩放和基于 HTTP 路径的负载均衡（http://blog.kubernetes.io/2015/11/Kubernetes-1-1-Performance-upgrades-improved-tooling-and-a-growing-community.html?m=1）。 - Brendan Burns
2我觉得你的“企业Web GUI”项目点中有很多微妙的好处。例如，GUI有一个市场，在那里你可以点击一个按钮说，“我想要一个数据库”或者“我想要一个持久队列”。它会回复，“好的，这是你的连接字符串”。我对使用k8s的印象是，这些事情都要靠自己解决：找到一个Docker容器并编写部署脚本，以便你的环境可以使用它。CF也提供了一个CLI来完成所有这些工作。 - Daniel Kaplan
1关于 Kubernetes 和 Cloud Foundry 的企业版套餐，还有很多值得探讨的地方。不幸的是，从他们的网站和文档中很难确定 PCF 实际具有哪些功能。我的比较主要是针对开源版。Kubernetes 也有专为企业定制的供应商，最后统计了4或5个不同的供应商。它们每个都有自己的功能、包管理器和安全插件等特性。 - KarlKFI
显示剩余4条评论
12
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有可能追赶这三者，但由于这些开源项目的普及度，这似乎不太可能。
- Jim Kruk
1
3我是一名Cloud Foundry的初学者。您能否举一些需要在Cloud Foundry中不容易支持的功能的使用案例？ - Somu
9
很难回答为什么一家公司会建造一个与另一个产品基本相似的产品。原因有很多。也许他们已经开始使用它并对其进行了投资。也许他们（CF）认为Kubernetes做得不好或API / 模型/细节出现错误。也许他们认为如果控制整个产品而不是贡献，他们可以更快地移动。
当然，我是一名Kubernetes开发人员 - 人们可能会问同样的问题：Kubernetes vs Mesos，Amazon ECS vs Kubernetes或Docker Swarm vs Kubernetes。
我希望随着时间的推移，我们都朝着同一个方向发展，可以更多地合作，花费更少的时间重新发明彼此的工作。
至于Kubernetes-重点在于应用程序开发人员：简单而强大的基元，让您能够快速构建和部署应用程序。我们依靠我们的经验（好吧，Google的经验）来规划我们的课程。其他人会有不同的经验或意见。
当然，我是一名Kubernetes开发人员 - 人们可能会问同样的问题：Kubernetes vs Mesos，Amazon ECS vs Kubernetes或Docker Swarm vs Kubernetes。
我希望随着时间的推移，我们都朝着同一个方向发展，可以更多地合作，花费更少的时间重新发明彼此的工作。
至于Kubernetes-重点在于应用程序开发人员：简单而强大的基元，让您能够快速构建和部署应用程序。我们依靠我们的经验（好吧，Google的经验）来规划我们的课程。其他人会有不同的经验或意见。
- Tim Hockin
1
10但同样也可以这样说：关于Kubernetes也可以这么说；Cloud Foundry v1在2011年推出，v2是在2013年中期与Docker首次开源大约同时构建和推出的容器，Diego（使用Go重写容器引擎）在2014年初开始提交代码，比Kube甚至早了6个月左右。也许人们认为CF做错了什么，等等，但许多项目显然正在重新创建它。我们还可以看到Swarm与K8S、Nomad或Marathon等之间的竞争。尽管如此，在开源领域中既有合作又有竞争，希望能在有意义的地方达成共识。 - Stuart Charlton
4
在我看来，一个显著的区别是它们采取的方法：
Cloud Foundry自动从3个组件构建运行时：用户提供的应用程序二进制文件、包含运行应用程序所需中间件的构建包和一个OS镜像（stemcell）。CF用户（开发人员）只需提供应用程序二进制文件（例如可执行jar文件），CF负责其余部分，即打包和运行应用程序。
Kubernetes期望开发人员提供包含中间件和操作系统的Docker镜像，已经构建并准备好运行。为此，Kubernetes“部署清单”（例如Helm图表）不仅描述单个应用程序或服务，还描述了在运行时组成解决方案的所有[微]服务。您提交对运行时的单个声明性描述，Kubernetes负责确保实际运行状态与您提供的描述相匹配。
因此，CF方法使其能够解决诸如“在整个云中替换带有修补安全漏洞的操作系统而无需停机”的用例。但它也专注于逐个服务进行部署，而不是针对系统目标“理想”的运行时的声明性描述。
- Sergey Shcherbakov
3
4年过去了，趋势如下：
现在，Kubernetes集群变得非常便宜，并且Kubernetes的工具环境更好。
此外，其他帖子列出的大多数竞争功能现在在Kubernetes内部很容易复制。
- Marcin Szymczak
2
Cloud Foundry是一个开源的平台即服务云计算系统。它允许在不同空间部署项目，并将任何云服务绑定到您的应用程序中。
Kubernetes更像是容器（pod）的装饰工具，可以自动化部署、扩展和管理容器化应用程序。它使用术语“pods”来定义容器或一组容器。
任何Kubernetes部署至少需要两个资源：
1）deployment.yaml：该资源定义了需要从容器注册表中选择哪个版本的映像，副本集（pod副本），滚动升级策略，扩展和探测等。
2）service.yaml：它是内部pod和外部世界之间的接口，所有外部流量都将侦听在此资源中定义的端口上，从而将负载分配给内部pod。
另外，Kubernetes提供了Ingress资源，用于管理群集中服务的外部访问，通常是HTTP。通过Ingress，您可以提供负载平衡、SSL终止和基于名称的虚拟主机。
有关Kubernetes的更多信息，请参见以下链接：https://kubernetes.io/docs/
Kubernetes更像是容器（pod）的装饰工具，可以自动化部署、扩展和管理容器化应用程序。它使用术语“pods”来定义容器或一组容器。
任何Kubernetes部署至少需要两个资源：
1）deployment.yaml：该资源定义了需要从容器注册表中选择哪个版本的映像，副本集（pod副本），滚动升级策略，扩展和探测等。
2）service.yaml：它是内部pod和外部世界之间的接口，所有外部流量都将侦听在此资源中定义的端口上，从而将负载分配给内部pod。
另外，Kubernetes提供了Ingress资源，用于管理群集中服务的外部访问，通常是HTTP。通过Ingress，您可以提供负载平衡、SSL终止和基于名称的虚拟主机。
有关Kubernetes的更多信息，请参见以下链接：https://kubernetes.io/docs/
- Manvendra Jina
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接