設定服務的工作階段相依性

本頁面說明如何為 Cloud Run 服務修訂版本啟用工作階段相依性。

工作階段相依性的運作方式

根據預設，系統不會啟用工作階段相依性，因此同一個用戶端提出的要求可能會由不同的執行個體處理，如下所示：

如果啟用工作階段相依性，Cloud Run 會將特定用戶端的連續要求轉送至相同的修訂版本執行個體。Cloud Run 會使用工作階段相依性 Cookie (存留時間為 30 天)，並檢查其值，以辨識同一用戶端傳送的多個要求，並將所有要求導向同一個執行個體，如下所示：

需要注意的重要行為

如上圖所示，啟用工作階段親和性後，用戶端會連線至相同的例項。不過，請注意，執行個體可以接收來自不同用戶端的要求。工作階段相依性並不代表該例項只專屬於一個用戶端。

由於 Cloud Run 的自動調整大小行為，工作階段相依性是盡力相依性。如果執行個體因任何原因而終止，或達到要求並行處理數上限或 CPU 使用率上限，則工作階段相依性會中斷，後續要求會轉送到其他執行個體。

雖然您可以在例項的記憶體中快取用戶端工作階段資料，但即使已啟用工作階段親和性，也不能假設用戶端會一律重新連線至相同的例項。

Cloud Load Balancing 工作階段相依性和 Cloud Run 工作階段相依性是兩種獨立的實作工作階段相依性。您可以在 Cloud Run 服務上啟用 Cloud Run 的工作階段相依性，即使該服務位於負載平衡器後方也一樣。不過，您不應在無伺服器網路端點群組中啟用 Cloud Load Balancing 工作階段相依性，因為系統不支援這項功能。

工作階段相依性和流量分配

您可以在修訂版本層級啟用或停用工作階段相依性。如果您在 Cloud Run 修訂版本上啟用工作階段相依性，同時也使用流量拆分功能，則工作階段相依性會優先於任何流量拆分。在極端情況下，如果使用工作階段親和性的單一用戶端負責處理大部分的所有要求，則所有這些要求都會轉送至特定修訂版本，無論流量分配設定為何。

如果您為修訂版本啟用流量拆分功能，其中部分修訂版本已啟用工作階段相依性，而其他則未啟用，結果就是要求會逐漸轉移至已啟用工作階段相依性的修訂版本，即使您未明確變更流量拆分設定也一樣。原因是每個未附加工作階段相依性 Cookie 的請求都會隨機分割，其中部分請求最終會指派給具有工作階段相依性的修訂版本，而後續這些請求都會保留在該特定修訂版本中。

更新 Cloud Run 服務的流量拆分設定時，附帶工作階段相依性 Cookie 的後續要求可能會指派給不同的修訂版本。Cloud Run 會盡量減少重新導向至新修訂版本的用戶端數量。

舉例來說，如果服務以 90%/10% 的比例拆分流量，而流量拆分比例更新為 80%/20%，則 10% 的流量會重新導向至目前提供 20% 流量的修訂版本。

設定工作階段相依性

任何設定變更都會建立新的修訂版本。除非您明確做出更新，否則後續的修訂版本也會自動取得這個設定。

您可以使用 Google Cloud 主控台、gcloud 指令列或 .yaml 檔案，在建立新服務或部署新版本時設定工作階段相依性：

gcloud run services update SERVICE --session-affinity

gcloud run services update SERVICE --no-session-affinity

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-aff"
  location = "us-central1"
  deletion_protection = false
  ingress = "INGRESS_TRAFFIC_ALL"

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"
    }
    session_affinity = BOOL
  }
}

查看工作階段相依性設定

如要查看 Cloud Run 服務目前的工作階段相依性設定，請按照下列步驟操作：