Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Scaling à zéro instance avec KEDA

Standard

Ce tutoriel explique comment réduire vos charges de travail GKE à zéro pod à l'aide de KEDA. Le scaling des déploiements à zéro pod permet d'économiser des ressources pendant les périodes d'inactivité (comme les week-ends et les heures non ouvrées) ou pour les charges de travail intermittentes telles que les jobs périodiques.

Objectifs

Ce tutoriel décrit les cas d'utilisation suivants :

Réduire votre charge de travail Pub/Sub à zéro: faites évoluer le nombre de pods en proportion du nombre de messages mis en file d'attente sur le sujet Pub/Sub. Lorsque la file d'attente est vide, la charge de travail est automatiquement réduite à zéro pod.
Réduire votre charge de travail LLM à zéro. Déployez vos serveurs de modèles LLM sur des nœuds avec GPU. Lorsque le service est inactif, la charge de travail est automatiquement réduite à zéro pod.

Coûts

Dans ce document, vous utilisez les composants payants suivants de Google Cloud:

GKE
GPU resources used by GKE
Pub/Sub

Obtenez une estimation des coûts en fonction de votre utilisation prévue, utilisez le simulateur de coût.

Les nouveaux utilisateurs de peuvent bénéficier d'un essai sans frais. Google Cloud

Une fois que vous avez terminé les tâches décrites dans ce document, supprimez les ressources que vous avez créées pour éviter que des frais vous soient facturés. Pour en savoir plus, consultez la section Effectuer un nettoyage.

Avant de commencer

Dans ce tutoriel, vous utilisez Cloud Shell pour exécuter des commandes. Cloud Shell est un environnement shell permettant de gérer les ressources hébergées sur Google Cloud. Il est doté des outils de ligne de commande préinstallés suivants : Google Cloud CLI, kubectl, Helm et Terraform. Si vous n'utilisez pas Cloud Shell, vous devez installer Google Cloud CLI et Helm.

Pour exécuter les commandes sur cette page, configurez gcloud CLI dans l'un des environnements de développement suivants :
Cloud Shell

Pour utiliser un terminal en ligne avec gcloud CLI déjà configuré, activez Cloud Shell :

En bas de la page, une session Cloud Shell démarre et affiche une invite de ligne de commande. L'initialisation de la session peut prendre quelques secondes.
Shell local

Pour utiliser un environnement de développement local, procédez comme suit :

Connectez-vous à votre Google Cloud compte. Si vous débutez avec Google Cloud, créez un compte pour évaluer les performances de nos produits dans des scénarios réels. Les nouveaux clients bénéficient également de 300 $ de crédits sans frais pour exécuter, tester et déployer des charges de travail.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Resource Manager, Compute Engine, GKE, Pub/Sub APIs.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the APIs

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Resource Manager, Compute Engine, GKE, Pub/Sub APIs.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the APIs

Configurer votre environnement

Pour configurer votre environnement avec Cloud Shell, 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 PROJECT_ID par votre Google Cloud ID de projet et LOCATION par les régions ou zones dans lesquelles votre cluster GKE doit être créé.

Remarque : Pour déployer une charge de travail Ollama, choisissez un emplacement compatible avec le type de machine g2-standard-4. Pour en savoir plus, consultez la section Régions et zones disponibles.

Si vous ne suivez pas l'intégralité du tutoriel en une seule session ou si vos variables d'environnement ne sont pas définies pour une raison quelconque, veillez à exécuter à nouveau cette commande pour définir à nouveau les variables.

Créez un cluster GKE standard avec l'autoscaling de cluster et la fédération d'identité de charge de travail pour GKE activés :

gcloud container clusters create scale-to-zero \
    --project=${PROJECT_ID} --location=${LOCATION} \
    --machine-type=n1-standard-2 \
    --enable-autoscaling --min-nodes=1 --max-nodes=5 \
    --workload-pool=${PROJECT_ID}.svc.id.goog

Installer KEDA

