將第 1 代函式升級為 Cloud Run 函式
本指南說明如何將第 1 代 HTTP 和 Pub/Sub 函式升級為 Cloud Run 函式，並在 Cloud Run 環境中執行。本指南僅適用於 Cloud Functions 第 1 版 API 所建立的第 1 代函式。本指南中的操作說明不適用於 Cloud Functions 第 2 代 API 或 Cloud Functions for Firebase 所建立的第 2 代函式，因為是不同的產品。您可以選擇從現有的第 2 版 API 環境卸載第 2 代函式，而這些函式之後只能使用 Cloud Run Admin API 管理。
升級完成後，只能透過 Cloud Run Admin API 和 Cloud Run 工具操作升級後的函式。
限制
升級工具目前僅支援升級 HTTP 和 Pub/Sub 所觸發的函式。
升級程序總覽
升級程序概述如下：
此程序詳述於以下各節。
升級啟動步驟總覽
- 開始升級時 (使用 Google Cloud CLI 或 Google Cloud 控制台)，升級工具會建立一個臨時第 2 代函式，作為原始第 1 代函式的副本。開始遷移程序後，請勿刪除 Cloud Storage 中的函式原始碼，也不要刪除 Artifact Registry 中的函式容器。此第 2 代函式有以下特性：
- 用作原始第 1 代函式與最終完全升級函式之間的橋接設定。
- 其名稱、程式碼和設定皆與原始第 1 代函式相同。
- 如果升級的是 HTTP 函式，則與原始第 1 代函式具有相同的
cloudfunctions.net網址，而且也會有run.appCloud Run 網址。- 升級開始後，第 1 代函式與第 2 代函式副本都會指派至相同的
cloudfunctions.net網址。向cloudfunctions.net網址傳送要求時，流量仍會轉送至第 1 代函式。第 2 代函式副本也具有 Cloud Runrun.app網址。直到下一步驟重新導向流量之前，第 2 代函式網址都不會接收流量。
- 升級開始後，第 1 代函式與第 2 代函式副本都會指派至相同的
- 若是升級 Pub/Sub 函式，則會使用與第 1 代函式相同的 Pub/Sub 主題，但此時尚不會建立訂閱項目。
- 如果升級的是 HTTP 函式，則與原始第 1 代函式具有相同的
- 請注意，如果未將依附元件固定於特定版本，新建立的第 2 代函式副本可能會使用較新的依附元件版本。
- 第 1 代函式會繼續列於第 1 代Google Cloud 控制台，而臨時複製的第 2 代副本會首次出現在 Cloud Run 控制台。
範例：下表顯示初始升級步驟期間的 HTTP 函式狀態。
| 函式 | 提供流量？ | 顯示於控制台？ |
|---|---|---|
| 原始第 1 代函式 | 是，來源為 cloudfunctions.net 網址 |
是，第一代控制台。 |
| 新的第 2 代副本 | 不會。此函式同時有 cloudfunctions.net 和 run.app 網址，但必須完成重新導向步驟，才會開始提供流量。 |
是，Cloud Run 控制台。 |
重新導向流量總覽
- 重新導向流量時，結果取決於所升級的函式為 HTTP 函式或 Pub/Sub 函式：
- 如要升級 HTTP 函式，導向
cloudfunctions.net網址的流量會前往第 2 代函式。第 1 代函式仍會存在，但不會接收任何流量。 - 若要升級 Pub/Sub 函式，第 2 代函式觸發條件會使用相同的 Pub/Sub 主題，但會建立新的訂閱項目，將訊息傳送至 Cloud Run 函式。而舊的訂閱項目會被刪除。
- 如要升級 HTTP 函式，導向
- 第 1 代函式會從第 1 代控制台消失。
- 執行
gcloud functions describe指令後，即可看到函式處於第 2 代環境。 - 請注意，這個轉換階段存在以下風險，尤其是 Pub/Sub 函式：
- 重複的訊息：系統會先建立新訂閱項目，再刪除舊訂閱項目。在轉換期間，系統可能會將相同的 Pub/Sub 訊息同時傳送至舊函式和新函式。
- 遺失訊息：如果升級的是 Pub/Sub 函式，而新函式在重新導向流量後無法處理訊息，則可能會遺失 Pub/Sub 訊息。如果函式已停用重試功能，則尤其容易發生此狀況。詳情請參閱「升級 Pub/Sub」。
範例：下表顯示流量重新導向步驟期間的 HTTP 函式狀態。
| 函式 | 提供流量？ | 顯示於控制台？ |
|---|---|---|
| 原始第 1 代函式 | 不會。 | 不再顯示在第 1 代控制台，但仍然存在。 |
| 新的第 2 代副本 | 是，來源為 cloudfunctions.net 網址以及 run.app Cloud Run 網址。 |
是，Cloud Run 控制台。 |
復原流量總覽
- 復原流量時，升級工具會將第 2 代函式副本所有流量復原至原始的第 1 代函式，屆時會由該函式提供所有流量，而第 2 代函式仍可用於測試。
- 如果復原的是 Pub/Sub 函式，系統會重新建立第 1 代函式訂閱項目，並刪除第 2 代函式訂閱項目。
- 如要在復原流量後繼續升級，請先將流量重新導向至新的第 2 代函式。
範例：下表顯示復原流量後 HTTP 函式的狀態。
| 函式 | 提供流量？ | 顯示於控制台？ |
|---|---|---|
| 原始第 1 代函式 | 是。 | 是，第一代控制台。 |
| 新的第 2 代副本 | 不會。 | 不再顯示於 Cloud Run 控制台，但仍然存在。 |
取消作業總覽
升級作業在提交之前，隨時都可以取消。一旦提交完成，升級就無法復原。
範例：下表顯示取消升級後的 HTTP 函式狀態。
| 函式 | 提供流量？ | 顯示於控制台？ |
|---|---|---|
| 原始第 1 代函式 | 是。 | 是，第一代控制台。 |
| 第 2 代副本 | 不會。 | 不再顯示於 Cloud Run 控制台，且不復存在。 |
提交作業總覽 (無法復原)
- 完成升級後，第 1 代函式的升級程序隨即完成。這個動作無法復原。
- 系統會基於 Cloud Run Admin API，將臨時第 2 代函式轉換為正式的 Cloud Run 函式。
- 這等同於對第 2 代函式執行
detach指令。detach指令會將 Cloud Functions 第 2 代函式從其原有的 API 環境中卸載。 - 升級後，您只能使用 Cloud Run Admin API 和 Cloud Run 工具操作函式。
- 這等同於對第 2 代函式執行
- 系統會刪除第 1 代函式，並將所有流量提供給升級後的 Cloud Run 函式。
範例：下表顯示提交升級後 HTTP 函式的狀態：
| 函式 | 提供流量？ | 顯示於控制台？ |
|---|---|---|
| 基於 Cloud Run Admin API 的新 Cloud Run 函式。 | 是，來源為 cloudfunctions.net 網址以及 run.app Cloud Run 網址。 |
是，Cloud Run 控制台。 |
| 原始第 1 代函式 | 不會。 | 不會，已不復存在。 |
| 第 2 代副本 | 不會。 | 不會，已不復存在。 |
測試訣竅
測試是升級程序的必要步驟。
建議您先以非正式版函式測試升級工具，熟悉工具的使用方式。請在充分熟練程序且穩定測試成功後，再開始升級正式版函式。
在升級程序中，可使用以下幾項工具來測試函式：
每當函式變更狀態時，請使用 Google Cloud CLI
describe指令確認函式存在，並驗證環境及版本皆為正常。請依據要升級函式的目前狀態，選用下列相應的指令：Cloud Run：
gcloud run services describe FUNCTION_NAME --format yaml
Cloud Functions：
gcloud functions describe --region REGION_NAME FUNCTION_NAME
請使用第 1 代控制台與 Cloud Run 控制台的「Logging」頁面，查看函式流量的詳細資料。
在升級過程中，可透過 Cloud Run 控制台查看並測試第 2 代函式副本，瞭解其進展狀況。
- 升級程序開始後，請使用「Triggers」(觸發條件)分頁測試第 2 代函式副本。
- 使用「YAML」分頁標籤查看函式詳細資料，包括 Cloud Run
run.app網址。
事前準備
開始升級前，請確認符合下列先決條件：
已啟用 Cloud Run API：
gcloud services enable run.googleapis.com
具備現有的第 1 代 HTTP 或 Pub/Sub 函式。
具備必要的 IAM 角色：
- 您必須在函式的服務帳戶中設定
roles/iam.serviceAccountUser。 - 您必須具備專案的
roles/cloudfunctions.admin角色或同等角色才能執行升級作業。 - 如果是設定為
no-retry的 Pub/Sub 函式，則您必須有roles/serviceusage.consumer角色或具備serviceusage.services.user權限的自訂角色。您也需要pubub.topic.getIAMPermissions和pubsub.topic.setIAMPermissions角色。 - 您必須具備
roles/pubsub.admin角色才可提交 Pub/Sub 函式升級作業。roles/pubsub.admin是專案層級角色，可針對專案中所有 Pub/Sub 資源授予管理員權限。
您可依下列方式查看函式的身分與存取權管理 (簡稱 IAM) 政策：
gcloud functions get-iam-policy FUNCTION_NAME
- 您必須在函式的服務帳戶中設定
您必須對函式服務帳戶授予
roles/cloudfunctions.admin角色。如要授予roles/cloudfunctions.admin角色，請使用gcloud functions add-iam-policy-binding指令，例如：gcloud functions add-iam-policy-binding FUNCTION_NAME \ --region=REGION \ --member=serviceAccount:SERVICE_ACCOUNT \ --role="roles/cloudfunctions.admin"
嘗試執行這項指令時若發生錯誤，請確認函式是否符合貴組織的政策。例如，貴組織可能不允許未經驗證的 HTTP 函式。
如要進一步瞭解成員和角色，請參閱「新增主體和授予角色」。
升級 HTTP 函式
本節說明如何將第 1 代 HTTP 函式升級為 Cloud Run 函式。如要瞭解如何升級第 1 代 Pub/Sub 函式，請參閱後續章節。
如後續章節所述，重新導向流量並完成升級後，與原始第 1 代 HTTP 函式相關聯的 cloudfunctions.net 網址會繼續運作，並將流量導向新的 Cloud Run 函式。
開始升級 HTTP 函式
此步驟會建立第 1 代函式的第 2 代副本。
控制台
前往 Google Cloud 控制台的「Functions (1st gen)」(函式 (第 1 代)) 頁面：
找出要升級的第 1 代函式，並確認「Upgrade status」(升級狀態) 欄中的狀態為「Ready to upgrade」(可升級)。
按一下函式名稱以顯示詳細資料頁面。
在函式詳細資料頁面中，按一下「Upgrade eligible」(符合升級資格) 下方的「Upgrade」(升級)。
按照提示開始升級程序。
此步驟完成後，系統會顯示「Upgrade in progress」(升級中)面板，提示您點按「Go to Cloud Run」(前往 Cloud Run)連結，繼續進行升級程序。
gcloud
執行加上 --setup-config 旗標的 gcloud beta functions upgrade 指令：
gcloud beta functions upgrade FUNCTION_NAME --setup-config
將 FUNCTION_NAME 替換為第 1 代函式的名稱。
升級程序開始後：
- 第 1 代函式會繼續將流量導向原始網址。如要查看這個網址，請前往函式 (第 1 代) 控制台的函式詳細資料頁面，然後開啟「Trigger」(觸發條件)分頁。
系統會建立第 2 代函式，以作為第 1 代函式的副本。其與第 1 代函式同樣具有
cloudfunctions.net網址以及新的 Cloud Runrun.app網址。如要查看這兩個網址，請前往 Cloud Run 控制台的函式詳細資料頁面，然後開啟「YAML」分頁。或者，亦可使用下列指令：gcloud run services describe YOUR_SERVICE_NAME \ --region YOUR_REGION \ --format="value(status.url)"您可以確認第 1 代函式的第 2 代副本是否存在：
gcloud run services describe FUNCTION_NAME --format yaml
您可以驗證第 1 代函式的環境，指令輸出內容應顯示該函式環境為
1st gen。gcloud functions describe --region REGION_NAME FUNCTION_NAME
升級啟動步驟疑難排解
下列狀況會導致升級失敗：
- 相同區域和專案中已有同名函式。
- 第 1 代函式使用已停用的執行階段，此狀況必須改用受支援的執行階段重新部署才可升級。
- 呼叫端沒有
cloudfunctions.functions.generationUpgrade權限。請注意，呼叫端必須具備專案的roles/cloudfunctions.admin角色或同等角色。
重新導向 HTTP 函式的流量
在此階段，應分別測試原始函式及其副本的網址。請先確認兩者皆運作正常，再繼續下一步驟。如果遇到問題，請取消升級並返回淨空狀態，以便處理第 1 代函式的潛在問題。
重新導向步驟會將流量從第 1 代 Cloud Functions 網址重新導向至第 2 代函式副本。
控制台
- 在 Cloud Run 函式詳細資料頁面的「Upgrade in progress」(升級中) 面板中，按一下「Go to Cloud Run」(前往 Cloud Run)。
- 按一下「Test function」(測試函式) 對函式進行測試 (此為選擇性步驟，但強烈建議執行)。
- 準備好時，請按一下「Redirect traffic」(重新導向流量)。
gcloud
執行加上 --redirect-traffic 旗標的 gcloud beta functions upgrade 指令：
gcloud beta functions upgrade FUNCTION_NAME --redirect-traffic
重新導向流量後，第 2 代函式副本會將流量提供給函式網址 (cloudfunctions.net) 和 Cloud Run 網址 (run.app)。
在重新導向後測試 HTTP 函式
驗證函式環境：
gcloud functions describe --region REGION_NAME FUNCTION_NAME
輸出內容會顯示環境為
2nd gen。請使用控制台記錄工具對照比較第 2 代函式副本與原始第 1 代函式。
重新導向步驟疑難排解
下列狀況會導致重新導向失敗：
- 尚未執行先前步驟 (
--setup-config)。
復原 HTTP 函式的流量
如果還沒準備好升級，可以將流量復原至第 1 代函式。
控制台
在 Cloud Run 控制台的 Cloud Run 函式詳細資料頁面中，點選「Upgrade in progress」(升級中) 面板中的「Rollback traffic」(復原流量)。
gcloud
執行加上 --rollback-traffic 旗標的 gcloud beta functions upgrade 指令：
gcloud beta functions upgrade FUNCTION_NAME --rollback-traffic
復原流量後：
- 第 1 代函式會將流量提供給
cloudfunctions.net網址。 - 此時仍可使用第 2 代函式副本，並透
run.app網址進行觸發。
您可以按照下列步驟驗證函式環境。輸出內容應顯示函式環境為 1st gen：
gcloud functions describe --region REGION_NAME FUNCTION_NAME
若未將流量重新導向至第 2 代函式，復原就會失敗。
提交 HTTP 函式升級程序
此步驟會完成升級，之後就無法取消程序。執行此步驟前，請務必徹底測試函式。
控制台
在 Cloud Run 控制台的 Cloud Run 函式詳細資料頁面中，點選「Upgrade in progress」(升級中) 面板中的「Commit upgrade」(提交升級)。
gcloud
執行加上 --commit 旗標的 gcloud beta functions upgrade 指令：
gcloud beta functions upgrade FUNCTION_NAME --commit
提交升級後：
- 系統會刪除第 1 代函式，並卸載第 2 代函式副本，使其成為完備的 Cloud Run 函式。
- Cloud Run 函式會保留
cloudfunctions.net網址和新的run.app網址。 您可以驗證第 1 代函式是否已不存在：
gcloud functions describe --region REGION_NAME FUNCTION_NAME
您可以驗證 Cloud Run 服務詳細資料：
gcloud run services describe FUNCTION_NAME --format yaml
輸出內容會顯示已建立的新生成內容，且 Goog-managed-by
標籤的值為空白。
如果流量未重新導向至 Cloud Run 函式，提交作業就會失敗。
升級 Pub/Sub 函式
本節說明如何將第 1 代 Pub/Sub 函式升級為 Cloud Run 函式。
第 1 代 Pub/Sub 函式升級的基本模式與 HTTP 函式相同，但另須注意下列事項：
Cloud Run 不支援停用「失敗重試」功能，但這是第一代函式的預設設定，因此兩種類型的函式可能同時並存升級工具的行為取決於這項設定：
- 如果第 1 代函式已停用重試功能 (第 1 代的預設設定)，升級工具會建立 Eventarc Pub/Sub 觸發條件，以及無效信件佇列 (DLQ)。升級工具會為訂閱項目及其主題設定身分與存取權管理 (IAM) 政策。升級完成後，無效信件佇列主題會儲存未送達的訊息；如有需要，為該無效信件佇列建立新的訂閱項目即可擷取。如要為 DLQ 主題使用客戶自行管理的加密金鑰 (CMEK)，請在遷移後更新主題的 CMEK。
- 如果第 1 代函式已啟用重試功能，升級工具會以預設的設定值建立 Eventarc Pub/Sub 觸發條件。
開始升級 Pub/Sub 函式
此步驟會建立第 1 代函式的第 2 代副本。
控制台
前往 Google Cloud 控制台的「Cloud Functions (1st gen)」(Cloud Functions (第 1 代)) 頁面：
找出要升級的第 1 代函式，並確認「Upgrade status」(升級狀態) 欄中的狀態為「Ready to upgrade」(可升級)。
按一下函式名稱以顯示詳細資料頁面。
在函式詳細資料頁面中，按一下「Upgrade eligible」(符合升級資格) 下方的「Upgrade」(升級)。
此階段完成後，系統會顯示「Upgrade in progress」(升級中)面板，提示您點按「Go to Cloud Run」(前往 Cloud Run)連結，繼續進行升級程序。
gcloud
執行加上 --setup-config 旗標的 gcloud beta functions upgrade 指令：
gcloud beta functions upgrade FUNCTION_NAME --setup-config
將 FUNCTION_NAME 替換為第 1 代函式的名稱。
如有需要，可選擇為觸發條件指定服務帳戶：
gcloud beta functions upgrade FUNCTION_NAME --setup-config --trigger-service-account=CUSTOM_SA_EMAIL
將 CUSTOM_SA_EMAIL 替換成自訂服務帳戶的電子郵件地址。
如果觸發服務帳戶 (預設 Compute Engine 服務帳戶或指定的自訂服務帳戶) 缺少 run.route.invoke 權限，系統會提示您繫結 roles/run.invoker 角色。
升級程序開始後：
- 第 1 代函式會繼續將流量導向原始網址。
- 系統會建立第 1 代函式的第 2 代副本。您可以使用 Cloud Run 網址觸發這項函式。
- 第 1 代函式會繼續將流量導向至其
cloudfunctions.net網址。
在升級啟動步驟後測試 Pub/Sub 函式
您可以確認第 1 代函式的第 2 代副本是否存在：
gcloud run services describe FUNCTION_NAME --format yaml
您可以驗證第 1 代函式的環境，指令輸出內容應顯示該函式環境為
1st gen。gcloud functions describe --region REGION_NAME FUNCTION_NAME
將訊息發布至目標主題，以觸發第 1 代函式。
如要測試新函式，請為函式新增 Pub/Sub 觸發條件，並確認函式是否正常回應觸發條件：
- 在 Cloud Run 控制台選取函式，然後開啟「Triggers」(觸發條件) 分頁。
- 按一下「Add Trigger」(新增觸發條件) ，然後在「Eventarc trigger」(Eventarc 觸發條件) 面板中，選取要用來觸發函式的主題。根據預設，系統會在訊息發布至主題時觸發函式。
- 在「Upgrade in Progress」(升級中) 面板按一下「Test function」(「測試函式」)。
- 在開啟的 Cloud Code for Cloud Shell 視窗中，將訊息發布至「Triggers」(觸發條件) 分頁中新增的主題。
- 在 Cloud Run 控制台中，前往「Observability」(觀測功能) >「Logs」(記錄)，確認函式已發布訊息。或者，也可以使用 Cloud Code for Cloud Shell 中的指令列查看記錄輸出內容。
例如，假設有一個發布問候語的基本 Hello World 函式。指定新的觸發條件後，即可在 Cloud Code for Cloud Shell 進行測試，方法如下：
gcloud pubsub topics publish YOUR_TOPIC_NAME --message YOUR_NAME gcloud functions logs read --region YOUR_REGION --limit 50
Pub/Sub 升級啟動步驟疑難排解
下列狀況會導致升級失敗：
- 相同區域和專案中已有同名 Cloud Run 函式。
- 您嘗試升級第 2 代函式。
- 第 1 代函式已在進行升級程序。
- 第 1 代函式不存在。
- 第 1 代函式處於錯誤狀態。
- 第 1 代函式既非 HTTP 函式也不是 Pub/Sub 函式。
- 呼叫端沒有
cloudfunctions.functions.generationUpgrade權限。請注意，呼叫端必須具備專案的roles/cloudfunctions.admin角色或同等角色。
重新導向 Pub/Sub 函式的流量
此步驟會將流量從第 1 代 Cloud Functions 網址重新導向至第 2 代函式副本。
控制台
- 在 Cloud Run 函式詳細資料頁面的「Upgrade in progress」(升級中) 面板中，按一下「Go to Cloud Run」(前往 Cloud Run)。
- 按一下「Test function」(測試函式) 對函式進行測試 (此為選擇性步驟，但強烈建議執行)。
- 準備好時，請按一下「Redirect traffic」(重新導向流量)。
gcloud
執行加上 --redirect-traffic 旗標的 gcloud beta functions upgrade 指令：
gcloud beta functions upgrade FUNCTION_NAME --redirect-traffic
重新導向流量後，第 2 代函式會同時透過 Cloud Functions 網址和 Cloud Run 網址提供流量。
在重新導向流量後測試 Pub/Sub
您可以驗證函式環境：
gcloud functions describe --region REGION_NAME FUNCTION_NAME
輸出內容會顯示環境為
2nd gen。eventTrigger.retryPolicy符合函式建立期間指定的重試政策。eventTrigger.serviceAccountEmail是預設的 Compute Engine 服務帳戶或指定的自訂服務帳戶。- 現在將訊息發布至目標主題，就會觸發第 2 代函式副本。
Pub/Sub 重新導向步驟疑難排解
下列狀況會導致重新導向失敗：
- 尚未執行先前步驟 (
--setup-config)。 - Cloud Run 函式已被手動刪除。
復原 Pub/Sub 函式的流量
此步驟會將流量復原至第 1 代函式。
控制台
在 Cloud Run 函式詳細資料頁面的「Upgrade in progress」(升級中) 面板按一下「Rollback traffic」(復原流量)。
gcloud
執行加上 --rollback-traffic 旗標的 gcloud beta functions upgrade 指令：
gcloud beta functions upgrade FUNCTION_NAME --rollback-traffic
復原流量後：
- 函式會還原至初始升級步驟剛完成後的狀態。
- 第 1 代函式會將流量提供給
cloudfunctions.net網址。 此時仍可使用第 2 代函式副本，並透過 Cloud Run 網址進行觸發。
您可以驗證函式環境：
gcloud functions describe --region REGION_NAME FUNCTION_NAME
輸出內容應顯示函式環境為
1st gen。將訊息發布至目標主題，即可觸發第 1 代函式。
如果未將流量重新導向至 Cloud Run 函式，復原就會失敗。
提交 Pub/Sub 函式升級
此步驟會完成升級，之後就無法取消程序，且不可復原。執行此步驟前，請務必徹底測試函式。
控制台
在 Cloud Run 函式詳細資料頁面的「Upgrade in progress」(升級中) 面板按一下「Commit upgrade」(提交升級)。
gcloud
執行加上 --commit 旗標的 gcloud beta functions upgrade 指令：
gcloud beta functions upgrade FUNCTION_NAME --commit
提交升級後：
- 系統會刪除第 1 代函式。
- Cloud Run 函式會保留
cloudfunctions.net網址。 - 您可以驗證清單不再顯示該函式：
gcloud functions describe --region REGION_NAME FUNCTION_NAME
- 您可以驗證 Cloud Run 服務詳細資料：
gcloud run services describe FUNCTION_NAME --format yaml
- 輸出內容會顯示已建立新世代函式。「
Goog-managed-by」標籤的值應為空白。
- 輸出內容會顯示已建立新世代函式。「
- 若在建立第 1 代函式時未勾選「Retry on Failures」(失敗重試)，觸發條件的 Pub/Sub 訂閱項目就會有無效信件佇列 (DLQ)。
- 現在將訊息發布至目標主題，即可觸發第 Cloud Run 函式。
下列狀況會導致提交失敗：
- 流量未重新導向至 Cloud Run 函式。
- Cloud Run 函式已被手動刪除。
取消升級
此動作會取消升級程序。系統會刪除新的第 2 代函式副本，而第 1 代函式則會繼續將流量導向至原本的 cloudfunctions.net 網址。升級過程中可隨時執行此動作，但必須在提交升級前完成。
如果使用 Google Cloud 控制台執行升級，則只能在初始升級作業完成後立即透過使用者介面取消程序。「Abort」(取消) 按鈕位於 Functions (第 1 代) 控制台的左上角。如果使用 Google Cloud CLI，則可在提交前隨時取消升級，提交後就無法復原。
即使透過 Google Cloud 控制台執行升級程序，仍可使用 Google Cloud CLI 取消函式升級：
gcloud beta functions upgrade FUNCTION_NAME --abort
取消升級後：
- 第 2 代函式副本隨之刪除。
- 第 1 代函式會將流量提供給
cloudfunctions.net網址。 - 在 Google Cloud 控制台，函式的升級狀態會從「Configuration copied」(已複製設定) 變回「Ready to Upgrade」(可升級)。
您可以驗證 Cloud Run 服務已不再顯示於清單中：
gcloud run services list
您可以驗證函式環境：
gcloud functions describe --region REGION_NAME FUNCTION_NAME
輸出內容會顯示函式環境為 1st gen。
如果已提交升級作業，取消作業就會失敗。
檢查轉換後的 IAM 政策
在升級程序中，升級工具會盡可能轉換第 1 代 Cloud Functions 與新版 Cloud Run 函式之間的角色和權限。
升級程序會將第 1 代 Cloud Functions IAM 角色轉換為對應的 Cloud Run 角色。
轉換規則：
roles/cloudfunctions.invoker轉換為roles/run.invoker。roles/cloudfunctions.developer轉換為roles/run.sourceDeveloper。roles/cloudfunctions.viewer轉換為roles/run.sourceViewer。roles/cloudfunctions.admin會轉換為roles/run.admin和roles/run.sourceDeveloper。
如果呼叫端缺少 projects.getIamPolicy 或 run.setIamPolicy 權限，IAM 政策升級就會失敗。呼叫端必須具備專案的 roles/cloudfunctions.admin 角色或同等角色。
驗證 IAM 政策升級
為驗證 IAM 政策正確升級，請在升級程序的各階段檢查政策設定值均為正常：
開始函式升級程序：
gcloud beta functions upgrade FUNCTION_NAME --setup-config
如果偵測到自訂角色繫結，輸出內容會顯示警告訊息。
驗證在第 1 代函式上設定的 IAM 政策是否已轉換並升級至 Cloud Run 函式：
gcloud functions get-iam-policy FUNCTION_NAME gcloud run services get-iam-policy FUNCTION_NAME
驗證專案層級的 Cloud Run functions 叫用者角色繫結是否已轉換並升級至 Cloud Run 函式：
gcloud projects get-iam-policy PROJECT_ID | grep "roles/cloudfunctions.invoker" gcloud run services get-iam-policy FUNCTION_NAME
後續步驟
- 進一步瞭解 Cloud Run functions。