選取受管理的容器執行階段環境

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 標準模式中的 VM 是 Kubernetes 叢集節點。Compute Engine 中的 VM 是核心平台服務，您可以自訂 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、Binary Authorization，以及透過 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 會持續監控及最佳化基礎架構資源，確保資源最符合需求，同時為工作負載提供SLA。

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 Volume，並以 Persistent Disk 為後盾，讓您執行各種有狀態的部署作業，包括自行管理的資料庫。Cloud Run 和 GKE Autopilot 都能與 Filestore 和 Cloud Storage 儲存空間等其他服務連線。此外，兩者都可透過 Cloud Storage FUSE 將物件儲存桶掛接到檔案系統中。

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 生態系統，可加快開發速度並縮短上市時間。

現有的內部工具

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

開發團隊設定檔

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

對於成長中的團隊，招募能力可能會影響機構的平台選擇。在某些市場，Kubernetes 技能可能很稀少，因此聘用這類人才的費用較高。選擇 Cloud Run 等環境有助於簡化聘用程序，並在預算範圍內加速團隊成長。

操作支援

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

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

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

選取

如要開始選取程序，請與各個利害關係人討論。針對每個應用程式，請組成工作群組，成員包括開發人員、營運人員、任何中央技術管理群組的代表、內部應用程式使用者和消費者、安全團隊、雲端財務最佳化團隊，以及貴機構中可能相關的其他角色或群組。您可能會選擇發放資訊收集問卷調查，彙整應用程式特徵，並在課程前分享結果。建議您選取小型工作團隊，只納入必要的利害關係人。並非每次工作階段都需要所有代表。

您也可以納入其他團隊或群組的代表，他們在 Autopilot 或 Cloud Run (或兩者) 上建構及執行應用程式方面有經驗，請參考本文的技術和組織考量，與對方討論並評估應用程式是否適合各個潛在平台。

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

後續步驟

貢獻者

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

其他貢獻者：