绕过FaaS，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

获取更多开源云技术资讯&大咖交流&免费活动，欢迎添加开源云中文社区小助手，备注开源云！

（长按识别二维码添加）