Esegui il deployment dello strumento Autoscaler in GKE

Il modello di deployment di Google Kubernetes Engine (GKE) è una buona scelta per i team indipendenti che vogliono gestire autonomamente l'infrastruttura e la configurazione dei propri Autoscaler su Kubernetes.

Questo documento fa parte di una serie che include anche:

Questa serie è rivolta ai team IT, Operations e Site Reliability Engineering (SRE) che vogliono ridurre l'overhead operativo e ottimizzare il costo degli implementazioni di Spanner.

Il deployment di GKE presenta i seguenti vantaggi e svantaggi:

Vantaggi:

  • Basato su Kubernetes: per i team che potrebbero non essere in grado di utilizzare servizi come le funzioni Cloud Run, il deployment su Kubernetes consente di utilizzare l'autoscalabilità.
  • Configurazione: il controllo dei parametri di pianificazione appartiene al team proprietario dell'istanza Spanner, che dispone dei privilegi più elevati per adattare lo strumento di scalabilità automatica alle proprie esigenze.

Svantaggi:

  • Infrastruttura: rispetto al design delle funzioni Cloud Run, sono richiesti alcuni servizi e infrastrutture a lungo termine.
  • Manutenzione: poiché ogni team è responsabile della configurazione e dell'infrastruttura di Autoscaler, potrebbe essere difficile assicurarsi che tutti gli Autoscaler dell'azienda seguano le stesse linee guida di aggiornamento.
  • Controllo: a causa dell'elevato livello di controllo di ciascun team, un controllo centralizzato potrebbe diventare più complesso.

Questa pagina illustra due modi per eseguire il deployment di Autoscaler in GKE in base ai tuoi requisiti:

  • Una topologia di deployment disaccoppiata. Il modello di deployment disaccoppiato ha il vantaggio che puoi assegnare autorizzazioni individuali ai componenti Poller e Scaler in modo che vengano eseguiti come service account separati. Ciò significa che hai la flessibilità di gestire e scalare i due componenti in base alle tue esigenze. Tuttavia, questo modello di deployment richiede che il componente Scaler venga disegnato come servizio a lungo termine, che consuma risorse.
  • Una topologia di deployment unificata. Il modello di deployment unificato ha il vantaggio che i componenti Poller e Scaler possono essere dispiacchiati come un singolo pod, che viene eseguito come job cron Kubernetes. Quando i due componenti vengono di cuipiati come un singolo pod, non sono presenti componenti a esecuzione prolungata ed è richiesto un solo account di servizio.

Per la maggior parte dei casi d'uso, consigliamo il modello di implementazione unificato.

Configurazione

Lo strumento Autoscaler gestisce le istanze Spanner tramite la configurazione definita in un ConfigMap Kubernetes. Se è necessario eseguire il polling di più istanze Spanner con lo stesso intervallo, ti consigliamo di configurarle nello stesso ConfigMap. Di seguito è riportato un esempio di configurazione in cui due istanze Spanner vengono gestite con una configurazione:

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

Un'istanza può avere una configurazione di Autoscaler con il metodo lineare per le operazioni normali e un'altra configurazione di Autoscaler con il metodo diretto per i carichi di lavoro batch pianificati. Consulta l'elenco completo delle opzioni di configurazione nel file README del poller.

Esegui il deployment su GKE

Per scoprire come eseguire il deployment di Autoscaler in GKE nel modello di deployment disaccoppiato o unificato, consulta la guida passo passo al deployment di GKE.

Passaggi successivi