排解 Cloud Run 問題

本頁說明如何排解使用 Cloud Run 時可能遇到的錯誤。Personalized Service Health 會發布所有因基礎 Google Cloud 基礎架構而產生的 Cloud Run 事件，找出影響專案的 Google Cloud 服務中斷情形。建議您設定 Personalized Service Health 事件快訊。如要瞭解影響所有 Google Cloud 服務的事件，請參閱「Google Cloud Service Health」資訊主頁。

在公開 Issue Tracker 中查看現有問題或提交新問題。

如需本頁未列出的其他錯誤訊息，請參閱「Cloud Run 的已知問題」。如果按照本指南中的步驟操作後，仍持續發生錯誤，請與支援團隊聯絡。

請參閱下列各節，瞭解如何解決 Cloud Run 中的問題：

部署錯誤

本節說明 Cloud Run 中常見的部署錯誤，以及排解這些錯誤的方法。

容器無法啟動

嘗試部署時發生下列錯誤：

Container failed to start. Failed to start and then listen on the port defined by the PORT environment variable.

如要解決這個問題，請按照下列步驟操作：

  1. 確認您可以在本機執行容器映像檔。如果容器映像檔無法在本機執行，請先在本機診斷及修正問題。

  2. 檢查容器是否在正確的通訊埠上監聽要求。容器必須監聽 Cloud Run 定義的通訊埠，並透過 PORT 環境變數提供。如需指定通訊埠的操作說明，請參閱「為服務設定容器」。

  3. 檢查容器是否正在監聽所有網路介面，通常以 0.0.0.0 表示。請注意，您的容器「不應」監聽 127.0.0.1。

  4. 確認容器映像檔已編譯為 64 位元 Linux，這是容器執行階段合約的規定。

  5. 使用 Cloud Logging在 stdout 或 stderr 記錄檔中尋找應用程式錯誤。您也可以查看 Error Reporting 擷取的當機事件。

    您可能需要更新程式碼或修訂版本設定，才能修正錯誤或當機問題。您也可以在本機排解服務問題。

容器匯入錯誤

嘗試部署時發生下列錯誤：

The service has encountered an error during container import. Please try again later. Resource readiness deadline exceeded.

如要解決這個問題，請按照下列步驟操作：

  1. 確認容器的檔案系統不含非 UTF-8 字元。

  2. 部分以 Windows 為基礎的 Docker 映像檔會使用外部層。Cloud Run 的控制層不支援外部層。如要解決這個問題，請嘗試在 Docker daemon 中設定 --allow-nondistributable-artifacts 旗標。

不支援這項功能

呼叫 Cloud Run Admin API 時發生下列錯誤：

The feature is not supported in the declared launch stage

如果直接呼叫 Cloud Run Admin API，並使用 Beta 版功能，但未指定推出階段註解或欄位，就會發生這項錯誤。

如要解決這個問題，請在要求中新增推出階段欄位。

請參考下列範例，瞭解如何在使用 v1 或 v2 REST API 時新增推出階段參照：

  • 使用 JSON 和 v1 REST API，將推出階段註解新增至用戶端要求：

      "annotations": {
    "run.googleapis.com/launch-stage": "BETA"
  }

  • LaunchStage 參考用戶端要求，使用 JSON 和 v2 REST API：

    "launchStage": "BETA"

  • 使用 YAML 和 v1 REST API，將推出階段註解套用至服務要求：

    kind: Service
metadata:
annotations:
  run.googleapis.com/launch-stage: BETA

找不到使用者 root

使用 --key 參數指定客戶自行管理的加密金鑰時，會發生下列錯誤：

ERROR: "User \"root\""not found in /etc/passwd

如要解決這個問題，請在 Dockerfile 中指定 USER 0，而非 USER root。

預設的 Compute Engine 服務帳戶已刪除

部署期間發生下列錯誤：

ERROR: (gcloud.run.deploy) User EMAIL_ADDRESS does not have permission to access namespace NAMESPACE_NAME (or it may not exist): Permission 'iam.serviceaccounts.actAs' denied on service account PROJECT_NUMBER-compute@developer.gserviceaccount.com (or it may not exist).

這個問題會在下列任一情況發生時出現：

如何解決這個問題：

  1. 使用 --service-account 旗標指定服務帳戶：

    gcloud run services update SERVICE_NAME --service-account SERVICE_ACCOUNT

  2. 確認您指定的服務帳戶具備部署所需的權限。

如要確認 Google Cloud 專案中是否有預設的 Compute Engine 服務代理，請按照下列步驟操作：

  1. 前往 Google Cloud 控制台的 Identity and Access Management「Permissions」(權限) 頁面：

    前往權限設定

  2. 勾選「包含 Google 提供的角色授予項目」核取方塊。

  3. 在「Principals」(主體) 清單中，找出 Compute Engine 服務代理的 ID，格式為 PROJECT_NUMBER-compute@developer.gserviceaccount.com。

Cloud Build 服務帳戶問題

如果 Cloud Build 服務帳戶沒有必要權限或已停用，來源部署期間會發生下列錯誤：

ERROR: (gcloud.run.deploy) NOT_FOUND: Build failed. The service has encountered an internal error. Please try again later. This command is authenticated as EMAIL_ADDRESS which is the active account specified by the [core/account] property.

Cloud Build 變更了新專案中服務帳戶的預設行為使用方式。詳情請參閱「Cloud Build 預設服務帳戶異動」一文。這項異動會導致新專案首次從原始碼部署至 Cloud Run 時，可能使用權限不足的預設 Cloud Build 服務帳戶，無法從原始碼部署。

如要解決這個問題，請按照下列步驟操作：

Cloud Run 服務代理缺少讀取映像檔的權限

