本頁說明如何使用預設的 Cloud Run 自動調度資源行為，設定服務的最低執行個體數，藉此啟用閒置執行個體。如要手動調整服務資源配置，請參閱手動調整資源配置。
如要進一步控管服務的自動調度行為，您可以設定執行個體數量下限，避免容器啟動時間過長，並縮短服務延遲時間。如果是 Cloud Run 服務，Cloud Run 預設會根據傳入要求數量調度執行個體。
不過，如果服務需要縮短延遲時間，特別是從零個有效執行個體開始擴充時，您可以變更這項預設行為，指定要保持暖機狀態、準備好處理要求的最低容器執行個體數量。如要進一步瞭解這項最佳化作業，請參閱一般開發提示。
Cloud Run 會移除未處理要求的執行個體 (閒置)。
設定執行個體數量下限後，即使沒有處理要求，Cloud Run 仍會讓至少下限數量的執行個體保持運作。如果有效執行個體未收到要求，min-instances 個以上的有效執行個體可能會進入閒置狀態。
舉例來說，如果 min-instances 為 10，且有效執行個體數量為 0，則閒置執行個體數量為 10。當作用中執行個體數量增加至 6 時，閒置執行個體數量就會減少至 4。
請注意，如果服務最近未放送流量，即使您為最低執行個體指定了一或多個執行個體，有效執行個體指標仍可能顯示沒有任何執行個體處於有效狀態。
您隨時可以重新啟動最低執行個體數。
帳單
使用「最少量執行個體」功能持續執行的執行個體會產生帳單費用。
下圖說明為服務或修訂版本設定最低執行個體數時，執行個體生命週期的計費方式：
系統會根據您設定的帳單設定，以以下方式收取服務費用：
- 如果採用以要求為依據的計費模式，當執行個體處於閒置狀態並等待處理要求時，系統會按照較低的費率收費。如果將執行個體數量下限設為
0，執行個體閒置時就不會產生費用。 - 如果採用以執行個體為依據的計費模式，系統會針對整個執行個體生命週期收取預設費率的費用。啟動和關閉之間的時間包括執行個體處理要求或閒置的時間。換句話說，即使將 min_instances 設為
0，系統仍會以預設費率計費。如果您需要在非處理要求時使用 CPU，這個選項就很適合。如果將 min instances 設為0，系統會以預設費率計費。
由於這些費用是可預測的，因此 Google 建議您購買承諾使用折扣。
在服務層級套用執行個體數量下限，而非修訂版本層級
您可以在服務層級或修訂版本層級設定執行個體數量下限。Google 建議您在服務層級套用執行個體數量下限，並避免合併服務層級和修訂版本層級的執行個體數量下限。進一步瞭解同時設定服務層級和修訂版本層級資源調度設定時的行為。
如果您在修訂版本層級套用執行個體數量下限，設定會在修訂版本部署後生效。如果您在服務層級套用這項功能，設定就會生效，不需要部署新修訂版本。
修訂版本和執行個體數量下限
在服務層級設定最低執行個體數量後，系統會根據流量分配比例，將傳入要求分配給所有提供流量的修訂版本。
在修訂版本層級設定執行個體數量下限後，只要流量分配參照修訂版本，或修訂版本已指派流量標記，系統就會啟動最少數量的執行個體。也就是說，執行個體在處理要求時會產生費用，等待傳入要求時也會產生費用。
已加上標記的修訂版本和服務層級的執行個體數量下限
如果啟動已指派標記的修訂版本，且該版本屬於流量分割，則執行個體會計入服務層級的最低執行個體數。
使用最少執行個體數量的要求轉送
設定執行個體下限後，Cloud Run 會在所有佈建的執行個體之間平均分配傳入要求。瞭解這項行為對於管理費用非常重要，尤其是採用以要求為準的計費方式，或是打算維持閒置的熱備援執行個體時。為盡量降低成本，請將執行個體數量下限設為提供一般流量所需的執行個體數量。
必要的角色
如要取得設定及部署 Cloud Run 服務所需的權限，請要求管理員授予下列 IAM 角色：
-
Cloud Run 開發人員 (
roles/run.developer) 在 Cloud Run 服務上 -
服務帳戶使用者 (
roles/iam.serviceAccountUser) 服務身分
如果您要從原始碼部署服務或函式，您也必須在專案和 Cloud Build 服務帳戶中獲得額外角色。
如需與 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：專案 ID。 Google Cloud
查看服務層級的執行個體數量下限
如要查看 Cloud Run 服務目前的服務等級執行個體數量下限設定：
控制台
前往 Google Cloud 控制台的 Cloud Run：
按一下感興趣的服務，開啟「服務詳細資料」面板。
服務詳細資料面板右上角會顯示目前的設定，旁邊是「Scaling」(調整規模)。
gcloud
使用下列指令：
gcloud run services describe SERVICE
在傳回的設定中，找出「資源調度：自動 (下限：MIN_VALUE，上限：MAX_VALUE)」的值。
設定修訂版本層級的執行個體數量下限
變更任何設定都會建立新的修訂版本。除非您明確做出更新，變更這項設定，否則後續的修訂版本也會自動取得這個設定。
根據預設，容器執行個體會min-instances關閉，並設為 0。您可以在建立新服務或部署新修訂版本時，使用 Google Cloud 控制台、Google Cloud CLI 或 YAML 檔案變更這項預設值：
控制台
前往 Google Cloud 控制台的 Cloud Run：
從選單中選取「服務」，然後按一下「部署容器」，設定新服務。如要設定現有服務，請按一下該服務，然後點選「Edit and deploy new revision」(編輯及部署新修訂版本)。
如要設定新服務，請填寫初始服務設定頁面，然後按一下「容器、磁碟區、網路與安全性」，展開服務設定頁面。
按一下「容器」分頁標籤。
- 在標示為「執行個體數量下限」的欄位中，指定要保持暖機狀態的容器執行個體數量，以便隨時接收要求。
按一下 [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。 |
判斷所需的執行個體數量下限
如果設定的執行個體下限高於一般流量所需，許多執行個體可能會稍微啟動，各自處理少量要求。舉例來說，如果您的服務通常需要 200 個執行個體才能處理尖峰負載，但您將最低執行個體數設為 600，系統就會將傳入的要求分散到所有 600 個執行個體。因此，這 600 個執行個體中有許多會變得有些活躍，各自處理一小部分的流量，而不是約 200 個執行個體高度活躍，其餘 400 個則完全閒置。
如要盡量降低成本 (在較少的執行個體上提高使用率)，請將最低執行個體數設為與實際執行個體數相近的值，以處理一般流量。
此外，當自動調度資源功能佈建的額外執行個體數量超過設定的執行個體數量下限時，Cloud Run 會優先將傳入要求轉送至設定的執行個體數量下限，再將要求傳送至自動調度資源的執行個體。採用以要求為準的計費方式時，這項優先將要求轉送至設定最低執行個體數量的功能，可先填滿設定的最低執行個體數量，再使用自動調度執行個體，進而降低費用。請注意，視流量大小而定，這種優先路由也可能導致設定的最低執行個體數，比自動調度資源的執行個體數有更高的使用率。