為服務設定執行個體數量下限

本頁面說明如何使用預設的 Cloud Run 自動調度資源行為設定執行個體數量下限，為服務啟用閒置執行個體。如要手動調度服務資源，請參閱「手動調度資源」。

如要進一步控管服務的自動調度資源行為，可以設定執行個體數量下限，避免容器啟動時間過長，並縮短服務延遲時間。如果是 Cloud Run 服務，Cloud Run 預設會依據傳入要求的數量，將執行個體數量向內縮減。

不過，如果服務需要縮短延遲時間，尤其是從零個活躍執行個體擴充時，您可以變更這項預設行為，指定要保持暖機狀態、準備好處理要求的最低容器執行個體數量。如要進一步瞭解這項最佳化，請參閱一般開發提示。

Cloud Run 會移除未處理要求 (閒置) 的執行個體。設定執行個體數量下限後，Cloud Run 會維持至少該數量的執行個體運作，即使這些執行個體未處理要求也一樣。如果未收到要求，超過 min-instances 個的執行個體可能會閒置。

舉例來說，如果 min-instances 為 10，且使用中的執行個體數量為 0，則閒置執行個體數量為 10。當使用中的執行個體數量增加到 6 時，閒置執行個體數量就會減少到 4。

請注意，如果服務近期未曾處理流量，即使您已指定一或多個執行個體下限，使用中執行個體指標仍可能顯示沒有執行個體處於使用中狀態。

最低執行個體數量隨時可以重新啟動。

高可用性最佳做法

為確保服務維持高可用性，建議您將執行個體數量下限設為至少 3 個。

執行個體數量下限

執行個體數量下限是盡力達成的目標，目的是讓執行個體保持暖機狀態，隨時可供使用。即使您設定 3 個以上的執行個體，仍可能因下列未緩解的風險，導致執行個體數量暫時低於設定的下限：

• 可用區或區域容量：如果可用區或區域的容量嚴重不足，系統可能無法啟動或執行執行個體。
• 基礎架構重新平衡：基礎架構有時會重新平衡，這可能會導致啟動替代執行個體時暫時延遲。如要進一步瞭解執行個體的終止方式，請參閱執行個體關閉說明文件。
• 應用程式異常終止：如果容器在啟動時異常終止，或持續無法通過健康狀態檢查，系統會不斷嘗試啟動執行個體，以達到數量下限，但健康狀態良好、可提供服務的執行個體數量仍低於設定的下限。
• 配額和計費限制：如果專案達到 CPU 或記憶體配額上限，或計費功能已停用，平台會停止調度資源，並可能終止執行個體，無論最低執行個體設定為何。

帳單

使用執行個體數量下限功能，讓執行個體保持運作，會產生已計費用。

下圖說明為服務或修訂版本設定執行個體數量下限時，執行個體生命週期中的計費方式：

圖 1 接收並處理三項要求的執行個體範例。

根據帳單設定，服務的計費方式如下：

• 如果採用以要求為依據的計費模式，當執行個體閒置並等待處理要求時，系統會以較低的費率計費。如果執行個體數量下限設為 0，則執行個體閒置時不會計費。
• 如果採用以執行個體為依據的計費模式，系統會依據預設費率，針對整個執行個體生命週期收費。從啟動到關閉的時間，包括執行個體處理要求或閒置的時間。換句話說，即使執行個體數量下限設為 0，系統仍會按照預設費率向您收費。如果需要在要求以外使用 CPU，這個選項就很適合。如果執行個體數量下限設為 0，系統會按照預設費率計費。

由於這些費用可以預測，Google 建議您購買承諾使用折扣。

在服務層級和修訂版本層級套用執行個體數量下限

您可以在服務層級或修訂版本層級設定執行個體數量下限。Google 建議您在服務層級套用執行個體數量下限，並避免合併服務層級和修訂版本層級的執行個體數量下限。進一步瞭解同時設定服務層級和修訂版本層級資源調度設定時的行為。