當您嘗試從專案部署時，如果使用儲存在 Artifact Registry 中的映像檔，並在其他專案中使用 gcr.io 網域，就會發生下列錯誤：

Google Cloud Run Service Agent must have permission to read the image, gcr.io/PROJECT-ID/IMAGE-NAME. Ensure that the provided container image URL is correct and that above account has permission to access the image. If you just enabled the Cloud Run API, the permissions might take a few minutes to propagate. Note that PROJECT-ID/IMAGE-NAME is not in project PROJECT-ID-2. Permission must be granted to the Google Cloud Run Service Agent from this project.

如果您嘗試從專案部署映像檔，但該映像檔儲存在其他專案的 Artifact Registry 中，也可能會看到下列錯誤訊息：

ERROR: (gcloud.run.deploy) PERMISSION_DENIED: User must have permission to read
the image, REGION.pkg.dev/PROJECT_ID/ARTIFACT_REGISTRY_REPO/IMAGE:latest. Ensure that the provided container image URL is correct
and that the above account has permission to access the image. If you just enabled
the Cloud Run API, the permissions might take a few minutes to propagate. Note
that the image is from project PROJECT_ID, which is not the same as
this project PROJECT_ID.

如要解決這個問題，請按照下列疑難排解建議操作：

  • 請按照從其他 Google Cloud 專案部署容器映像檔的操作說明，確保主體具備必要權限。

  • 如果專案位於 VPC Service Controls perimeter 內，且 Cloud Storage API 設有限制，禁止 Cloud Run 服務代理提出要求，也可能發生這個問題。修正方法如下：

    1. 在 Google Cloud 控制台中開啟「Logs Explorer」(記錄檔探索工具)。(請勿使用 Cloud Run 頁面中的「Logs」(記錄) 頁面)：

      前往 Logs Explorer

    2. 在查詢欄位中輸入下列文字：

      protoPayload.@type="type.googleapis.com/google.cloud.audit.AuditLog"
severity=ERROR
protoPayload.status.details.violations.type="VPC_SERVICE_CONTROLS"
protoPayload.authenticationInfo.principalEmail="service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com"

    3. 如果使用這項查詢後看到任何記錄項目，請檢查這些項目，判斷是否需要更新 VPC Service Controls 政策。這可能表示您需要在現有的存取權政策中新增 service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com。

缺少來源部署作業的權限

從來源部署時，可能會發生下列錯誤：

ERROR: (gcloud.run.deploy) EMAIL_ADDRESS does not have permission
to access namespaces instance PROJECT_ID (or it may not exist): Google
Cloud Run Service Agent does not have permission to get access tokens for
the service account SERVICE_ACCOUNT. Please give SERVICE_ACCOUNT
permission iam.serviceAccounts.getAccessToken on the service account.

Alternatively, if the service account is unspecified or in the same project you
are deploying in, ensure that the Service Agent is assigned the Google
Cloud Run Service Agent role roles/run.serviceAgent. This
command is authenticated as EMAIL_ADDRESS, which is the active account
specified by the [core/account] property.

每項 Cloud Run 服務都與一個服務帳戶相關聯，在服務存取其他資源時，該帳戶則用於識別身分。這個服務帳戶可以是預設服務帳戶 (PROJECT_NUMBER-compute@developer.gserviceaccount.com)，也可以是使用者自行管理的服務帳戶。

在多個服務存取不同資源的環境中，您可以使用每個服務身分，搭配不同的使用者管理服務帳戶，而非預設服務帳戶。

如要解決這個問題，請在做為服務身分使用的服務帳戶上，授予部署者帳戶「服務帳戶使用者」角色 (roles/iam.serviceAccountUser)。這個預先定義的角色包含 iam.serviceAccounts.actAs 權限，可將服務帳戶附加至服務或修訂版本。建立使用者自行管理的服務帳戶時，系統會自動授予 iam.serviceAccounts.actAs 權限，但其他部署者必須由建立該帳戶的使用者授予這項權限。

如要進一步瞭解新建立服務帳戶的存取權規定，請參閱「取得建立專用服務帳戶的建議」。

使用者權限不足，無法完成來源部署作業

如果部署者帳戶缺少專案的必要權限，就會發生下列錯誤：

ERROR: (gcloud.run.deploy) 403 Could not upload file EMAIL_ADDRESS does
not have storage.objects.create access to the Google Cloud Storage object. Permission storage.objects.create denied on resource (or it may not exist). This
command is authenticated as EMAIL_ADDRESS which is the active account.

如要解決這項錯誤，請要求管理員授予您下列 Identity and Access Management 角色：

從其他 Google Cloud 專案部署 Cloud Run 服務時發生錯誤

將 Cloud Run 服務從來源專案部署至目標專案時，會發生下列錯誤：

Failed to create service.
Operation failed due to missing permissions.

Google Cloud Run Service Agent does not have permission to get access
tokens for the service account SERVICE_ACCOUNT. Please give
SERVICE_ACCOUNT permission iam.serviceAccounts.getAccessToken
on the service account. Alternatively, if the service account is unspecified or
in the same project you are deploying in, ensure that the Service Agent is
assigned the Google Cloud Run Service Agent role roles/run.serviceAgent.

如要解決這個問題，請按照下列步驟操作：

  1. 在目標專案中，將服務帳戶使用者 (roles/iam.serviceAccountUser) 角色授予您做為服務身分的服務帳戶。

  2. 將服務帳戶權杖建立者 (roles/iam.serviceAccountTokenCreator) 角色授予目標專案中的 Cloud Run 服務帳戶。將 Cloud Run 服務代理電子郵件 (service-PROJECT_NUMBER@SERVICE_DOMAIN.iam.gserviceaccount.com) 新增為來源專案的主體。

  3. 關閉 iam.disableCrossProjectServiceAccountUsage 組織政策。

