?一.簡略介紹

二.文字介紹

1.Serverless

1.1 Serverless介紹：

• 字面理解即無服務架構，指由第三方云計算供應商以服務的方式為開發者提供所需功能，例如數據庫、消息，以及身份驗證等。它的核心思想是讓開發者專注構建和運行應用，而無需管理服務器。

1.2 Serverless優點：

• Serverless 最大的優點就是自動擴展伸縮、無需自己管理。
• 在以往部署一個應用時，需要經歷購買服務器、安裝操作系統、購買域名等等一系列步驟，應用才能真正的上線。后來有了云服務器，我們就省去了購買服務器、安裝操作系統這些操作步驟。只需要在云服務器上搭建環境、安裝數據庫就可以部署應用了。但是這仍然有個問題，當網站訪問量過大時，你需要增加服務器；訪問量過小時，需要減少服務器。如果使用 Serverless，你就不需要考慮這些，云服務商會幫你管理這一切。云服務商會根據你的訪問量自動調整所需的資源。

2.knative 引入

2.1 knative介紹：

• Knative?開源于 2018 年 7 月 24 日，由 Pivotal、Google、IBM 等公司共同發起，從以 K 打頭的名字上就可以看出來 Knative 是用來擴展 Kubernetes 的。官方給 Knative 的定位是：基于 Kubernetes 的平臺用來構建、部署和管理現代 Serverless 的工作負載。通過 Knative 可將云原生應用開發在三個領域的最佳實踐結合起來——服務構建部署的自動化、服務編排的彈性化以及事件驅動基礎設施的標準化。

2.2 為什么選擇knative？

• 業務代碼部署到 Serverless 平臺上就離不開源碼的編譯、部署和事件的管理。 然而無論是開源的解決方案還是各公有云的 FAAS 產品大家的實現方式大家都各不相同，缺乏統一的標準導致市場呈現碎片化。因此無論選擇哪一個方案都面臨供應商綁定的風險。這對云廠商來說用戶 Serverless 上云就比較困難，對于 PAAS 提供商來說很難做一個通用的 PAAS 平臺給用戶使用。基于這樣的背景 Google 牽頭聯合 IBM、Red Hat 等發起了 Knative 項目。

3.knative的幾個核心組件

3.1? serving 服務

Knative Serving 中定義了以下 CRD 資源：

• Service: 自動管理工作負載整個生命周期。負責創建 Route、Configuration 以及 Revision 資源。通過 Service 可以指定路由流量使用最新的 Revision 還是固定的 Revision
• Route：負責映射網絡端點到一個或多個 Revision。可以通過多種方式管理流量。也允許以百分?的?式跨 Revision 進?流量分配。?持諸如增量發布、藍綠部署或者其他復雜的路由場景。
• Configuration: 負責保持 Deployment 的期望狀態，提供了代碼和配置之間清晰的分離。修改一次 Configuration 產生一個 Revision。
• Revision：Revision 資源是對工作負載進行的每個修改的代碼和配置的時間點快照。Revision 是不可變對象，可以長期保留。

3.2? event服務

事件源：

• ?歌云、微軟云、阿里云等服務中的主題并監聽消息。
• Kubernetes Event （kubernetes 事件） Kubernetes 集群中發?的所有事件的反饋。
• GitHub 監視 GitHub 存儲庫中的事件，諸如版本的 pull 請求，推送和創建發布。
• Container Source（容器源）

通道（Channel）：

• 通道處理緩沖和持久性，有助于確保將事件傳遞到其預期的服務，即使該服務已被關閉。也支持外部接入常用的MNS、RocketMQ、kafka等消息中間件 ,自己訂閱事件處理。內部通過Broker/Trigger模型實現事件的訂閱、過濾和路由機制。內部幾種常見的事件訂閱處理.? ? 1.ACR鏡像更新自動發布服務。2.代碼提交自動構建鏡像。3.AI音視頻處理、定時任務等。

3.3? Tekon

tekton三個階段：

• 資源、參數輸入：包括git代碼庫等
• 執行邏輯：mvn clean package、docker build等
• 自定義資源輸出：docker push等

tekton的幾個概念：

• 步驟（Step）：具體操作，比如golang的單元測試、比如編譯Java程序。
• 任務（Task）?：作為命令、二進制文件或腳本的步驟序列，也就是按順序排列的Step集合。
• 頻道（Pipeline）：一組串行或并行的任務。具體點就是tekton收集所有任務，將它們連接在一個有向無環圖中，然后按順序執行該圖形的任務。換句話說，它創建了多個Pod對象，并確保每個Pod按成功的按照預期運行。
• 管道運行（PipelineRun）：執行包含一個或多個任務的管道。例如，我們可以要求Tekton每天固定時間運行某個工作流。
• 任務運行（TaskRun）：通過一個或多個步驟執行任務。

為什么需要Pineline：

• 既然Tekton是一個CI/CD工具，我們除了用它來編譯和構建鏡像，還可以做更多，例如，加入一些自動化測試的流程，對接其他kubernetes集群實現容器鏡像的更新部署。當然，這一切都放到task里的steps也未嘗不可，但是這樣無法抽象出各種task進行組織和復用，所以Tekton提供了更高一級的CRD描述，Pipeline和PipelineRun，Pipeline中可以引用很多task，而PipelineRun可用來運行Pipeline

4.knative的流量治理

簡單說下彈性伸縮，彈性伸縮分為hpa和kpa:

• hpa：基于一些監控指標，比如CPU、內存等情況來決定是否需要擴縮容pod的數量，另外hpa不支持將實例數降到0個。
• kpa：基于監控到的并發請求數來自動彈性伸縮實例數，當并發高的時候就擴容，當持續一段時間沒有請求的時候，就讓pod處于閑置狀態，將流量轉給看門人activator來中轉。一旦有新請求，立馬召回pod，并對外服務。

Knative Serving 流量管理模塊的核心原理如下圖所示。下圖中的 Route 可以理解成是 Istio Gateway 的角色。

• 當縮容到零時進來的流量就會指到 Activator 上面。
• 當 Pod 數不為零時流量就會指到對應的 Pod 上面，此時流量不經過 Activator。
• 其中 Autoscaler 模塊根據請求的 Metrics 信息實時動態的擴縮容

Knative Serving為每個Pod注入代理容器（queue-proxy），該容器負責向Autoscaler報告業務容器的并發指標。Autoscaler接收到這些指標之后，會根據并發請求數及相應的算法，調整Deployment的Pod數量，從而實現自動擴縮容。這里其實也可以使用istio的mixer，我們可以將 Knative 原有的參考架構的冷啟動（cold-start）時間與新的 Istio Mixer 適配器參考架構進行了比較。結果顯示它們的冷啟動時間很接近。使用 Mixer 適配器的實現更加簡單。無需處理基于底層網絡的機制，因為這些機制是由 Envoy 處理的。

總結

以上是生活随笔為你收集整理的knative的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。