Google Cloud 提供兩大平台，可執行容器化應用程式：GKE 可在 Kubernetes 叢集上執行容器，Cloud Run 則可在 Google Cloud 基礎架構上直接執行容器。但何時該使用哪一種呢？可以同時使用嗎？本頁面將比較這兩個平台及其優勢，協助您判斷單一平台或混合策略是否適合您。
這個頁面適用於基礎架構管理員和應用程式營運人員，他們執行各種容器化工作負載，並想運用 Google Kubernetes Engine (GKE) 和 Cloud Run 的優勢，將應用程式部署到Google Cloud Platform。
閱讀本頁面之前，請先熟悉下列概念：
無狀態和有狀態工作負載
為何要同時使用 GKE 和 Cloud Run？
GKE 和 Cloud Run 在執行容器化應用程式時各有優勢，且適用於不同複雜程度的工作負載。不過，您不必在兩者之間做選擇。您可以視需要在這兩個平台之間遷移工作負載，同時運用 GKE 和 Cloud Run 的優勢。這類混合策略可協助您盡量降低成本、提升效能，並減輕管理負擔。
同時使用這兩種執行階段部署工作負載的優點如下：
GKE 和 Cloud Run 提供相對較高的可攜性：
這兩個平台都使用標準容器映像檔做為部署構件。您可以在任一平台中，使用相同的應用程式映像檔，不必進行任何修改，因此可在 GKE 和 Cloud Run 之間順暢遷移工作負載。只要容器映像檔儲存在 Artifact Registry，您就不必更新持續整合設定，即可在 GKE 和 Cloud Run 之間遷移。
GKE 和 Cloud Run 都使用宣告式 API 模型。Cloud Run Admin API v1 的設計與 Kubernetes API 相容。也就是說，您可以使用熟悉的 Kubernetes 概念 (例如 Deployments、Services 和水平 Pod 自動調度器) 管理 Cloud Run 服務。這項相似性可讓您更輕鬆地在這兩個平台之間轉換設定。
資源在 YAML 檔案中以相同的陳述式和標準結構表示，因此可在執行階段之間輕鬆遷移。以下是範例，比較 Kubernetes 部署作業和 Cloud Run 服務的 YAML 檔案。
GKE 和 Cloud Run 都能與 Cloud Logging 和 Cloud Monitoring 完美整合，讓您在 Google Cloud 控制台中集中查看應用程式指標，無論應用程式使用哪個平台都沒問題。您也可以在兩個平台上使用服務等級目標 (SLO) 監控，並在 Cloud Monitoring 資訊主頁上查看統一顯示的 SLO。
您可以使用 Cloud Deploy，對 GKE 資源或 Cloud Run 服務實作持續推送軟體更新。或者，您也可以使用平行部署，同時將應用程式部署至 GKE 和 Cloud Run。
您可以透過外部和內部負載平衡器，管理 GKE 和 Cloud Run 服務的流量，進而進階管理流量。包括公開外部端點，以便在兩個平台部署及執行相同應用程式的不同網址。您也可以將相同服務的流量分配到 GKE 和 Cloud Run，從一個平台無縫遷移至另一個平台。
Google Cloud 提供安全防護工具，協助您在使用這兩種執行階段時，提升安全防護機制。OS 掃描功能可讓您在部署至任一平台之前，掃描容器是否有安全漏洞。集中式二進位授權政策可強制與 GKE 和 Cloud Run 控制層整合，因此可以依據您定義的政策允許或封鎖映像檔部署作業。透過 VPC Service Controls，安全團隊可以為 GKE 和 Cloud Run 資源定義精細的範圍控管措施。
比較 GKE 和 Cloud Run
如要充分運用 GKE 和 Cloud Run 的最佳功能，並瞭解何時要在兩者之間移動工作負載，請務必瞭解這兩項服務的差異。
| 功能 | GKE | Cloud Run |
|---|---|---|
| 部署與管理 | 管理 Kubernetes 叢集，包括節點設定、網路、資源調度和升級。 Google Cloud 管理基礎架構，並提供簡化叢集作業的工具，但您仍須負責核心 Kubernetes 相關事宜。 |
直接在 Google Cloud的可擴充基礎架構上執行容器。 您只需要提供原始碼或容器映像檔，Cloud Run 就能為您建構容器。您不必建立叢集，也不必佈建及管理基礎架構。 |
| 控管與彈性 | 具備 Kubernetes 叢集的完整控制權。 您可以進階自訂節點設定、網路政策、安全性設定和外掛程式。 |
對底層基礎架構的控管程度較低。 您可以設定環境變數、並行和網路連線等項目，但無法自訂基礎架構或環境。適合追求簡單和速度的使用者。 |
| 應用程式類型 | 支援無狀態和有狀態應用程式，非常適合有特定資源需求的複雜應用程式。 | 最適合無狀態、要求或事件導向的服務、網路服務和函式。 |
| 定價模式 | 無論運作模式 (標準或 Autopilot)、叢集大小或拓撲為何，均以每小時為單位，按叢集計費。 | 按用量計費，進位至最接近的 100 毫秒倍數。 |
用途
假設您是零售公司的平台管理員，負責建構大型電子商務平台。您有下列容器化工作負載可供部署：
前端網站和行動應用程式：處理產品瀏覽、搜尋和結帳的無狀態網頁應用程式。
產品庫存管理：管理產品供應情形和更新的具狀態服務。
推薦引擎：複雜的微服務，可為每位使用者產生個人化產品推薦內容。
批次處理作業：包括更新產品目錄和分析使用者行為等定期工作。
這些工作負載代表無狀態和有狀態服務的組合，因此您決定同時使用 GKE 和 Cloud Run，以獲得最佳效能。以下是為工作負載導入混合式做法的一種方式。
閱讀 Cloud Run 工作負載適用性條件後，您決定使用 Cloud Run 處理網站、行動應用程式和批次處理工作。在 Cloud Run 上部署這些服務有以下優點：
流量暴增和大型批次工作會自動調度資源，不需手動介入。
按用量計費，符合成本效益。只有在使用者瀏覽或結帳時，以及在批次工作執行期間使用資源時，您才需要付費。
更新內容會立即提供，因此部署速度更快，使用者體驗也更好。
輕鬆整合其他 Google Cloud 服務。舉例來說，如要進行事件驅動處理，您可以使用 Cloud Run 函式在 Cloud Run 上啟動批次處理工作，並啟用無縫工作流程。
產品庫存管理是需要精細控制的具狀態服務，可能需要自訂儲存解決方案。您決定使用 GKE 部署這項服務，因為 GKE 提供永久儲存空間，可讓您附加磁碟區，確保產品資料的永久性和可靠性。
建議引擎是複雜的微服務，可從 GKE 受益。透過 GKE，您可以管理複雜的依附元件，並精細控管資源分配和擴充作業。
GKE 最適合複雜的微服務架構、具狀態的應用程式、需要自訂基礎架構或網路設定的工作負載，以及需要深入控管 Kubernetes 的情境。Cloud Run 最適合事件導向的應用程式。非常適合無狀態網路服務、API、批次工作，以及其他可從隨用隨付價格獲益的工作負載。
上述範例說明如何結合 GKE 和 Cloud Run，為電子商務平台提供強大且彈性的解決方案。您可同時享有這兩個平台的優點：無狀態工作負載的無伺服器效率，以及複雜微服務和有狀態元件的 Kubernetes 控制項。
如要統一查看以混合式方法部署的不同元件，並瞭解這些元件如何共同運作，形成連貫的應用程式，可以使用 App Hub。詳情請參閱「應用程式中心支援的資源」。
注意事項
GKE 和 Cloud Run 相輔相成，可滿足複雜應用程式環境中的不同需求。
採用混合式方法部署工作負載時，請考量下列事項：
在 Cloud Run 上執行無狀態微服務，提高成本效益和可擴充性。
在 GKE 上部署需要深度自訂的複雜有狀態應用程式。
如果您在 Google Cloud上使用私人網路，如要從 Cloud Run 服務存取 GKE 叢集中的資源，可以透過直接虛擬私有雲輸出流量，將要求傳送至虛擬私有雲 (VPC) 網路。如要在 GKE 叢集中存取 Kubernetes 服務，Cloud Run 服務必須連線至叢集的 VPC 網路，且 Kubernetes 服務必須使用內部直通網路負載平衡器。
如要在 Cloud Run 和 GKE 之間遷移流量，您可以透過全域外部應用程式負載平衡器公開外部端點。在兩個執行階段的服務前方實作這個負載平衡器後，您就能在 Cloud Run 和 GKE 部署相同的應用程式，進而逐步將流量從一個平台轉移至另一個平台。
如要在 Virtual Private Cloud 中透過私人 IP 位址公開 Cloud Run 服務，請使用內部負載平衡器。
請注意，如果工作負載已在 Cloud Run 上，您隨時可以視需要遷移至 GKE。
不應同時使用 GKE 和 Cloud Run 的情況
雖然 GKE 和 Cloud Run 為許多容器化工作負載提供極具吸引力的做法，但在某些情況下，一起使用這兩項服務可能不是最佳選擇。以下列舉幾個可能決定不採用混合式方法的例子：
緊密耦合的微服務：如果微服務彼此高度依賴，且需要頻繁進行低延遲通訊，在不同平台管理這些服務可能會造成複雜性。平台之間頻繁的網路呼叫可能會增加額外負荷和潛在瓶頸，進而影響效能。
具有自訂依附元件的舊版應用程式：如果應用程式依賴 Cloud Run 不支援的特定程式庫、架構或設定，則使用 Cloud Run 處理部分應用程式時，可能需要大幅重構或採用解決方法。這可能會抵銷無伺服器優勢，並造成平台專屬的維護負擔。
預算有限且工作負載可預測：如果工作負載的資源需求一致，且預算有限，GKE 的節點付費模式可能比 Cloud Run 的用量計費模式更具成本效益。如果工作負載可預測，您可能無法充分利用 Cloud Run 的自動調整功能，因此 GKE 的固定費用會更具吸引力。
最終，最適合的做法取決於您的特定需求和優先事項。決定採用混合式 GKE 和 Cloud Run 架構前，請先仔細評估應用程式需求、資源限制和團隊專業知識。
後續步驟
請參閱「從 Cloud Run 遷移至 GKE」，瞭解如何將 Cloud Run 服務轉換為 Kubernetes 部署作業。
按照「從 Kubernetes 遷移至 Cloud Run」一文的說明，將 Kubernetes 部署作業封裝至與 Cloud Run 相容的容器。