Knative 與終端使用者

發佈於：2022-03-10

作者：Murugappan Chetty (Optum，代表 Knative 指導委員會的終端使用者)

Knative 是一個高度重視終端使用者貢獻/互動的開源社群，這在 PR、每月聚會、Slack 互動等中可見。最重要的是，Knative 最近在指導委員會中設立了一個終端使用者席位。這有幾個原因非常重要

讓終端使用者組織更有信心在生產環境中使用 Knative
極少數的 OSS 社群在指導委員會中有終端使用者代表

我很榮幸能成為指導委員會中的第一位終端使用者代表。在本部落格中，我想分享我組織迄今為止的 Knative 經驗。

為什麼選擇 Knative？¶

首先，選擇 Knative 並非因為它是下一個熱門的新玩意。整個過程是有機的。以下因素導致需要 Kubernetes 抽象化。

成熟的容器生態系統。
無伺服器工作負載
需要比原始 Kubernetes 更好的開發人員體驗 (部署 + 服務 + 網路入口 + ...)

現在是在 Kubernetes 之上建立新平台的成熟時機。在執行此操作之前，我們想檢查是否可以利用現有的開源解決方案，其中有一些解決方案處於不同的成熟度級別，而 Knative 是其中最突出的一個

與所有同類產品相比，具有最佳的擴展效能。
開發人員體驗 (單一 Knative 服務資源會產生 Kubernetes 部署 + 服務 + 網路入口 + 憑證 + 自訂網域)。
用於建置開發人員平台的穩健基本元素。
具有良好治理模型的 OSS 社群
由多家供應商支援
對開放且免費的專案提供大力支援

實作¶

為了滿足具有不同技能水平的開發人員，我們在 Knative 之上建立了一個抽象化。此層讓新使用者更容易入門，進階使用者則可以繞過此層。我們還建立了與企業應用程式整合的元件。下圖顯示了我們的部署模型和內部建立的整合。

Platform Architecture

Enterprise Integration

透過上述部署模型和整合，我們能夠為內部使用者提供從程式碼到 URL 的簡潔體驗。只需幾個參數，開發人員就能在幾秒鐘內部署他們的服務並接收已啟用 TLS 的 URL。

與社群互動¶

自我們首次部署 Knative 服務以來已兩年，我們的平台以驚人的速度成長，為數百名開發人員提供服務。如果沒有 Knative 社群的支援，這是不可能實現的。有多種途徑可以與社群互動。

Slack¶

時至今日，Slack 頻道中的動能絲毫沒有減緩，大多數問題幾乎立即得到解決。Slack 是開始使用 Knative 的好地方。

Hacky Hours¶

如果問我選擇 Knative 至今的最佳體驗是什麼，每週的 Hacky Hours 會是首選。這些非正式/虛擬聚會過去會在星期五下午舉行。每週都會有 Knative 維護人員/貢獻者/終端使用者的示範，帶來許多「啊哈」時刻。在這些會議中，我可以與 Knative 的重要人物進行一對一互動，並驗證我們的實作。

每月聚會¶

Hacky Hours 可能暫時暫停，但每月聚會每個月都會舉行。這是了解專案 TLDR 和一些整潔的使用案例示範的好地方。我很榮幸在這裡展示我們的 Knative 實作。沒有比在聚會/會議上發表演講更好的方法來驗證實作了。對於終端使用者，我絕對建議在這裡示範解決方案。

貢獻¶

在實作過程中，我們確實遇到了一些小問題和一些缺少的功能，這讓我們有機會開啟 PR 並向上游貢獻。維護人員很樂於接受我們的問題，並且大多數問題都已合併，對於未合併的問題，則有合理的理由和良好的討論來學習。我為大多數儲存庫做出了貢獻，但我的一些重大貢獻是到客戶端儲存庫，我最終被提升為審閱者。

除了向上游貢獻之外，我們還建立了自訂 Knative 頻道實作和 Knative 事件來源，並在我們的 GitHub 組織下開源。

我們的 Knative 實作讓我有了在會議上發表演講的機會。最重要的是 Kubecon 和 IstioCon。現在Knative 加入 CNCF，這應該會為終端使用者打開更多在 Kubecon 上分享他們故事的大門。

結語¶

在結語中，我想分享 Knative 對我來說是什麼。幾年前，我開始嘗試使用 Knative，當時並不知道有一天我會進入 Knative 指導委員會。我沒有為每個 OSS 專案做出貢獻，但曾參與過各種社群，提出問題、提供回饋、在 Slack 頻道上互動等等，有了這些經驗，我可以自信地說，成為這個社群的一份子在各方面都很有回報。毫不誇張地說，在這些疫情期間，Knative 一直是我的動力之一。

My Knative Timeline