Contrôler les attributs de nœud avec autoscaling à l'aide de ComputeClasses personnalisées

Ce document explique comment contrôler l'infrastructure de calcul et le comportement d'autoscaling des clusters Google Kubernetes Engine (GKE) en fonction des besoins spécifiques de vos charges de travail à l'aide de ComputeClasses personnalisées.

Ce document s'adresse aux administrateurs de plate-forme qui souhaitent définir de manière déclarative des profils d'autoscaling pour les nœuds, et aux opérateurs de cluster qui souhaitent exécuter leurs charges de travail sur des ComputeClasses spécifiques.

À propos des ComputeClasses personnalisées

Les ComputeClasses personnalisées sont des ressources personnalisées Kubernetes qui vous permettent de définir des priorités que GKE doit suivre lors du provisionnement de nœuds pour exécuter vos charges de travail. Vous pouvez utiliser une ComputeClass personnalisée pour effectuer les opérations suivantes :

  • Fournissez à GKE un ensemble de priorités à suivre séquentiellement lors du provisionnement des nœuds, chacun avec des paramètres spécifiques tels qu'une série de machines Compute Engine ou une capacité de ressources minimale.
  • Définissez des seuils et des paramètres d'autoscaling pour supprimer les nœuds sous-utilisés et consolider efficacement les charges de travail sur la capacité de calcul existante.
  • Indiquez à GKE de remplacer automatiquement les configurations de nœuds "moins préférées" par des configurations de nœuds "plus préférées" pour des performances de charge de travail optimales.

Pour comprendre toutes les options de configuration et leur interaction entre elles, ainsi qu'avec les modes GKE Autopilot et GKE Standard, consultez À propos des ComputeClasses personnalisées.

Tarifs

La ressource personnalisée ComputeClass est fournie sans frais supplémentaires dans GKE. Les considérations tarifaires suivantes s'appliquent :

Limites

Le nom de votre ComputeClass ne peut pas commencer par gke ni autopilot.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
    • Activer l'API Google Kubernetes Engine
  • Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la commande gcloud components update. Il est possible que les versions antérieures de gcloud CLI ne permettent pas d'exécuter les commandes de ce document.
  • Assurez-vous de disposer d'un cluster GKE existant exécutant la version 1.30.3-gke.1451000 ou ultérieure. Pour en savoir plus, consultez Créer un cluster Autopilot.

  • Si vous utilisez un cluster en mode standard, assurez-vous de remplir l'une des conditions suivantes :

Exemple de scénario pour les ComputeClasses

Ce document présente un exemple de scénario pour lequel vous définissez une ComputeClass personnalisée. En pratique, vous devez tenir compte des exigences spécifiques de vos charges de travail et de votre organisation, et définir des ComputeClasses qui répondent à ces exigences. Pour obtenir une description complète de toutes les options de ComputeClasses et des considérations spéciales, consultez À propos des ComputeClasses personnalisées.

Considérons par exemple le scénario suivant :

  • Votre objectif est d'optimiser les coûts d'exécution de vos charges de travail.
  • Vos charges de travail sont tolérantes aux pannes et ne nécessitent pas d'arrêt progressif ni de durée d'exécution prolongée.
  • Vos charges de travail ont besoin d'au moins 64 vCPU pour fonctionner de manière optimale.
  • Vous êtes limité à la série de machines N4 de Compute Engine.

Sur la base de l'exemple de scénario, vous décidez que vous souhaitez une classe ComputeClass effectuant les opérations suivantes :

  • Priorise les nœuds Spot N4 disposant d'au moins 64 vCPU
  • Permet à GKE de revenir à n'importe quel nœud spot N4, quelle que soit la capacité de calcul
  • Si aucun nœud Spot N4 n'est disponible, autorise GKE à utiliser des nœuds N4 à la demande.
  • Indique à GKE de déplacer vos charges de travail vers des nœuds Spot dès qu'ils sont à nouveau disponibles.

Configurer une ComputeClass en mode Autopilot