KEDA est un composant qui complète l'autoscaler horizontal de pods Kubernetes. Avec KEDA, vous pouvez réduire un déploiement à zéro pod et l'augmenter de zéro à un pod. Un déploiement est un objet d'API Kubernetes qui vous permet d'exécuter plusieurs instances dupliquées de pods répartis entre les nœuds d'un cluster. L'algorithme standard de l'autoscaler horizontal de pods s'applique une fois que GKE a créé au moins un pod.

Une fois que GKE a réduit le déploiement à zéro pod, l'autoscaling ne peut pas s'appuyer sur des métriques de pod telles que l'utilisation du processeur, car aucun pod n'est en cours d'exécution. Par conséquent, KEDA permet d'extraire des métriques provenant de l'extérieur du cluster à l'aide d'une implémentation de l'API Kubernetes External Metrics. Vous pouvez utiliser cette API pour effectuer un autoscaling en fonction de métriques telles que le nombre de messages en attente dans un abonnement Pub/Sub. Consultez la documentation KEDA pour obtenir la liste de toutes les sources de métriques compatibles.

Installez KEDA sur votre cluster avec Helm ou kubectl.

Helm

Exécutez les commandes suivantes pour ajouter le dépôt Helm KEDA, installer le chart Helm KEDA et accorder au compte de service KEDA un accès en lecture à Cloud Monitoring :

helm repo add kedacore https://kedacore.github.io/charts
helm repo update
helm install keda kedacore/keda --create-namespace --namespace keda

gcloud projects add-iam-policy-binding projects/${PROJECT_ID} \
     --role roles/monitoring.viewer \
     --member=principal://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/${PROJECT_ID}.svc.id.goog/subject/ns/keda/sa/keda-operator

Notez que cette commande configure également des règles d'autorisation qui nécessitent que le cluster soit configuré avec Workload Identity Federation for GKE.

`kubectl`

Exécutez les commandes suivantes pour installer KEDA à l'aide de kubectl apply et accorder au compte de service KEDA un accès en lecture à Cloud Monitoring :

kubectl apply --server-side  -f https://github.com/kedacore/keda/releases/download/v2.15.1/keda-2.15.1.yaml

gcloud projects add-iam-policy-binding projects/${PROJECT_ID} \
     --role roles/monitoring.viewer \
     --member=principal://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/${PROJECT_ID}.svc.id.goog/subject/ns/keda/sa/keda-operator

Notez que cette commande configure également des règles d'autorisation qui nécessitent que le cluster soit configuré avec Workload Identity Federation for GKE.

Vérifiez que toutes les ressources KEDA s'affichent sous l'espace de noms keda :

kubectl get all -n keda

Pour en savoir plus sur la conception et les ressources KEDA, consultez la documentation KEDA.

Réduire votre charge de travail Pub/Sub à zéro

Cette section décrit une charge de travail qui traite les messages d'un abonnement Pub/Sub, en gérant chaque message et en accusant réception de sa finalisation. La charge de travail évolue de manière dynamique : à mesure que le nombre de messages non reconnus augmente, l'autoscaling instancie davantage de pods pour garantir un traitement rapide.

Le scaling à zéro garantit qu'aucun pod n'est instancié lorsqu'aucun message n'a été reçu depuis un certain temps. Cela permet d'économiser des ressources, car aucun pod ne reste inactif pendant de longues périodes.

Déployer une charge de travail Pub/Sub

Déployez un exemple de charge de travail qui traite les messages mis en file d'attente sur un sujet Pub/Sub. Pour simuler une charge de travail réaliste, cet exemple de programme attend trois secondes avant d'accuser réception d'un message. La charge de travail est configurée pour s'exécuter sous le compte de service keda-pubsub-sa.

Exécutez les commandes suivantes pour créer le sujet et l'abonnement Pub/Sub, configurer leurs autorisations et créer le déploiement en démarrant la charge de travail sous l'espace de noms keda-pubsub.

