Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Faire évoluer les charges de travail GKE vers et depuis zéro à l'aide de AHP

Autopilot Standard

Ce tutoriel vous explique comment optimiser l'utilisation des ressources dans Google Kubernetes Engine (GKE) en configurant les charges de travail pour qu'elles passent automatiquement à zéro réplica lorsqu'elles sont inactives et qu'elles repassent à l'échelle supérieure lorsque la demande augmente. Cette approche intègre l'autoscaler horizontal de pods (AHP) à l'infrastructure d'autoscaling gérée de GKE pour gérer le scaling en fonction de métriques externes.

Configurez votre déploiement pour qu'il passe à zéro en définissant la valeur du champ minReplicas sur 0 et en définissant une métrique de type External ou Object dans votre fichier manifeste AHP. GKE surveille ces métriques à l'aide de la ressource personnalisée AutoscalingMetric, qui permet d'assurer une gestion efficace des ressources pour vos applications.

Avec cette configuration, vous n'avez pas besoin d'utiliser d'adaptateurs de métriques tiers, tels que KEDA, pour mettre à l'échelle les charges de travail GKE. Cette solution gère l'ingestion de métriques et les recommandations de scaling directement dans le plan de contrôle GKE, ce qui réduit la surcharge de gestion des clusters.

Dans ce tutoriel, vous allez déployer un exemple d'application de nœud de calcul asynchrone qui traite les messages d'une file d'attente Pub/Sub. Vous configurez un autoscaler horizontal de pods pour surveiller la profondeur de la file d'attente (pubsub.googleapis.com:num_undelivered_messages) à l'aide d'une ressource personnalisée AutoscalingMetric :

Lorsque des messages arrivent dans l'abonnement : GKE augmente le nombre de pods de nœuds de calcul pour traiter la file d'attente.
Lorsque la file d'attente est vide : GKE réduit automatiquement le nombre de répliques du déploiement de nœuds de calcul à zéro.

Ce tutoriel s'adresse aux développeurs d'applications, aux administrateurs et opérateurs de plate-forme, ainsi qu'aux professionnels DevOps qui souhaitent optimiser l'utilisation des ressources dans GKE en mettant à l'échelle les charges de travail sur zéro lorsqu'elles sont inactives.

Remarques

Avant de configurer les charges de travail pour qu'elles soient mises à l'échelle à zéro, tenez compte des points suivants :

