绕过FaaS,Knative重振PaaS

开源云中文社区
Google Cloud Run服务(一个在Knative上运行的托管无状态容器自动扩展平台)的用户还在寻求对PaaS进行更细粒度的控制,因为他们的应用程序需求不断增长和成熟。

Knative项目于2018年夏季推出,彼时无服务器一词通常与功能即服务产品(如AWS Lambda)挂钩。

然而,一年之后,行业专家认为,Knative将促进下一代平台即服务(PaaS)基础设施,因为企业DevOps专业人员为内部开发人员建立了应用程序部署平台。在大约六个月之后,早期采用者开始看到了它的潜力——除了功能即服务之外,它也可以向应用程序提供事件驱动的基础设施。

“我们希望能够让开发人员推出代码而不用关心DevOps下面的平台。”Amalgam Insights的分析师Tom Petrocelli说,“而现在,开发人员必须花不少精力在平台上。”

Knative将Kubernetes带到了PaaS的根本

Knative解决了将Kubernetes资源缩减到零的棘手技术问题,而不是要求至少有最小数量的闲置资源来等待工作负载。它还通过与功能即服务接口的集成,将大部分基础架设施管理从开发人员那里抽象出来。这些抽象也常见于第一代PaaS平台,如Heroku、Engine Yard和Google App Engine,以及Docker。

与早期基于VM的完全托管PaaS产品不同,Knative和Kubernetes允许企业DevOps和SRE团队在幕后保持对Kubernetes基础设施的控制。它们还可以控制基础设施成本,因为管理员可以将许多容器打包到他们选择的云计算环境中,而且Kubernetes和Knative是免费的开源软件。

事实上,去年Knative开源的时候,一些前沿用户已经因为这些原因开始从Heroku转向Kubernetes。Rainforest QA、Salsify、Fairwinds和Periscope等公司的工程师们都公开宣布了这种转变,其动机是通过管理基于容器和开源软件的自动化基础设施,更严格地控制基础设施的安全性和数据库可扩展性而节省成本。

Google Cloud Run显示了Knative的实际效果

Google Cloud Run服务(一个在Knative上运行的托管无状态容器自动扩展平台)的用户还在寻求对PaaS进行更细粒度的控制,因为他们的应用程序需求不断增长和成熟。

视觉软件测试SaaS提供商Perceptual(即大家熟悉的Percy,其产品被Shopify、Fastly、Spotify和谷歌等技术公司用于UI和客户体验测试)开始使用完全托管版本的Cloud Run服务,4月份快速处理了数以亿计的视觉快照。

然而,在完全托管平台上运行几周之后,Percy的工程师意识到,由于其特定工作负载的性质,该服务的完全托管版本的成本太高而无法维持。该公司改用了一种名为Cloud Run on Google Kubernetes Engine(GKE)的变体,允许用户通过Knative接口调整底层基础设施。

“(全面托管的)Cloud Run使用Docker容器,提供最多60个工作负载的并发。”Percy工程总监David Jones说,“但我们的工作负载非常重,以至于我们无法允许并发发生,并且一次只能有一个Docker容器处理一个请求。”

Percy的工作负载在更少的更大的容器上运行,而不是为并发配置多个Docker容器。Johns说,通过GKE Cloud Run中的Knative接口进行的配置调整使这成为可能。从开发人员的角度来看,Knative还从完全托管的Google Cloud Run切换到Cloud Run on GKE。

“http端点保持不变,只是名称变了。”Johns说,“我们没有改变称呼这些端点的方式,因为一切都是兼容的。”

Jones表示,Percy的工程师希望在未来的Cloud Run版本中深入研究Knative的autoscaler控制。“你不能为Knative的autoscaler使用自定义指标,而我们希望能做到这一点。如果Knative的autoscaler可以预测需求,那就会很好,将使我们能够更好地满足需求,而不是依赖于手工配置的规则。”

Knative autoscaler的自定义指标支持功能已在上游社区中进行了讨论,但尚未达到让用户测试的就绪状态。

Kubernetes平台供应商为Knative需求做准备

基础设施自动化向开发人员隐藏了复杂性,同时保留了对底层系统的组织化控制,因此在企业IT公司中大家都喜欢,云、DevOps和容器的普及程度也激增。像红帽和Pivotal这样的Kubernetes平台供应商已经成了Knative的贡献者并将其整合到它们的产品中。红帽表示,一直很受欢迎的Knative on OpenShift开发者预览版,预计将在未来六个月左右GA。红帽还与KEDA合作,后者使用Knative来管理Azure Functions on OpenShift。

“Knative实际上根本没有功能即服务组件,但它为Kubernetes原生无服务器生态系统提供了构建模块,无论是基于功能还是仅仅是一般应用程序。”Red Hat OpenShift的云平台服务总裁兼总经理Reza Shafii说道,“这就是为什么我们选择它,因为这就是我们所需要的。”

在DevOps世界的应用交付方面,Knative也在基础设施自动化之外掀起波澜。一个Knative衍生项目Tekton,提供事件驱动的CI / CD管道规范,是JenkinsX(Jenkins的云原生更新)的关键组件,可在Google Cloud Platform上使用。

原文链接:

https://searchitoperations.techtarget.com/news/252469607/Knative-serverless-Kubernetes-bypasses-FaaS-to-revive-PaaS

THEEND

最新评论(评论仅代表用户观点)

更多
暂无评论