Déployer l'outil Autoscaler sur GKE

Le modèle de déploiement Google Kubernetes Engine (GKE) est un bon choix pour les équipes indépendantes qui souhaitent gérer elles-mêmes l'infrastructure et la configuration de leurs propres autoscalers sur Kubernetes.

Ce document fait partie d'une série qui comprend également les documents suivants:

Cette série est destinée aux équipes informatique et aux équipes chargées des opérations et de l'ingénierie en fiabilité des sites (SRE) qui souhaitent réduire les coûts opérationnels et optimiser le coût des déploiements Spanner.

Le déploiement GKE présente les avantages et les inconvénients suivants:

Avantages :

  • Basé sur Kubernetes: pour les équipes qui ne peuvent pas utiliser des services tels que les fonctions Cloud Run, le déploiement sur Kubernetes permet d'utiliser l'autoscaler.
  • Configuration: le contrôle des paramètres du programmeur appartient à l'équipe qui possède l'instance Spanner. Elle dispose ainsi des droits les plus élevés pour adapter l'autoscaler à ses besoins.

Inconvénients :

  • Infrastructure: par rapport à la conception des fonctions Cloud Run, certains services et infrastructures durables sont requis.
  • Maintenance: chaque équipe étant responsable de la configuration et de l'infrastructure d'Autoscaler, il peut être difficile de s'assurer que tous les Autoscalers de l'entreprise suivent les mêmes consignes de mise à jour.
  • Audit: en raison du haut niveau de contrôle de chaque équipe, un audit centralisé peut devenir plus complexe.

Cette page présente deux façons de déployer l'autoscaler dans GKE en fonction de vos besoins:

  • Topologie de déploiement déconnectée Le modèle de déploiement dissocié présente l'avantage de vous permettre d'attribuer des autorisations individuelles aux composants Poller et Scaler afin qu'ils s'exécutent en tant que comptes de service distincts. Vous pouvez ainsi gérer et faire évoluer les deux composants en fonction de vos besoins. Toutefois, ce modèle de déploiement nécessite que le composant Scaler soit déployé en tant que service de longue durée, ce qui consomme des ressources.
  • Topologie de déploiement unifiée : Le modèle de déploiement unifié présente l'avantage que les composants Poller et Scaler peuvent être déployés en tant que pod unique, qui s'exécute en tant que tâche cron Kubernetes. Lorsque les deux composants sont déployés en tant que pod unique, il n'y a pas de composants de longue durée et un seul compte de service est requis.

Pour la plupart des cas d'utilisation, nous vous recommandons le modèle de déploiement unifié.

Configuration

L'outil Autoscaler gère les instances Spanner via la configuration définie dans un ConfigMap Kubernetes. Si plusieurs instances Spanner doivent être interrogées au même intervalle, nous vous recommandons de les configurer dans le même ConfigMap. Voici un exemple de configuration dans laquelle deux instances Spanner sont gérées avec une configuration:

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

Une instance peut disposer d'une configuration Autoscaler avec la méthode linéaire pour les opérations normales, mais aussi d'une autre configuration Autoscaler avec la méthode directe pour les charges de travail par lot planifiées. Consultez la liste complète des options de configuration dans le fichier README d'interrogation.

Déploiement sur GKE

Pour découvrir comment déployer l'autoscaler dans GKE avec le modèle de déploiement déconnecté ou unifié, consultez le guide par étapes du déploiement dans GKE.

Étape suivante