Knative項(xiàng)目于2018年夏季推出，彼時(shí)無服務(wù)器一詞通常與功能即服務(wù)產(chǎn)品（如AWS Lambda）掛鉤。
然而，一年之后，行業(yè)專家認(rèn)為，Knative將促進(jìn)下一代平臺(tái)即服務(wù)（PaaS）基礎(chǔ)設(shè)施，因?yàn)槠髽I(yè)DevOps專業(yè)人員為內(nèi)部開發(fā)人員建立了應(yīng)用程序部署平臺(tái)。在大約六個(gè)月之后，早期采用者開始看到了它的潛力——除了功能即服務(wù)之外，它也可以向應(yīng)用程序提供事件驅(qū)動(dòng)的基礎(chǔ)設(shè)施。
“我們希望能夠讓開發(fā)人員推出代碼而不用關(guān)心DevOps下面的平臺(tái)。”Amalgam Insights的分析師Tom Petrocelli說，“而現(xiàn)在，開發(fā)人員必須花不少精力在平臺(tái)上。”
Knative將Kubernetes帶到了PaaS的根本
Knative解決了將Kubernetes資源縮減到零的棘手技術(shù)問題，而不是要求至少有最小數(shù)量的閑置資源來等待工作負(fù)載。它還通過與功能即服務(wù)接口的集成，將大部分基礎(chǔ)架設(shè)施管理從開發(fā)人員那里抽象出來。這些抽象也常見于第一代PaaS平臺(tái)，如Heroku、Engine Yard和Google App Engine，以及Docker。
與早期基于VM的完全托管PaaS產(chǎn)品不同，Knative和Kubernetes允許企業(yè)DevOps和SRE團(tuán)隊(duì)在幕后保持對(duì)Kubernetes基礎(chǔ)設(shè)施的控制。它們還可以控制基礎(chǔ)設(shè)施成本，因?yàn)楣芾韱T可以將許多容器打包到他們選擇的云計(jì)算環(huán)境中，而且Kubernetes和Knative是免費(fèi)的開源軟件。
事實(shí)上，去年Knative開源的時(shí)候，一些前沿用戶已經(jīng)因?yàn)檫@些原因開始從Heroku轉(zhuǎn)向Kubernetes。Rainforest QA、Salsify、Fairwinds和Periscope等公司的工程師們都公開宣布了這種轉(zhuǎn)變，其動(dòng)機(jī)是通過管理基于容器和開源軟件的自動(dòng)化基礎(chǔ)設(shè)施，更嚴(yán)格地控制基礎(chǔ)設(shè)施的安全性和數(shù)據(jù)庫可擴(kuò)展性而節(jié)省成本。
Google Cloud Run顯示了Knative的實(shí)際效果
Google Cloud Run服務(wù)（一個(gè)在Knative上運(yùn)行的托管無狀態(tài)容器自動(dòng)擴(kuò)展平臺(tái)）的用戶還在尋求對(duì)PaaS進(jìn)行更細(xì)粒度的控制，因?yàn)樗麄兊膽?yīng)用程序需求不斷增長(zhǎng)和成熟。
視覺軟件測(cè)試SaaS提供商Perceptual（即大家熟悉的Percy，其產(chǎn)品被Shopify、Fastly、Spotify和谷歌等技術(shù)公司用于UI和客戶體驗(yàn)測(cè)試）開始使用完全托管版本的Cloud Run服務(wù)，4月份快速處理了數(shù)以億計(jì)的視覺快照。
然而，在完全托管平臺(tái)上運(yùn)行幾周之后，Percy的工程師意識(shí)到，由于其特定工作負(fù)載的性質(zhì)，該服務(wù)的完全托管版本的成本太高而無法維持。該公司改用了一種名為Cloud Run on Google Kubernetes Engine（GKE）的變體，允許用戶通過Knative接口調(diào)整底層基礎(chǔ)設(shè)施。
“（全面托管的）Cloud Run使用Docker容器，提供最多60個(gè)工作負(fù)載的并發(fā)。”Percy工程總監(jiān)David Jones說，“但我們的工作負(fù)載非常重，以至于我們無法允許并發(fā)發(fā)生，并且一次只能有一個(gè)Docker容器處理一個(gè)請(qǐng)求。”
Percy的工作負(fù)載在更少的更大的容器上運(yùn)行，而不是為并發(fā)配置多個(gè)Docker容器。Johns說，通過GKE Cloud Run中的Knative接口進(jìn)行的配置調(diào)整使這成為可能。從開發(fā)人員的角度來看，Knative還從完全托管的Google Cloud Run切換到Cloud Run on GKE。
“http端點(diǎn)保持不變，只是名稱變了。”Johns說，“我們沒有改變稱呼這些端點(diǎn)的方式，因?yàn)橐磺卸际羌嫒莸摹?rdquo;
Jones表示，Percy的工程師希望在未來的Cloud Run版本中深入研究Knative的autoscaler控制。“你不能為Knative的autoscaler使用自定義指標(biāo)，而我們希望能做到這一點(diǎn)。如果Knative的autoscaler可以預(yù)測(cè)需求，那就會(huì)很好，將使我們能夠更好地滿足需求，而不是依賴于手工配置的規(guī)則。”
Knative autoscaler的自定義指標(biāo)支持功能已在上游社區(qū)中進(jìn)行了討論，但尚未達(dá)到讓用戶測(cè)試的就緒狀態(tài)。
Kubernetes平臺(tái)供應(yīng)商為Knative需求做準(zhǔn)備
基礎(chǔ)設(shè)施自動(dòng)化向開發(fā)人員隱藏了復(fù)雜性，同時(shí)保留了對(duì)底層系統(tǒng)的組織化控制，因此在企業(yè)IT公司中大家都喜歡，云、DevOps和容器的普及程度也激增。像紅帽和Pivotal這樣的Kubernetes平臺(tái)供應(yīng)商已經(jīng)成了Knative的貢獻(xiàn)者并將其整合到它們的產(chǎn)品中。紅帽表示，一直很受歡迎的Knative on OpenShift開發(fā)者預(yù)覽版，預(yù)計(jì)將在未來六個(gè)月左右GA。紅帽還與KEDA合作，后者使用Knative來管理Azure Functions on OpenShift。
“Knative實(shí)際上根本沒有功能即服務(wù)組件，但它為Kubernetes原生無服務(wù)器生態(tài)系統(tǒng)提供了構(gòu)建模塊，無論是基于功能還是僅僅是一般應(yīng)用程序。”Red Hat OpenShift的云平臺(tái)服務(wù)總裁兼總經(jīng)理Reza Shafii說道，“這就是為什么我們選擇它，因?yàn)檫@就是我們所需要的。”
在DevOps世界的應(yīng)用交付方面，Knative也在基礎(chǔ)設(shè)施自動(dòng)化之外掀起波瀾。一個(gè)Knative衍生項(xiàng)目Tekton，提供事件驅(qū)動(dòng)的CI / CD管道規(guī)范，是JenkinsX（Jenkins的云原生更新）的關(guān)鍵組件，可在Google Cloud Platform上使用。
原文鏈接：
https://searchitoperations.techtarget.com/news/252469607/Knative-serverless-Kubernetes-bypasses-FaaS-to-revive-PaaS
