Knative v0.3 自動擴展 — 一段愛的物語 ¶
發佈於：2021-10-06 , 修訂於：2024-01-17
Knative v0.3 自動擴展 — 一段愛的物語¶
作者：Joseph Burnett，Google 軟體工程師
Knative v0.3 自動擴展 — 一段愛的 物語
Knative v0.3 版本中的擴展包含自訂自動擴展子系統的新選項。從內建、預設縮放至零，到完全取代自動擴展系統的能力，以及介於兩者之間的一切。PodAutoscaler 是 Knative 中的新自訂資源，提供了一個擴充和控制點，可用於設定您的應用程式。
為了說明這些選項，讓我們逐步了解 Web 應用程式從最初到複雜自動擴展的演變。我們保證，「Knative 自動擴展將與您一同成長。」
我只想保持 簡單
一天早上，您突然從床上坐起來，意識到人們真正想要的是…愛。您編寫了一個快速的 Web 應用程式，將心形浮水印應用於任何給定的影像的正確位置。由於您是一位精明的現代應用程式開發人員，因此您將其放入容器中，並使用 `gcloud run deploy --image gcr.io/joe-does-knative/love` 在 GKE 上的 Knative 服務上啟動它。
這就是您的 Knative 服務的樣子
您將其展示給您的死黨，他們將其發佈在 Hacker News 上。瞧，您登上了駭客網際網路的頭版！HN 試圖給您擁抱式死亡，但您的應用程式和叢集會擴展以無縫處理每秒 1000 個操作的流量。過了一段時間，興奮感消退，您的服務每小時收到 1 或 2 個請求。幸運的是，Knative 在不使用時會將 Pod 縮放至零，因此您不會花錢運行閒置的程序。而且您在初始部署後從未更改任何內容！這很簡單。
請不要 離開
幾週後，靈光再次閃現，您意識到…「我可以靠這個賺錢」。顯然人們喜歡心形浮水印。也許您可以讓大家使用您的服務為整個網站上的影像加上浮水印！在您的 Ruby 指令碼（是的，它是 Ruby）前面新增一個快速的記憶體內快取，重新部署，然後開始宣傳您的產品作為一般影像處理服務。事情進展順利，但您很快意識到您的流量是不可預測的 — 它會大量突發。而且當服務縮放至 0 個 Pod，稍後流量恢復時，您會在前幾分鐘再次建立快取，這會使請求延遲有點過高。因此，您決定在 Knative 服務的修訂範本中新增註釋，以始終維持至少 2 個 Pod。
這就是您現在的 Knative 服務的樣子
事情沒有縮放至零。但這很好，因為您從這項事業中賺了一些錢。
事情正在 升溫
哇！流量開始增加。您平均約為每秒 500 個操作，並且根據一天中的時間運行 10 到 50 個 Pod。您已注意到此工作主要是 CPU 密集型，並且您並未盡可能有效率地利用所有資源。因此，您對預設自動擴展目標進行了一些調整
但最終您得出結論，您只需要根據 CPU 進行擴展，以使您的機器保持運轉。因此，您選擇了完全不同的 Knative 自動擴展類別。類別註釋會告訴 Knative 使用不同的 PodAutoscaler 控制器實作，有點像 Kubernetes Ingress。
這是您現在的 Knative 服務
以 60% 的 CPU 持續運作，您實際上開始賺的錢比您花的錢還多！因此，您辭去了日常工作，全職從事心形浮水印。
讓我們 認真一點
事情變得複雜。為了尋求專業幫助，您聘請了 Mark 博士來幫助您運行服務操作。他實施的第一件事是您服務的推出模式。不再是未看清就跳躍！
在 Mark 博士的領導下，事情進展順利！隨著時間的推移，新年除夕即將到來，您開始看到指標出現非線性增長。與 Mark 博士的快速諮詢證實了您最擔心的事。人們會在新年除夕瘋狂地互相發送帶有心形的圖片。而且他們會同時這樣做，就像他們在協調一場愛的 DDOS 攻擊一樣。您需要一個計劃。
幸運的是，馬克博士一直在研讀 Knative Serving 的發行說明，並開始嘗試編輯現有 Knative 修訂版本上的 PodAutoscaler。PodAutoscaler 是 Knative 用來保存其 Knative 修訂版本的自動縮放狀態和配置的地方。與 Knative 修訂版本不同，它是可變的（這是故意的）。您制定了一個計劃，在全球各地新年活動開始前，隨著流量的增加而略微提前增加容量（是的，它發生 24 次！）
在整個晚上，新年從一個時區移動到另一個時區。您在第一個新年活動中看到幾分鐘的錯誤，因為 60% 的 CPU 目標太高。但是在您將下一個活動的目標調整到 40% 後，整個晚上的運行都很順暢。萬歲！🎉
你很特別
這是一年忙碌的一年，事情變得非常瘋狂！您已經與幾個主要的圖片託管網站進行了深度整合，它們現在帶來了您 80% 的流量和收入。當您手頭有一些空閒時間時，您開始分析您的自動縮放統計數據。您意識到，上游推薦人觀察到的流量幾乎完美地預測了您的流量模式。他們可以通過您的 API 整合向您提供這些指標！
但是您已經實施了與 Knative 協同工作的 CI/CD 管道。而且您所有的操作經驗都是在運行 Knative 工作負載中。如果為了實施您自己的自動縮放演算法而拋棄所有這些，那將是一種遺憾。但是您還記得馬克博士在開始研究 Knative v0.3 時說過的話。使用 PodAutoscaler 自定義資源，您可以在不更改 Knative Serving 系統其他任何內容的情況下，實施您自己的協調器和自動縮放系統。好了，就是這樣！
快速複製 Kubernetes 範例控制器，您已經實施了一個在您自己的 Knative PodAutoscaler 類別上運作的協調器。它會查詢上游指標以進行預測性的縮放。
這是您必須在 Knative 服務中進行更改以連接它的方式
哇。撰寫控制器和自動縮放器很困難。但這是您業務的核心問題，並且您已經讓它啟動並運行了。而且您不必接觸所有與這個特定自動縮放問題無關的其他內容。當您思考 Knative 在過去幾年中如何隨著您的業務成長時，您不得不說「我有很多選擇，但 Knative……你是最好的！」
發生了什麼事？
若要瞭解更多關於 PodAutoscaler 的運作方式以及 Knative 自動縮放的選項，請觀看 Kubecon 的演講 Knative: Scaling From 0 to Infinity 並在 Github 上查看程式碼。或試用 Knative Serving 自動縮放範例。
這是 PodAutoscaler 與其他 Knative 實體之間的關係
