選取代管容器執行階段環境

Last reviewed 2024-08-30 UTC

本文可協助您評估應用程式需求，並根據技術和組織考量，在 Cloud Run 和 Google Kubernetes Engine (GKE) Autopilot 之間做出選擇。這份文件適用於需要為工作負載選擇 Google Cloud 目標容器執行階段環境的雲端架構師。並假設您熟悉 Kubernetes 和 Google Cloud，且對 Cloud Run、Cloud Run functions 或 AWS Lambda 等雲端無伺服器執行階段環境有一定瞭解。

Google Cloud 提供多種執行階段環境選項，具備多種功能。下圖顯示 Google Cloud代管服務的範圍：

Google Cloud 服務，從代管程度最高到最低。

圖表顯示下列內容：

  • 全代管執行階段環境 (本指南重點)：

    這些選項由 Google 管理，使用者不需管理底層運算基礎架構。

  • 代管程度最低的執行階段環境：

    • GKE Standard：針對企業工作負載最佳化，單一叢集最多可擴充至 65,000 個節點。
    • Compute Engine：包含加速器最佳化的 A3 系列虛擬機器，適用於機器學習 (ML) 和高效能運算 (HPC) 工作負載。

    這些選項需要一定程度的使用者層級基礎架構管理，例如運算功能底層的虛擬機器 (VM)。GKE Standard 中的 VM 是 Kubernetes 叢集節點。Compute Engine 中的 VM 是核心平台服務，您可以根據需求自訂。

本指南可協助您在 Cloud Run 和 GKE Autopilot 這兩個最受歡迎的代管執行階段環境之間做出選擇。如要進一步瞭解 Google Cloud 執行階段環境，請參閱Google Cloud 應用程式託管選項指南。

環境總覽

本節提供 Cloud Run 和 GKE Autopilot 功能的總覽。Cloud Run 和 GKE Autopilot 都與 Google Cloud緊密整合，因此兩者有許多共通點。這兩個平台都支援多種負載平衡選項，並採用 Google 高度可靠且可擴充的負載平衡服務。兩者也都支援虛擬私有雲網路、Identity-Aware Proxy (IAP) 和 Google Cloud Armor，可滿足更精細的私人網路需求。這兩個平台只會依據您實際使用的應用程式資源向您收費。

從軟體推送的角度來看，Cloud Run 和 GKE Autopilot 做為容器執行階段環境，是由構成 Google Cloud 容器生態系統的服務支援。這些服務包括 Cloud Build、Artifact Registry、二進位授權，以及使用 Cloud Deploy 持續推送軟體更新，確保應用程式安全可靠地部署至正式環境。這表示您和團隊擁有建構和部署決策權。

由於這兩個平台有共通點，您可能想採用彈性的應用程式部署方式，充分發揮各個平台的優勢，詳情請參閱「搭配使用 GKE 和 Cloud Run」指南。以下各節說明 Cloud Run 和 Autopilot 的獨特之處。

Cloud Run

Cloud Run 是無伺服器代管運算平台，可讓您直接在 Google 的可擴充基礎架構上執行應用程式。Cloud Run 為兩種主要應用程式提供自動化和資源調度功能：

  • Cloud Run 服務：用於回應網頁要求的程式碼。
  • Cloud Run 工作：適用於執行一或多項背景工作，並在工作完成後結束的程式碼。

Cloud Run 支援這兩種部署模式，可支援多種應用程式架構，同時啟用最佳做法，讓開發人員專注於程式碼。

Cloud Run 也支援從下列來源部署應用程式程式碼：

  • 個別輕量函式
  • 從原始碼建構完整應用程式
  • 容器化應用程式

Cloud Run 整合了建構和部署功能，除了預先建構的容器執行階段功能外，還支援 FaaS 和從原始碼建構的功能。以這種方式使用 Cloud Run 時，系統會自動執行建構和部署應用程式容器映像檔的步驟，您不需要自訂設定。

GKE Autopilot

GKE Autopilot 是 GKE 中預設且建議使用的叢集作業模式。Autopilot 可讓您在 Kubernetes 上執行應用程式，不必費心管理基礎架構。使用 Autopilot 時，Google 會管理叢集設定的重要基礎層面，包括節點佈建和資源調度、預設資安態勢，以及其他預先設定。Autopilot 會管理節點資源，因此您只需為工作負載要求的資源付費。Autopilot 會持續監控及最佳化基礎架構資源，確保最適合您的工作負載，同時提供服務水準協議。

