說一說 Serverless 到底是什么？

關(guān)于 Kubernetes Service 理解的系列文章，本篇是最后一篇：

• Part 1: Kubernetes Services
• Part 2: Kubernetes Ingress
• Part 3: Kubernetes Istio
• Part 4: (本文)

Serverless 是一種云原生開發(fā)模型，可使開發(fā)人員專注構(gòu)建和運(yùn)行應(yīng)用，而無需管理服務(wù)器。簡單來說 Serverless 就是讓你不與或少與運(yùn)行應(yīng)用程序所需的服務(wù)器和基礎(chǔ)設(shè)施進(jìn)行交互，當(dāng)今天我們提到 "serverless" 這個詞的時候通常它可以指 CaaS 和 FaaS 這兩種服務(wù)。

CaaS - 容器即服務(wù)

當(dāng)我們創(chuàng)建容器后，把它扔到 CaaS 上，它就會自動運(yùn)行、服務(wù)和擴(kuò)展，比如 Azure Container Instances、Google Cloud Run 或 AWS Fargate 這些服務(wù)。

FaaS - 函數(shù)即服務(wù)

當(dāng)我們寫好代碼，扔給 FaaS，它就會自動運(yùn)行、服務(wù)和擴(kuò)展。比如 Azure Functions、Google Functions 或者 AWS Lambda 這些服務(wù)。

FaaS 可以用不同的方式來運(yùn)行你的代碼，一種方式可能是 FaaS 為每一次代碼變化構(gòu)建一個容器，就類似于使用 CaaS 這種服務(wù)。

另一種方式是 FaaS 在啟動過程中動態(tài)地將函數(shù)的源碼拉到一個預(yù)定義的環(huán)境（容器）中，不同的語言會有不同的環(huán)境，當(dāng)使用像 Go 這樣的編譯語言時，那么編譯必須在啟動時進(jìn)行。

事件或伸縮

FaaS 大多數(shù)時候與函數(shù)實(shí)例的觸發(fā)器事件系統(tǒng)一起使用，事件可以來源于 API 網(wǎng)關(guān)、Github、Kafka、RabbitMQ、CronJobs 等。

對于每個事件，將創(chuàng)建一個新的函數(shù)來處理它，如果有多個事件同時發(fā)生，將創(chuàng)建多個實(shí)例來處理這些事件。這樣我們就有了自動伸縮的功能。

FaaS 與各種事件源進(jìn)行通信，所以函數(shù)本身不需要去實(shí)現(xiàn)，它們只需要與 FaaS 使用的一種事件格式進(jìn)行通信，比如 CloudEvents 或者通過 HTTP 傳輸。

Kubernetes 應(yīng)用

下面讓我們來看看開發(fā)一個運(yùn)行在 Kubernetes 上的傳統(tǒng)非 serverless 應(yīng)用需要的步驟。

我們需要構(gòu)建一個容器，創(chuàng)建各種 Kubernetes 資源清單文件，然后決定我們需要多少個工作節(jié)點(diǎn)來運(yùn)行我們的應(yīng)用程序。

我們需要多少個工作節(jié)點(diǎn)的可以通過配置一個 Cluster/Node autoscaler來動態(tài)地處理，但是我們?nèi)匀槐仨毰渲盟⑶倚枰O(shè)置一個最小+最大的節(jié)點(diǎn)數(shù)量。

Kubernetes Serverless 應(yīng)用

現(xiàn)在我們來探討一下為 Kubernetes 開發(fā)應(yīng)用時的 serverless 方法。

CaaS - 容器即服務(wù)

可以看到我們大大減少了需要創(chuàng)建的 Kubernetes 資源清單的數(shù)量，CaaS 將為我們創(chuàng)建所有必要的子資源，比如 autoscaler、Ingress 或 Istio 路由。

我們要做的就是提供一個（Docker）容器，并創(chuàng)建一個單一的 k8s 資源，即通過 CRD 引入的 CaaS-容器資源。CaaS 決定什么時候啟動我們應(yīng)用的實(shí)例，以及啟動多少個，可能是基于事件或我們自定義的方式。

我們必須確保我們構(gòu)建的容器能夠接收和處理來自 CaaS 的事件，例如可以通過 HTTP 或 CloudEvents，這可能需要容器內(nèi)部的某些庫支持。

Knative 就是一個典型的 CaaS 服務(wù)，Knative 提供了靈活的構(gòu)建模塊，其他解決方案也可以使用和依賴它。

FaaS - 函數(shù)即服務(wù)

在 FaaS 服務(wù)中的 function.yml 文件中將包含一個來自 FaaS 系統(tǒng)的 K8s 資源，通過 CRD 引入，在該資源中，我們可以配置函數(shù)名稱、源代碼位置、語言運(yùn)行時和觸發(fā)事件等內(nèi)容。

有了 FaaS，我們也就擁有了 CaaS 解決方案的一切能力了，現(xiàn)在我們進(jìn)一步減少了工作量，因為我們有工具在 Kubernetes 集群中運(yùn)行，可以直接執(zhí)行/構(gòu)建我們的應(yīng)用源代碼。

