Kubernetes 对 CloudFoundry

很难回答为什么一个公司会建立一个产品实质上是相似的另一个产品。有很多原因。也许他们已经开始使用它，并投资于它。也许他们(CF)认为 Kubernetes 做得不好，或者在 API/模型/细节上有错误。也许他们认为，如果他们控制整个产品，而不是贡献，他们可以更快地行动。

当然，作为一个库伯内特的开发者，我可能会问同样的问题，比如 Kubernetes vs Mesos，亚马逊 ECS vs 库伯内特，或者 Docker Swarm vs 库伯内特。

I hope that over time, we are all trending in the same direction and can collaborate more and spend less time reinventing each other's work.

至于 Kubernetes，重点是应用程序开发人员: 简单而强大的原语，可以让你快速构建和部署大规模的应用程序。我们正在依靠我们的经验(好吧，谷歌的)与类似的技术来规划我们的路线。其他人会有不同的经历或观点。

作为 CloudFoundry (过去)和 Kubernetes (现在)的提交者，我可能是唯一有资格回答这个问题的人。

就像 Paas 一样

我喜欢把 CloudFoundry 称为“应用 PaaS”，而 Kubernetes 称为“容器 PaaS”，但鉴于两个项目随着时间的推移都会发生变化，以便在同一个市场上竞争，因此这两者之间的区别相当微妙和不确定。

这两者之间的区别在于 CF 有一个临时层，它接受一个(12-factor)用户应用程序(例如 jar 或 gem)和一个 Heroku 风格的构建包(例如 Java + Tomcat 或 Ruby) ，并生成一个小液滴(类似于 Docker 映像)。CF 不会向用户公开集装箱化界面，但库伯内特斯会。

观众

CloudFoundry 的主要受众是企业应用程序开发人员，他们希望使用 Heroku 风格的 buildpack 部署12因素的无状态应用程序。

Kubernetes 的受众范围更广一些，包括无状态应用程序和提供自己的容器的有状态服务开发人员。

这种区别将来可能会改变:

• CloudFoundry 可以开始接受 docker 映像(Lattice 接受 Docker 图像)。
• Kubernetes 可以添加一个图像生成层(OpenShift 做类似的事情)。

特征比较

随着两个项目的成熟和竞争，它们的相似点和不同点将会改变。因此，对下面的特征进行一些比较。

CF 和 k8都有很多相似的特性，比如集装箱化、名称空间、身份验证、,

Kubernetes competitive advantages:

• 对共享网络堆栈的容器进行分组和缩放，而不仅仅是单独缩放
• 自带容器
• 状态持久层
• 更大更活跃的 OSS 社区
• 具有可替换组件和第三方插件的更具扩展性的架构
• 免费的网络图形用户界面

CloudFoundry 竞争优势:

• 成熟的身份验证、用户分组和多租户支持[ x ]
• 带上你自己的应用程序
• 包括负载平衡器
• 由 BOSH [ x ]部署、扩展并保持生存
• 健壮的日志记录和度量聚合[ x ]
• 企业网络图形用户界面[ x ]

[ x ]这些特征不是迭戈的一部分，也不包含在格子中。

部署

CloudFoundry 的一个竞争优势是它有一个成熟的部署引擎 BOSH，它支持扩展、复活和监视核心 CF 组件等特性。BOSH 还支持许多 IaaS 层，提供可插入的云提供者抽象。不幸的是，博士的学习曲线和部署组态管理都是噩梦。(作为 BOSH 提交者，我想我可以准确地说出这一点。)

库伯内特的部署抽象仍处于初级阶段。核心回购中提供了多个目标环境，但并非所有环境都能正常工作、经过良好测试或得到主要开发人员的支持。这基本上是成熟的表现。随着时间的推移，人们可能会期望这种情况得到改善，并在抽象方面得到增加。例如，Kubernetes on DCOS允许使用一个命令将 Kubernetes 部署到现有的 DCOS集群。

历史背景