GKE Autopilot 支援可能不適合 Cloud Run 的工作負載。舉例來說，GKE Autopilot 通常支援長期或有狀態的工作負載。

選擇執行階段環境

一般來說，如果工作負載的特性適合代管平台，Cloud Run 的無伺服器執行階段環境會是理想選擇。使用 Cloud Run 可減少需要管理的基礎架構和自行管理的設定，進而降低營運負擔。除非您特別想要或需要 Kubernetes，否則建議您先考慮將無伺服器做為目標執行階段環境。雖然 Kubernetes 提供強大的開放平台抽象化功能，但使用時會增加複雜度。如果您不需要 Kubernetes，建議您考慮應用程式是否適合無伺服器。如果您的工作負載不適合無伺服器，建議使用 Autopilot。

以下各節將詳細說明一些條件，協助您回答這些問題，尤其是工作負載是否適合無伺服器。Autopilot 和 Cloud Run 之間有許多共通點，如前幾節所述，在沒有任何技術或其他阻礙的情況下，在平台之間遷移是一項簡單的工作。如要進一步瞭解遷移選項，請參閱「從 Cloud Run 遷移至 GKE」和「從 Kubernetes 遷移至 Cloud Run」。

為工作負載選擇執行階段環境時，您需要考量技術和組織層面的因素。技術考量是指應用程式或 Google Cloud執行階段環境的特性。組織考量因素是指組織或團隊的非技術特性，可能會影響您的決策。

技術考量

以下是會影響平台選擇的一些技術考量：

  • 控管和設定能力：執行環境的控管精細程度。
  • 網路流量管理和轉送：可設定網路互動。
  • 水平和垂直擴充性：支援動態擴充和縮減容量。
  • 支援有狀態應用程式：可儲存永久狀態。
  • CPU 架構：支援不同的 CPU 類型。
  • 加速器卸載 (GPU 和 TPU)：可將運算作業卸載至專用硬體。
  • 高記憶體、CPU 和其他資源容量：各種資源的消耗程度。
  • 明確依附 Kubernetes：Kubernetes API 的使用規定。
  • 多租戶的複雜 RBAC：支援共用集區資源。
  • 容器工作逾時時間上限：長時間執行的應用程式或元件的執行時間。

以下各節將詳細說明這些技術考量，協助您選擇執行階段環境。

控管與設定

與 Cloud Run 相比，GKE Autopilot 可讓您更精細地控管工作負載的執行環境。在 Pod 的情境中，Kubernetes 提供許多可設定的原語，您可以調整這些原語來滿足應用程式需求。設定選項包括權限層級、服務品質參數、容器生命週期事件的自訂處理常式，以及多個容器之間的程序命名空間共用。

Cloud Run 直接支援 Kubernetes Pod API 介面的子集，詳情請參閱 Cloud Run 服務物件的參考 YAML 和 Cloud Run 工作物件的參考 YAML。這些參考指南可協助您根據應用程式需求評估這兩個平台。

Cloud Run 執行環境的容器合約相對簡單，適合大多數服務工作負載。不過，合約會指定必須達成的特定要求。如果應用程式或其依附元件無法滿足這些要求，或者您需要更精細地控管執行環境，那麼 Autopilot 可能更適合。

如要減少設定和管理時間，建議選擇 Cloud Run 做為執行階段環境。Cloud Run 的設定選項比 Autopilot 少，因此可協助您大幅提升開發人員的工作效率，並減少作業負擔。

網路流量管理和轉送

Cloud Run 和 GKE Autopilot 都與 Google Cloud Load Balancing 整合。不過，GKE Autopilot 還提供豐富強大的原始物件，可用於設定服務對服務通訊的網路環境。設定選項包括精細權限，以及使用命名空間和網路政策在網路層進行隔離、通訊埠重新對應，以及叢集內建的 DNS 服務探索。GKE Autopilot 也支援高度可設定且彈性的 Gateway API。這項功能可讓您有效控管流量轉送至叢集內服務，以及在叢集內服務之間轉送的方式。

Autopilot 具備高度可設定性，如果有多項服務高度依賴網路，或是在應用程式元件之間的流量轉送方面有複雜的需求，Autopilot 會是最佳選擇。這種模式的例子是分散式應用程式，其分解成多個微服務，具有複雜的相互依賴模式。在這種情況下，Autopilot 網路設定選項可協助您管理及控管服務之間的互動。

水平和垂直擴充性

