揭开平台的神秘面纱：Cloud Foundry、Kubernetes、Eirini与Knative

Matthias Haeussler 和 Dr Nic Williams 在今年的SpringOne Platform 2019大会上讨论了不同的云平台并站在开发人员的角度对它们进行了对比。他们讨论了Cloud Foundry、Kubernetes、Eirini项目和Knative无服务器平台。

在演讲的开头，Haeussler 和 Williams 首先回顾了容器和平台和历史。这段历史从 1979 年的chroot开始一直到 2018 年的 Knative 和 Eirini 项目，他们还讨论了 Cloud Foundry 和 Kubernetes 平台的基础理念。他们认为平台应该为开发人员提供自助服务，为所有支持的角色提供 UX，以及自动化 &监控、自愈和资源优化。平台应该以基础设施为中心，而不应以应用为中心。

他们建议开发人员避免“非我所创平台（Not Invented Here Platform）”（Not Invented Here 指的是人们基于这样或那样的原因，避免使用或购买已经存在的产品，参见维基百科对它的阐述。——译者注）的反模式。如果你没有使用平台的话，那么你肯定就是在构架自己的平台。没有意识到这一点并不能改变你正在 DIY 自己的云平台的事实。标准的平台可能无法让你做任何想做的事情，但是它们可以满足你在平台方面的大多数需求。

Haeussler 展示了将应用部署到不同云平台的样例。Cloud Foundry 应用部署要使用像cf push、cf scale和cf ssh这样的命令。

Eirini 项目是针对 Cloud Foundry 的 Kubernetes 后端。它使用 OCI 镜像将应用部署到 Kubernetes 引擎中。运维人员可以选择使用 Diego 或 Kubernetes 来编排应用容器实例。

Quarks项目是来自 Cloud Foundry 基金会的另一项贡献，它能够将 Cloud Foundry 应用运行时（Cloud Foundry Application Runtime，CFAR）打包成容器而不是虚拟机，这样的话更易于部署到 Kubernetes 中。容器化的 CFAR 提供与 BOSH 管理的 Cloud Foundry 安装包相同的开发人员体验。你可以在应用程序中同时使用 Eirini 和 Quarks。

Haeussler 和 Williams 还谈到了Cloud Native Build Packs，这是 CNCF 托管的一个项目，可以用做将应用程序交付到云平台的标准构建和部署过程，开发人员不必再担心应用程序会部署在哪个特定平台上。工程师可以在本地计算机或集群中使用这些构建包。该项目还有助于重新设置容器中的层，对现有 OCI 镜像进行操作系统更新、漏洞检测以及将更新部署到集群中的所有容器。

接下来，他们讨论了kpack工具，这是一个 Kubernetes 原生容器构建服务，它利用 Kubernetes 原语提供 OCI 镜像的构建，以此作为 Cloud Native Build Packs 的平台实现。kpack是Pivotal Build Service的一部分。有关此新构建工具的更多信息，请查看它们的教程。另一个名为Open Service Broker的计划有助于让 Cloud Foundry“即插即用”。Open Service Broker API 项目允许云供应商向在 Cloud Foundry 和 Kubernetes 等云原生平台上运行的工作负载提供支撑服务。

他们还展示了如何在云原生应用中使用Istio服务网格。Knative 平台有助于构建和部署，并可以管理组织中的所有的无服务器工作负载。它为 Kubernetes 上的云原生应用程序提供了缩放至零、自动伸缩、集群内构建以及事件框架等特性。

关于这次演讲的更多细节，你可以参考文稿或视频录像。你也可以通过 SpringOne 2019 大会上 Emily Casey 和 Joe Kutner 所做的演讲来了解 Kubenetes 上的 Cloud-Native Buildpacks。

原文链接：

Platforms Demystified: Cloud Foundry, Kubernetes, Eirini, and Knative