使用 Knative 的無伺服器工作負載 ¶
發布於：2019-04-10 , 修訂於：2024-01-17
使用 Knative 的無伺服器工作負載¶
作者：Mark Chmarny，Google 雲端 OSS TL
到目前為止，Kubernetes 應該是您部署的預設目標。是的，仍然有一些用例中 Kubernetes 不是最佳選擇，但這些代表現代工作負載中越來越小的比例。
Kubernetes 的主要價值在於它大大抽象化了許多基礎架構管理上的痛點。幾乎所有主要雲端服務供應商 (CSP) 的廣泛支援也表示您的工作負載是可移植的。結合 Kubernetes 相關工具已蓬勃發展的生態系統，表示負責管理 Kubernetes 的操作員的體驗現在非常順暢。
但是，開發人員的體驗呢？開發人員是在 Kubernetes 上建構解決方案的人。
儘管有些人可能會告訴您，Kubernetes 今天還不是應用程式伺服器。首先，在 Kubernetes 上開發、部署和管理服務的行為仍然太複雜。是的，有許多用於記錄、監控、整合等的開源專案，但是，即使您將這些專案組合在一起，在 Kubernetes 上進行開發的體驗仍然很脆弱且過於勞力密集。
如果這還不夠，函式作為程式碼開發的基本單元的日益普及進一步增加了整體複雜性。通常會在兩個不連貫的表面區域上建立不同的開發模式：一個用於函式 (FaaS)，另一個用於應用程式 (PaaS)。
因此，今天的開發人員被迫擔心與基礎架構相關的問題：例如，映像檔建立、登錄發布、部署服務、負載平衡、記錄、監控和擴展。但是，他們真正想做的只是編寫程式碼。
Knative 簡介
本週在舊金山舉行的 Google Cloud Next 大會上，Google 公布了 GKE 無伺服器附加元件的早期預覽 (g.co/serverlessaddon)。Google 還開源了 Knative (kay-nay-tiv)，這個專案支援無伺服器附加元件 (github.com/knative)。
Knative 實作了 Google 的許多學習經驗。該開源專案已經有來自 Pivotal、IBM、Red Hat 和 SAP 等公司的貢獻，並與 OpenWhisk、riff 和 Kyma 等開源函式即服務框架社群合作，這些社群要麼重新平台化到 Knative，要麼取用 Knative 專案中的一個或多個元件。
Knative 協助開發人員在 Kubernetes 上建置、部署和管理現代無伺服器工作負載。
它提供一組建構區塊，可在 Kubernetes 上實現現代、以來源為中心和基於容器的開發工作負載
Knative 文件提供了如何在像Google Cloud Platform 或 IBM 等託管 Kubernetes 產品上，以及像 Pivotal 提供的內部部署 Kubernetes 安裝上安裝它的說明。最後，Knative 儲存庫還包含範例和操作說明，以協助您開始在 Kubernetes 上進行開發。
Knative 概述
Knative 基於明確關注點分離的前提。它允許開發人員和操作員透過以自訂資源定義 (CRD) 的形式定義基本物件來推論工作負載開發、部署和管理，這些 CRD 擴展了 Kubernetes 中找到的物件模型。
- 組態 — 是您的服務的所需狀態，包括程式碼和組態
- 修訂 — 表示您的程式碼和組態的不可變時間點快照
- 路由 — 將流量指派給您的服務的一個或多個修訂
- 服務 — 是上述所有物件的組合輕量版本，可啟用簡單的使用案例
除了這些物件之外，Knative 還定義了事件處理的主要物件……您知道，因為它是無伺服器。Knative 將事件生產者和消費者分離，並實作 CNCF CloudEvents (v0.1) 以簡化事件處理。
- 事件來源 — 表示事件的生產者 (例如，GitHub)
- 事件類型 — 描述不同事件來源支援的事件類型 (例如，上述 GitHub 來源的 Webhook)
- 事件消費者 — 表示您動作的目標 (即 Knative 定義的任何路由)
- 事件饋送 — 是將事件類型連接到動作的繫結或組態
Knative 物件模型的實用性意味著 Knative 不僅容易上手，同時也具備足夠的能力來應對隨著解決方案複雜性增加而出現的更進階的使用情境。
總結
我希望這篇介紹能讓您理解 Knative 的價值。以及 Knative 物件如何簡化 Kubernetes 上的開發流程，無論您是開發應用程式還是函式。
在接下來的幾週，我將會介紹每個主要的 Knative 使用模式（映像檔推送、藍綠部署模型、源碼到 URL 等）。在每篇文章中，我也會提供範例程式碼來說明該模式，並讓您可以在 Knative 上重現它們。我非常興奮能與您分享 Knative，也希望您能回來了解更多。