Dans GKE Autopilot, vous définissez une ComputeClass, la déployez sur le cluster et interrogez cette ComputeClass dans vos charges de travail. GKE effectue pour vous toutes les étapes de configuration des nœuds, comme l'application de libellés et de rejets.

Enregistrez le manifeste suivant sous le nom compute-class.yaml :

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: cost-optimized
spec:
  priorities:
  - machineFamily: n4
    spot: true
    minCores: 64
  - machineFamily: n4
    spot: true
  - machineFamily: n4
    spot: false
  activeMigration:
    optimizeRulePriority: true
  nodePoolAutoCreation:
    enabled: true

Configurer une ComputeClass en mode Standard

Dans les clusters en mode Standard de GKE, vous devrez peut-être effectuer une configuration manuelle pour vous assurer que les pods de votre ComputeClass sont planifiés comme prévu. La configuration manuelle varie selon que vos pools de nœuds sont automatiquement créés ou non, comme suit :

Pour permettre à GKE de créer automatiquement des pools de nœuds pour votre ComputeClass, procédez comme suit :

  1. Pour les clusters en mode Standard qui exécutent une version antérieure à 1.33.3-gke.1136000 et qui ne sont pas enregistrés dans le version disponible rapide, activez le provisionnement automatique des nœuds au niveau du cluster.

  2. Enregistrez l'exemple de fichier manifeste suivant sous le nom compute-class.yaml :

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: cost-optimized
spec:
  priorities:
  - machineFamily: n4
    spot: true
    minCores: 64
  - machineFamily: n4
    spot: true
  - machineFamily: n4
    spot: false
  activeMigration:
    optimizeRulePriority: true
  nodePoolAutoCreation:
    enabled: true

    Lorsque vous déployez des pods qui nécessitent cette classe de calcul et que de nouveaux nœuds doivent être créés, GKE donne la priorité à la création de nœuds dans l'ordre des éléments du champ priorities. Si nécessaire, GKE crée des pools de nœuds qui répondent aux exigences matérielles de la ComputeClass.

Vous pouvez également spécifier un type de machine personnalisé précis dans vos priorités. L'utilisation de types de machines personnalisés nécessite GKE version 1.33.2-gke.1111000 ou ultérieure. L'exemple suivant configure une ComputeClass qui donne la priorité aux VM spot pour le type de machine personnalisé n4-custom-8-20480 et revient aux VM à la demande du même type si la capacité spot n'est pas disponible :

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: custom-machine-type
spec:
  priorities:
  - machineType: n4-custom-8-20480
    spot: true
  - machineType: n4-custom-8-20480
    spot: false
  nodePoolAutoCreation:
    enabled: true

Utiliser des ComputeClasses avec des pools de nœuds créés manuellement

Cette section explique comment définir une ComputeClass dans un cluster qui n'utilise que des pools de nœuds créés manuellement.

  1. Enregistrez le manifeste suivant sous le nom compute-class.yaml :

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: cost-optimized
spec:
  priorities:
  - machineFamily: n4
    spot: true
    minCores: 64
  - machineFamily: n4
    spot: true
  - machineFamily: n4
    spot: false
  activeMigration:
    optimizeRulePriority: true

  2. Créez un pool de nœuds avec autoscaling qui utilise des VM Spot et associez-le à la ComputeClass :

    gcloud container node-pools create cost-optimized-pool \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --machine-type=n4-standard-64 \
    --spot \
    --enable-autoscaling \
    --max-nodes=9 \
    --node-labels="cloud.google.com/compute-class=cost-optimized" \
    --node-taints="cloud.google.com/compute-class=cost-optimized:NoSchedule"

    Remplacez les éléments suivants :

    • LOCATION : emplacement de votre cluster.
    • CLUSTER_NAME : nom de votre cluster existant.

  3. Créez un pool de nœuds avec autoscaling avec des VM à la demande et associez-le à la ComputeClass :

    gcloud container node-pools create on-demand-pool \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --machine-type=n4-standard-64 \
    --enable-autoscaling \
    --max-nodes=9 \
    --num-nodes=0 \
    --node-labels="cloud.google.com/compute-class=cost-optimized" \
    --node-taints="cloud.google.com/compute-class=cost-optimized:NoSchedule"