gcloud pubsub topics create keda-echo
gcloud pubsub subscriptions create keda-echo-read --topic=keda-echo
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}.svc.id.goog/subject/ns/keda-pubsub/sa/keda-pubsub-sa

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/kubernetes-engine-samples/refs/heads/main/cost-optimization/gke-keda/cloud-pubsub/deployment/keda-pubsub-with-workload-identity.yaml

Configurer le scaling à zéro instance

Pour configurer votre charge de travail Pub/Sub afin qu'elle soit réduite à zéro, utilisez KEDA pour définir une ressource ScaledObject afin de spécifier comment le déploiement doit être mis à l'échelle. KEDA crée et gère ensuite automatiquement l'objet HorizontalPodAutoscaler (AHP) sous-jacent.

Créez la ressource ScaledObject pour décrire le comportement d'autoscaling attendu :

curl https://raw.githubusercontent.com/GoogleCloudPlatform/kubernetes-engine-samples/refs/heads/main/cost-optimization/gke-keda/cloud-pubsub/deployment/keda-pubsub-scaledobject.yaml | envsubst | kubectl apply -f -

Cela crée l'objet suivant :

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: keda-pubsub
  namespace: keda-pubsub
spec:
  maxReplicaCount: 5
  scaleTargetRef:
    name: keda-pubsub
  triggers:
    - type: gcp-pubsub
      authenticationRef:
        name: keda-auth
      metadata:
        subscriptionName: "projects/${PROJECT_ID}/subscriptions/keda-echo-read"

Inspectez l'objet HorizontalPodAutoscaler (AHP) que KEDA crée en fonction de l'objet ScaledObject :
```
kubectl get hpa keda-hpa-keda-pubsub -n keda-pubsub -o yaml
```
Remarque : Même si le champ minReplicas n'est pas défini sur zéro, KEDA le remplace en supprimant tous les pods du déploiement cible lors du scaling à zéro.

Pour en savoir plus sur l'autoscaling, consultez la documentation Kubernetes.

Attendez que KEDA confirme que l'abonnement Pub/Sub est vide et réduise le déploiement à zéro instance dupliquée.

Inspectez l'autoscaler de charge de travail :

kubectl describe hpa keda-hpa-keda-pubsub -n keda-pubsub

Notez que dans la réponse de la commande, la condition ScalingActive est définie sur "false". Le message associé indique que l'autoscaler horizontal de pods reconnaît que KEDA a réduit le déploiement à zéro, après quoi il cesse de fonctionner jusqu'à ce que le déploiement soit de nouveau mis à l'échelle sur un pod.

Name:                                                  keda-hpa-keda-pubsub
Namespace:                                             keda-pubsub
Metrics:                                               ( current / target )
  "s0-gcp-ps-projects-[...]]" (target average value):  0 / 10
Min replicas:                                          1
Max replicas:                                          5
Deployment pods:                                       5 current / 5 desired
Conditions:
  Type            Status  Reason               Message
  ----            ------  ------               -------
  AbleToScale     True    ScaleDownStabilized  recent recommendations were higher than current one [...]
  ScalingActive   False   ScalingDisabled      scaling is disabled since the replica count of the target is zero
  ScalingLimited  True    TooManyReplicas      the desired replica count is more than the maximum replica count

Déclencher le scaling à la hausse

Pour stimuler le scaling à la hausse du déploiement :

Mettez en file d'attente des messages sur le sujet Pub/Sub :

for num in {1..20}
do
  gcloud pubsub topics publish keda-echo --project=${PROJECT_ID} --message="Test"
done

Vérifiez que le déploiement est mis à l'échelle :

kubectl get deployments -n keda-pubsub

Dans le résultat, notez que la colonne "Prêt" affiche une instance dupliquée :

NAME          READY   UP-TO-DATE   AVAILABLE   AGE
keda-pubsub   1/1     1            1           2d

KEDA met à l'échelle le déploiement après avoir constaté que la file d'attente n'est pas vide.

