Autoscaling-Tool in GKE bereitstellen

Das Bereitstellungsmodell der Google Kubernetes Engine (GKE) eignet sich gut für unabhängige Teams, die die Infrastruktur und Konfiguration ihrer eigenen Autoskalatoren in Kubernetes selbst verwalten möchten.

Dieses Dokument ist Teil einer Reihe, die folgende Themen behandelt:

Diese Reihe richtet sich an IT-, Betriebs- und Site Reliability Engineering-Teams (SRE), die den operativen Aufwand reduzieren und die Kosten der Spanner-Bereitstellungen optimieren möchten.

Die GKE-Bereitstellung hat folgende Vor- und Nachteile:

Vorteile:

  • Kubernetes-basiert: Teams, die möglicherweise keine Dienste wie Cloud Run-Funktionen verwenden können, können mit der Bereitstellung in Kubernetes den Autoscaler nutzen.
  • Konfiguration: Die Kontrolle über Scheduler-Parameter gehört dem Team, das die Spanner-Instanz besitzt. Das Team hat somit die höchsten Berechtigungen, den Autoscaler an seine Anforderungen anzupassen.

Nachteile:

  • Infrastruktur: Im Vergleich zum Design von Cloud Run-Funktionen sind einige langlebige Infrastrukturen und Dienste erforderlich.
  • Wartung: Da jedes Team für die Konfiguration und Infrastruktur des Autoscalings verantwortlich ist, kann es schwierig sein, sicherzustellen, dass alle Autoscaler im gesamten Unternehmen den gleichen Aktualisierungsrichtlinien folgen.
  • Audit: Aufgrund der hohen Kontrolle durch jedes Team kann eine zentrale Prüfung komplexer werden.

Auf dieser Seite werden zwei Möglichkeiten vorgestellt, wie Sie den Autoscaler je nach Ihren Anforderungen in GKE bereitstellen können:

  • Eine entkoppelte Bereitstellungstopologie. Das entkoppelte Bereitstellungsmodell hat den Vorteil, dass Sie Poller- und Scaler-Komponenten individuelle Berechtigungen zuweisen können, damit sie als separate Dienstkonten ausgeführt werden. So haben Sie die Flexibilität, die beiden Komponenten nach Ihren Anforderungen zu verwalten und zu skalieren. Bei diesem Bereitstellungsmodell muss die Scaler-Komponente jedoch als langlebiger Dienst bereitgestellt werden, was Ressourcen verbraucht.
  • Eine einheitliche Bereitstellungstopologie. Das einheitliche Bereitstellungsmodell hat den Vorteil, dass die Poller- und Scaler-Komponenten als einzelner Pod bereitgestellt werden können, der als Kubernetes-Cron-Job ausgeführt wird. Wenn die beiden Komponenten als einzelner Pod bereitgestellt werden, gibt es keine lang laufenden Komponenten und es ist nur ein einziges Dienstkonto erforderlich.

Für die meisten Anwendungsfälle empfehlen wir das einheitliche Bereitstellungsmodell.

Konfiguration

Das Autoscaling-Tool verwaltet Spanner-Instanzen über die Konfiguration, die in einer Kubernetes-ConfigMap definiert ist. Wenn mehrere Spanner-Instanzen mit demselben Intervall abgefragt werden müssen, empfehlen wir Ihnen, diese im selben ConfigMap zu konfigurieren. Das folgende Beispiel zeigt eine Konfiguration, bei der zwei Spanner-Instanzen mit einer einzigen Konfiguration verwaltet werden:

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

Eine Instanz kann beispielsweise eine Autoscaling-Konfiguration mit der linearen Methode für normale Vorgänge haben, aber auch eine weitere Autoscaling-Konfiguration mit der direkten Methode für geplante Batcharbeitslasten. Eine vollständige Liste der Konfigurationsoptionen finden Sie in der Poller-README-Datei.

In GKE bereitstellen

Informationen zum Bereitstellen des Autoscalings in GKE mit dem dezentralen oder einheitlichen Bereitstellungsmodell finden Sie in der schrittweisen Anleitung zur GKE-Bereitstellung.

Nächste Schritte