Lorsque vous déployez des pods qui nécessitent cette ComputeClass et que de nouveaux nœuds doivent être créés, GKE donne la priorité à la création de nœuds dans le pool de nœuds cost-optimized-pool. Si de nouveaux nœuds ne peuvent pas être créés, GKE crée des nœuds dans le pool de nœuds on-demand-pool.

Pour en savoir plus sur la façon dont les pools de nœuds créés manuellement interagissent avec les ComputeClasses personnalisées, consultez Configurer des pools de nœuds créés manuellement pour une classe de calcul.

Personnaliser les seuils d'autoscaling pour la consolidation des nœuds

Par défaut, GKE supprime les nœuds sous-utilisés et replanifie vos charges de travail sur d'autres nœuds disponibles. Vous pouvez personnaliser davantage les seuils et le délai après lequel un nœud peut être supprimé à l'aide du champ autoscalingPolicy dans la définition ComputeClass, comme dans l'exemple suivant :

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: cost-optimized
spec:
  priorities:
  - machineFamily: n4
    spot: true
    minCores: 64
  - machineFamily: n4
    spot: true
  - machineFamily: n4
    spot: false
  activeMigration:
    optimizeRulePriority: true
  autoscalingPolicy:
    consolidationDelayMinutes : 5
    consolidationThreshold    : 70

Dans cet exemple, un nœud devient candidat à la suppression s'il est sous-utilisé à 70 % de sa capacité de processeur et de mémoire disponible pendant plus de cinq minutes. Pour obtenir la liste des paramètres disponibles, consultez Définir les paramètres d'autoscaling pour la consolidation des nœuds.

Déployer une ComputeClass dans un cluster

Après avoir défini une ComputeClass, déployez-la sur le cluster :

kubectl apply -f compute-class.yaml

Cette ComputeClass est prête à être utilisée dans le cluster. Vous pouvez demander la ComputeClass dans les spécifications du pod ou, éventuellement, la définir comme ComputeClass par défaut dans un espace de noms spécifique.

Demander une ComputeClass dans une charge de travail

Pour demander une ComputeClass dans une charge de travail, ajoutez un sélecteur de nœud pour cette ComputeClass dans votre fichier manifeste, comme dans les étapes suivantes :

  1. Enregistrez le manifeste suivant sous le nom cc-workload.yaml :

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: custom-workload
spec:
  replicas: 2
  selector:
    matchLabels:
      app: custom-workload
  template:
    metadata:
      labels:
        app: custom-workload
    spec:
      nodeSelector:
        cloud.google.com/compute-class: cost-optimized
      containers:
      - name: test
        image: gcr.io/google_containers/pause
        resources:
          requests:
            cpu: 1.5
            memory: "4Gi"

  2. Déployer la charge de travail :

    kubectl apply -f cc-workload.yaml

Lorsque vous déployez cette charge de travail, GKE ajoute automatiquement une tolérance aux pods qui correspond au rejet de nœud pour la ComputeClass demandée. Cette tolérance garantit que seuls les pods qui demandent la ComputeClass s'exécutent sur les nœuds ComputeClass.

Mettre à jour une ComputeClass déployée

Pour mettre à jour une ComputeClass déployée, modifiez le fichier manifeste YAML de la ComputeClass. Déployez ensuite le fichier manifeste modifié en exécutant la commande suivante :

kubectl apply -f PATH_TO_FILE

Remplacez PATH_TO_FILE par le chemin d'accès à votre fichier manifeste modifié. Assurez-vous que la valeur du champ name reste inchangée.

Lorsque vous déployez votre ComputeClass mise à jour, GKE utilise votre configuration mise à jour pour créer des nœuds. GKE ne modifie aucun nœud existant avec votre configuration mise à jour.

Au fil du temps, GKE peut déplacer les pods existants vers des nœuds qui utilisent votre configuration mise à jour si la ComputeClass utilise la migration active et si les pods existants sont éligibles à la migration.

Étapes suivantes