问题描述
CloudFoundry / Diego的下一个版本将为Docker容器提供原生支持，这些容器将在多个主机[链接]之间进行编排。这听起来与Kubernetes非常相似。
当然，Kubernetes试图解决的问题更为通用，其中CloudFoundry更专注于应用程序开发。然而，对我来说，它听起来都朝着类似的方向发展，而CloudFoundry正在简单的业务流程之上添加更多功能。
所以，我想知道Kubernetes会比CloudFoundry增加更多有价值的用例吗？
高票回答
作为CloudFoundry（过去）和Kubernetes（现在）的提交者，我可能有资格回答这个问题。
PaaS平台
我喜欢将CloudFoundry称为“应用程序PaaS”，将Kubernetes称为“容器PaaS”，但鉴于两个项目都会随着时间的推移而在同一市场中竞争，因此区别相当微妙和流畅。
两者之间的区别在于CF有一个暂存层，它采用（12-factor）用户应用程序（例如jar或gem）和Heroku风格的buildpack（例如Java + Tomcat或Ruby）并生成一个Droplet（类似于Docker镜像）。CF不会将容器化接口暴露给用户，但Kubernetes会这样做。
受众人员
CloudFoundry的主要受众是希望使用Heroku风格的buildpack部署12-factor无状态应用程序的企业应用程序开发人员。
Kubernetes的受众范围更广，包括无状态应用程序和提供自己容器的有状态服务开发人员。
这种区别可能在未来发生变化：
- CloudFoundry开始接受docker镜像
- Kubernetes可以添加镜像生成层
功能比较
随着两个项目的成熟和竞争，它们的异同将发生变化。因此，请将以下特征进行比较。
CF和K8都有许多相似的功能，如容器化，命名空间，身份验证。
Kubernetes的竞争优势：
- 对共享网络堆栈的容器进行分组和扩展，而不是仅仅进行独立扩展
- 提供自己的容器
- 有状态持久层
- 更大、更活跃的OSS社区
- 具有可替换组件和第三方插件
- 免费的web GUI
CloudFoundry的竞争优势：
- 成熟的身份验证，用户分组和多租户支持[x]
- 提供自己的APP
- 包括负载均衡器
- 由BOSH部署，扩展并保持状态[x]
- 强大的日志记录和度量聚合[x]
- 企业Web GUI [x]
[x] 这些功能不是Diego的一部分或包含在Lattice中。
部署
CloudFoundry的竞争优势之一是它拥有成熟的部署引擎BOSH，可以实现核心CF组件的扩展，恢复和监控等功能。BOSH还支持许多具有可插拔云提供程序抽象的IaaS层。不幸的是，BOSH的学习曲线和部署配置管理是噩梦。（作为BOSH提交者，我想我可以准确地说出来。）
Kubernetes的部署抽象仍处于起步阶段。核心仓库中提供了多个目标环境，但它们并非全部正在运行，经过良好测试或得到主要开发人员的支持。这主要是成熟的事情。人们可能会期望这会随着时间的推移而改进并且会增加抽象。例如，DCOS上的Kubernetes允许使用单个命令将Kubernetes部署到现有DCOS群集。
历史背景
Diego是CF的Droplet执行代理的重写。它最初是在Kubernetes宣布之前开发的，随着竞争格局的演变，它已经具有更多的功能范围。它的最初目标是生成droplets（用户应用程序 + CF buildpack）并在Warden（在Go中重写时重命名为Garden）容器中运行它们。自成立以来，它也被重新打包为Lattice，它有点像CloudFoundry-lite（虽然这个名字是由现有项目拍摄的）。出于这个原因，Lattice有点像玩具一样，因为它故意减少了用户的观众和范围，显然缺少使其达到“企业就绪”的功能。CF已经提供的功能。这部分是因为Lattice用于测试核心组件，而没有来自更复杂的CF的一些开销，但您也可以在内部高信任环境中使用Lattice，其中安全性和多租户不是那么重要。
值得一提的是，CloudFoundry和Warden（它的容器引擎）也早于Docker，差不多几年了。
另一方面，Kubernetes是一个相对较新的项目，由Google根据BORG和Omega多年的容器使用情况开发而成。Kubernetes可以被认为是谷歌的第三代容器编排，就像Diego是Pivotal / VMware的第三代容器编排一样（v1在VMware编写; v2在VMware与Pivotal Labs帮助; v3在Pivotal接管项目后）。