Kubernetes与CloudFoundry的比较
Answers:
作为CloudFoundry（过去）和Kubernetes（现在）的提交者，我可能有资格回答这一问题。
类似PaaS
我喜欢将CloudFoundry称为“ Application PaaS”，将Kubernetes称为“ Container PaaS”，但是鉴于两个项目随时间变化以在相同的市场中竞争，因此两者之间的区别相当微妙而又不稳定。
两者之间的区别在于，CF具有一个过渡层，该过渡层需要一个（12个因数）用户应用程序（例如jar或gem）和一个Heroku风格的buildpack（例如Java + Tomcat或Ruby）并生成一个droplet（类似于一个Docker映像）。CF不会向用户公开容器化接口，但是Kubernetes可以。
听众
CloudFoundry的主要受众是企业应用程序开发人员，他们希望使用Heroku样式的构建包来部署12要素无状态应用程序。
Kubernetes的受众范围更广一些，包括无状态应用程序和提供自己容器的有状态服务开发人员。
这种区别将来可能会改变：
- CloudFoundry可能开始接受Docker映像（莱迪思接受Docker映像）。
- Kubernetes可以添加一个图像生成层（OpenShift做这样的事情）。
功能比较
随着这两个项目的成熟和竞争，它们的相似性和差异将改变。因此，将以下功能与一粒盐进行比较。
CF和K8都有许多相似的功能，例如容器化，命名空间，身份验证，
Kubernetes的竞争优势：
- 对共享网络堆栈的容器的容器进行分组和缩放，而不仅仅是独立缩放
- 带上自己的容器
- 有状态持久层
- 更大，更活跃的OSS社区
- 具有可替换组件和第三方插件的更可扩展的体系结构
- 免费的Web GUI
CloudFoundry的竞争优势：
- 成熟的身份验证，用户分组和多租户支持[x]
- 带上自己的应用
- 随附的负载均衡器
- 由BOSH部署，扩展和保持活动[x]
- 强大的日志记录和指标聚合[x]
- 企业Web GUI [x]
[x]这些功能不是迭戈的一部分，也不包含在莱迪思中。
部署方式
CloudFoundry的竞争优势之一是拥有成熟的部署引擎BOSH，该引擎可实现诸如扩展，复活和监视核心CF组件之类的功能。BOSH还通过可插拔的云提供程序抽象支持许多IaaS层。不幸的是，BOSH的学习曲线和部署配置管理是噩梦。（作为BOSH提交者，我认为我可以准确地说出来。）
Kubernetes的部署抽象还处于起步阶段。核心存储库中提供了多个目标环境，但是它们并没有全部正常工作，没有经过良好测试或没有得到主要开发人员的支持。这主要是成熟的事情。可能会随着时间的流逝而改善并增加抽象度。例如，DCOS上的Kubernetes允许通过单个命令将Kubernetes部署到现有DCOS集群。
历史背景
Diego是CF的Droplet执行代理的重写。它最初是在Kubernetes宣布之前开发的，随着竞争格局的发展，它具有更多的功能范围。它的最初目标是生成液滴（用户应用程序+ CF buildpack）并在Warden（在Go中重写时重命名为Garden）容器中运行它们。自成立以来，它也被重新打包为Lattice，这有点像CloudFoundry-lite（尽管该名称是由现有项目使用的））。因此，Lattice有点像玩具，因为它故意减少了用户的听众和范围，明显缺少使它“可用于企业”的功能。CF已经提供的功能。这部分是因为Lattice用于测试核心组件，而没有来自更复杂的CF的一些开销，但是您也可以在内部高信任度环境中使用Lattice，而安全性和多租户并不是那么重要。
还值得一提的是，CloudFoundry和Warden（其容器引擎）也比Docker早了几年。
另一方面，Kubernetes是一个相对较新的项目，由Google根据BORG和Omega多年的容器使用情况而开发。Kubernetes可以被认为是Google的第三代容器编排，就像Diego是Pivotal / VMware的第三代容器编排（在VMware编写的v1；在Pivotal Labs帮助下在VMware的v2；在接管项目后在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-重点是应用程序开发人员：简单而强大的原语，可让您非常快速地大规模构建和部署应用程序。我们依靠类似技术的经验（当然是Google的经验）来规划我们的课程。其他人会有不同的经历或意见。
我认为，他们所采用的方法是一个重大区别：
CF从3个组件自动构建运行时：用户提供的应用程序二进制文件，包含运行该应用程序所需的中间件的buildpack和OS映像（干细胞）。CF用户（开发人员）仅需提供应用程序二进制文件（例如，可执行的jar文件）。CF负责其余的工作，即打包和运行应用程序。
Kubernetes希望开发人员可以在Docker映像中包含已经内置并可以运行的中间件和OS。为此，Kubernetes的“部署清单”（例如，Helm图表）不仅描述了单个应用程序或服务，而且还描述了在运行时构成您的解决方案的所有微服务。您只提交一个关于运行时的声明式描述，Kubernetes会考虑实际运行时状态是否与您提供的描述相匹配。
因此，CF方法允许它解决诸如“在整个云中更换具有补丁程序安全漏洞的操作系统而不会造成服务停机”之类的用例。但是，它也专注于每个服务部署的服务，而不是对系统目标“理想”运行时的声明式描述。
Cloud Foundry是一个开源的平台即服务云计算系统。Cloud Foundry允许将项目部署在不同的空间，并将任何云服务绑定到您的应用程序。
Kubernete更像是容器（pod）的装饰工具，它可以自动化容器化应用程序的部署，扩展和管理。它使用术语“容器”来定义容器或一组容器。
任何kubernetes部署至少需要两个资源：
1）deployment.yaml：此资源定义需要从容器寄存器，副本集（pod副本），推出策略，缩放和探测等中获取图像的版本。
2）service.yaml：它是内部Pod与外界之间的接口，所有外部流量都将侦听此资源中定义的端口，从此端口将负载分配给内部Pod。
kubernetes提供的更多资源是入口，用于管理对群集中服务的外部访问，通常是http。通过Ingress，您可以提供负载平衡，SSL终止和基于名称的虚拟主机。
有关kubernetes的更多信息，您可以在下面找到：https ://kubernetes.io/docs/
[pcf vs kubernetes] [1] pcf和kubernetes之间的区别
PCF
（在应用程序级别的平台抽象）•Pivotal Cloud Foundry是云原生应用程序开发的高层抽象。
•我们在应用程序级别具有平台抽象，可以构建和部署完全配置的应用程序
•PCF是“应用程序” PaaS（也称为Cloud Foundry应用程序运行时）的一个示例。
•开发人员将来维护应用程序
•非常适合新应用程序，云原生应用程序。对于使用短生命周期和频繁发布的团队，PCF提供了出色的产品。
Kubernetes
（容器级别的平台抽象）•Kubernetes是容器调度程序或协调器。
•我们在容器级别具有平台抽象，将容器构建和部署作为完整应用程序的一部分。
•Kubernetes是一个“容器” PaaS（有时称为CaaS）。
•使用容器编排工具，开发人员可以在将来创建然后维护容器。
•对于新应用，您的工程团队需要做更多的工作，并降低生产率
四年后的趋势如下：
如今，Kubernetes集群变得非常便宜，并且Kubernetes的工具环境更好。
最近，其他海报列出的大多数竞争功能也很容易在kubernetes中复制。