如需詳細操作說明，請參閱「為服務設定服務身分」。

將 Python 原始碼部署至 Cloud Run 時發生錯誤

使用 Python 執行階段從原始碼部署 Cloud Run 服務時，會發生下列其中一個錯誤：

  • Revision REVISION_NAME is not ready and cannot serve traffic.
The user provided container failed to start and listen on port defined by PORT=8080
environment variable within the allocated timeout. This can happen if the port is
misconfigured or if the timeout is too short. The healthcheck timeout can be extended.
  • 部署作業成功，但記錄中出現 HTTP 500 錯誤代碼。

Python 建構套件會為 Cloud Run 來源部署作業設定預設進入點。如果是 Python 3.13 以上版本，Python buildpack 會根據 requirements.txt 檔案中的 Web 服務設定，設定進入點。如果您未在 requirements.txt 檔案中指定網頁伺服器或框架，或是使用 Python 3.12 以下版本，Python buildpack 會將預設進入點設為 gunicorn -b :8080 main:app。詳情請參閱「建構 Python 應用程式」。

你可以透過下列幾種方式解決這個問題：舉例來說，您可以在 requirements.txt 檔案中指定下列其中一個網路伺服器：

  • gunicorn：

      # https://pypi.org/project/gunicorn/
  gunicorn==21.2.0

  • fastapi 和 uvicorn：

    
# https://pypi.org/project/fastapi
fastapi[standard]==0.116.1

# https://pypi.org/project/uvicorn
uvicorn==0.35.0

或者，您也可以按照下列任一步驟解決部署錯誤：

  • 執行下列來源部署指令，指定進入點：

    gcloud run deploy SERVICE --source .  --set-build-env-vars GOOGLE_ENTRYPOINT="ENTRYPOINT"

    更改下列內容：

    • SERVICE：要部署至的服務名稱。
    • ENTRYPOINT：要用於原始碼的預設進入點。

  • 使用 Procfile 設定進入點。

放送錯誤

本節列出可能會遇到的放送問題，並附上每項問題的修正建議。

修訂版本不存在或已刪除

更新服務流量時發生下列問題：

Revision REVISION_NAME does not exist or is deleted

如果更新服務流量時發生錯誤 (例如「修訂版本不存在或已刪除」)，可能表示流量設定中的標記仍參照已刪除的修訂版本。如要解決這個問題，請手動更新流量分配，移除孤立代碼：

  • 使用 CLI：執行 gcloud run services update-traffic <var>SERVICE_NAME</var> --to-latest，或明確將流量標記重新指派給現有的有效修訂版本。
  • 使用 Google Cloud 控制台：前往服務，前往「Revisions」(修訂版本)分頁，然後編輯流量分配，移除指向已刪除修訂版本的標記。

HTTP 404：找不到

放送期間發生下列問題：

`HTTP 404`:Not found

在下列情況中，您可能會遇到 HTTP 404 錯誤：

  1. 如果要求網址或應用程式程式碼有誤，系統會傳回 404 錯誤。如要解決這個問題，請按照下列步驟操作：

    1. 請確認要求的網址是否正確。如要驗證網址，請前往 Google Cloud 控制台的服務詳細資料頁面，或執行下列指令：

      gcloud run services describe SERVICE_NAME | grep URL

    2. 檢查應用程式傳回 404 錯誤代碼的位置。如果應用程式傳回 404，您可以在 Cloud Logging 中找到。此外，請確認在本機執行應用程式時，不會傳回 404 錯誤代碼。

    3. 請確保應用程式在準備好接收要求前，不會開始監聽設定的連接埠。

  2. 要求未送達容器，導致在下列情況發生 404 錯誤：

    • 要求不符合指定的網路限制，尤其是 Cloud Run 服務的輸入設定設為「Internal」(內部) 或「Internal and Cloud Load Balancing」(內部和 Cloud Load Balancing) 時。

    • Cloud Run 服務的預設 run.app 網址已停用，而用戶端嘗試透過該 run.app 網址連線至服務。

    在這兩種情況下，即使套用下列篩選器，也無法在 Cloud Logging 中找到 404 錯誤：

    resource.type="cloud_run_revision"
log_name="projects/PROJECT_ID/logs/run.googleapis.com%2Frequests"
httpRequest.status=404

  3. 在相同的輸入設定下，VPC Service Controls 可能會根據呼叫端的環境 (包括專案和 IP 位址) 封鎖要求。如要檢查是否違反 VPC Service Controls 政策，請按照下列步驟操作：

    1. 在 Google Cloud 控制台中開啟 Logs Explorer：

      前往 Logs Explorer

    2. 在查詢欄位中輸入下列文字：

      resource.type="audited_resource"
log_name="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fpolicy"
resource.labels.method="run.googleapis.com/HttpIngress"

    3. 如果使用這項查詢後看到任何記錄項目，請檢查記錄項目，判斷是否需要更新 VPC Service Controls 政策。

  4. 使用 Python 執行階段，透過負載平衡器存取服務端點。如要解決這個問題，請驗證負載平衡器的網址遮罩，並確認為負載平衡器指定的網址路徑與 Python 原始碼中的路徑相符。

沒有可用的容器執行個體

放送期間發生下列錯誤：

HTTP 429
The request was aborted because there was no available instance.
The Cloud Run service might have reached its maximum container instance
limit or the service was otherwise not able to scale to incoming requests.
This might be caused by a sudden increase in traffic, a long container startup time or a long request processing time.

