我們探索直接且與工具無關的方式使Kubernetes無服務器
本文是關於什麼的
· 您刻苦學習的Kubernetes知識是否會因無服務器而變得過時，並且浪費了3年的生命？
· 如何在不使雲提供商陷入困境的情況下使用無服務器？
· 這不是特定工具的比較，而是一般性想法
TL; DR
Kubernetes上的無服務器技術以一種獨立於雲提供商的方式減少了重複配置。 這只是不斷地使手動工作自動化的結果。
在談論Kubernetes上的無服務器時，我們需要考慮兩個不同的領域：
· 在集群中無服務器地部署應用程序（減少每個應用程序+自動構建容器所需的YAML文件數）
· 在沒有服務器的情況下運行Pod的容器而無需服務器
無服務器
簡而言之：您無需與運行應用程序所需的服務器和基礎架構進行交互或進行較少的交互。 今天，當使用"無服務器"一詞時，它可以指向兩種不同的事物：CaaS和FaaS。
CaaS —容器即服務
您創建（Docker）容器，將其扔到CaaS上，然後它會自動運行，服務和縮放。
託管示例包括Azure容器實例，Google Cloud Run或AWS Fargate。
FaaS —服務即功能
您編寫代碼，將其扔到FaaS上，它將自動運行，服務和縮放。
託管示例包括Azure Functions，Google Functions或AWS Lambda。
FaaS實施
FaaS如何運行代碼的方式可能不同。 一種方式是FaaS實際上為每次代碼更改構建一個容器，然後使用如下CaaS：
> FaaS building a container and sending it to CaaS
另一種方式可能是FaaS在引導過程中將功能的源代碼動態地拉入預定義的環境（容器）中。 環境將適用於不同的語言。 當使用必須像Go一樣編譯的語言時，那麼在引導過程中也必須完成編譯。
活動/擴展
FaaS通常在與事件系統結合使用時觸發事件的功能實例化。 事件可以源自API網關，Github，Kafka，RabbitMQ，CronJobs等。
> the FaaS encapsulates communication with event sources
對於每個事件，將創建一個新函數來處理它。 如果同時發生多個事件，則將創建多個實例來處理這些事件。 這樣我們就可以自動縮放。
FaaS與各種事件源進行通信，因此功能本身不必如此。 它們只需要使用FaaS使用的一種事件格式，例如CloudEvents或通過HTTP傳輸。
> https://cloudevents.io
有一個CloudEvents項目，它以"標準"形式描述了事件的結構和元數據。 它還包括數據和描述該數據的模式。 雲事件是包裹事件數據的信封。 如果被許多供應商採用以實現互操作性，這可能會很棒。
Kubernetes應用
讓我們看一下開發在Kubernetes上運行的傳統非無服務器應用程序所需的步驟：
> quite a bit of manual "server" interactions necessary
我們需要構建一個容器，創建各種Kubernetes資源（YAML文件），然後確定運行我們的應用程序需要多少個工作節點。
通過配置群集/節點自動縮放器，可以更動態地處理我們需要多少個工作節點的決定。 儘管即使那樣，我們仍然必須對其進行配置，並且需要設置最小+最大數量的節點。
我們使用這種傳統方法與"服務器"進行了很多交互。 首先創建/構建容器，然後編寫YAML文件，然後定義節點的數量和資源。
Kubernetes無服務器應用程序
現在，讓我們探索為Kubernetes開發應用程序時的無服務器方法。
CaaS —容器即服務
> we reduced the creation of a lot of YAML files
在這裡，我們減少了要創建的Kubernetes資源（YAML文件）的數量。 CaaS將為我們創建所有必要的子資源，例如自動縮放器，Ingress或Istio路由。
我們要做的就是提供一個（Docker）容器並創建一個單一的k8s資源，即通過CRD引入的CaaS容器資源。 CaaS可以根據事件或我們的定義來決定何時啟動我們的應用程序實例以及多少實例。
我們必須確保我們構建的容器可以接收和處理來自CaaS的事件，例如可以通過HTTP或CloudEvents。 這可能需要容器內的某些庫。
CaaS示例：Knative（Knative提供了其他解決方案可以使用和依賴的靈活構建基塊）。
FaaS —服務即功能
> we now also automate the build process and maybe have a nice FaaS webinterface
FaaS function.yml將包含通過CRD引入的FaaS系統中的一個K8s資源。 在該資源中，我們設置了諸如函數名稱，源代碼位置，語言運行時和觸發事件之類的內容。
如果我們通過網絡界面上傳代碼，則無需創建FaaS函數。yaml。 但是將函數保留為代碼應該是一種好習慣。 Web界面非常適合原型設計或測試修改。
藉助FaaS，我們還可以獲得CaaS解決方案所提供的一切。 但是現在，我們進一步減少了工作量，因為我們在Kubernetes集群中運行了可以直接執行/構建應用程序源代碼的工具。
為我們構建的容器已經包含必要的庫，例如HTTP或CloudEvents，以從FaaS接收事件。 我們不必為此擔心。
源可能存儲在Git存儲庫中，可以通過Web界面上傳，也可以在其他地方使用。 FaaS將訪問代碼，偵聽更改，構建容器，然後將其傳遞給CaaS以服務最終事件。
> example webinterface of TriggerMesh to upload code and deploy as a function
FaaS示例：
· TriggerMesh（使用Knative作為CaaS）
· OpenFaaS
· 無核
· 裂變（與環境而不是不變的功能容器一起使用，更進一步）
· OpenWhisk
· 各種K8 FaaS的概述和比較
冷暖啟動
冷啟動意味著沒有任何Pod正在運行來處理事件，因此創建它會花費一些時間。 通常，這些吊艙在最後使用後會存活一段時間，並且可以重複使用。 在"已經運行"期間的調用將被稱為熱啟動。 暖啟動更快，但也浪費資源。
基於裂變/環境的FaaS
> Fission architecture (source)
K8s FaaS的一個例子Fission實際上並沒有為每個函數的代碼更改構建不可變的容器，而是使用了可變環境容器（"通用容器"）的思想，該容器動態地拉入代碼，然後將其轉換為"特定功能容器"。 我認為這也是AWS Lambda運作的方式。
可觀察性
從容器化微服務轉移到功能可能導致必須管理比以前更多和更少的服務。 這是由於易於創建僅偵聽和處理單個事件的小功能而引起的。 當我與第1部分中的Container Microservices和第2部分中的AWS Serverless創建相同的演示應用程序時，我自己注意到了這一點。
要管理大量的服務或功能，必須保持可觀察性（度量，日誌記錄，跟蹤）。 這就是為什麼大多數Kubernetes FaaS和CaaS已經與Prometheus，Jaeger和Istio或Linkerd之類的服務網格進行集成的原因。
Kubernetes無服務器節點
在上一節中，我們討論了K8的無服務器應用程序，並且看到了使用CaaS或FaaS時的工作流程。 這些簡化了流程並大大減少了重複工作。
但是開發人員或操作員仍在與服務器交互：用作群集中工作節點的VM。 他們仍然需要指定要擁有多少個節點及其資源（CPU /內存）。
現在，我們進一步邁出了一步，使用虛擬Kubelet使實際的基礎Kubernetes底層節點無服務器。
> FaaS on top of Kubernetes with Virtual Kubelet as nodes. The ultimate setup?
虛擬Kubelet模擬了Kubernetes的工作節點，然後可以像其他任何普通節點一樣使用該節點調度Pod。 儘管Pod的容器未在VM上運行，但是在無服務器容器的雲提供商中提供，例如AWS Fargate，Google Cloud Run或Azure容器實例。
在我有關虛擬Kubelet的詳細文章中閱讀更多內容。
K8的無服務器應用程序和Kubernetes的K8的無服務器節點的結合可能是一個強大的工具。 但是，如果我們無所事事，為什麼還要使用K8呢？
為什麼仍然使用Kubernetes？
> sorry, I was in the mood for a goofy image O:)
Kubernetes提供了強大而靈活的構建塊，而不是為了方便交互和最終用戶而構建的。 這使得K8變得複雜，並且在直接使用時需要大量重複工作。
Kubernetes成為獨立於雲提供商的標準。 在無服務器時使用無服務器框架是最重要的，以保持這種獨立性。 如有必要，我們總是可以更詳細地定義我們的應用程序，因為它仍在後臺運行K8。
通過在K8上使用無服務器，我們可以大大減少重複工作，從而使我們可以花更多的時間來構建實際的應用程序。
概括
> traditional
> serverless
結論
我認為現代的無服務器事件驅動架構已經證明了自己，並將在未來幾年中越來越流行。 讓我們繼續在諸如K8之類的開放標準之上使用它，以確保更好的互操作性。
Kubernetes上的無服務器只是不斷地使手動工作自動化的結果。
資料來源
· 互聯網。
· Kubernetes無服務器框架的快速比較
· Gitlab使用Knative和Triggermesh提供無服務器應用程序
· Google Cloud Run在後臺使用Knative
· Kubeless和TriggerMesh創作者的精彩視頻
6.關於Kubernetes，Serverless和OpenWhisk的另一個精彩視頻
(本文翻譯自Kim Wuestkamp的文章《Kubernetes Serverless simply visually explained》，參考：https://itnext.io/kubernetes-serverless-simply-visually-explained-ccf7be05a689)
閱讀更多 聞數起舞 的文章
