介紹
談到 Serverless 時，Kubernetes 是一個無法迴避的話題。
在今天的課程中，我們將繼續學習如何搭建一個私有的 Serverless 環境。具體來說，我們將以上一堂課基於本地 K8s 部署的內容為基礎，進一步建構 Serverless 基礎設施。接著，我們會安裝額外的元件來擴展 K8s 叢集的能力，最終讓本地的 K8s 叢集能夠支援 Serverless。
建構 Serverless 的前置條件
在開始之前，我們先來釐清一個在 Serverless 運算（尤其是 FaaS）基礎課程中提到的問題。有些學員問：「微服務、Service Mesh 和 Serverless 之間有什麼關係？」
這些概念經常在討論中出現，但別感到壓力。我一開始學習 Serverless 時也對這些概念感到困惑。讓我們先回顧一下微服務。當你使用微服務來建立 BaaS 時，你可能已經注意到微服務中的許多概念與 Serverless 非常相似。
簡單來說，Service Mesh 是一種微服務網路通訊解決方案，其運作方式不需要微服務本身察覺。我們也可以將 Serverless 架構中的網路通訊委託給 Service Mesh。透過 Service Mesh，Serverless 元件可以與 K8s 叢集緊密合作，最終以 Serverless 的方式支援我們部署的應用程式。請看下面的架構圖：
從圖中可以清楚看到，Serverless 的底層基礎設施可以建立在 Service Mesh 之上。不過，Service Mesh 只是實現 Serverless 網路通訊的解決方案之一。還有其他選項，例如 RSocket、gRPC 和 Dubbo。我選擇 Service Mesh，是因為這個解決方案可以基於 K8s 元件，並提供視覺化工具來幫助我們理解 Serverless 的運作機制，例如如何實現零啟動時間以及控制流量進行逐步釋出。如果你想實際演練，Service Mesh 無疑是首選。
Serverless 基礎設施：Service Mesh
有些人將 Kubernetes、Service Mesh 和 Serverless 技術稱為雲端原生應用開發的「三大支柱」。到目前為止，我想你應該明白原因了。不過，我必須澄清，在接下來的課程中，我們會介紹許多新術語。我已經給了你這些術語的概觀，讓你有廣泛的了解。如果時間允許，你應該深入鑽研它們。
現在，讓我們回到正題，仔細看看 Service Mesh 的原理。
當我們討論微服務時，只涵蓋了拆解與整合的理論指導，沒有觸及具體實作。如果轉到實作層面，業界其實有許多微服務框架，但大多侷限於特定語言的 SDK，尤其是 Java 微服務框架。
SDK 形式的微服務框架通常很重視微服務間網路通訊的實作，例如重試失敗的服務請求、跨多個服務實例的負載平衡，以及在服務請求量高時限制流量。這些邏輯通常需要微服務開發者關注，並且需要在每種 SDK 語言中重複實作。那麼，有沒有可能將微服務網路通訊邏輯從 SDK 中抽離出來，讓我們的微服務更輕量，甚至不必擔心網路通訊？
答案是 Service Mesh。
如果我們將拆解後的應用程式部署到 K8s 叢集的 Pod 中，過程如下圖所示，MyApp 應用程式會直接在叢集內透過 HTTP 呼叫使用者微服務和待辦事項微服務。
但是，直接使用 HTTP 存取會帶來安全問題。如果有人在我們的叢集中啟動一個 BusyBox 容器，他們不就能直接攻擊我們的使用者微服務和待辦事項微服務嗎？此外，當我們有多個使用者微服務實例時，該如何分配流量？
傳統上，我們會使用微服務架構 SDK，其中包含大量這類邏輯和許多策略，我們需要在呼叫 SDK 時決定何時啟用這些策略。我們的程式碼也會與微服務架構 SDK 高度耦合。
而 Service Mesh 則採取不同的方法，它將網路通訊邏輯從微服務中抽離，並以非侵入式的方式管理網路流量，讓我們不再需要擔心龐大的微服務 SDK。讓我們來看看 Service Mesh 如何解決這個問題。
Service Mesh 可以分為資料平面和控制平面。資料平面負責管理網路通訊，而控制平面則控制和監控網路通訊的狀態。Service Mesh 透過注入 Sidecar 來攔截所有網路流量。
在資料平面中，我們的應用程式和微服務看起來是直接與 Sidecar 通訊，但實際上 Sidecar 可以透過流量劫持來達成這一點。因此，我們的應用程式和微服務通常不會察覺，也不需要任何修改，只需使用 HTTP 請求來傳輸資料即可。
控制平面則更為複雜，是 Service Mesh 運作的核心。Pilot 是整個控制平面的驅動者，負責服務發現、流量管理和擴展。Citadel 是控制平面的守護堡壘，負責安全憑證和認證。Mixer 是通訊官，負責分發控制平面的策略並收集各個服務的運作狀態。
現在你應該清楚了解什麼是 Service Mesh，它如何將微服務網路通訊邏輯從 SDK 中抽離，以及為什麼我們說 Service Mesh 是 Serverless 的網路通訊基礎。
Serverless 與容器引擎的關係
Serverless 的核心價值在於不必管理伺服器，可以專注於業務邏輯。容器技術為 Serverless 提供了必要的強大基礎設施和靈活排程能力，特別是與 Kubernetes 這類編排工具結合使用時。
容器提供了輕量封裝、資源隔離和快速啟動等優勢。容器將應用程式及其相依項目封裝起來，確保執行環境的一致性，有助於在 Serverless 平台上快速部署和啟動應用程式實例。此外，容器提供隔離的執行環境，確保不同應用程式不會互相干擾，從而提高平台的整體穩定性。而且，容器的啟動速度比虛擬機器更快，能滿足 Serverless 應用對彈性擴展的高要求。
作為 Serverless 排程的核心，Kubernetes 具有自動部署、彈性擴展和服務發現等功能。它可以根據預設規則自動部署容器化應用程式，無需人工干預；根據即時負載調整應用程式實例的數量，在確保效能的同時最佳化資源使用率；並提供服務發現機制，方便 Serverless 平台內各元件之間的通訊。
要建立基於容器的 Serverless 平台，首先需要將應用程式及其相依項目封裝成容器映像，確保應用程式能夠在平台上快速部署和執行。然後，選擇合適的雲端平台或搭建自有的 Kubernetes 叢集，作為 Serverless 平台的基礎設施。接著，開發 Serverless 平台元件，包括用於接收和路由外部請求的 API 閘道、用於載入和執行函式程式碼以及管理函式生命週期的函式執行環境，以及監聽各種事件來源並將事件轉換為函式呼叫的事件觸發器。最後，使用 Kubernetes 的 Deployment 來管理應用程式實例的部署和更新，使用 Service 進行服務發現和負載平衡，並使用 HPA 實現自動彈性擴展。
基於容器的 Serverless 平台具有高靈活性、強自訂性和成本效益。開發人員可以自由選擇底層容器技術和 Kubernetes 平台，根據需求自訂 Serverless 平台的功能和特性，並利用 Kubernetes 的資源排程能力來最佳化資源使用率、降低成本。
容器技術與 Kubernetes 的結合，為建立高效、靈活且可擴展的 Serverless 平台提供了強大的工具和方法，讓開發人員能夠輕鬆建立自己的 Serverless 平台，專注於業務邏輯開發，提升開發效率。
Novita AI Serverless
在 Novita AI，我們開發了自己的容器引擎 Nexus。憑藉 Nexus 強大的分散式運算和資源排程能力，Novita AI 建立了專為下一代生成式 AI 打造的 Serverless 服務。使用者只需專注於業務創新，無需擔心底層運算資源。現已開放預約，加入候補名單即可搶先體驗 Novita AI Serverless。
Novita AI 是一站式雲端平台，助力您的 AI 雄心。整合 API、Serverless、GPU 執行個體 — 您所需的成本效益工具。無須基礎設施，免費起步，讓您的 AI 願景成真。
推薦閱讀
