CloudFoundry / Diego 的下一版本将为 Docker 容器提供本机支持，这些容器将在多个主机 [link] 之间进行编排。 这听起来与 Kubernetes 非常相似。
当然，Kubernetes 试图解决的问题更笼统，CloudFoundry 更专注于应用程序开发。但是，对我来说，听起来两者都在朝着相似的方向发展，而且 CloudFoundry 在普通编排的基础上添加了更多功能。
所以我想知道 Kubernetes 会比 CloudFoundry 增加更多价值的用例吗？
【问题讨论】：
作为 CloudFoundry（过去）和 Kubernetes（现在）的提交者，我可能是唯一有资格回答这个问题的人。
我喜欢将 CloudFoundry 称为“应用程序 PaaS”，将 Kubernetes 称为“容器 PaaS”，但两者之间的区别是相当微妙和流动的，因为这两个项目会随着时间的推移而变化以在相同的市场中竞争。
两者之间的区别在于 CF 有一个暂存层，它接受一个（12 因子）用户应用程序（例如 jar 或 gem）和一个 Heroku 样式的构建包（例如 Java+Tomcat 或 Ruby）并生成一个 droplet（类似于 Docker 映像）。 CF 不会向用户公开容器化接口，但 Kubernetes 会。
CloudFoundry 的主要受众是希望使用 Heroku 样式构建包部署 12 要素无状态应用程序的企业应用程序开发人员。
Kubernetes 的受众范围更广一些，包括提供自己的容器的无状态应用程序和有状态服务开发人员。
这种区别将来可能会改变：
随着两个项目的成熟和竞争，它们的异同会发生变化。因此，将以下特征与一粒盐进行比较。
CF 和 K8s 都有许多相似的特性，比如容器化、命名空间、身份验证，
Kubernetes 竞争优势：
CloudFoundry 竞争优势：
[x] 这些功能不属于 Diego 或 Lattice。
CloudFoundry 的竞争优势之一是它拥有成熟的部署引擎 BOSH，它支持扩展、复活和监控核心 CF 组件等功能。 BOSH 还支持许多具有可插拔云提供商抽象的 IaaS 层。不幸的是，BOSH 的学习曲线和部署配置管理是噩梦般的。 （作为 BOSH 提交者，我想我可以准确地说出来。）
Kubernetes 的部署抽象仍处于起步阶段。核心 repo 中提供了多个目标环境，但它们并非全部正常工作、经过良好测试或得到主要开发人员的支持。这主要是成熟的事情。人们可能期望这会随着时间的推移而改进并增加抽象。例如，Kubernetes on DCOS 允许使用单个命令将 Kubernetes 部署到现有的DCOS 集群。
Diego 是对 CF 的 Droplet Execution Agent 的重写。它最初是在 Kubernetes 发布之前开发的，随着竞争格局的发展，它具有更多的功能范围。它最初的目标是生成液滴（用户应用程序 + CF buildpack）并在 Warden（用 Go 重写时重命名为 Garden）容器中运行它们。自成立以来，它也被重新包装为Lattice，这有点像CloudFoundry-lite（尽管该名称是由existing project 取的）。出于这个原因，Lattice 有点像玩具，因为它故意减少了用户的受众和范围，明确地缺少使其“为企业做好准备”的功能。 CF 已经提供的功能。这部分是因为 Lattice 用于测试核心组件，没有来自更复杂 CF 的一些开销，但您也可以在安全性和多租户不太关注的内部高信任环境中使用 Lattice .
还值得一提的是，CloudFoundry 和 Warden（其容器引擎）也比 Docker 早了几年。
另一方面，Kubernetes 是一个相对较新的项目，由 Google 基于多年来与 BORG 和 Omega 的容器使用情况开发。 Kubernetes 可以被认为是 Google 的第三代容器编排，就像 Diego 是 Pivotal/VMware 的第三代容器编排一样（v1 在 VMware 编写；v2 在 VMware 的 Pivotal Labs 帮助下；在 Pivotal 接管项目后的 v3） .
【讨论】：
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 有可能赶上这三个，但由于这些开源项目的流行，这似乎不太可能。
【讨论】：
很难回答为什么一家公司会制造一种与另一种产品大体相似的产品。有很多原因。也许他们已经开始使用它并对其进行了投资。也许他们（CF）认为 Kubernetes 做得不好，或者 API/模型/细节有误。也许他们认为如果他们控制整个产品而不是做出贡献，他们可以更快地行动。
诚然，作为一名 Kubernetes 开发人员，我这么说 - 人们可能会问 Kubernetes 与 Mesos、Amazon ECS 与 Kubernetes 或 Docker Swarm 与 Kubernetes 的相同问题。
我希望随着时间的推移，我们都朝着同一个方向发展，可以更多地合作，花更少的时间重新发明彼此的工作。
至于 Kubernetes，重点是应用开发者：简单而强大的原语，让您可以非常快速地大规模构建和部署应用。我们依靠我们在类似技术方面的经验（嗯，谷歌的）来规划我们的路线。其他人会有不同的经历或意见。
【讨论】：
在我看来，一个显着的不同是他们采用的方法：
CF 自动从 3 个组件构建运行时：用户提供的应用程序二进制文件、包含运行应用程序所需的中间件的 buildpack 和一个 OS 映像（一个 stemcell）。 CF 用户（开发人员）必须仅提供应用程序二进制文件（例如可执行的 jar 文件）。 CF 负责其余的工作，即打包和运行应用程序。
Kubernetes 期望开发人员 Docker 映像包含已内置并准备运行的中间件和操作系统。 为此，Kubernetes “部署清单”（例如 Helm 图表）不仅描述了单个应用程序或服务，还描述了在运行时构成您的解决方案的所有 [微] 服务。 您提交运行时的单一声明性描述，Kubernetes 会注意实际运行时状态是否与您提供的描述相匹配。
因此，CF 方法允许它解决此类用例，例如“在您的服务不停机的情况下，用整个云中已修补的安全漏洞替换操作系统”。 但它也关注每个服务部署的服务，而不是对系统目标“理想”运行时的声明性描述。
【讨论】：
Cloud Foundry 是一个开源平台即服务云计算系统。 Cloud Foundry 允许将项目部署在不同的空间中，并将任何云服务绑定到您的应用程序。
Kubernetes 更像是容器（pod）的装饰工具，它可以自动部署、扩展和管理容器化应用程序。它使用术语 pod 来定义容器或容器组。
任何 kubernetes 部署至少需要两个资源：
1) deployment.yaml ：该资源定义了它需要从您的容器注册、副本集（pod 副本）、推出策略、缩放和探测等中获取哪个版本的映像。
2) service.yaml ：它是您的内部 pod 和外部世界之间的接口，所有外部流量都将侦听此资源中定义的端口，并将负载分配到内部 pod。
更多资源是 kubernetes 提供的入口，用于管理对集群中服务的外部访问，通常是 http。通过 Ingress，您可以提供负载平衡、SSL 终止和基于名称的虚拟主机。
您可以在下面找到有关 Kubernetes 的更多信息： https://kubernetes.io/docs/
【讨论】：