Cloud Run 和 GKE Autopilot 都支援手動和自動水平擴充服務和工作。水平資源調度會在需要時增加處理能力，並在不需要時移除增加的處理能力。對於一般工作負載，Cloud Run 通常能比 GKE Autopilot 更快水平擴展，因應每秒要求數激增的情況。舉例來說，影片示範「無伺服器運算的新功能」顯示 Cloud Run 在大約 10 秒內，從零擴充至超過 10,000 個執行個體。如要提高 Kubernetes 的水平擴充速度 (需支付額外費用)，Autopilot 可讓您佈建額外的運算容量。

如果應用程式無法透過新增執行個體來擴充可用資源，則可能較適合使用 Autopilot。Autopilot 支援垂直資源調度，可動態調整可用的處理能力，而不必增加應用程式的執行個體數量。

Cloud Run 可在應用程式未使用時，自動將應用程式縮減至零個副本，這對特別注重成本最佳化的特定用途很有幫助。由於應用程式可將資源調度率降至零，因此您可以採取多個最佳化步驟，盡可能縮短從收到要求到應用程式啟動並執行，以及能夠處理要求的時間。

支援有狀態應用程式

Autopilot 提供完整的 Kubernetes 磁碟區支援，並由永久磁碟支援，可讓您執行各種有狀態部署作業，包括自行管理的資料庫。Cloud Run 和 GKE Autopilot 都能連結 Filestore 和 Cloud Storage bucket 等其他服務。兩者也都能使用 Cloud Storage FUSE，將物件儲存庫 bucket 掛接至檔案系統。

Cloud Run 使用記憶體內檔案系統，可能不適合需要「永久」本機檔案系統的應用程式。此外，本機記憶體內檔案系統會與應用程式的記憶體共用。因此，暫時檔案系統以及應用程式和容器記憶體用量，都會導致記憶體用量達到上限。如要避免這個問題，請使用有大小限制的專用記憶體內磁碟區。

Cloud Run 服務或工作容器有工作逾時上限。在 Autopilot 叢集的 Pod 中執行的容器可以重新排程，但須遵守 Pod 中斷預算 (PDB) 設定的任何限制。不過，如果 Pod 受到保護，不會因節點自動升級或縮減事件而遭到淘汰，則最多可執行七天。一般來說，Cloud Run 中的批次工作負載較可能需要考量工作逾時問題。如果是長期工作負載，以及無法在最長工作時間內完成的批次工作，Autopilot 可能是最佳選擇。

CPU 架構

所有 Google Cloud 運算平台都支援 x86 CPU 架構。Cloud Run 不支援 Arm 架構處理器，但 Autopilot 支援以 Arm 架構為基礎的代管節點。如果工作負載需要 Arm 架構，則必須使用 Autopilot。

加速器卸載

Autopilot 支援使用 GPU 和使用 TPU，包括使用預留資源的能力。Cloud Run 支援使用 GPU，但有一些限制。

記憶體、CPU 和其他資源需求量大

相較於 GKE Autopilot 資源要求限制，單一 Cloud Run 服務或工作 (單一執行個體) 可耗用的 CPU 和記憶體資源上限較低。視工作負載的特性而定，Cloud Run 可能會有其他限制，會限制可用的資源。舉例來說，Cloud Run 可能會限制啟動逾時時間和傳出連線數量上限。如果使用 Autopilot，部分限制可能不適用，或允許的值可能較高。

明確依附於 Kubernetes

某些應用程式、程式庫或架構可能明確依附於 Kubernetes。Kubernetes 依附元件可能是下列其中一項原因所致：

  1. 應用程式需求 (例如應用程式呼叫 Kubernetes API，或使用 Kubernetes 自訂資源)。
  2. 用於設定或部署應用程式的工具 (例如 Helm) 的需求。
  3. 第三方創作者或供應商的支援需求。

在這些情境中，Autopilot 是目標執行階段環境，因為 Cloud Run 不支援 Kubernetes。

多用戶群適用的複雜 RBAC

如果貴組織的組織結構或多用戶群架構需求特別複雜，請使用 Autopilot，以便利用 Kubernetes 的角色式存取控管 (RBAC)。如要採用更簡單的做法，可以使用 Cloud Run 內建的安全性和隔離功能。

組織考量

以下是會影響環境選擇的一些組織考量：

  • 廣泛技術策略：貴組織的技術方向。
  • 運用 Kubernetes 生態系統：有意運用 OSS 社群。
  • 現有內部工具：目前使用的特定工具。
  • 開發團隊簡介：開發人員技能組合和經驗。
  • 營運支援：營運團隊的能力和重點。

