如果獨立團隊想要自行管理 Kubernetes 上自有調整器的基礎架構和設定,Google Kubernetes Engine (GKE) 部署模型就是不錯的選擇。
本文件是一系列文章的一部分,其他文章如下:
本系列文章適用於想降低營運負擔,並將 Spanner 部署成本降至最低的 IT、營運和網站可靠度工程 (SRE) 團隊。
GKE 部署作業有下列優缺點:
優點:
- 以 Kubernetes 為基礎:如果團隊無法使用 Cloud Run 函式等服務,則可將應用程式部署至 Kubernetes,以便使用自動調整器。
- 設定:排程器參數的控管權屬於擁有 Spanner 執行個體的團隊,該團隊擁有最高權限,可視需求調整自動配置器。
缺點:
- 基礎架構:與 Cloud Run 函式設計相比,需要一些長效基礎架構和服務。
- 維護:由於每個團隊都負責 Autoscaler 設定和基礎架構,因此可能很難確保公司內所有 Autoscaler 都遵循相同的更新指南。
- 稽核:由於各團隊的控管程度很高,因此集中稽核作業可能會變得更複雜。
本頁面將介紹兩種方法,讓您根據需求將 Autoscaler 部署至 GKE:
- 分離式部署拓撲。分離式部署模式的優點在於,您可以為 Poller 和 Scaler 元件指派個別權限,讓這些元件以不同的服務帳戶執行。這表示您可以視需求靈活管理及調整這兩個元件。不過,這個部署模式要求 Scaler 元件必須部署為長時間執行的服務,這會消耗資源。
- 統一部署拓撲。統一部署模式的優點在於,您可以將 Polling 和 Scaler 元件部署為單一 Pod,並以 Kubernetes cron 工作執行。如果兩個元件以單一 Pod 部署,就沒有長時間執行的元件,且只需要一個服務帳戶。
對於多數用途,我們建議採用統一部署模式。
設定
自動配置器工具會透過 Kubernetes ConfigMap
中定義的設定來管理 Spanner 執行個體。如果需要以相同間隔輪詢多個 Spanner 例項,建議您在相同 ConfigMap
中設定這些例項。以下是使用單一設定管理兩個 Spanner 執行個體的設定範例:
apiVersion: v1
kind: ConfigMap
metadata:
name: autoscaler-config
namespace: spanner-autoscaler
data:
autoscaler-config.yaml: |
---
- projectId: spanner-autoscaler-test
instanceId: spanner-scaling-linear
units: NODES
minSize: 5
maxSize: 30
scalingMethod: LINEAR
- projectId: spanner-autoscaler-test
instanceId: spanner-scaling-threshold
units: PROCESSING_UNITS
minSize: 100
maxSize: 3000
metrics:
- name: high_priority_cpu
regional_threshold: 40
regional_margin: 3
執行個體可以有一個自動配置器設定,其中包含用於一般作業的線性方法,以及另一個自動配置器設定,其中包含用於排程批次工作負載的直接方法。如需完整的設定選項清單,請參閱 Poller README
檔案。
部署至 GKE
如要瞭解如何在分離或統一部署模式中,將自動調整器部署至 GKE,請參閱 GKE 部署的逐步指南。
後續步驟
- 瞭解如何將 Autoscaler 工具部署至 Cloud Run 函式。
- 進一步瞭解 Spanner 的建議閾值。
- 進一步瞭解 Spanner 的 CPU 使用率指標和延遲指標。
- 瞭解 Spanner 結構定義設計的最佳做法,以避免資源使用率不均,並將資料載入 Spanner。
- 探索 Google Cloud 的參考架構、圖表和最佳做法。歡迎瀏覽我們的雲端架構中心。