上个月，Pivotal [url=https://content.pivotal.io/blog/pivotal-brings-the-magic-of-cf-push-to-kubernetes]宣布[/url]他们的旗舰产品 - 基于Cloud Foundry的Pivotal应用服务 将使用Kubernetes。我进行了实验：请求访问私有alpha，并被允许进入。在添加一些资源后，我在实验室环境中部署了它。
安装完成后，cf push足以让我的应用程序代码在Kubernetes上作为容器运行。
- 所以您可能会问：“但是等等，自2010年以来，部署在Cloud Foundry上的应用程序不会作为容器运行吗？”
是的。
- “Cloud Foundry没有配备运行所有这些应用程序的容器协调器（如Kubernetes）吗？”
是的，它的协调器被称为Diego。
- “它Diego更复杂吗？”
相反。它不要求用户投资容器或容器协调器知识。
- “我想它Diego必不如Kubernetes成熟？”
不完全是这样。它及其前身 - Droplet执行代理（DEA） - 多年来已经在这个世界上最大的企业组织中运行了数十万甚至数百万的应用程序。事实上，甚至在Kubernetes或Docker之前还是那么一回事。
- “但我们肯定可以用Kubernetes做更多的事，对吧？”
是的，也不是，Kubernetes有更多的旋钮和螺栓来调整应用程序的运行方式。但是，它还没有Diego现在提供的所有选项。
- “我很困惑：鉴于上述情况，你为什么要用Kubernetes取代Diego？”
因为开源并不是一场零和游戏，正数之和由玩家数决定。
- “再来一次？”
无论喜欢与否，到目前为止，致力于Kubernetes的组织数量如此巨大，几乎可以肯定它将成为基础架构的未来，因为虚拟机已经摆在面前。
- “因此，我们的想法是从转向标准平台中获利？”
Cloud Foundry贡献者将不再需要维护他们自己的自定义容器协调器，因为他们可以释放他们最好的人来处理技术栈中更高的功能。增加更多价值。
其次，Kubernetes社区有这样的势头，当我们从同一点开始时，可能会以类似的方式替换Cloud Foundry的更多组件。
最后，客户特别要求它。尽管容器协调器只是更丰富的Cloud Foundry产品中的实现细节，但仍有一些人关心。
- “当我们拥有Kubernetes时，我们还需要Cloud Foundry吗？”
没有任何改变。虽然Kubernetes可能是基础架构的未来，但它不是开发人员平台。但有些人认为也是开发者平台，但如果你强迫 - 或允许 - 你的开发人员直接与容器和容器协调器一起工作，你可以确定他们将大部分时间花在这上面，而不是编写为你的业务增加价值的代码。
- “所以在K8上的PAS中，一切都作为容器运行吗？”
不。只是应用程序。两年前，IBM启动了一项名为Eirini的计划，将Cloud Foundry的容器协调器从Diego切换到Kubernetes。Pivotal今年加入，结果是Kubernetes（K8s）的Pivotal Application Service（PAS）。
还有另一个计划 - 项目Quarks - 旨在将Cloud Foundry组件（目前使用虚拟机上的BOSH版本部署）切换到Kubernetes可部署的Helm图表。这还没有在K8上的PAS中。此外，Helm包管理器存在严重问题，需要在它变得像BOSH一样坚固之前加以解决。
- “最终用户会注意到什么吗？”
理想情况下，不会注意到。Cloud Foundry的最终用户一直是开发人员，对他们来说没什么变化。请注意，这不是第一次或最后一次将Cloud Foundry的自定义元素替换为已成为开源标准的软件。例如，自定义路由器层正在被Istio服务网格取代，这项工作正在进行中。
- “它将如何帮助我们自己的客户？”
与常规PAS一样：通过授权他们更快，更安全地创建和部署新业务功能而无需停机。