如果您在修訂版本層級套用執行個體數量下限，設定會在部署修訂版本時生效。如果您在服務層級套用這項功能，設定就會生效，不必部署新修訂版本。

修訂版本和執行個體數量下限

在服務層級設定執行個體數量下限時，傳入的要求會按照流量拆分比例，分配給所有提供流量的修訂版本。

在修訂版本層級設定執行個體數量下限後，只要修訂版本在流量拆分中參照或獲派流量標記，系統就會啟動執行個體數量下限。也就是說，執行個體在處理要求和等待傳入要求時，都會產生費用。

重要事項： 如果設定了修訂版本層級的執行個體數量下限和流量標記，所有加上標記的修訂版本都會啟動並保持運作，即使沒有傳入要求也一樣。如要避免產生標記修訂版本的已計費用，請使用服務層級的執行個體數量下限，或在不再需要時移除修訂版本的標記。

已標記的修訂版本和服務層級執行個體數量下限

如果啟動已指派標記的修訂版本，且該修訂版本屬於流量拆分的一部分，則執行個體會計入服務層級的執行個體數量下限。

使用最少執行個體轉送要求

設定執行個體數量下限後，Cloud Run 會將傳入的要求平均分配給所有佈建的執行個體。瞭解這項行為對於管理成本至關重要，尤其是採用以要求為基礎的計費方式，或打算維護閒置的熱備援執行個體時。如要盡可能降低費用，請將執行個體數量下限設為處理一般流量所需的執行個體數量。

必要的角色

如要取得設定及部署 Cloud Run 服務所需的權限，請要求管理員授予您下列 IAM 角色：

• Cloud Run 服務的 Cloud Run 開發人員 (roles/run.developer)
• 服務身分的服務帳戶使用者 (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 檔案變更這項預設設定：

控制台

1. 前往 Google Cloud 控制台的「Cloud Run」頁面：

   前往 Cloud Run。

2. 從 Cloud Run 導覽選單中選取「Services」(服務)：

   1. 如要設定新服務，請按一下「Deploy container」(部署容器)，然後填寫初始服務設定頁面。

   2. 如要設定現有服務，請按一下該服務，然後按一下「Scaling」(資源調度) 分頁標籤。

3. 在「Service scaling」(服務資源調度) 區段的「Minimum number of instances」(執行個體數量下限) 欄位中，指定容器執行個體數量下限。

4. 按一下「建立」，建立新服務。依序點選「查看差異並重新部署」和「部署變更」，即可更新現有服務。

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

任何設定變更都會建立新的修訂版本。後續修訂版本也會自動套用這項設定，除非您明確變更。

1. 如果您要建立新服務，請略過這個步驟。如要更新現有服務，請下載其 YAML 設定：

   gcloud run services describe SERVICE --format export > service.yaml

2. 更新 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：要保持暖機狀態、準備接收要求的執行個體數量。

3. 使用下列指令建立或更新服務：

   gcloud run services replace service.yaml

   gcloud run services replace 指令預設會使用 service.yaml 檔案 (如有)。

用戶端程式庫

如要透過程式碼更新服務層級的執行個體數量下限，請按照下列步驟操作：

• Go
• Java
• Node.js
• Python
• Ruby
• PHP
• .NET

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 服務目前的服務層級執行個體數量下限設定，請按照下列步驟操作：

控制台

1. 前往 Google Cloud 控制台的 Cloud Run「Services」(服務) 頁面：

   前往 Cloud Run。

2. 按一下您感興趣的服務，開啟「Service details」(服務詳細資料) 面板。

3. 按一下「Scaling」(資源調度) 分頁標籤。

4. 在「Service scaling」(服務資源調度) 專區下方，找到「Minimum number of instances」(執行個體數量下限) 設定。

gcloud

1. 使用下列指令：

   gcloud run services describe SERVICE

2. 在傳回的設定中，找出「Scaling: Auto (Min: MIN_VALUE, Max: MAX_VALUE)」的值。

設定修訂版本層級的執行個體數量下限

任何設定變更都會建立新的修訂版本。後續修訂版本也會自動套用這項設定，除非您明確變更。

根據預設，容器執行個體會關閉 min-instances，設定為 0。

只有先前已設定這項功能的服務，才能使用修訂版本層級資源調度。

控制台

1. 前往 Google Cloud 控制台的「Cloud Run」頁面：

   前往 Cloud Run。

2. 從 Cloud Run 導覽選單中選取「Services」(服務)：

   1. 如要設定新服務，請按一下「Deploy container」(部署容器)，然後填寫初始服務設定頁面。然後按一下「容器、網路、安全性」，展開服務設定頁面。

   2. 如要設定現有服務，請按一下該服務，然後按一下「Scaling」(資源調度) 分頁標籤。

3. 在「Revision scaling」(修訂版本資源調度) 區段中，於「Minimum number of instances」(執行個體數量下限) 欄位指定容器執行個體數量下限。

4. 按一下「建立」，建立新服務。依序點選「查看差異並重新部署」和「部署變更」，即可更新現有服務。

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

1. 如果您要建立新服務，請略過這個步驟。如要更新現有服務，請下載其 YAML 設定：

   gcloud run services describe SERVICE --format export > service.yaml

2. 更新 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 個字元

3. 使用下列指令建立或更新服務：

   gcloud run services replace service.yaml

   gcloud run services replace 指令預設會使用 service.yaml 檔案 (如有)。

Terraform

如要瞭解如何套用或移除 Terraform 設定，請參閱「基本 Terraform 指令」。

在 Terraform 設定中，將下列內容新增至 google_cloud_run_v2_service 資源：

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-min-instances"
  location = "us-central1"

  deletion_protection = false # set to "true" in production

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"
    }
    scaling {
      # Min instances
      min_instance_count = 1
    }
  }
}

