本頁說明如何使用預設的 Cloud Run 自動調度資源行為,設定服務的最低執行個體數,藉此啟用閒置執行個體。如要手動調整服務規模,請參閱手動調整資源配置。
如要進一步控管服務的自動調度行為,您可以設定執行個體數量下限,避免容器啟動時間過長,並縮短服務延遲時間。如果是 Cloud Run 服務,Cloud Run 預設會根據傳入要求數量調度執行個體。
不過,如果服務需要縮短延遲時間,特別是從零個有效執行個體開始擴充時,您可以變更這項預設行為,指定要保持暖機狀態、準備好處理要求的最低容器執行個體數量。如要進一步瞭解這項最佳化作業,請參閱一般開發提示。
Cloud Run 會移除未處理要求的執行個體 (閒置)。
設定執行個體數量下限後,即使執行個體未處理要求,Cloud Run 仍會讓至少下限數量的執行個體保持運作。如果有效執行個體未收到要求,min-instances
個以上的有效執行個體可能會進入閒置狀態。
舉例來說,如果 min-instances
為 10
,且有效執行個體數量為 0
,則閒置執行個體數量為 10
。當作用中執行個體數量增加至 6
時,閒置執行個體數量就會減少至 4
。
請注意,如果服務最近未放送流量,即使您為最低執行個體數指定了一或多個執行個體,有效執行個體指標仍可能顯示沒有任何執行個體處於有效狀態。
必要的角色
如要取得設定及部署 Cloud Run 服務所需的權限,請要求管理員授予下列 IAM 角色:
-
Cloud Run 開發人員 (
roles/run.developer
) 在 Cloud Run 服務上 -
服務帳戶使用者 (
roles/iam.serviceAccountUser
) 服務身分
如需與 Cloud Run 相關聯的 IAM 角色和權限清單,請參閱 Cloud Run IAM 角色和 Cloud Run IAM 權限。如果 Cloud Run 服務與Google Cloud API (例如 Cloud 用戶端程式庫) 介接,請參閱服務身分設定指南。 如要進一步瞭解如何授予角色,請參閱部署權限和管理存取權。
設定服務層級的執行個體數量下限
根據預設,容器執行個體會關閉服務層級的執行個體數量下限,並設為 0
。您可以使用Google Cloud 控制台、Google Cloud CLI 或 YAML 檔案變更這項預設值:
控制台
前往 Google Cloud 控制台的 Cloud Run:
如要設定新服務,請從選單中選取「服務」,然後按一下「部署容器」,顯示「建立服務」表單。找到「服務資源調度」表單。
如要設定現有服務,請按一下該服務以顯示詳細資料面板,然後按一下詳細資料面板右上方的「編輯服務層級資源調度設定」
。在標示為「Minimum number of instances」(執行個體數量下限) 的欄位中,指定要保持暖機狀態的容器執行個體數量,以便隨時接收要求。
按一下新服務的「建立」,或現有服務的「部署」。
gcloud
使用下列指令更新特定服務的執行個體數量下限:
gcloud run services update SERVICE --min MIN-VALUE
取代:
- SERVICE 改為您的服務名稱。
- MIN-VALUE,並指定要保持暖機狀態的容器執行個體數量,以便隨時接收要求。指定
default
即可清除任何最低執行個體設定。
或者,您也可以在部署期間使用以下指令,設定執行個體數量下限:
gcloud run deploy --image IMAGE_URL --min MIN-VALUE
取代
- IMAGE_URL,並參照容器映像檔,例如
us-docker.pkg.dev/cloudrun/container/hello:latest
。如果您使用 Artifact Registry,則必須先建立存放區 REPO_NAME。網址的格式為LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG
- MIN-VALUE,並指定要保持暖機狀態的容器執行個體數量,以便隨時接收要求。指定
default
即可清除所有執行個體數量下限設定。
YAML
變更任何設定都會建立新的修訂版本。除非您明確做出更新,變更這項設定,否則後續的修訂版本也會自動取得這個設定。
如要建立新服務,請略過這個步驟。 如要更新現有服務,請下載其 YAML 設定:
gcloud run services describe SERVICE --format export > service.yaml
更新
run.googleapis.com/minScale
屬性:apiVersion: serving.knative.dev/v1 kind: Service metadata: name: SERVICE annotations: run.googleapis.com/minScale: 'MIN_INSTANCE'
取代:
- SERVICE 改為 Cloud Run 服務名稱
- 將 MIN-INSTANCE 替換為要保持暖機狀態的執行個體數量,以便隨時接收要求。
使用下列指令建立或更新服務:
gcloud run services replace service.yaml
用戶端程式庫
如要透過程式碼更新服務的服務層級執行個體數量下限:
REST API
如要更新特定服務的服務層級最低執行個體數,請將 PATCH
HTTP 要求傳送至 Cloud Run Admin API service
端點。
例如使用 curl
:
curl -H "Content-Type: application/json" \ -H "Authorization: Bearer ACCESS_TOKEN" \ -X PATCH \ -d '{ "scaling": { "minInstanceCount": MIN-VALUE }}' \ https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services/SERVICE?update_mask=scaling.minInstanceCount
取代:
- ACCESS_TOKEN,並提供帳戶的有效存取權權杖,該帳戶必須具備更新服務的 IAM 權限。舉例來說,如果您已登入
gcloud
,可以使用gcloud auth print-access-token
擷取存取權杖。在 Cloud Run 容器執行個體中,您可以使用容器執行個體中繼資料伺服器擷取存取權杖。 - MIN-VALUE,並將其替換為要保持暖機狀態的容器執行個體數量,以便隨時接收要求。
- 將 SERVICE 改為服務名稱。
- 將 REGION 替換為服務的 Google Cloud 區域。
- 將 PROJECT-ID 改成 Google Cloud 專案 ID。
查看服務層級的執行個體數量下限
如要查看 Cloud Run 服務目前的服務等級執行個體數量下限設定:
控制台
前往 Google Cloud 控制台的 Cloud Run:
按一下感興趣的服務,開啟「服務詳細資料」面板。
服務詳細資料面板右上角會顯示目前的設定,旁邊是「Scaling」(調整規模)。
gcloud
使用下列指令:
gcloud run services describe SERVICE
在傳回的設定中,找出「資源調度:自動 (下限:MIN_VALUE,上限:MAX_VALUE)」的值。
在服務層級與修訂版本層級套用執行個體數量下限
您可以在服務層級或修訂版本層級設定執行個體數量下限。Google 建議您在服務層級套用執行個體數量下限,並避免合併服務層級和修訂版本層級的執行個體數量下限。
如果您在修訂版本層級套用執行個體數量下限,設定會在修訂版本部署後生效。如果您在服務層級套用這項功能,設定就會生效,不需要部署新修訂版本。
已加上標記的修訂版本和服務層級的執行個體數量下限
已標記的修訂版本會啟動,但只有在屬於流量分割時,才會計入服務層級的最低執行個體數。
帳單
使用「最少量執行個體」功能持續執行的執行個體會產生帳單費用。 由於這些費用非常容易預測,Google 建議您購買承諾使用折扣。
執行個體數量下限和以執行個體為依據的計費方式
如需要求以外的 CPU,可以設定以執行個體為準的帳單。
執行個體重新啟動次數下限
您隨時可以重新啟動最少執行個體。
修訂版本和執行個體數量下限
在服務層級設定執行個體數量下限時,系統會根據流量分配比例,將執行個體分配給所有提供流量的版本。
在修訂版本層級設定執行個體數量下限後,只要流量分配中參照修訂版本 (即使是 0%),或修訂版本已指派流量標記,系統就會啟動執行個體數量下限。
使用最少執行個體數量的要求轉送
設定執行個體下限後,Cloud Run 會在所有佈建的執行個體之間平均分配傳入要求。瞭解這項行為有助於管理費用,特別是採用以要求為準的計費方式,或是打算維護閒置的熱備援執行個體時。
如果設定的執行個體下限高於一般流量所需,許多執行個體可能會稍微啟動,各自處理少量要求。舉例來說,如果您的服務通常需要 200 個執行個體才能處理尖峰負載,但您將最低執行個體數設為 600,系統就會將傳入的要求分散到所有 600 個執行個體。因此,這 600 個執行個體中有許多會變得有些活躍,各自處理一小部分的流量,而不是約 200 個執行個體非常活躍,其餘 400 個則完全閒置。
如要盡量減少執行個體數量,同時提高使用率,進而節省成本,請將執行個體下限設為與實際數量相近的值,以利處理一般流量。
此外,當自動調度資源功能佈建的額外執行個體數量超過設定的執行個體數量下限時,Cloud Run 會優先將傳入要求轉送至設定的執行個體數量下限,再將要求傳送至自動調度資源的執行個體。採用以要求為準的計費方式時,優先將要求轉送至設定的最低執行個體數,可減少費用,因為系統會先填滿設定的最低執行個體數,再使用自動調度執行個體。請注意,視流量大小而定,這種優先轉送方式也可能導致設定的最低執行個體數使用率高於自動調度資源的執行個體。
設定修訂版本層級的執行個體數量下限
變更任何設定都會建立新的修訂版本。除非您明確做出更新,變更這項設定,否則後續的修訂版本也會自動取得這個設定。
根據預設,容器執行個體會min-instances
關閉,設定為 0
。您可以在建立新服務或部署新修訂版本時,使用 Google Cloud 控制台、Google Cloud CLI 或 YAML 檔案變更這項預設值:
控制台
前往 Google Cloud 控制台的 Cloud Run:
從選單中選取「服務」,然後按一下「部署容器」,設定新服務。如要設定現有服務,請按一下該服務,然後點選「編輯並部署新修訂版本」。
如要設定新服務,請填寫初始服務設定頁面,然後按一下「容器、磁碟區、網路與安全性」,展開服務設定頁面。
按一下「容器」分頁標籤。
- 在標示為「執行個體數量下限」的欄位中,指定要保持暖機狀態、準備好接收要求的容器執行個體數量。
按一下 [Create] (建立) 或 [Deploy] (部署)。
gcloud
您可以使用以下指令更新特定服務的 min-instance
:
gcloud run services update SERVICE --min-instances MIN-VALUE
取代:
- SERVICE 改為您的服務名稱。
- MIN-VALUE,並指定要保持暖機狀態的容器執行個體數量,以便隨時接收要求。指定
default
即可清除任何最低執行個體設定。
您也可以在部署期間使用以下指令設定 min-instance
:
gcloud run deploy --image IMAGE_URL --min-instances MIN-VALUE
取代:
- IMAGE_URL,並參照容器映像檔,例如
us-docker.pkg.dev/cloudrun/container/hello:latest
。如果您使用 Artifact Registry,則必須先建立存放區 REPO_NAME。網址的格式為LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG
- MIN-VALUE,並指定要保持暖機狀態的容器執行個體數量,以便隨時接收要求。指定
default
即可清除任何最低執行個體設定。
YAML
如要建立新服務,請略過這個步驟。 如要更新現有服務,請下載其 YAML 設定:
gcloud run services describe SERVICE --format export > service.yaml
更新
autoscaling.knative.dev/minScale:
屬性:apiVersion: serving.knative.dev/v1 kind: Service metadata: name: SERVICE spec: template: metadata: annotations: autoscaling.knative.dev/minScale: 'MIN-INSTANCE' name: REVISION
取代:
- SERVICE 改為 Cloud Run 服務名稱
- 將 MIN-INSTANCE 替換為要保持暖機狀態的執行個體數量,以便隨時接收要求。
- REVISION,並提供新的修訂版本名稱,或刪除該名稱 (如有)。如果您提供新的修訂版本名稱,則必須符合下列條件:
- 開頭為「
SERVICE-
」 - 只能包含小寫字母、數字和
-
- 結尾不是
-
- 不超過 63 個半形字元
- 開頭為「
使用下列指令建立或更新服務:
gcloud run services replace service.yaml
Terraform
如要瞭解如何套用或移除 Terraform 設定,請參閱「基本 Terraform 指令」。
在 Terraform 設定中,將下列內容新增至google_cloud_run_v2_service
資源:上述 google_cloud_run_v2_service
資源會指定 1
的執行個體數量下限 (template.scaling
)。將 1
替換為您自己的執行個體數量下限。
查看修訂版本層級的執行個體數量下限
如要查看 Cloud Run 服務目前的修訂版本層級執行個體數量下限設定,請執行下列操作:
主控台
前往 Google Cloud 控制台的 Cloud Run:
按一下感興趣的服務,開啟「服務詳細資料」面板。
按一下「Revisions」(修訂版本) 分頁標籤。
在右側的詳細資料面板中,「修訂版本最少執行個體數」設定會列在「容器」分頁下方。
gcloud
使用下列指令:
gcloud run services describe SERVICE
在傳回的設定中找出「最少執行個體數」的值。
同時使用服務層級和修訂版本層級的執行個體數量下限或上限
下表說明合併服務層級的最低執行個體數,以及修訂版本層級的最低或最高執行個體數時的行為:
設定 | 行為 |
---|---|
服務層級和修訂版本層級的執行個體數量下限都已設定。 | 修訂版本的有效值是修訂版本層級的執行個體數量下限和服務層級的執行個體數量下限中較大的值。 |
已設定服務層級的執行個體數量下限和修訂版本層級的執行個體數量上限。 | 修訂版本的有效值是修訂版本層級的執行個體數量上限,以及服務層級的執行個體數量下限中較小的值。 即使修訂版本層級的執行個體數量上限,會導致服務無法達到服務層級執行個體數量下限所設定的執行個體數量,也是如此。 |
使用服務層級的執行個體數量下限和流量拆分功能
如果使用流量分配,系統會根據流量分配比例,將服務層級的最低執行個體數分配給各個修訂版本。舉例來說,如果服務層級的最低執行個體數 = 10,則 50/50 的流量分配會為每個修訂版本分配 5 個服務層級的最低執行個體數。
下表列出設定情境範例:
應用實例範本 | 範例設定 | 產生的行為 |
---|---|---|
沒有修訂版本層級設定 | 服務層級的最低執行個體數量:10 個
|
修訂版本 A 會根據流量分配比例,從服務層級的執行個體數量下限接收 6 個執行個體。修訂版本 B 會根據流量分配比例,從服務層級的執行個體數量下限取得 4 個執行個體。 |
由於修訂版本層級的執行個體數量下限,收到的執行個體數量超過服務層級的執行個體數量下限 | 服務層級的最低執行個體數量:10 個
|
修訂版本 A 會從修訂版本層級的執行個體數量下限取得 6 個執行個體。修訂版本 B 會根據流量分配比例,從服務層級的執行個體數量下限取得 5 個執行個體。這超過服務層級的執行個體數量下限,且為預期行為。 |
由於修訂版本層級的執行個體數量上限,收到的執行個體數量少於服務層級的執行個體數量下限。 | 服務層級的最低執行個體數量:10 個
|
修訂版本 A 會從流量分配驅動的服務層級執行個體數量下限取得 3 個執行個體,但會受限於修訂版本層級的執行個體數量上限。 修訂版本 B 會從與流量分配成比例的服務層級執行個體數量下限取得 5 個執行個體。因此會產生 8 個服務層級執行個體,因為修訂版本 A 的修訂版本層級執行個體數量上限為 2,所以會遺失 2 個執行個體。 |
服務層級的執行個體數量下限大於流量分配中的修訂版本數量,且執行個體數量與流量分配成正比 | 服務層級的執行個體數量下限:3 個
|
修訂版本 A 的執行個體數量下限為 1,修訂版本 B 的執行個體數量下限為 2。服務的執行個體計數為 3。 |