Réduire votre charge de travail LLM à zéro

Cette section décrit une charge de travail de grand modèle de langage (LLM) qui déploie un serveur Ollama avec un GPU associé. Ollama permet d'exécuter des LLM populaires tels que Gemma et Llama 2, et expose ses fonctionnalités principalement via HTTP.

Installer le module complémentaire KEDA-HTTP

La réduction d'un service HTTP à zéro pod pendant les périodes d'inactivité entraîne des échecs de requêtes, car aucun backend ne peut les gérer.

Cette section explique comment résoudre ce problème à l'aide du module complémentaire KEDA-HTTP. KEDA-HTTP démarre un proxy HTTP qui reçoit les requêtes des utilisateurs et les transmet aux services configurés pour le scaling à zéro instance. Lorsque le service ne comporte aucun pod, le proxy déclenche le scaling à la hausse du service et met en mémoire tampon la requête jusqu'à ce que le service soit mis à l'échelle sur au moins un pod.

Installez le module complémentaire KEDA-HTTP à l'aide de Helm. Pour en savoir plus, consultez la documentation KEDA-HTTP.

helm repo add ollama-helm https://otwld.github.io/ollama-helm/
helm repo update

# Set the proxy timeout to 120s, giving Ollama time to start.
helm install http-add-on kedacore/keda-add-ons-http  \
  --create-namespace --namespace keda \
  --set interceptor.responseHeaderTimeout=120s

Déployer une charge de travail LLM Ollama

Pour déployer une charge de travail LLM Ollama :

Créez un pool de nœuds contenant des nœuds g2-standard-4 avec des GPU associés, et configurez l'autoscaling de cluster pour fournir entre zéro et deux nœuds :
```
gcloud container node-pools create gpu --machine-type=g2-standard-4 \
    --location=${LOCATION} --cluster=scale-to-zero \
    --min-nodes 0 --max-nodes 2 --num-nodes=1 --enable-autoscaling
```
Remarque : Votre emplacement doit être compatible avec le type de machine g2-standard-4. Pour en savoir plus, consultez la section Régions et zones disponibles.
Ajoutez le dépôt officiel du chart Helm Ollama et mettez à jour le dépôt de votre client Helm local :
```
helm repo add ollama-helm https://otwld.github.io/ollama-helm/
helm repo update
```

Déployez le serveur Ollama à l'aide du chart Helm :

helm install ollama ollama-helm/ollama --create-namespace --namespace ollama \
  -f https://raw.githubusercontent.com/GoogleCloudPlatform/kubernetes-engine-samples/refs/heads/main/cost-optimization/gke-keda/ollama/helm-values-ollama.yaml

La configuration helm-values-ollama.yaml spécifie les modèles LLM à charger, les exigences en matière de GPU et le port TCP du serveur Ollama.

Configurer le scaling à zéro instance

Pour configurer votre charge de travail Ollama afin qu'elle soit réduite à zéro, KEDA-HTTP utilise un HTTPScaledObject.

Créez la ressource HTTPScaledObject pour décrire le comportement d'autoscaling attendu :

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/kubernetes-engine-samples/refs/heads/main/cost-optimization/gke-keda/ollama/keda-ollama-httpscaledobject.yaml

Cela crée l'objet HTTPScaledObject qui définit les champs suivants :

scaleTargetRef: spécifie le service auquel KEDA-HTTP doit transférer les requêtes. Dans cet exemple, toutes les requêtes avec l'hôte ollama.ollama sont acheminées vers le serveur Ollama.
scaledownPeriod: spécifie (en secondes) la vitesse de réduction lorsque aucune requête n'est reçue.
replicas: spécifie le nombre minimal et maximal de pods à maintenir pour le déploiement Ollama.
scalingMetric: spécifie les métriques utilisées pour l'autoscaling, telles que le taux de demandes dans cet exemple. Pour plus d'options de métriques, consultez la documentation KEDA-HTTP.