Pour mettre à l'échelle les charges de travail vers et depuis zéro à l'aide de AHP, le plan de contrôle et les nœuds du cluster GKE doivent exécuter la version 1.37 ou ultérieure dans les clusters nouveaux et existants mis à niveau. Si vous utilisez un cluster existant, vérifiez sa version ou mettez à niveau votre cluster ou ses nœuds vers la version 1.37 ou ultérieure.
Votre fichier manifeste HPA doit utiliser la configuration apiVersion: autoscaling/v2 pour prendre en charge le paramètre minReplicas: 0 et les métriques externes.
Avant de rétrograder des pools de nœuds vers une version antérieure à 1.37, mettez à jour tous les fichiers manifestes AHP configurés pour effectuer un scaling de zéro à un nombre supérieur ou inversement en définissant le champ minReplicas sur 1 ou une valeur supérieure. Les versions antérieures à 1.37 ne sont pas compatibles avec le paramètre minReplicas: 0, ce qui peut entraîner le blocage des charges de travail à zéro réplica.
Vous devez configurer au moins une métrique External ou Object (telle que la profondeur de la file d'attente) dans votre autoscaler horizontal de pods. GKE ne peut pas collecter de métriques sur le processeur ou la mémoire (Resource) lorsqu'une charge de travail ne comporte aucun pod. Par conséquent, les métriques sur les ressources seules ne peuvent pas déclencher un scaling à la hausse à partir de zéro.
AutoscalingMetric, HorizontalPodAutoscaler et le déploiement cible doivent résider dans le même espace de noms Kubernetes.

Avant de commencer

Installez la Google Cloud CLI.
Configurez la gcloud CLI afin d'utiliser votre identité fédérée.

Pour en savoir plus, consultez Se connecter à la gcloud CLI avec votre identité fédérée.
Pour initialiser la gcloud CLI, exécutez la commande suivante :
```
gcloud init
```
Créez ou sélectionnez un projet Google Cloud .
Rôles requis pour sélectionner ou créer un projet
- Sélectionnez un projet : la sélection d'un projet ne nécessite pas de rôle IAM spécifique. Vous pouvez sélectionner n'importe quel projet pour lequel un rôle vous a été attribué.
- Créer un projet : pour créer un projet, vous devez disposer du rôle Créateur de projet (roles/resourcemanager.projectCreator), qui contient l'autorisation resourcemanager.projects.create. Découvrez comment attribuer des rôles.
Remarque : Si vous ne comptez pas conserver les ressources créées dans cette procédure, créez un projet au lieu de sélectionner un projet existant. Après avoir suivi ces étapes, vous pouvez supprimer le projet. Cela entraîne la suppression de toutes les ressources qui lui sont associées.
- Créez un projet Google Cloud :
```
gcloud projects create PROJECT_ID
```
  Remplacez PROJECT_ID par le nom du projet Google Cloud que vous créez.
- Sélectionnez le projet Google Cloud que vous avez créé :
```
gcloud config set project PROJECT_ID
```
  Remplacez PROJECT_ID par le nom de votre projet Google Cloud .
Vérifiez que la facturation est activée pour votre projet Google Cloud .
Activez les API GKE et Pub/Sub :
Rôles requis pour activer les API
Pour activer les API, vous devez disposer de l'autorisation serviceusage.services.enable. Si vous avez créé le projet, vous disposez probablement déjà de cette autorisation grâce au rôle Propriétaire (roles/owner). Sinon, vous pouvez obtenir cette autorisation grâce au rôle Administrateur Service Usage (roles/serviceusage.serviceUsageAdmin). Découvrez comment attribuer des rôles.
```
gcloud services enable container.googleapis.com pubsub.googleapis.com
```

Rôles requis

Pour obtenir les autorisations nécessaires pour suivre ce tutoriel, demandez à votre administrateur de vous accorder les rôles IAM suivants sur votre projet :

Administrateur de cluster GKE (roles/container.clusterAdmin)
Administrateur Pub/Sub (roles/pubsub.admin)
Administrateur de projet IAM (roles/resourcemanager.projectIamAdmin)
Utilisateur du compte de service (roles/iam.serviceAccountUser)

Pour en savoir plus sur l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises avec des rôles personnalisés ou d'autres rôles prédéfinis.

Configurer votre environnement

Pour plus de simplicité, les commandes de ce tutoriel créent toutes les ressources (le cluster GKE, ainsi que le sujet et l'abonnement Pub/Sub) dans un seul projet Google Cloud (PROJECT_ID).

Pour configurer votre environnement, procédez comme suit :

Définissez les variables d'environnement :
```
export PROJECT_ID=PROJECT_ID
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format 'get(projectNumber)')
export LOCATION=LOCATION
```
Remplacez les éléments suivants :
- PROJECT_ID : ID de votre projet Google Cloud.
- LOCATION : région ou zone dans laquelle vous souhaitez créer votre cluster GKE, par exemple us-central1. Pour les clusters Autopilot, spécifiez une région.
Remarque : Ces variables d'environnement sont utilisées tout au long de ce tutoriel. Si vous ouvrez une nouvelle session de shell ou si vous vous déconnectez, exécutez à nouveau ces commandes pour définir les variables.
Créez un cluster GKE exécutant la version 1.37 ou ultérieure avec la Workload Identity Federation for GKE activée. Nous vous recommandons d'utiliser un cluster Autopilot pour une expérience Kubernetes entièrement gérée et pour maximiser les économies lorsque les charges de travail sont mises à l'échelle sur zéro. Pour choisir le mode de fonctionnement le mieux adapté à vos charges de travail, consultez Choisir un mode de fonctionnement GKE :
Autopilot
Créez un cluster Autopilot :
gcloud container clusters create-auto scale-to-zero \ --project=${PROJECT_ID} \ --location=${LOCATION}
La fédération d'identité de charge de travail pour GKE est activée par défaut sur les clusters Autopilot.
Standard
Créez un cluster Standard avec Workload Identity Federation for GKE activée :
gcloud container clusters create scale-to-zero \ --project=${PROJECT_ID} \ --location=${LOCATION} \ --workload-pool=${PROJECT_ID}.

Configurez kubectl de manière à communiquer avec votre cluster :

gcloud container clusters get-credentials scale-to-zero \
    --project=${PROJECT_ID} \
    --location=${LOCATION}

Créer les ressources Pub/Sub

Ce tutoriel utilise la profondeur de la file d'attente Pub/Sub comme exemple de source de métriques externes.

Pour créer un sujet et un abonnement Pub/Sub, procédez comme suit :

Créez un sujet Pub/Sub

gcloud pubsub topics create my-worker-topic \
    --project=${PROJECT_ID}

Créez un abonnement associé au sujet :

gcloud pubsub subscriptions create my-worker-subscription \
    --topic=my-worker-topic \
    --project=${PROJECT_ID}

Configurer Workload Identity Federation for GKE

Configurez Workload Identity Federation for GKE afin de permettre à votre application de nœud de calcul de s'authentifier auprès des API Google Cloud et de consommer des messages depuis Pub/Sub.

GKE gère automatiquement l'authentification avec Cloud Monitoring pour les ressources AutoscalingMetric du même projet. Pour en savoir plus sur la définition des métriques pour l'autoscaling, consultez Récupérer des métriques personnalisées ou externes à partir de Cloud Monitoring.

Pour configurer Workload Identity Federation for GKE pour votre charge de travail de nœud de calcul, procédez comme suit :

Créez un compte de service Kubernetes pour votre application de nœud de calcul dans l'espace de noms default :
```
kubectl create serviceaccount async-worker-sa \
    --namespace default
```

Attribuez le rôle roles/pubsub.subscriber au compte de service Kubernetes afin que l'application puisse recevoir des messages de votre abonnement Pub/Sub :

gcloud projects add-iam-policy-binding projects/${PROJECT_ID} \
    --role=roles/pubsub.subscriber \
    --member=principal://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/${PROJECT_ID}./subject/ns/default/sa/async-worker-sa

Pour en savoir plus, consultez Configurer des applications pour qu'elles utilisent la fédération d'identité de charge de travail pour GKE.

Créer l'exemple de déploiement

Avant de pouvoir créer un objet AHP, vous devez créer la charge de travail qu'il surveillera.

Pour créer l'exemple de déploiement, procédez comme suit :

Enregistrez le manifeste suivant sous le nom async-worker.yaml :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: async-worker
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: async-worker
  template:
    metadata:
      labels:
        app: async-worker
    spec:
      containers:
      - name: async-worker
        image: nginx:latest
        ports:
        - containerPort: 80
        resources:
          limits:
            memory: 100Mi
          requests:
            cpu: 50m
            memory: 100Mi

Appliquez le déploiement async-worker.yaml :
```
kubectl apply -f async-worker.yaml
```

Configurer une charge de travail pour qu'elle passe de zéro à une valeur donnée et inversement

Dans cette section, vous allez configurer le déploiement async-worker pour qu'il soit réduit à zéro lorsque la file d'attente Pub/Sub est vide, et qu'il soit de nouveau augmenté lorsque de nouveaux messages arrivent.

Créer la ressource AutoscalingMetric

Pour définir le signal externe surveillé par GKE, créez la ressource personnalisée AutoscalingMetric. Dans l'exemple de fichier manifeste suivant, la métrique interroge Cloud Monitoring pour obtenir le nombre de messages Pub/Sub non distribués dans l'abonnement my-worker-subscription.

Pour créer la ressource AutoscalingMetric, procédez comme suit :

Enregistrez le fichier manifeste suivant sous le nom pubsub-metric.yaml :

apiVersion: autoscaling.gke.io/v1beta1
kind: AutoscalingMetric
metadata:
  name: pubsub-queue-depth
  namespace: default
spec:
  metrics:
  - promql:
      name: pubsub-undelivered
      query: >
          {
            "pubsub.googleapis.com/subscription/num_undelivered_messages",
            subscription_id="my-worker-subscription"
          }

Appliquez le fichier manifeste pubsub-metric.yaml :
```
kubectl apply -f pubsub-metric.yaml
```
Vérifiez l'état de la métrique et récupérez son identifiant :
```
kubectl describe autoscalingmetric pubsub-queue-depth
```
Dans la section Status du résultat, vérifiez qu'aucune erreur n'est listée et notez la valeur Hpa Name au format autoscaling.gke.io|CUSTOM_RESOURCE_NAME|METRIC_NAME. Vous ferez référence à cet identifiant de métrique externe lorsque vous créerez l'objet HorizontalPodAutoscaler dans la section suivante. Si la section Status signale des erreurs de configuration ou si les métriques ne sont pas récupérées comme prévu, consultez Résoudre les problèmes liés aux métriques récupérées pour le scaling automatique.

Configurer l'autoscaler horizontal des pods

Pour configurer le comportement de l'autoscaling, créez une ressource HorizontalPodAutoscaler ciblant le déploiement.

Pour configurer l'autoscaler horizontal de pods, procédez comme suit :

Enregistrez le fichier manifeste suivant sous le nom worker-hpa.yaml :
```
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: async-worker-hpa
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: async-worker
  minReplicas: 0
  maxReplicas: 20
  metrics:
  - type: External
    external:
      metric:
        name: autoscaling.gke.io|pubsub-queue-depth|pubsub-undelivered
      target:
        type: AverageValue
        averageValue: "10"
```
Ce fichier manifeste configure les champs clés suivants :
- minReplicas: 0 : active le scaling à zéro instance en permettant au contrôleur de réduire le déploiement à 0 répliques lorsque la demande tombe à zéro.
- type: External : configure une source de métrique externe afin que l'AHP puisse déclencher le scale-up lorsque la charge de travail ne comporte aucun pod.
- name: autoscaling.gke.io|pubsub-queue-depth|pubsub-undelivered : mappe le AHP directement à la ressource AutoscalingMetric créée à l'étape précédente en utilisant le format d'identifiant autoscaling.gke.io|CUSTOM_RESOURCE_NAME|METRIC_NAME.
Appliquez le fichier manifeste worker-hpa.yaml :
```
kubectl apply -f worker-hpa.yaml
```

Vérifier le comportement et les conditions de mise à l'échelle à zéro

Lorsque tous les messages de l'abonnement Pub/Sub sont traités, l'autoscaler horizontal de pods évalue la demande nulle et réduit le déploiement à 0 répliques.

Pour vérifier que l'autoscaler horizontal de pods a activé l'état zéro, inspectez les conditions d'état de la ressource async-worker-hpa en exécutant la commande suivante :

kubectl describe hpa async-worker-hpa

Le résultat ressemble à ce qui suit :

Name:             async-worker-hpa
Namespace:        default
Reference:        Deployment/async-worker
Metrics:          ( current / target )
  "autoscaling.gke.io|pubsub-queue-depth|pubsub-undelivered" (external metric):  0 / 10
Min replicas:     0
Max replicas:     20
Deployment pods:  0 current / 0 desired
Conditions:
  Type            Status  Reason               Message
  ----            ------  ------               -------
  AbleToScale     True    SucceededGetScale    the HPA controller was able to get the target's current scale
  ScalingActive   True    ValidMetricFound     the HPA was able to successfully calculate a replica count from external metric
  ScaledToZero    True    ScaledToZero         the HPA has scaled the target resource to 0 replicas due to zero metric demand

Comprendre la condition `ScaledToZero`

La condition ScaledToZero indique si l'autoscaler horizontal de pods a mis à l'échelle la charge de travail à zéro réplica :

ScaledToZero: True (Reason: ScaledToZero) : indique que le contrôleur AHP a correctement mis à l'échelle votre charge de travail à 0 répliques, car la demande de métriques externes est tombée à zéro. Le HPA reste actif (ScalingActive: True) et interroge en permanence GKE pour détecter quand la demande de charge de travail augmente.
ScaledToZero: False : indique que la charge de travail a été mise à l'échelle sur une ou plusieurs répliques.

Si vous mettez manuellement à l'échelle un déploiement à zéro réplique, par exemple avec la commande kubectl scale --replicas=0, le AHP met en veille l'autoscaling (ScalingActive: False) pour éviter les modifications conflictuelles. Pour reprendre l'autoscaling, redimensionnez le déploiement à une ou plusieurs répliques (kubectl scale deployment async-worker --replicas=1).

Pour résoudre les problèmes de scaling à zéro ou à la hausse des charges de travail, consultez Résoudre les problèmes de scaling à zéro et à la hausse des charges de travail GKE à l'aide de HPA. Si l'autoscaler horizontal de pods signale des métriques externes manquantes ou non valides, consultez Résoudre les problèmes liés aux métriques récupérées pour l'autoscaling.

Effectuer un nettoyage

Pour éviter que les ressources utilisées dans ce tutoriel ne soient facturées sur votre compte Google Cloud , procédez comme suit :

Supprimez le cluster GKE :

gcloud container clusters delete scale-to-zero \
    --project=${PROJECT_ID} \
    --location=${LOCATION}

Supprimez l'abonnement et le sujet Pub/Sub :

gcloud pubsub subscriptions delete my-worker-subscription \
    --project=${PROJECT_ID}
gcloud pubsub topics delete my-worker-topic \
    --project=${PROJECT_ID}

Étapes suivantes

Découvrez comment atténuer la latence de démarrage à froid à l'aide des tampons de capacité GKE.
Découvrez comment diagnostiquer les problèmes de scaling lorsque vous passez à zéro et inversement à l'aide du HPA.