Diego 是 CF 的液滴执行代理的重写。它最初是在 Kubernetes 被宣布之前开发的，随着竞争环境的演变，它已经采用了更多的功能范围。它最初的目标是生成水滴(用户应用程序 + CF buildpack)并在 Warden (在 Go 中重写时重命名为 Garden)容器中运行它们。从一开始，它就被重新打包为 格子，这有点像 CloudFoundry-lite (尽管这个名字被 现有计划所取代)。由于这个原因，Lattice 有点像玩具，因为它有意地减少了用户受众和范围，明确地缺少了使其“企业级”的特性。CF 已经提供的特性。这在一定程度上是因为 Lattice 用于测试核心组件，而没有更复杂的 CF 带来的一些开销，但是您也可以在内部高信任环境中使用 Lattice，在这种环境中，安全性和多租户不是很重要。

同样值得一提的是 CloudFoundry 和 Warden (它的容器引擎)也比 Docker 早几年。

Kubernetes on the other hand, is a relatively new project that was developed by Google based on years of container usage with BORG and Omega. Kubernetes could be thought of as 3rd generation container orchestration at Google, the same way Diego is 3rd generation container orchestration at Pivotal/VMware (v1 written at VMware; v2 at VMware with Pivotal Labs help; v3 at Pivotal after it took over the project).

云铸造是一个伟大的工具，假设你愿意始终工作在提供的限制，因为它是非常固执己见/规定。Web UI 在第一天看起来很酷，但是在你开始和客户一起工作并配置好你的 CI/CD 管道之后很少使用。我发现，云铸造是伟大的，直到用例弹出，不容易在云铸造完全支持。交付这些用例可能会延迟项目，因为你试图解决这些问题，结果你失去了基础设施的可见性和这些组件的支持好处，然后大部分运行在外面的云 Foundry (想想多个数据库，卡夫卡，hadoop，卡桑德拉等)我怀疑随着时间的推移，围绕着 Docker 的势头和云 Foundry 的僵化将驱动用户到 Kubernetes，Mesos 或 Docker Swarm/Datacenter。Cloud Foundry 有可能赶上这三个项目，但由于这些开源项目的流行，这似乎不太可能。

在我看来，一个重要的区别在于他们所采取的方法:

CF 自动从3个组件构建运行时: 用户提供的应用程序二进制文件、包含运行应用程序所需的中间件的 buildpack 和操作系统映像(干细胞)。 The CF user (a developer) has to provide application binary only (e.g. an executable jar file). The CF takes care about the rest, that is packaging and running the app.

Kubernetes 希望开发人员能够提供 Docker 映像，其中包含已经内置并准备运行的中间件和操作系统。 为此，Kubernetes 的“部署清单”(例如 Helm 图表)不仅描述了单个应用程序或服务，而且还描述了在运行时构成解决方案的所有[微]服务。 You submit a single declarative description of your runtime and Kubernetes takes care about actual runtime state matches your provided description.

因此 CF 方法允许它处理这样的用例，比如“在整个云中用补丁安全缺陷替换操作系统，而不会导致服务停机”。 但是它也关注每个服务部署的服务，而不是系统的目标“理想”运行时的声明性描述。

Cloud Foundry 是一个开源平台即服务的云计算系统。 Cloud Foundry 允许在不同的空间部署项目，并且它将任何云服务绑定到您的应用程序。

Kubernete 更像是容器(pods)的装饰工具，可以自动部署、缩放和管理容器化应用程序。它使用术语 pods 来定义容器或容器组。

任何库伯内部署都至少需要两种资源:

Yaml: 这个资源定义了需要从容器注册表、复制集(pod 副本)、展示策略、缩放和探测等中提取哪个版本的图像。

Yaml: 它是内部 pods 和外部世界之间的一个接口，所有外部通信都将监听这个资源中定义的端口，从这个端口将负载分配给内部 pods。

另一个资源是库伯网提供的入口，它管理对集群中服务(通常是 http)的外部访问。通过 Inress，您可以提供负载平衡、 SSL 终止和基于名称的虚拟主机。

更多关于库伯内氏综合症的资料如下: Https://kubernetes.io/docs/

After 4 years trends look like this:

这些天，库伯内特集群变得非常便宜，而且库伯内特的工具环境更好。

此外，其他海报列出的大多数竞争特征最近很容易复制内库伯内斯这些天。