如要解決這個問題，請查看服務的「Container instance count」(容器執行個體數量) 指標，如果用量接近上限，建議您提高這項限制。 詳情請參閱「為服務設定執行個體數量上限」，如需更多執行個體，請申請提高配額。

Cloud Run 無法管理流量速率

在提供服務期間，或服務尚未達到容器執行個體數量上限時，會發生下列錯誤：

HTTP 500
The request was aborted because there was no available instance

如要解決這個問題，請按照下列步驟操作：

  1. 請解決下列可能的根本原因：

    • 流量突然大幅增加。
    • 冷啟動時間過長。
    • 要求處理時間過長，或要求處理時間突然增加。
    • 服務已達容器執行個體數量上限 (HTTP 429)。
    • 歸因於 Cloud Run 服務的暫時性因素。

  2. 針對不得捨棄的要求，實作指數輪詢和重試機制。如果流量或要求處理時間短暫且突然增加，可能只有在 Cloud Monitoring 中放大至 10 秒解析度時才會顯示。

  3. 如果問題的根本原因是一段時間內暫時性的錯誤增加，且完全歸因於 Cloud Run，請與支援團隊聯絡。

Cloud Run 執行個體無法啟動

提供服務時發生下列錯誤：

HTTP 500
The request failed because the instance could not start successfully.

如果容器無法在設定的時間內啟動並保持正常運作，就會發生這個錯誤。這類問題可能有多種原因，但常見的原因是容器無法從 Secret Manager 存取必要密鑰。

如要解決這個問題，請考慮下列做法：

  1. 驗證 IAM 權限：確認 Cloud Run 服務帳戶具備 Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) 角色，可存取您嘗試存取的密鑰。

  2. 檢查密鑰路徑：確認您在應用程式設定中指定正確的密鑰名稱和版本。

  3. 檢查網路設定：如果您使用 VPC Service Controls perimeter 或防火牆規則，請確保允許輸出流量至 secretmanager.googleapis.com。

  4. 輸出有效記錄：在應用程式的啟動程序中加入記錄，特別是擷取 Secret 的部分，以便診斷特定失敗。

未實作作業

叫用 Cloud Run 工作時，如果指定錯誤的 REGION，就會發生下列錯誤，例如在 asia-southeast1 區域部署工作，並使用 southeast1-asia 或 asia-southeast 叫用工作：

HTTP 501
Operation is not implemented, or supported, or enabled.

如需支援的區域清單，請參閱「Cloud Run 位置」。

服務傳回 5xx 錯誤，且 Cloud Run 工作和 worker 集區無法啟動

如果 Google Cloud 帳單帳戶達到支出上限，Cloud Run 資源可能會傳回 HTTP 5xx 狀態碼。

此外，如果您執行 Cloud Run 工作或 worker 集區，新的工作執行作業或 worker 集區執行個體可能無法啟動。

如何解決這個問題：

  1. 請查看 Cloud Run 控制台。如果帳戶達到支出上限，系統會顯示快訊橫幅。
  2. 前往 Cloud Billing 控制台，查看預算和快訊。
  3. 如要恢復運作，請解除或調整支出上限。或者，等到下一個帳單週期開始時，系統會自動重設每月額度。

解除支出上限後，Cloud Run 資源最多可能需要 30 分鐘才會恢復提供流量服務。詳情請參閱「已知問題」。

找不到預設憑證

如果應用程式因缺少檔案、憑證路徑無效或環境變數指派錯誤而無法正確驗證，就會發生下列錯誤：

HTTP 503: System.InvalidOperationException System.InvalidOperationException your Default
credentials were not found.

如何解決這個問題：

  1. 安裝並初始化 gcloud CLI。

  2. 使用與使用者相關聯的憑證，設定應用程式預設憑證 (ADC)。使用下列方式設定 ADC：

      gcloud auth application-default login

    登入畫面會隨即顯示。登入後，您的憑證會儲存在 本機憑證檔案中，供 ADC 使用。

  3. 使用 GOOGLE_APPLICATION_CREDENTIALS 環境變數，提供 Google Cloud 專案中憑證 JSON 檔案的位置。

    詳情請參閱「設定應用程式預設憑證」。

容器執行個體超過記憶體限制

在 Cloud Logging 中提供服務時，發生下列 HTTP 500 或 HTTP 503 錯誤：

While handling this request, the container instance was found to be using too much memory and was terminated. This is likely to cause a new container instance to be used for the next request to this revision. If you see this message frequently, you may have a memory leak in your code or may need more memory. Consider creating a new revision with more memory.

如何解決這個問題：

  1. 判斷容器執行個體是否超出可用記憶體。在 varlog/system 記錄中尋找相關錯誤。
  2. 如果執行個體超過可用的記憶體，請考慮提高記憶體限制。