kind: HTTPScaledObject
apiVersion: http.keda.sh/v1alpha1
metadata:
    namespace: ollama
    name: ollama
spec:
    hosts:
    - ollama.ollama
    scaleTargetRef:
        name: ollama
        kind: Deployment
        apiVersion: apps/v1
        service: ollama
        port: 11434
    replicas:
        min: 0
        max: 2
    scaledownPeriod: 3600
    scalingMetric:
        requestRate:
            targetValue: 20

Exécutez la commande suivante pour vérifier que KEDA-HTTP a bien traité l'HTTPScaledObject créé à l'étape précédente :

kubectl get hpa,scaledobject -n ollama

Le résultat affiche les ressources HorizontalPodAutoscaler (créées par KEDA) et ScaledObject (créées par KEDA-HTTP) :

NAME                                                  REFERENCE           TARGETS       MINPODS   MAXPODS   REPLICAS   AGE
horizontalpodautoscaler.autoscaling/keda-hpa-ollama   Deployment/ollama   0/100 (avg)   1         2         1          2d

NAME                          SCALETARGETKIND      SCALETARGETNAME   MIN   MAX   TRIGGERS        AUTHENTICATION   READY   ACTIVE   FALLBACK   PAUSED    AGE
scaledobject.keda.sh/ollama   apps/v1.Deployment   ollama            0     2     external-push                    True    False    False      Unknown   2d

Vérifiez que le déploiement est réduit à zéro pod.

Attendez la période définie dans le champ scaledownPeriod et exécutez la commande :
```
kubectl get deployments -n ollama
```
Le résultat indique que KEDA a réduit le déploiement Ollama et qu'aucun pod n'est en cours d'exécution :
```
NAME     READY   UP-TO-DATE   AVAILABLE   AGE
ollama   0/0     0            0           2d
```

Déclencher le scaling à la hausse

Pour stimuler le scaling à la hausse du déploiement, appelez le service Ollama à l'aide du proxy configuré par le module complémentaire KEDA-HTTP. Cela augmente la valeur de la métrique taux de demandes et déclenche la création d'un premier pod.

Utilisez les fonctionnalités de transfert de port kubectl pour accéder au proxy, car il n'est pas exposé en externe.

kubectl port-forward svc/keda-add-ons-http-interceptor-proxy -n keda 8080:8080 &

# Set the 'Host' HTTP header so that the proxy routes requests to the Ollama server.
curl -H "Host: ollama.ollama" \
  http://localhost:8080/api/generate \
  -d '{ "model": "gemma:7b", "prompt": "Hello!" }'

La commande curl envoie l'invite "Hello!" à un modèle Gemma. Observez les jetons de réponse qui reviennent dans la réponse. Pour connaître la spécification de l'API, consultez le guide Ollama.

Libérer de l'espace

Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet et supprimez les ressources individuelles.

Nettoyez l'abonnement et le sujet Pub/Sub :

gcloud pubsub subscriptions delete keda-echo-read
gcloud pubsub topics delete keda-echo

Supprimez le cluster GKE :

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

Étape suivante

En savoir plus sur l'autoscaling des charges de travail d'inférence LLM dans GKE.
Explorez le dépôt GitHub et la documentation KEDA.

Scaling à zéro instance avec KEDA Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Objectifs

Coûts

Avant de commencer

Cloud Shell

Shell local

Configurer votre environnement

Installer KEDA

Helm

kubectl

Réduire votre charge de travail Pub/Sub à zéro

Déployer une charge de travail Pub/Sub

Configurer le scaling à zéro instance

Déclencher le scaling à la hausse

Réduire votre charge de travail LLM à zéro

Installer le module complémentaire KEDA-HTTP

Déployer une charge de travail LLM Ollama

Configurer le scaling à zéro instance

Déclencher le scaling à la hausse

Libérer de l'espace

Étape suivante

Scaling à zéro instance avec KEDA

`kubectl`