為我們構(gòu)建的容器已經(jīng)包含了必要的庫，比如 HTTP 或 CloudEvents，來接收來自 FaaS 的事件，所以我們不必?fù)?dān)心這個問題。

源碼可能存儲在 Git 倉庫中，也可能是通過 web 界面上傳的，或者是在其他地方提供的。FaaS 將訪問代碼，監(jiān)聽變化，構(gòu)建容器，然后將其傳遞給 CaaS，用于服務(wù)終端事件。

冷熱啟動

冷啟動將意味著沒有 Pod 已經(jīng)在運(yùn)行處理事件，所以需要一些時間來創(chuàng)建它。通常情況下，這些 Pod 在最后一次使用后會保持一段時間，可以重復(fù)使用。在 "已經(jīng)運(yùn)行" 期間的調(diào)用被稱為熱啟動，熱啟動的速度較快，但也會消耗資源。

Fission

Fission 是一個典型的運(yùn)行在 Kubernetes 環(huán)境下面的 Faas 服務(wù)，實(shí)際上并沒有為每個函數(shù)的代碼變化構(gòu)建一個不可變的容器，而是使用了可變的環(huán)境容器（"Generic pods"）的概念，動態(tài)地將代碼拉進(jìn)來，然后將這些容器轉(zhuǎn)換成 "Specific Function pods"，這也是 AWS Lambda 使用用 AWS Firecracker 的工作方式。

可觀測性

從容器化的微服務(wù)轉(zhuǎn)向函數(shù)，可能會導(dǎo)致不得不管理比以前更多、更小的服務(wù)。這是因為創(chuàng)建小型函數(shù)是很容易的，這些函數(shù)只是監(jiān)聽和處理一個單一事件。

為了管理更多的服務(wù)或功能，所以非常有必要保持可觀察性（指標(biāo)、日志、跟蹤），這就是為什么大多數(shù) Kubernetes 的 FaaS 和 CaaS 已經(jīng)與Prometheus、Jaeger 和 Istio 或 Linkerd 等服務(wù)網(wǎng)格進(jìn)行了集成。

Kubernetes Serverless 節(jié)點(diǎn)

上面我們談到了 K8s Serverless 應(yīng)用，我們看到了使用 CaaS 或 FaaS 時的工作流程，這些服務(wù)減少了我們很多重復(fù)性的工作。

但是開發(fā)人員或運(yùn)維人員仍然在與服務(wù)器交互：作為集群中的工作節(jié)點(diǎn)的虛擬機(jī)，他們?nèi)匀恍枰付ㄓ卸嗌俟?jié)點(diǎn)以及它們的資源（CPU/內(nèi)存）。

下面我們來看下使用?Virtual Kubelet 讓實(shí)際的底層 Kubernetes 節(jié)點(diǎn)成為 Serverless 節(jié)點(diǎn)。

Virtual Kubelet 給 Kubernetes 模擬了一個 worker 節(jié)點(diǎn)，然后可以調(diào)度 Pods 到上面來工作，就像其他普通節(jié)點(diǎn)一樣。雖然 Pods 的容器不是運(yùn)行在虛擬機(jī)上，而是在云提供商的無服務(wù)器容器產(chǎn)品中，如 AWS Fargate、Google Cloud Run 或 Azure Container Instances。

K8s Serverless 應(yīng)用和 K8s Serverless 節(jié)點(diǎn)可能是一個強(qiáng)大的組合，但是，如果我們把所有的東西都 serverless 化了，那為什么還要使用 K8s呢？

為什么還要用 Kubernetes

Kubernetes 提供了強(qiáng)大而靈活的構(gòu)建功能，而不是為了方便交互和終端用戶而生的的。這使得 K8s 變得很復(fù)雜，直接使用時需要大量的重復(fù)性工作。

Kubernetes 成為一個獨(dú)立于云提供商的標(biāo)準(zhǔn)，在上面使用 serverless 框架，在使用 serverless 時保持這種獨(dú)立性是有意義的，如果有必要的話，我們可以隨時對我們的應(yīng)用進(jìn)行更加詳細(xì)的定義，因為它的下面仍然只是運(yùn)行 K8s 而已。

通過在 K8s 上使用 serverless，我們可以減少很多重復(fù)性工作，這樣我們就可以花更多的時間來構(gòu)建實(shí)際的應(yīng)用了。

總結(jié)

最后我們來回顧下傳統(tǒng)的 K8s 應(yīng)用和 serverless 應(yīng)用的區(qū)別。

我認(rèn)為現(xiàn)代 serverless 事件驅(qū)動的架構(gòu)已經(jīng)證明了自己的能力，并且在未來幾年會越來越普遍。Kubernetes上的 Serverless 只是持續(xù)自動化掉手工作業(yè)的結(jié)果。

“

原文鏈接：https://itnext.io/kubernetes-serverless-simply-visually-explained-ccf7be05a689

”