Kubernetes与CloudFoundry
CloudFoundry / Diego的下一个版本将为Docker容器提供本地支持，Docker容器将在多个主机上进行编排[ 链接 ]。 这听起来和Kubernetes非常相似。
当然，Kubernetes试图解决的问题更多的是generics，CloudFoundry更侧重于应用程序开发。 然而，对我来说，这听起来都正在走向一个类似的方向，CloudFoundry在纯业务stream程之上添加了更多的function。
所以我想知道Kubernetes会比CloudFoundry增加更多价值的用例吗？
作为CloudFoundry（过去）和Kubernetes（现在）的提交者，我可能有唯一的资格来回答这个问题。
PaaS的样
我喜欢将CloudFoundry称为“应用程序PaaS”，将Kubernetes称为“Container PaaS”，但鉴于两个项目随时间变化以在相同市场上竞争，所以区别相当微妙和stream畅。
两者之间的区别在于，CF具有一个接受（12因子）用户应用程序（例如jar或gem）和Heroku风格构build包（例如Java + Tomcat或Ruby）的中间层，并生成一个液滴（类似于Docker镜像）。 CF不向用户公开集装箱接口，但Kubernetes。
听众
CloudFoundry的主要受众是想要使用Heroku风格的构build包部署12因素无状态应用程序的企业应用程序开发人员。
Kubernetes的观众范围更广一些，包括无国籍的应用程序和提供自己的容器的有状态的服务开发人员。
这种区别在未来可能会改变：
- CloudFoundry可以开始接受Docker镜像 （ 莱迪思接受Docker镜像 ）。
- Kubernetes可以添加一个图像生成层（ OpenShift做这样的事情 ）。
function比较
随着两个项目的成熟和竞争，他们的异同将会改变。 所以用一粒盐做下面的特征比较。
CF和K8都有许多相似的function，如容器化，命名空间，authentication，
Kubernetes竞争优势：
- 对共享networking堆栈的容器进行分组和缩放，而不是单独扩展
- 带上你自己的容器
- 有状态的持久层
- 更大，更活跃的OSS社区
- 更可扩展的架构，可更换组件和第三方插件
- 免费网页graphics用户
CloudFoundry的竞争优势：
- 成熟的身份validation，用户分组和多租户支持[x]
- 带上你自己的应用程序
- 包括负载平衡器
- BOSH [x]部署，扩展并保持活力
- 可靠的日志logging和度量聚合[x]
- 企业网页界面[x]
[x]这些function不属于迭戈的一部分，也不包含在莱迪思中。
部署
CloudFoundry的竞争优势之一就是拥有一个成熟的部署引擎BOSH，可以实现对核心CF组件的扩展，复活和监控等function。 BOSH还通过可插拔的云提供商抽象支持许多IaaS层。 不幸的是，BOSH的学习曲线和部署configurationpipe理是噩梦般的。 （作为一名BOSH提交者，我想我可以准确地说出这一点。）
Kubernetes的部署抽象仍处于起步阶段。 核心回购中提供了多个目标环境，但是它们并不都是正常工作，经过良好testing或者由主要开发人员支持的。 这主要是一个成熟的事情。 人们可能会认为这会随着时间的推移而提高，并在抽象上增加。 例如， DCOS上的Kubernetes允许使用单个命令将Kubernetes部署到现有的DCOS群集。
历史背景
迭戈是重写CF的液滴执行代理。 它最初是在Kubernetes宣布之前开发的，随着竞争格局的发展，它已经具备了更多的function范围。 它的最初目标是生成水滴（用户应用程序+ CF buildpack），并运行在Warden（更名为Garden时重写Go）容器中。 自成立以来，它也被重新包装为莱迪思 ，它有点像CloudFoundry-lite（虽然这个名字是由一个现有的项目拍摄的）。 出于这个原因，莱迪思有点像玩具一样，因为它有意地减less了用户的观众和范围，明确地缺less了使其“企业就绪”的特征。 CF已经提供的function。 这部分是因为莱迪思被用来testing核心组件，而没有更复杂的CF的开销，但是你也可以在内部高信任的环境中使用莱迪思，在这种环境中安全性和多租户并不是那么重要。
另外值得一提的是，CloudFoundry和Warden（它的容器引擎）也比Docker早几年。
另一方面，Kubernetes是一个相对较新的项目，由Google根据多年来与BORG和Omega合作开发的容器开发而成。 Kubernetes可以被认为是谷歌的第三代容器编排，就像Diego在Pivotal / VMware上的第三代容器编排一样（在VMware上编写v1;在Pivotal Labs上，在VMware上v2;在Pivotal上接pipe项目后， 。
Cloud Foundry是一个很好的工具，假设你愿意在产品的限制范围内工作，因为它是非常有见地的/规定的。 Web UI很酷，可以在第一天看到，但在开始使用客户端并configuration您的CI / CDpipe道后很less使用。 我发现，Cloud Foundry非常棒，直到用户在Cloud Foundry中完全不易支持的情况下popup。 当您尝试解决这些问题时，交付这些用例可能会延迟项目，结果您将失去基础架构的可见性，并且支持那些大部分在Cloud Foundry之外运行的组件的益处（考虑多个数据库，kafka，hadoop，cassandra等等）我怀疑随着时间的推移，围绕Docker的动力和Cloud Foundry的僵化将推动用户进入Kubernetes，Mesos或者Docker Swarm / Datacenter。 Cloud Foundry有可能赶上这三个，但由于这些开源项目的普及，似乎不大可能。
很难回答为什么一家公司要生产与另一种产品相似的产品。 有很多原因。 也许他们已经开始使用它，并投资于它。 也许他们（CF）认为Kubernetes做得不好，或者API /模型/细节错误。 也许他们认为如果他们控制整个产品而不是贡献，他们可以更快地行动。
当然，我把这个说成是Kubernetes的开发者 – 你可能会问Kubernetes vs Mesos，Amazon ECS vs Kubernetes或Docker Swarm与Kubernetes相同的问题。
我希望随着时间的stream逝，我们都朝着相同的方向发展，可以更多地合作，花更less的时间重新开展对方的工作。
至于Kubernetes，重点是应用程序开发人员：简单而强大的原始程序，可让您快速构build和部署应用程序。 我们倾向于使用类似技术的经验（以及Google的经验）来绘制我们的课程。 其他人会有不同的经验或意见。
