Kubernetes与CloudFoundry [英] Kubernetes vs. CloudFoundry
问题描述
CloudFoundry/Diego的下一版本将为Docker容器提供本机支持，这些容器将在多个主机之间进行编排[
The next version of CloudFoundry / Diego will offer native support for Docker containers which will be orchestrated across multible hosts [link]. This sounds very similar to Kubernetes.
当然，Kubernetes试图解决的问题更笼统，其中CloudFoundry更专注于应用程序开发.但是，对我而言，听起来两者都朝着相似的方向发展，CloudFoundry在简单的业务流程之上添加了更多功能.
Of course, the problem Kubernetes is trying to solve is more a generic, where CloudFoundry is more focussed on app development. However, for me it sounds both are heading into a similar direction and CloudFoundry is adding a lot more features on top of the plain orchestration.
所以我想知道Kubernetes会比CloudFoundry增加更多价值的用例吗?
So I'm wondering about use-cases where Kubernetes would add more value than CloudFoundry?
推荐答案
作为CloudFoundry(过去)和Kubernetes(现在)的提交者，我可能有资格回答这一问题.
As both a CloudFoundry (past) and Kubernetes (present) commiter, I'm probably uniquely qualified to answer this one.
我喜欢将CloudFoundry称为"Application PaaS"，将Kubernetes称为"Container PaaS"，但是鉴于两个项目随时间变化以在相同的市场中竞争，因此两者之间的区别相当微妙而动荡.
I like to call CloudFoundry an "Application PaaS" and Kubernetes a "Container PaaS", but the distinction is fairly subtle and fluid, given that both projects change over time to compete in the same markets.
两者之间的区别在于，CF具有一个过渡层，该过渡层需要一个(12因子)用户应用程序(例如jar或gem)和一个Heroku风格的buildpack(例如Java + Tomcat或Ruby)并生成一个droplet(类似于Docker映像). CF不会向用户公开容器化界面，而Kubernetes可以.
The distinction between the two is that CF has a staging layer that takes a (12-factor) user app (e.g. jar or gem) and a Heroku-style buildpack (e.g. Java+Tomcat or Ruby) and produces a droplet (analogous to a Docker image). CF doesn't expose the containerization interface to the user, but Kubernetes does.
CloudFoundry的主要受众是企业应用程序开发人员，他们希望使用Heroku样式的构建包来部署12要素无状态应用程序.
CloudFoundry's primary audience is enterprise application devs who want to deploy 12-factor stateless apps using Heroku-style buildpacks.
Kubernetes的受众范围更广一些，包括无状态应用程序和提供自己的容器的有状态服务开发人员.
Kubernetes' audience is a little broader, including both stateless application and stateful service developers who provide their own containers.
这种区别将来可能会改变:
This distinction could change in the future:
- CloudFoundry可以开始接受Docker映像(莱迪思接受Docker映像).
- Kubernetes可以添加图像生成层( OpenShift会执行类似的操作 ).
- CloudFoundry could start to accept docker images (Lattice accepts Docker images).
- Kubernetes could add an image generation layer (OpenShift does something like this).
随着两个项目的成熟和竞争，它们的相似性和差异将改变.因此，将以下功能与一粒盐进行比较.
As both projects mature and compete, their similarities and differences will change. So take the following feature comparison with a grain of salt.
CF和K8都具有许多相似的功能，例如容器化，命名空间，身份验证，
Both CF and K8s share many similar features, like containerization, namespacing, authentication,
Kubernetes的竞争优势:
Kubernetes competitive advantages:
- 对共享网络堆栈的容器的容器进行分组和缩放，而不仅仅是独立缩放
- 带上自己的容器
- 状态持久层
- 更大，更活跃的OSS社区
- 更具可扩展性的体系结构，具有可替换的组件和第三方插件
- 免费的Web GUI
CloudFoundry的竞争优势:
CloudFoundry competitive advantages:
- 成熟的身份验证，用户分组和多租户支持[x]
- 自带应用
- 附带的负载均衡器
- BOSH [x]部署，扩展并保持活力
- 强大的日志记录和指标聚合[x]
- 企业网络GUI [x]
[x]这些功能不是迭戈的一部分，也不包含在莱迪思中.
[x] These features are not part of Diego or included in Lattice.
CloudFoundry的竞争优势之一是拥有成熟的部署引擎BOSH，该引擎可实现诸如扩展，复活和监视核心CF组件之类的功能. BOSH还通过可插拔的云提供程序抽象支持许多IaaS层.不幸的是，BOSH的学习曲线和部署配置管理是噩梦般的. (作为BOSH提交者，我认为我可以准确地说出来.)
One of CloudFoundry's competitive advantages is that it has a mature deployment engine, BOSH, which enables features like scaling, resurrection and monitoring of core CF components. BOSH also supports many IaaS layers with a pluggable cloud provider abstraction. Unfortunately, BOSH's learning curve and deployment configuration management are nightmarish. (As a BOSH committer, I think I can say this with accuracy.)
Kubernetes的部署抽象仍处于起步阶段.核心存储库中有多个目标环境，但是它们并没有全部正常工作，没有经过良好测试或没有得到主要开发人员的支持.这主要是成熟的事情.可能会随着时间的流逝而改善并增加抽象度.例如， DCOS上的Kubernetes 允许将Kubernetes部署到现有的
Kubernetes' deployment abstraction is still in its infancy. Multiple target environments are available in the core repo, but they're not all working, well tested, or supported by the primary developers. This is mostly a maturity thing. One might expect this to improve over time and increase in abstraction. For example, Kubernetes on DCOS allows deploying Kubernetes to an existing DCOS cluster with a single command.
Diego是CF的Droplet执行代理的重写.它最初是在Kubernetes宣布之前开发的，随着竞争格局的发展，它具有更多的功能范围.它的最初目标是生成液滴(用户应用程序+ CF buildpack)并在Warden(在Go中重写时重命名为Garden)容器中运行它们.自成立以来，它也被重新包装为 Lattice ，有点像CloudFoundry-lite(尽管该名称是由
Diego is a rewrite of CF's Droplet Execution Agent. It was originally developed before Kubernetes was announced and has taken on more feature scope as the competitive landscape has evolved. Its original goal was to generate droplets (user application + CF buildpack) and run them in Warden (renamed Garden when rewritten in Go) containers. Since its inception it's also been repackaged as Lattice, which is somewhat of a CloudFoundry-lite (although that name was taken by an existing project). For that reason, Lattice is somewhat toy-like, in that it has deliberately reduced user audience and scope, explicitly missing features that would make it "enterprise-ready". Features that CF already provides. This is partly because Lattice is used to test the core components, without some of the overhead from the more complex CF, but you can also use Lattice in internal high-trust environments where security and multi-tenancy aren't as much of a concern.
值得一提的是，CloudFoundry和Warden(其容器引擎)也比Docker早了两年.
It's also worth mentioning that CloudFoundry and Warden (its container engine) predate Docker as well, by a couple years.
Kubernetes是一个相对较新的项目，由Google根据与BORG和Omega的多年容器使用情况而开发. Kubernetes可以被视为Google的第三代容器编排，就像Diego是Pivotal/VMware的第三代容器编排(在VMware编写的v1；在Pivotal Labs帮助下在VMware的v2；在接管项目后在Pivotal的v3)一样.
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).
这篇关于Kubernetes与CloudFoundry的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