在 Cloud Run 中，寫入本機檔案系統的檔案會計入可用記憶體。這也包括寫入 /var/log/* 和 /dev/log 以外位置的任何記錄檔。

並行設定過高，因此無法處理部分要求

如果容器執行個體使用高 CPU 負載處理要求，導致無法處理所有要求，就會發生下列錯誤：

HTTP 503
The Cloud Run service probably has reached its maximum container instance limit. Consider increasing this limit.

如要解決這個問題，請按照下列步驟操作：

  1. 提高服務的容器執行個體數量上限。

  2. 降低服務的並行數量。詳情請參閱「設定每個執行個體的並行要求數量上限」。

與容器限制有關的 Cloud Logging 錯誤

在根命名空間下執行時，如果違反容器執行階段合約中列出的限制，您可能會在 Cloud Logging 記錄中看到 Linux 核心錯誤，例如「Operation not permitted」或「Permission denied」。如果系統呼叫嘗試執行這些動作遭到拒絕，就會顯示這些錯誤。如要瞭解如何讓容器與 Cloud Run 執行環境更相容，請參閱「調整容器以適用於 Cloud Run」。

嘗試掛接檔案系統時，可能會出現下列記錄：

  • mount.nfs: Operation not permitted
  • mount.cifs: Operation not permitted

如果應用程式嘗試使用 sysctl 等工具修改 /proc 或 /sys 下的檔案，記錄檔可能會包含下列錯誤：

  • sysctl: permission denied on key "vm.max_map_count"

嘗試執行 sudo 會失敗，並顯示下列記錄：

  • sudo: The "no new privileges" flag is set

其他系統呼叫 (例如 mlockall) 可能會失敗，並顯示類似下列的錯誤：

  • msg="mlockall syscall failed" error="cannot allocate memory"

錯誤專屬於有問題的程式碼，以及您實作記錄和錯誤處理的程度。

與待處理佇列要求中止有關的 Cloud Logging 錯誤

如果 Cloud Run 無法快速擴充來管理流量，就會發生下列其中一項錯誤：

  • The request was aborted because there was no available instance:
severity=WARNING ( Response code: 429 ) Cloud Run cannot
scale due to the max-instances limit you set
during configuration.

  • severity=ERROR ( Response code: 500 ) Cloud Run intrinsically
cannot manage the rate of traffic.

如要解決這個問題，請按照下列步驟操作：

  1. 解決可能導致擴充失敗的根本原因，例如：

    • 流量突然大幅增加。
    • 冷啟動時間過長。
    • 要求處理時間過長。
    • 原始碼錯誤率偏高。
    • 達到執行個體數量上限，導致系統無法擴充。
    • 歸因於 Cloud Run 服務的暫時性因素。

    如要進一步瞭解如何解決資源調度問題及最佳化效能，請參閱「一般開發提示」。

  2. 如果是以 HTTP 觸發條件為基礎的服務或函式，請讓用戶端針對不得捨棄的要求，實作指數輪詢和重試機制。如果是從 Workflows 觸發服務，則可使用 try/retry 語法達成此目的。

  3. 對於背景或事件導向服務或函式，Cloud Run 支援至少一次傳送。即使未明確啟用重試功能，Cloud Run 也會自動重新傳送事件，並重試執行作業。詳情請參閱「重試事件導向函式」。

  4. 如要解決冷啟動相關問題，請設定執行個體數量下限，減少冷啟動次數，但這會導致帳單費用增加。

  5. 如果問題的根本原因是一段時間內暫時性的錯誤增加，且完全歸因於 Cloud Run，或是您有問題需要協助，請與支援團隊聯絡。

Google 遮蓋的身分識別權杖簽章

開發和測試階段發生下列錯誤：

SIGNATURE_REMOVED_BY_GOOGLE

這個錯誤可能發生在下列情況：

  • 使用者透過 Google Cloud CLI 或 Cloud Shell 登入。

  • 使用者使用 gcloud 指令產生 ID 權杖。

  • 使用者嘗試使用 ID 權杖叫用非公開 Cloud Run 服務。

這是預期的預設行為。基於安全考量，Google 會移除權杖簽章，防止任何非公開的 Cloud Run 服務重播以這種方式產生的 ID 權杖。

如要解決這個問題，請使用新的 ID 權杖叫用私有服務。詳情請參閱「測試私人服務」。

記錄中的 OpenBLAS 警告

如果您在第一代執行環境中使用以 OpenBLAS 為基礎的程式庫 (例如 NumPy)，記錄中可能會顯示下列警告：

OpenBLAS WARNING - could not determine the L2 cache size on this system,
assuming 256k`

如果第一代執行環境使用的容器沙箱未公開低階硬體功能，就會發生 OpenBLAS 警告。這項警告不會影響服務。如要避免 OpenBLAS 警告記錄項目，請切換至第二代執行環境。

Spark 無法取得要繫結的機器 IP 位址

如果 Spark 在取得繫結機器的 IP 位址時失敗，就會發生下列其中一個錯誤：

assertion failed: Expected hostname (not IP) but got <IPv6 ADDRESS>
 
assertion failed: Expected hostname or IPv6 IP enclosed in [] but got <IPv6 ADDRESS>

如要解決這個問題，請在 Dockerfile 中將 SPARK_LOCAL_IP 環境變數設為 127.0.0.1，例如 ENV SPARK_LOCAL_IP="127.0.0.1"。如未設定 SPARK_LOCAL_IP 環境變數，系統會預設為 IPv6 對應項目，而非 localhost。此外，Spark 無法辨識設為 RUN export SPARK_LOCAL_IP="127.0.0.1" 的環境變數。

無法使用 NFS 存取檔案

錯誤 建議的補救措施
mount.nfs: Protocol not supported 部分基礎映像檔 (例如 debian 和 adoptopenjdk/openjdk11) 缺少 nfs-kernel-server 依附元件。
mount.nfs: Connection timed out 如果連線逾時，請確認您提供的 Filestore 執行個體 IP 位址正確無誤。
mount.nfs: access denied by server while mounting IP_ADDRESS:/FILESHARE 如果伺服器拒絕存取，請確認檔案共用名稱正確無誤。

無法使用 Cloud Storage FUSE 存取檔案

請參閱 Cloud Storage FUSE 疑難排解指南。

CPU 使用率低時延遲時間長

即使 Cloud Monitoring 顯示平均 CPU 使用率遠低於一般 60% 的擴充目標，您的服務仍可能出現要求延遲時間過長，或無法在負載下擴充的情況。

可能原因：

如果應用程式是 CPU 繫結工作用的單一執行緒，但部署在具有多個 vCPU 的執行個體上，就可能發生這種情況。您的應用程式可能會耗盡一個 vCPU 核心的資源，而其他核心則大多處於閒置狀態。Cloud Run 自動配置器會使用所有 vCPU 的平均 CPU 使用率，在這些情況下，這個平均值可能會偏低，導致無法根據 CPU 進行資源調度。

解決方法：

  • 單一執行緒應用程式：
    • 如果服務的記憶體需求可以滿足 (請參閱「記憶體限制和 CPU 下限」)，建議為服務設定 1 個 vCPU。這有助於 CPU 使用率指標準確反映負載。
    • 如果記憶體需求超過 1 個 vCPU 的限制，而必須使用多個 vCPU，則以 CPU 為基礎的自動調度資源功能可能較不有效。在這種情況下，請調低並行要求數量上限設定，以根據要求輸送量更快觸發擴充作業。請參閱「並行設定」。
  • 多 vCPU 設定：請確保應用程式架構能有效運用所有分配的 vCPU (例如使用多個 worker 程序或執行緒)。

連線能力和安全性錯誤

本節說明 Cloud Run 常見的連線能力和安全性錯誤，以及疑難排解方法。

用戶端未正確驗證

提供服務時發生下列錯誤：

HTTP 401: The request was not authorized to invoke this service

如何解決這個問題：

  1. 如果服務帳戶叫用 Cloud Run 服務，請將 Google 簽署的 ID 權杖的對象聲明 (aud) 設為下列值：

    • 如果您使用 https://SERVICE.run.app 或 https://REGION-PROJECT_ID.cloudfunctions.net/FUNCTION 格式，將 aud 設為接收服務的網址，您的服務必須要求驗證。使用 Cloud Run 網址或透過負載平衡器網址叫用 Cloud Run 服務。如需傳送已驗證要求的範例，請參閱「透過 HTTPS 要求進行叫用」。

    • 如果將 aud 設為 OAuth 2.0 用戶端 ID 的用戶端 ID，且類型為網頁應用程式，並使用 nnn-xyz.apps.googleusercontent.com 格式，即可透過受 IAP 保護的 HTTPS 負載平衡器叫用 Cloud Run 服務。如果應用程式負載平衡器是由不同區域的多項 Cloud Run 服務支援，建議採用這種做法。

    • 如果將 aud 設為已設定的自訂目標對象，請使用提供的確切值。舉例來說，如果自訂目標對象是 https://service.example.com，則目標對象宣告值也必須是 https://service.example.com。

  2. 確認要求包含 Authorization: Bearer ID_TOKEN 標頭，或自訂授權的 X-Serverless-Authorization: Bearer ID_TOKEN 標頭，且權杖是 ID 權杖，而非存取或更新權杖。在下列情況下，可能會因授權格式不正確而發生 401 錯誤：

    如要查看 JWT 的憑證附加資訊，請使用 jwt.io 工具。

  3. 如果您使用中繼資料伺服器擷取 ID 和存取權杖，透過 HTTP Proxy 轉送輸出流量，向 Cloud Run 服務或工作身分驗證要求，卻收到無效權杖，請將下列主機新增至 HTTP Proxy 例外狀況：

    • 169.254.*或169.254.0.0/16

    • *.google.internal

  4. 當 Cloud 用戶端程式庫使用中繼資料伺服器擷取應用程式預設憑證，以驗證 REST 或 gRPC 叫用時，通常會發生 401 錯誤。如未定義 HTTP Proxy 例外狀況，會發生下列行為：

    • 如果不同的 Google Cloud 工作負載託管 Cloud Run 服務或工作和 HTTP Proxy，即使 Cloud 用戶端程式庫擷取憑證，指派給 HTTP Proxy 工作負載的服務帳戶也會產生權杖。權杖可能沒有執行預期 Google Cloud API 作業所需的權限。這是因為服務帳戶會從 HTTP Proxy 工作負載的中繼資料伺服器檢視區塊擷取權杖，而不是從 Cloud Run 服務或工作擷取。

    • 如果 HTTP Proxy 並非代管於 Google Cloud，且您使用 Proxy 傳送中繼資料伺服器要求，則權杖要求會失敗，Google Cloud API 作業也無法通過驗證。

  5. 如果貴組織支援這項功能，請重新部署服務，允許公開存取。進行測試時這項功能相當實用。

用戶端未獲授權叫用服務

呼叫服務時發生下列其中一項錯誤：

HTTP 403: The request was not authenticated. Either allow public access or set the proper Authorization header
 
HTTP 403: Forbidden: Your client does not have permission to get URL from this server.

如果用於產生授權權杖的 IAM 成員缺少 run.routes.invoke 權限，可能會發生 403 錯誤。將這項權限授予產生權杖的使用者。

此外，如果 Cloud Logging 中有格式為 resource.type = "cloud_run_revision" 的錯誤項目，請按照下列步驟解決錯誤：

  1. 如要讓任何人都能叫用服務，請更新 IAM 設定，並將服務設為公開。

  2. 如要讓服務僅能由特定身分叫用，請使用適當的授權權杖叫用服務：

    • 如果開發人員或使用者叫用您的服務，請授予 run.routes.invoke 權限。您可以透過 Cloud Run 管理員 (roles/run.admin) 和 Cloud Run Invoker (roles/run.invoker) 角色提供這項權限。

    • 如果服務帳戶叫用您的服務，請確認該服務帳戶是 Cloud Run 服務的成員，並授予 Cloud Run 叫用者 (roles/run.invoker) 角色。

    • 如果呼叫缺少驗證權杖，可能會導致 403 錯誤。如果使用有效的驗證權杖呼叫，仍會導致 403 錯誤，請將 run.routes.invoke 權限授予產生權杖的 IAM 成員。

如果遇到 403 錯誤，但找不到 resource.type = "cloud_run_revision" 記錄項目，可能是因為 VPC Service Controls 封鎖了輸入設定設為 All 的 Cloud Run 服務。如要進一步瞭解如何排解 VPC Service Controls 拒絕存取的問題，請參閱「404 錯誤」。

透過網路瀏覽器存取服務時發生錯誤

透過網路瀏覽器存取 Cloud Run 服務時，會發生下列問題：

403 Forbidden
Your client does not have permission to get URL from this server.

從網路瀏覽器叫用 Cloud Run 服務時，瀏覽器會將 GET 要求傳送至服務。不過，要求不含呼叫使用者的授權權杖。如要解決這個問題，請按照下列步驟操作：

  1. 搭配 Cloud Run 使用 Identity-Aware Proxy (IAP)。透過 HTTPS 存取的應用程式可經由 IAP 建立中央授權層，透過 IAP，您可以使用應用程式層級的存取控管模型，而非網路層級的防火牆。如要進一步瞭解如何為 Cloud Run 設定 IAP，請參閱「為 Cloud Run 啟用 Identity-Aware Proxy」。

  2. 如要暫時解決這個問題，請在 Google Cloud CLI 中使用 Cloud Run Proxy，透過網路瀏覽器存取服務。如要在本機 Proxy 服務，請執行下列指令：

    gcloud run services proxy SERVICE --project PROJECT-ID

    Cloud Run 會將私有服務代理至 http://localhost:8080 (或您使用 --port 指定的連接埠)，並提供有效帳戶的權杖或您指定的其他權杖。建議您使用這種方式，在瀏覽器中私下測試網站或 API。詳情請參閱「測試私人服務」。

  3. 允許公開存取您的服務。這項設定適用於測試，或服務為公開 API 或網站時。

對等方已重設連線

當網路上的對等端意外關閉應用程式建立的 TCP 連線時，會發生下列其中一項錯誤：

Connection reset by peer
 
asyncpg.exceptions.ConnectionDoesNotExistError: connection was closed in the middle of operation
 
grpc.StatusRuntimeException: UNAVAILABLE: io exception
 
psycopg.OperationalError: the connection is closed
 
ECONNRESET

如要解決這個問題，請按照下列步驟操作：

  • 如要透過 CPU 節流執行背景工作，請使用依據執行個體計費設定。

  • 請確認您在傳出要求逾時範圍內。如果應用程式在閒置狀態下維持連線的時間超過這個門檻，閘道就會終止連線。

  • 根據預設，Cloud Run 會停用 TCP 通訊端選項 keepalive。無法直接在服務層級設定 keepalive 選項。如要為每個通訊端連線啟用 keepalive 選項，請在開啟新的 TCP 通訊端連線時，根據您在應用程式中用於此連線的用戶端程式庫，提供必要的通訊端選項。

  • 有時，傳出連線會因基礎架構更新而重設。如果應用程式會重複使用長期連線，建議將應用程式設為重新建立連線，避免重複使用失效的連線。

  • 如果您使用 HTTP Proxy 轉送 Cloud Run 服務或工作輸出流量，且 Proxy 強制執行連線時間長度上限，則 Proxy 可能會自動捨棄長時間執行的 TCP 連線，例如使用連線集區建立的連線。這會導致 HTTP 用戶端在重複使用已關閉的連線時失敗。如要透過 HTTP Proxy 轉送輸出流量，必須實作連線驗證、重試和指數輪詢。針對連線集區，設定連線存在時間、閒置連線和連線閒置逾時時間的上限值。

連線逾時

當應用程式嘗試與遠端主機建立新的 TCP 連線，且連線建立時間過長時，會發生下列錯誤：

java.io.IOException: Connection timed out
 
ConnectionError: HTTPSConnectionPool
 
dial tcp REMOTE_HOST:REMOTE_PORT: i/o timeout / context error
 
Error: 4 DEADLINE_EXCEEDED: Deadline exceeded

如要解決連線逾時問題，請按照下列步驟操作：

  1. 如果您使用VPC 連接器或直連虛擬私有雲，透過虛擬私有雲網路轉送所有輸出流量，請按照下列步驟操作：

    • 定義所有必要的防火牆規則，允許 VPC 連接器的輸入流量。

    • 虛擬私有雲防火牆規則必須允許輸入流量，從 VPC 連接器或直連虛擬私有雲輸出子網路傳送至目的地主機或子網路。

    • 請務必擁有所有必要路徑，確保流量能正確轉送至目的地主機，並從目的地主機轉送回來。透過虛擬私有雲網路對接或混合雲連線能力轉送輸出流量時，這項設定相當重要，因為封包會周遊多個網路，才會抵達遠端主機。

  2. 如果您使用 HTTP Proxy 轉送 Cloud Run 服務或作業的所有輸出流量，必須能透過 Proxy 連上遠端主機。

    視 Proxy 的資源使用率而定，透過 HTTP Proxy 轉送的流量可能會延遲。如果您使用 Proxy 轉送 HTTP 輸出流量，請實作重試、指數輪詢或斷路器。

設定 HTTP Proxy 例外狀況

使用 HTTP Proxy 轉送 Cloud Run 服務或作業的輸出流量時，請為 Cloud API 和其他未透過 Proxy 的主機和子網路新增例外狀況，避免發生延遲、連線逾時、連線重設和驗證錯誤。

非 Proxy 主機和子網路至少須包含下列項目：

  • 127.0.0.1
  • 169.254.*或169.254.0.0/16
  • localhost
  • *.google.internal
  • *.googleapis.com

非 Proxy 主機可能包括：

  • *.appspot.com
  • *.run.app
  • *.cloudfunctions.net
  • *.gateway.dev
  • *.googleusercontent.com
  • *.pkg.dev
  • *.gcr.io

如要為輸出網路設定 HTTP Proxy 例外狀況，請設定下列項目：

  • 環境變數：NO_PROXY 或 no_proxy。

    • 標準 Python HTTP 程式庫 (例如 urllib 和 requests) 不支援 NO_PROXY 或 no_proxy 環境變數中的星號萬用字元 *。如要比對子網域，請使用開頭點號，而非 *，例如 .googleapis.com 或 .google.internal。

  • Java 虛擬機器旗標 http.nonProxyHosts：

    • 未定義系統屬性 https.nonProxyHosts。這項系統屬性適用於 HTTP 和 HTTPS。

    • 系統屬性 http.nonProxyHosts 不支援 CIDR 標記。您必須使用模式比對運算式。

回應格式錯誤或容器執行個體連線問題

容器執行個體連線發生問題時，會出現下列錯誤：

HTTP 503
The request failed because either the HTTP response was malformed or connection to the instance had an error.

如要解決這個問題，請按照下列步驟操作：

  1. 檢查 Cloud Logging 是否有下列錯誤：

    • 記憶體不足錯誤。如果記錄檔包含容器執行個體超出記憶體限制的錯誤訊息，請參閱「容器執行個體超出記憶體限制」一節的建議。

    • 有效性探測失敗，記錄中顯示下列錯誤：

      LIVENESS HTTP probe failed 1 time consecutively for container CONTAINER_NAME on port 8080. The instance has been shut down.

      如果執行個體未在逾時期間內成功回應探測，請按照下列步驟操作：

  2. 如果要求在達到 Cloud Run 中設定的要求逾時時間前，就以錯誤代碼 503 終止，請更新語言架構的要求逾時設定：

  3. 在某些情況下，503 錯誤代碼可能是由下游網路瓶頸造成，例如在負載測試期間。舉例來說，如果服務透過無伺服器 VPC 存取連接器轉送流量，請按照下列步驟操作，確保連接器未超過處理量門檻：

    1. 在 Google Cloud 控制台中開啟「無伺服器 VPC 存取」：

      前往「Serverless VPC Access」(無伺服器 VPC 存取)

    2. 檢查處理量圖表直方圖中是否有任何紅色長條。如果出現紅色長條，建議增加連接器使用的執行個體數量上限或執行個體類型。或者，您也可以壓縮透過無伺服器 VPC 存取連接器傳送的流量。

  4. 如果容器執行個體每秒收到超過 800 個要求，可用的 TCP Socket 可能會耗盡。如要解決這個問題，請為服務啟用 HTTP/2，並對服務進行必要變更，以支援 HTTP/2。

閘道逾時錯誤

如果服務未在指定時間內傳回回應，要求就會終止，並發生下列錯誤：

HTTP 504
The request has been terminated because it has reached the maximum request timeout.

如要進一步瞭解這項錯誤，請參閱容器執行階段合約。

如要排解這個問題，請按照下列步驟操作：

  • 如果服務正在處理長時間要求，請增加要求逾時時間。

  • 檢測記錄和追蹤，瞭解應用程式在超過設定的要求逾時前，花費時間的位置。

  • 由於基礎架構更新，傳出連線有時會重設。如果應用程式會重複使用長期連線，建議將應用程式設為重新建立連線，避免重複使用失效的連線。

    視應用程式的邏輯或錯誤處理方式而定，504 錯誤可能表示應用程式嘗試重複使用失效的連線，且要求會遭到封鎖，直到設定的要求逾時為止。使用存活探測終止傳回永久錯誤的執行個體。

  • 應用程式程式碼中發生的記憶體不足錯誤 (例如 java.lang.OutOfMemoryError) 不一定會終止容器執行個體。如果記憶體用量未超過容器記憶體限制，Cloud Run 就不會終止執行個體。視應用程式如何處理應用程式層級的記憶體不足錯誤而定，要求可能要等到超過設定的要求逾時時間後，才會通過。

    如要終止容器執行個體，請按照下列步驟操作：

    • 將應用程式層級的記憶體限制設為大於容器記憶體限制。

    • 使用 liveness 探測，協助終止持續傳回錯誤的執行個體。

佈建憑證時，自訂網域卡住

對應自訂網域時發生下列其中一項錯誤：

The domain is available over HTTP.  Waiting for certificate provisioning. You must configure your DNS records for certificate issuance to begin and to accept HTTP traffic.
 
Waiting for certificate provisioning. You must configure your DNS records for certificate issuance to begin.

如何解決這個問題：

  1. 請等待至少 24 小時。佈建 SSL 憑證通常約需 15 分鐘，但最久可能需要 24 小時。

  2. 使用 Google Admin Toolbox Dig 工具，確認您已在網域註冊商正確更新 DNS 記錄。網域註冊商中的 DNS 記錄必須與Google Cloud 控制台提示您新增的記錄相符。

  3. 使用下列任一方法，驗證帳戶下的網域根目錄：

  4. 確認網域憑證未過期。如要找出到期界限，請使用下列指令：

    echo | openssl s_client -servername 'ROOT_DOMAIN' -connect 'ROOT_DOMAIN:443' 2>/dev/null | openssl x509 -startdate -enddate -noout

用戶端中斷連線不會傳播至 Cloud Run

在 Cloud Run 上使用 HTTP/1.1 時，用戶端中斷連線事件不會傳播至 Cloud Run 容器。

如要解決這個問題，請使用 Websockets 或 HTTP/2.0，這兩者會傳播用戶端中斷連線。