上述 google_cloud_run_v2_service 資源指定了 template.scaling 下 1 的執行個體數量下限。將 1 替換為您自己的執行個體數量下限。

查看修訂版本層級的執行個體數量下限

修訂版本層級資源調度功能僅適用於先前已設定該功能的服務。

如要查看 Cloud Run 服務目前的修訂版本層級執行個體數量下限設定，請按照下列步驟操作：

控制台

1. 前往 Google Cloud 控制台的 Cloud Run「Services」(服務) 頁面：

   前往 Cloud Run。

2. 按一下您感興趣的服務，開啟「Service details」(服務詳細資料) 面板。

3. 按一下「Scaling」(資源調度) 分頁標籤。

4. 在「Revision scaling」(修訂版本資源調度) 區段下方，找到「Minimum number of instances」(執行個體數量下限) 設定。

gcloud

1. 使用下列指令：

   gcloud run services describe SERVICE

2. 在傳回的設定中，找出「Min instances:」的值。

範例

以下各節說明設定執行個體數量下限時的服務行為。

同時使用服務層級和修訂版本層級的執行個體數量下限或上限

您可以合併服務層級和修訂版本層級的執行個體數量下限或上限。如果同時設定這兩項，最終的執行個體限制會依據下列規則決定：

• 上限一律優先於下限：無論下限設定為何，只要在服務層級或修訂版本層級設定上限，系統就絕對不會擴充超過該值。
• 下限以最大值為準：如果有多個下限生效，且未受上限限制，自動配置器會滿足最高的下限。

服務	修訂版本	解決規則	產生的行為
最小值	最小值	最高最低勝率	如果服務下限為 10，修訂版本下限為 5，修訂版本會執行 10 個執行個體，以滿足較大的全域下限。
最小值	最大值	修訂版本上限會覆寫服務下限	如果服務下限為 10，但修訂版本上限為 5，則修訂版本會嚴格限制為 5 個執行個體。
最大值	最小值	服務上限會覆寫修訂版本下限	如果服務上限為 5，但修訂版本下限為 10，則修訂版本會嚴格限制為 5 個執行個體。
最大值	最大值	最低最高勝率	如果服務上限為 5，修訂版本上限為 10，則修訂版本的執行個體數量上限為 5。

