Google Cloud 提供兩個主要平台，用於執行容器化應用程式：GKE 可在 Kubernetes 叢集上執行容器，Cloud Run 則可直接在 Google Cloud 基礎架構上執行容器。但何時該使用哪一種？可以同時使用嗎？本頁面比較這兩個平台及其優勢，協助您判斷單一平台或混合策略是否適合您。
本頁面適用於基礎架構管理員和應用程式操作員，他們執行多種容器化工作負載，並希望運用 Google Kubernetes Engine (GKE) 和 Cloud Run 的優勢，將應用程式部署至Google Cloud 平台。
閱讀本頁內容前，請先熟悉下列概念：
無狀態和有狀態工作負載
為何要同時使用 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 叢集。 您可以進一步自訂節點設定、網路政策、安全性設定和外掛程式。 |
對底層基礎架構的控管程度有限。 您可以設定環境變數、並行和網路連線等項目，但無法自訂基礎架構或環境。適合追求簡單快速的使用者。 |
| 應用程式類型 | 支援無狀態和有狀態應用程式，非常適合有特定資源需求的複雜應用程式。 | 最適合無狀態、要求或事件導向的服務、網路服務和函式。 |
| 定價模式 | 無論作業模式 (Standard 或 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。詳情請參閱「App Hub 支援的資源」。
注意事項
GKE 和 Cloud Run 彼此互補，可滿足複雜應用程式環境中的不同需求。
採用混合式方法部署工作負載時，請考量下列事項：
在 Cloud Run 上執行無狀態微服務，提高成本效益和可擴充性。
在 GKE 上部署需要深度自訂的複雜有狀態應用程式。
如果您在 Google Cloud上使用私人網路，如要從 Cloud Run 服務存取 GKE 叢集中的資源，可以透過直連虛擬私有雲輸出流量，將要求傳送至虛擬私有雲 (VPC) 網路。如要在 GKE 叢集中存取 Kubernetes 服務，Cloud Run 服務必須連線至叢集的虛擬私有雲網路，且 Kubernetes 服務必須使用內部直通式網路負載平衡器。
如要在 Cloud Run 和 GKE 之間遷移流量，您可以透過全域外部應用程式負載平衡器公開外部端點。在兩個執行階段的服務前方實作這個負載平衡器後，您就能在 Cloud Run 和 GKE 部署相同應用程式，進而逐步將流量從一個平台轉移至另一個平台。
如要在虛擬私有雲中透過私人 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 服務轉換為 Kubernetes 部署作業，請參閱「從 Cloud Run 遷移至 GKE」。
按照「從 Kubernetes 遷移至 Cloud Run」一文的說明，將 Kubernetes 部署作業封裝至與 Cloud Run 相容的容器。