Kubernetes是構(gòu)建平臺(tái)的元平臺(tái)：在過去的幾年中，Kubernetes獲得了業(yè)界的認(rèn)可，成為現(xiàn)代基礎(chǔ)設(shè)施的基礎(chǔ)。
現(xiàn)代應(yīng)用程序依賴容器（作為部署單元）。大部分代碼打包為容器鏡像，并作為pod部署在Kubernetes上。
Kubernetes對(duì)擴(kuò)展和管理部署生命周期提供了極好的支持。它簡(jiǎn)化了在管理虛擬機(jī)時(shí)存在的許多挑戰(zhàn)。
除了容器之外，另一個(gè)重要的趨勢(shì)是無服務(wù)器計(jì)算。AWS Lambda、Azure Functions、Google Cloud Functions和IBM Cloud Functions是一些可用于運(yùn)行代碼的商用無服務(wù)器環(huán)境。它們基于無服務(wù)器計(jì)算的功能即服務(wù)（FaaS）交付模型，開發(fā)人員將代碼片段直接部署到平臺(tái)上。
基于Kubernetes的容器即服務(wù)（CaaS）和功能即服務(wù)（FaaS）在部署和執(zhí)行代碼時(shí)遵循不同的方法。FaaS建立在按需執(zhí)行、每秒計(jì)費(fèi)和事件驅(qū)動(dòng)調(diào)用的基礎(chǔ)上，而CaaS旨在提供應(yīng)用程序的規(guī)模和可靠性。CaaS可以部署在企業(yè)數(shù)據(jù)中心內(nèi)，而FaaS仍然局限于公有云。
現(xiàn)代應(yīng)用程序使用多種模式和實(shí)踐來實(shí)現(xiàn)規(guī)模、可靠性、效率和安全性。它們使用CaaS和FaaS的組合來利用云提供商提供的交付模型?？紤]到這兩種交付模型之間的差距，開發(fā)人員將不得不處理極為不同的流程和工作流，這些流程和工作流容易出錯(cuò)且成本高昂。無論代碼在哪里執(zhí)行，開發(fā)人員都無法將容器鏡像標(biāo)準(zhǔn)化為標(biāo)準(zhǔn)的部署單元。
此外，還需要將無服務(wù)器計(jì)算帶到本地和企業(yè)數(shù)據(jù)中心。它應(yīng)該基于大多數(shù)開發(fā)人員使用的、經(jīng)過驗(yàn)證的基礎(chǔ)設(shè)施。
Knative
Knative是由谷歌、IBM、Pivotal、紅帽和SAP開發(fā)的一個(gè)開源項(xiàng)目，旨在使Kubernetes成為運(yùn)行微服務(wù)和無服務(wù)器應(yīng)用程序的最佳平臺(tái)。它也成為了Kubernetes的抽象層，隱藏了封裝和部署應(yīng)用程序所涉及的復(fù)雜性。
Knative是在Kubernetes元平臺(tái)之上構(gòu)建的一個(gè)PaaS，可以讓開發(fā)人員高效地工作。它公開了兩種執(zhí)行模型：長(zhǎng)時(shí)間運(yùn)行的工作負(fù)載和事件驅(qū)動(dòng)的代碼。
開發(fā)人員將Knative包代碼作為容器鏡像，而不考慮執(zhí)行模型。這消除了管理兩個(gè)并行執(zhí)行環(huán)境（CaaS和FaaS）的負(fù)擔(dān)。DevOps可以使用統(tǒng)一的、一致的CI/CD管道來構(gòu)建和部署代碼。
技術(shù)上，Knative可以部署在任何Kubernetes環(huán)境中，這使得在企業(yè)數(shù)據(jù)中心中公開無服務(wù)器環(huán)境成為可能。
在幕后，Knative依賴于Istio這樣的服務(wù)網(wǎng)格來管理流量路由、修訂和指標(biāo)。
以Knative為目標(biāo)的開發(fā)人員不需要理解Kubernetes的復(fù)雜性，比如pod、部署、服務(wù)和入口。他們將容器鏡像打包為一個(gè)微服務(wù)，并將其部署到Knative，Knative將處理剩下的事。
Knative提供了兩個(gè)核心構(gòu)建塊——serving和eventing。
Knative Serving
Knative的serving組件為Kubernetes帶來了一個(gè)熟悉的、類似PaaS的執(zhí)行模型。它負(fù)責(zé)公開、托管、擴(kuò)展和管理打包為容器鏡像的微服務(wù)的生命周期。
當(dāng)以Knative為目標(biāo)時(shí)，開發(fā)人員定義了一個(gè)管理整個(gè)部署生命周期的服務(wù)。他們還可以定義路由，有選擇地將流量發(fā)送到同一應(yīng)用程序的不同版本。配置定義提供了代碼和配置之間的清晰分離。修改配置將導(dǎo)致新的修訂。最后，Knative serving管理應(yīng)用程序的修訂，這是特定應(yīng)用程序的代碼和配置的時(shí)間點(diǎn)快照。
這些資源（服務(wù)、路由、配置和修訂）在Kubernetes中實(shí)現(xiàn)為自定義資源定義（CRD）。它們負(fù)責(zé)將Knative術(shù)語翻譯成標(biāo)準(zhǔn)的Kubernetes原語和對(duì)象。
Knative serving支持scale-to-zero功能——當(dāng)一段時(shí)間內(nèi)沒有請(qǐng)求時(shí)，服務(wù)會(huì)自動(dòng)終止。在被終止后，如果服務(wù)收到一個(gè)新的請(qǐng)求，serving資源將立即啟動(dòng)一個(gè)新的pod來處理該請(qǐng)求。諸如超時(shí)、冷卻周期和最大實(shí)例數(shù)的參數(shù)可以通過與服務(wù)相關(guān)聯(lián)的Knative配置來定義。
Knative Eventing
Knative eventing組件提供了必要的基礎(chǔ)設(shè)施，用于基于后期綁定中連接事件發(fā)布者和事件使用者。
與其他事件驅(qū)動(dòng)環(huán)境一樣，事件產(chǎn)生者和事件使用者彼此獨(dú)立。產(chǎn)生者可以在有活動(dòng)事件使用者之前生成事件。任何事件使用者都可以表達(dá)對(duì)某個(gè)事件或某類事件的興趣，甚至在產(chǎn)生者開始發(fā)布這些事件之前。
Knative有一個(gè)代理，充當(dāng)事件產(chǎn)生者和使用者之間的管道。產(chǎn)生者將代理當(dāng)作一個(gè)集線器，將所有消息發(fā)布給它。觸發(fā)器通過代理將使用者綁定到發(fā)布者。這種松散耦合的架構(gòu)使得部署高度可伸縮的eventing基礎(chǔ)設(shè)施成為可能。
由于可以將多種事件發(fā)送到同一代理，因此Trigger中的篩選器配置選項(xiàng)將訂閱特定類型的事件。
也可以在不通過代理的情況下直接將使用者與產(chǎn)生者連接起來。
Knative支持將容器、cron作業(yè)、Kubernetes控制器等源作為一些事件源。其他源（如Kafka、Google Cloud Pub/Sub和NATs）可以注冊(cè)為外部事件源，可以通過代理發(fā)送交付消息。
開發(fā)人員可以編寫代碼來響應(yīng)打包為容器鏡像并部署為Knative服務(wù)的事件。
小結(jié)
如果Kubernetes是基礎(chǔ)設(shè)施，Knative就是堆棧的平臺(tái)組件。它旨在增強(qiáng)開發(fā)人員的體驗(yàn)，交付無服務(wù)器執(zhí)行模型，并在Kubernetes中運(yùn)行事件驅(qū)動(dòng)的代碼。
原文鏈接：
https://thenewstack.io/knative-brings-event-driven-and-serverless-computing-to-kubernetes/