Cloud Run 會先計算有效的執行個體數量上限 (服務層級和修訂版本層級上限中較小的值)，藉此解決容量限制。接著，系統會判斷有效的執行個體數量下限 (修訂版本層級下限和分配的服務層級下限，兩者取較大值)，並將結果限制在有效上限。

如未設定值，自動配置器會使用預設值，例如服務層級和修訂版本層級的執行個體數量下限為 0，修訂版本層級的執行個體數量上限為 100。

使用服務層級執行個體數量下限，並拆分流量

如果您使用流量拆分功能，系統會根據流量拆分比例，將服務層級的執行個體數量下限分配給各個修訂版本。舉例來說，如果服務層級的執行個體數量下限為 10，則 50/50 的流量拆分會為每個修訂版本分配 5 個服務層級執行個體數量下限。

下表列出設定情境範例：

應用實例範本	服務分鐘數	修訂版本 A	修訂版本 B	流量拆分	產生的行為
沒有修訂版本層級設定	10	下限：0	下限：0	60/40	修訂版本 A 根據流量分配比例，從服務層級執行個體數量下限獲得 6 個執行個體。修訂版本 B 則會根據流量分配比例，從服務層級執行個體數量下限獲得 4 個執行個體。
因修訂版本層級的執行個體數量下限，而收到超過服務層級的執行個體數量下限	10	最小值：6	下限：0	50/50	修訂版本 A 根據修訂版本層級的執行個體數量下限，獲得 6 個執行個體。修訂版本 B 則會根據流量分配比例，從服務層級執行個體數量下限獲得 5 個執行個體。這超過服務層級的執行個體數量下限，符合預期。
由於修訂版本層級的執行個體數量上限，收到的執行個體數量低於服務層級的執行個體數量下限	10	最小值：0 最大值：3	下限：0	50/50	修訂版本 A 根據流量分配，從服務層級執行個體數量下限獲得 3 個執行個體，但受限於修訂版本層級執行個體數量上限。 修訂版本 B 根據流量分配，從服務層級執行個體數量下限獲得 5 個執行個體。因此，服務層級執行個體數量為 8 個，因為修訂版本 A 的修訂版本層級執行個體數量上限為 2 個，所以有 2 個執行個體遺失。
服務層級執行個體數量下限大於流量分配中的修訂版本數量，且執行個體數量與流量分配成比例	3	下限：0	下限：0	50/50	分數分配 (每個 1.5 個執行個體) 會四捨五入。流量部分中列出的第一個修訂版本會收到無條件進位的值：修訂版本 B (列在第一個) 取得 2 個執行個體，修訂版本 A 取得 1 個。執行個體總數為 3。

決定所需的執行個體數量下限

如果執行個體數量下限高於一般流量所需，許多執行個體可能會稍微活躍，各自處理少量要求。舉例來說，如果服務在尖峰負載時通常需要 200 個執行個體，但執行個體數量下限設為 600 個，傳入的要求就會分散到所有 600 個執行個體。這會導致這 600 個執行個體中，有許多執行個體變得有點活躍，每個執行個體都處理一小部分流量，而不是約 200 個執行個體高度活躍，其餘 400 個執行個體完全閒置。

如要盡可能降低費用 (在較少執行個體上提高使用率)，請將執行個體數量下限設為接近實際所需的執行個體數量，以便處理一般流量。

此外，如果自動調度資源功能佈建的執行個體數量超過設定的下限，Cloud Run 會優先將傳入的要求轉送至設定的下限執行個體，然後再將要求傳送至自動調度資源的執行個體。如果採用以要求為準的計費方式，系統會優先將流量轉送至設定的執行個體數量下限，填滿後才會使用自動調度資源的執行個體，進而降低費用。請注意，視流量而定，這項優先轉送功能也可能導致設定的執行個體數量下限使用率高於自動調度資源的執行個體。