Kibosh:Kubernetes Helm Package构建 PCF tiles的新利器

Jeenal Shah、Matt Cholick以及Pivotal平台工程团队喜欢挑战。因此,当团队有机会加深Cloud Foundry和Kubernetes的关联时,他们毫不犹豫地抓住了这个机会。

无论是将应用推送到Cloud Foundry,还是在Kubernetes中运行容器,您都需要一种将服务附加到代码的简单方法。两者都将Open Service Broker API视作此项任务的机制。为何需要在项目之间共享工具呢?

“客户向Pivotal寻求帮助,希望解决他们的问题。他们想要交付应用,但12要素模式无法面面俱到。Kubernetes和Pivotal Container Service能够解决许多其他场景的问题。”Cholick说道,“当您同时运行应用平台和Kubernetes时,需要尽可能使用通用抽象。”

这就是棘手的地方。比方说,您是一位ISV,希望为Cloud Foundry和Kubernetes用户提供数据库、API网关或代码存储库等软件的可安装版本。到目前为止,您必须维护两种产品版本:一个是与Pivotal Cloud Foundry配合使用的tile,另一个是适用于Kubernetes的Helm package。这并非不可能,但也不理想。

“几家ISV已为其代码提供完全受支持的Helm Chart。我们提倡务实,因此决定满足不同客户的需求。”Cholick说道,“问题变成了‘我们如何才能让ISV轻松将Helm package ‘移植’到熟悉的PCF tile中?’”

随着PKS的推出,答案变得异常简单。平台工程团队认为,PKS可以为ISV提供在Kubernetes中部署按需服务,并将它们提供给Pivotal Application Service的方法

“ ISV的Helm Chart是团队首先考虑的点。我们也充分理解了自己想要的成果。我们希望合作伙伴拥有易于维护的集成式tile。”Shah说道,“因此,摆在我们面前的工程任务是一个桥接练习。”

这项工作的成果是?

Kibosh,一个面向软件发布商的出色实用程序。该项目最近由Pivotal的平台工程团队实现了开源。

Kibosh启动会议上的白板

Kibosh到底是什么?

“Kibosh是一种Open Service Broker,当需要创建开放服务时,它会将Helm Chart部署到PKS。”Shah解释道。

“它有两个组件。第一个是通用OSBAPI合规代理,可调配群集中的Helm Chart。第二个组件是Helm Chart自身。它可能来自ISV或任何供应商。随后,软件发布商会使用Tile生成工具将Helm Chart随同Kibosh打包到tile中。然后,用户通常会下载tile并将其安装到PCF部署中。”

那么,在运维人员安装tile之后,会发生什么呢?如果您是开发人员,它的工作原理又是怎样的?让我们通过两个熟悉的CF CLI命令解答这些问题:

针对Kibosh的cf create-service调用将创建Chart描述的Kubernetes资源集合。

针对Kibosh的cf bind-service调用将揭示Chart创建的所有服务和密钥

Kibosh中工作流的UML图表

Cholick更简洁明了地总结了Kibosh:对于需要将自己的软件提供给Pivotal Cloud Foundry用户的ISV来说,Kibosh是合适的抽象。

“ISV希望客户能够轻松打包和使用他们的软件。如果他们已经构建了Helm Chart,并且在为客户执行维护工作,我们为何不接受这种情况呢?最终的结果是,我们会拥有一个蓬勃发展的市场,它可以为我们的客户提供众多选择自由和灵活性。这对我们的合作伙伴而言也大有裨益,因为他们能够获得工程开销极小的新业务机会。”

根据Cholick的观点,合作伙伴能从中获得的益处更多。

“合作伙伴面临的另一项挑战是我们的变革速度,这与平台运维人员面临的挑战类似。Pivotal可以相当快的速度交付大量软件。而我们的合作伙伴需要专注于改进核心产品。因此,我们需要最大限度减少集成代码方面的工作和返工。如果合作方不需要花费时间持有和维护增量式打包,他们就能更好地维护集成。Tile生成工具是我们为帮助解决这种问题而编写和维护的代码段之一。BOSH是用于分布式系统的部署工具链,可随时助力您完成集成。”

Kibosh是MVP - 赶快来试用吧!

近几周,Pivotal的平台团队与合作伙伴密切协作,目的是仔细检查Kibosh。

“Kibosh确实适用于各类附加服务。如果您需要存储Postgres、缓存或NoSQL数据库等的状态,您应该尝试一下Kibosh。”Shah建议,“DevOps工具甚至是底层代码平台也将从该项目中获益。”

合作伙伴还需要了解关于Kibosh的哪些内容?如果您之前与平台工程团队合作过,则可以在未来几个月内获得相关帮助,以使用Kibosh构建集成。

“今年,我们一直专注于如何通过打造工具来支持集成,Kibosh便是其中的成果之一。CF Marketplace可以提供强大的自助式开发人员体验。”Cholick补充道,“开发人员能够说‘我的应用可以存储状态,所以我只需要键入cf create-servicepostgres default-plan my-app-postgres即可’,这让我们觉得轻松极了。”

ISV也应该随时关注Hsobik,该项目旨在用久经考验的PAS市场服务填充Kubernetes服务目录。这项工作有助于企业快速发展可用于PKS部署的服务市场。

为何选择Cloud Foundry和Kubernetes

一个好的经验法则是,您应该使用能力范围内的最高抽象。为什么呢?合适的抽象能够最大限度减少费力的工作。您可以集中精力通过软件实现独特的业务价值。

在这种情况下,Kubernetes、Open Service Broker API和Kibosh是便捷抽象的三重彩。三者联合,可以有效帮助运行来自第三方ISV或内部自有部署团队的预打包软件。此外,这种标准模式可以为服务领域提供更多选择,可由开发人员将其与应用配合使用。这在任何场景下都是好消息。

“仅一个工具本身是不够的。您需要拥有应用平台、Kubernetes和无服务器模型。开发人员应该可以轻松地为所有代码添加合适的服务。这是合作伙伴团队的发展方向。”Shah说道。

Pivotal的生态系统团队一直忙于构建出色的工具,帮助将合作伙伴技术带入Cloud Foundry生态系统,包括Kibosh、Tile生成工具以及按需服务SDK。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180613G07WRP00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券

玩转腾讯云 有奖征文活动