以下各節將詳細說明這些組織考量，協助您選擇環境。

廣泛技術策略

組織或團隊可能已就偏好某些技術而非其他技術達成共識。舉例來說，如果團隊同意盡可能在無伺服器或 Kubernetes 上標準化，該協議可能會影響甚至決定目標執行階段環境。

如果特定工作負載不適合策略中指定的執行階段環境，您可以決定執行下列一或多項操作，並注意相關注意事項：

  • 重新架構工作負載。不過，如果工作負載不適合，這麼做可能會導致效能、成本、安全性或其他特性不佳。
  • 將工作負載註冊為策略方向的例外狀況。不過，如果過度使用例外狀況，可能會導致技術組合不一致。
  • 重新考慮策略。不過，這麼做可能會產生政策負擔，阻礙或阻擋進度。

運用 Kubernetes 生態系統

如前所述，在廣泛的技術策略中，組織或團隊可能會選擇 Kubernetes 做為平台，因為其生態系統龐大且不斷成長。這項選擇與因技術應用程式依附元件而選取 Kubernetes 不同，如前一節「明確依附於 Kubernetes」所述。使用 Kubernetes 生態系統時，應著重於活躍的社群、豐富的第三方工具，以及強大的標準和可攜性。運用 Kubernetes 生態系統，可加快開發速度，縮短上市時間。

現有的內部工具

在某些情況下，在貴組織或團隊中使用現有的工具生態系統 (適用於任何環境) 可能會帶來優勢。舉例來說，如果您使用 Kubernetes，可能會選擇繼續使用 ArgoCD 等部署工具、Gatekeeper 等安全性和政策工具，以及 Helm 等套件管理工具。現有工具可能包含既定規則，用於自動化組織法規遵循和其他功能，而這些功能可能需要較高的成本，或需要較長的前置時間，才能在替代目標環境中實作。

開發團隊簡介

應用程式或工作負載團隊可能具備 Kubernetes 經驗，可加快團隊在 Autopilot 上的交付速度和能力。團隊可能需要一段時間，才能熟悉新的執行階段環境。視營運模式而定，這麼做可能會在技能提升期間降低平台可靠性。

對於成長中的團隊，招聘能力可能會影響組織對平台的選擇。在某些市場，Kubernetes 技能可能較為稀缺，因此需要支付較高的招聘費用。選擇 Cloud Run 等環境，有助於簡化招聘流程，並在預算範圍內加快團隊成長速度。

操作支援

選擇執行階段環境時，請考量 SRE、DevOps、平台團隊和其他營運人員的經驗和能力。從可靠性的角度來看，營運團隊能否有效支援正式環境至關重要。此外，營運團隊也必須能支援試產環境，確保開發人員的速度不會因停機、依賴手動程序或繁瑣的部署機制而受到阻礙。

如果您使用 Kubernetes，中央營運或平台工程團隊可以處理 Autopilot Kubernetes 升級。雖然升級作業會自動執行，但營運人員通常會密切監控，確保工作負載中斷情形降到最低。有些組織會選擇手動升級控制層版本。GKE 也提供多項功能，可簡化多個叢集的應用程式管理作業。

與 Autopilot 不同，Cloud Run 不需要持續管理控制層，也不需要升級控制層。使用 Cloud Run 可簡化作業流程。選取單一執行階段環境，即可進一步簡化作業流程。如果您選擇使用多個執行階段環境，則必須確保團隊有能力、有興趣支援這些執行階段環境。

選取

如要開始選取，請與各個利害關係人討論。針對每個應用程式，請召集一個工作群組，成員包括開發人員、營運人員、任何中央技術管理群組的代表、內部應用程式使用者和消費者、資安人員、雲端財務最佳化團隊，以及組織內可能相關的其他角色或群組。您可以選擇發送資訊收集問卷，整理應用程式特性，並在會議前分享結果。建議您選取一個小型工作群組，其中只包含必要的利害關係人。並非所有代表都必須參加每場工作會議。

您也可以邀請其他團隊或群組的代表加入，這些團隊或群組應具備在 Autopilot 和/或 Cloud Run 上建構及執行應用程式的經驗。請參考本文中的技術和組織考量，引導對話並評估應用程式是否適合各個潛在平台。

建議您在幾個月後安排檢查，根據在新環境中部署應用程式的結果，確認或重新評估決策。

後續步驟

貢獻者

作者：Henry Bell | 雲端解決方案架構師

其他貢獻者：