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.

Bonnes pratiques pour les ComputeClasses

Autopilot Standard

Les ingénieurs de plate-forme peuvent utiliser des ComputeClasses personnalisées pour configurer de manière déclarative les paramètres des nœuds et les priorités de remplacement que Google Kubernetes Engine (GKE) utilise pour créer des nœuds lors de l'autoscaling. Vous pouvez créer des ComputeClass en fonction de stratégies spécifiques et des exigences des charges de travail. Ce document fournit des bonnes pratiques pour concevoir et implémenter des ComputeClass dans vos clusters. Vous devez déjà connaître les ComputeClass personnalisées. Pour obtenir une vue d'ensemble consolidée de toutes les bonnes pratiques GKE, consultez Bonnes pratiques pour GKE.

Conception de ComputeClass

Les sections suivantes fournissent des bonnes pratiques pour concevoir et implémenter des ComputeClass dans vos clusters en fonction d'objectifs tels que l'optimisation de la disponibilité et des performances. Les ComputeClass fonctionnent avec les pools de nœuds créés manuellement et automatiquement.

Concevoir chaque ComputeClass en fonction d'une stratégie

Concevez chaque ComputeClass pour répondre à un objectif spécifique pour vos charges de travail, vos équipes ou votre organisation. Utilisez le comportement de remplacement des ComputeClass et la possibilité de sélectionner des pools de nœuds créés manuellement et automatiquement pour hiérarchiser certains résultats, tels que la réduction de la surcharge manuelle ou l'amélioration des performances de planification. Les sections suivantes décrivent les stratégies courantes.

Améliorer la disponibilité et réduire la surcharge manuelle

Pour déléguer la création de pools de nœuds à GKE, n'utilisez que des pools de nœuds créés automatiquement dans votre ComputeClass. L'autoscaler configure les nœuds en fonction de la disponibilité du matériel, des exigences en ressources des pods et de la capacité zonale. Cette stratégie élimine la nécessité de créer et d'ajuster manuellement les pools de nœuds, et peut réduire les coûts associés à la capacité de nœud inutilisée.

Améliorer les performances de planification et affiner les nœuds

Pour affiner vos nœuds les plus prioritaires et réduire la latence de planification, utilisez un mélange de pools de nœuds créés manuellement et automatiquement dans votre ComputeClass. Cette stratégie hybride réduit la fréquence à laquelle les pods attendent que GKE crée des pools de nœuds. Étant donné que vos pools de nœuds les plus prioritaires sont créés manuellement, vous pouvez affiner le matériel pour répondre aux exigences exactes de vos pods.

La stratégie hybride implique les types de pools de nœuds suivants par ordre de priorité dans la ComputeClass :

Pools de nœuds créés manuellement : ces pools de nœuds présentent les spécifications exactes sur lesquelles vous souhaitez que la plupart de vos pods s'exécutent. Configurez ces pools de nœuds avec des libellés de nœuds, des rejets de nœuds, des réservations de capacité ou des configurations spéciales telles que les paramètres kubelet. Créez ces pools de nœuds avec autant de nœuds que vous estimez que vos pods en auront besoin. Dans votre ComputeClass, attribuez la priorité la plus élevée à ces pools de nœuds.
Pools de nœuds créés automatiquement : par mesure de remplacement, utilisez la ComputeClass pour demander des pools de nœuds supplémentaires qui sont toujours optimisés pour vos pods. Attribuez une priorité inférieure à ces pools de nœuds créés automatiquement par rapport à vos pools de nœuds créés manuellement.

L'exemple suivant de ComputeClass utilise cette stratégie hybride :

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: hybrid-class
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - nodepools: ['manual-pool1']
  - machineFamily: n4
    minCores: 16
    minMemoryGb: 64
  whenUnsatisfiable: DoNotScaleUp

Lorsque vous déployez une charge de travail qui utilise cette ComputeClass, GKE place les pods sur les nœuds disponibles dans manual-pool1. GKE ne crée des pools de nœuds que lorsque le pool de nœuds créé manuellement ne dispose d'aucune capacité disponible. La latence de planification diminue lorsque le nombre de nœuds existants dans le pool de nœuds créé manuellement augmente, car GKE n'a pas besoin de créer de nouveaux nœuds aussi fréquemment.

Définir explicitement le comportement de scaling de dernier recours

Le champ whenUnsatisfiable contrôle ce qui se passe si GKE ne peut pas répondre aux exigences de l'une des règles de priorité d'une ComputeClass. Pour éviter tout comportement inattendu après une mise à niveau de version, spécifiez explicitement une valeur pour ce champ dans chaque ComputeClass. La définition d'une valeur permet aux utilisateurs de ComputeClass de savoir à quoi s'attendre lorsqu'ils sélectionnent cette ComputeClass dans une charge de travail. La valeur recommandée pour ce champ dépend du type de charge de travail, comme suit :

Charges de travail à usage général : si vos charges de travail peuvent s'exécuter sur n'importe quelle série de machines, spécifiez la valeur ScaleUpAnyway. Si les nœuds qui correspondent à une règle de priorité dans la ComputeClass ne sont pas disponibles, GKE met à l'échelle les nœuds qui utilisent la série de machines par défaut du cluster.
Charges de travail nécessitant du matériel spécialisé : pour les charges de travail d'accélérateurs ou de calcul hautes performances qui dépendent de matériel spécifique, tel que des GPU ou certaines séries de machines Compute Engine, spécifiez la valeur DoNotScaleUp. Si les nœuds qui correspondent à une règle de priorité dans la ComputeClass ne sont pas disponibles, les pods restent à l'état Pending jusqu'à ce que des ressources soient disponibles. Cette approche empêche les pods de s'exécuter sur du matériel incompatible.

Pour en savoir plus, consultez Définir le comportement de scaling lorsqu’aucune règle de priorité s’applique.

Définir une ComputeClass par défaut au niveau du cluster pour la plupart des charges de travail

Si la plupart de vos charges de travail ont les mêmes exigences matérielles, configurez une ComputeClass par défaut pour le cluster. GKE applique la ComputeClass par défaut à toutes les charges de travail qui ne sélectionnent pas explicitement de ComputeClass. En définissant une ComputeClass par défaut, les opérateurs d'application n'ont pas besoin de modifier les sélecteurs de nœuds ni de demander manuellement des pools de nœuds et du matériel spécifiques dans des pods individuels. Si vous définissez une ComputeClass par défaut au niveau du cluster, n'ajoutez pas de libellés et de rejets de nœuds pour d'autres ComputeClass aux pools de nœuds existants dans le cluster. Lors de la planification de la ComputeClass par défaut au niveau du cluster, GKE ignore tous les pools de nœuds qui comportent des libellés ou des rejets de nœuds pour d'autres ComputeClass.

Définir des ComputeClass par défaut pour les espaces de noms afin de séparer les locataires

En plus d'une ComputeClass par défaut au niveau du cluster, vous pouvez définir une ComputeClass par défaut pour des espaces de noms spécifiques. Si vous disposez d'environnements mutualisés ou si vous souhaitez séparer les charges de travail qui s'exécutent sur du matériel spécialisé, configurez des ComputeClass par défaut pour ces espaces de noms. Pour empêcher les pods système de s'exécuter sur du matériel spécialisé tel que des nœuds GPU, ajoutez une ComputeClass à usage général comme ComputeClass par défaut pour les espaces de noms système.

Exécuter des charges de travail à faible interaction en mode Autopilot

Si vous avez des charges de travail qui ne nécessitent pas d'interaction ni de gestion manuelles, exécutez-les en mode Autopilot à l'aide de ComputeClass. Vous pouvez activer le mode Autopilot dans n'importe quelle ComputeClass, même si vous disposez d'un cluster Standard. GKE exécute les charges de travail qui sélectionnent une ComputeClass Autopilot sur des nœuds entièrement gérés qui implémentent les fonctionnalités de sécurité, de scaling et de facturation de GKE Autopilot. Pour en savoir plus, consultez À propos des charges de travail en mode Autopilot dans GKE Standard.

Charges de travail avec état

Les sections suivantes fournissent des bonnes pratiques pour réduire les interruptions ou les comportements inattendus dans les charges de travail avec état qui s'appuient sur des données persistantes.

Désactiver la migration active

La migration active déplace automatiquement les pods vers de nouveaux nœuds qui ont une priorité plus élevée dans la ComputeClass ou qui ont la capacité d'exécuter des pods DaemonSet non planifiés. Lors de la migration active, GKE arrête les pods sur les nœuds existants et crée de nouveaux pods sur les nœuds prioritaires. Si vous avez des charges de travail qui s'appuient sur des données dans un stockage persistant local, le déplacement des pods vers de nouveaux nœuds peut entraîner des interruptions, car les pods perdent l'accès aux données persistantes. Pour éviter ce problème, désactivez la migration active pour les ComputeClass destinées aux charges de travail avec état.

Améliorer la fiabilité de la planification à l'aide de StorageClass

Utilisez des StorageClass pour améliorer la fiabilité de la planification des charges de travail avec état de la manière suivante :

Créer des volumes uniquement après la création de pods : si vous utilisez le provisionnement dynamique de volumes, spécifiez la valeur WaitForFirstConsumer dans le volumeBindingMode champ d'une StorageClass. Ce mode de liaison de volume empêche la création d'un PersistentVolume tant que GKE n'a pas créé de pod qui utilise le PersistentVolumeClaim correspondant. GKE provisionne le PersistentVolume dans la même zone que le nœud qui exécute le pod.
Utiliser des StorageClass compatibles avec la topologie : si votre ComputeClass couvre plusieurs générations d'une série de machines (par exemple, C4 et C3), utilisez une StorageClass pour laquelle la sélection automatique du type de disque est activée et qui ne planifie que sur les nœuds compatibles avec les types de disques spécifiés. Vous pouvez utiliser la StorageClass dynamic-rwo intégrée ou une StorageClass personnalisée. Vos charges de travail avec état peuvent ensuite s'exécuter sur plusieurs générations d'instances Compute Engine, car l'autoscaler de cluster choisit dynamiquement un type de disque compatible.

Disponibilité

Les sections suivantes fournissent des bonnes pratiques pour améliorer la disponibilité dans les ComputeClass, afin que vos pods passent moins de temps à l'état Pending.

Demander une série de machines au lieu de types de machines

Vous pouvez demander une série de machines Compute Engine ou des types de machines spécifiques dans les règles de priorité ComputeClass. Sauf si vous avez une dépendance stricte à un type de machine spécifique, sélectionnez une série de machines à l'aide du machineFamily champ. Lors d'une opération de scaling, GKE peut créer des nœuds qui utilisent n'importe quel type de machine viable dans cette série de machines, ce qui augmente la probabilité que vos pods s'exécutent sur votre configuration de nœud préférée.

Utiliser des réservations de capacité pour le matériel à forte demande

Si vos charges de travail dépendent de matériel à forte demande, tel que des TPU ou des GPU hautes performances, créez des réservations de capacité Compute Engine pour le matériel et consommez ces réservations dans vos ComputeClass. Les réservations de capacité améliorent la probabilité que le matériel soit disponible dans votre région ou zone, ce qui vous aide à augmenter la disponibilité des ressources. Pour consommer une réservation dans une ComputeClass sans affecter le comportement de remplacement, utilisez l'affinité de réservation Specific ou AnyThenFail. Si vous utilisez l'affinité AnyBestEffort ou Automatic et qu'aucune capacité réservée n'est disponible, Compute Engine peut contourner les règles de priorité ComputeClass et revenir au matériel à la demande. Pour en savoir plus, consultez la section Consommer des ressources zonales réservées.

Ne pas consommer de nouvelles réservations pendant au moins une heure

L'autoscaler de cluster stocke des informations sur les réservations de capacité dans un cache. Lorsque vous créez une réservation de capacité, l'autoscaler peut mettre jusqu'à une heure pour la découvrir. Une fois que vous avez créé une réservation, attendez au moins une heure avant de la consommer dans une charge de travail. Si vous déployez une charge de travail qui utilise la réservation avant que l'autoscaler ne la stocke dans le cache, l'opération d'autoscaling peut échouer.

Sécurité

Les sections suivantes fournissent des bonnes pratiques pour améliorer la sécurité des ComputeClass dans vos clusters. Ces mesures sont importantes, car les ComputeClass peuvent être utilisées pour créer et configurer des nœuds qui utilisent du matériel coûteux ou dont la disponibilité est limitée. Une utilisation abusive intentionnelle ou accidentelle peut entraîner des interruptions de charge de travail, des frais d'utilisation de ressources non planifiés et l'épuisement des quotas.

Restreindre l'accès à l'API aux configurations ComputeClass

Les charges de travail peuvent utiliser des ComputeClass pour créer des nœuds qui exécutent du matériel spécialisé, y compris des GPU et des TPU. Limitez l'accès à la création, à la modification et à la suppression des ComputeClass aux mêmes principaux qui peuvent créer, modifier et supprimer des nœuds dans vos clusters. Pour contrôler l'accès aux ComputeClass, utilisez des stratégies RBAC.

Restreindre la disponibilité des ComputeClass par espace de noms

Les clients GKE séparent souvent les différentes équipes ou types de charges de travail par espace de noms Kubernetes. Les ComputeClass sont une ressource à l'échelle du cluster, ce qui signifie que n'importe quelle charge de travail dans n'importe quel espace de noms peut sélectionner n'importe quelle ComputeClass par défaut. Pour éviter toute utilisation abusive intentionnelle ou accidentelle, utilisez des ValidatingAdmissionPolicies pour contrôler l'ensemble des ComputeClass que les charges de travail de chaque espace de noms peuvent sélectionner. Par exemple, vous pouvez empêcher les pods de votre espace de noms d'interface Web de sélectionner des ComputeClass qui créent des accélérateurs. Vérifiez que vos ValidatingAdmissionPolicies vérifient les configurations courantes suivantes :

Vérifier tous les champs de sélection : une charge de travail peut sélectionner une ComputeClass à l'aide des champs nodeSelector, nodeAffinity ou tolerations dans la spécification de pod. Pour éviter toute sélection involontaire de ComputeClass, vérifiez tous ces champs dans vos expressions ValidatingAdmissionPolicy.
Vérifier les contournements de tolérance génériques : bloquez ou validez explicitement les tolérances génériques (par exemple, la tolérance operator: Exists sans clé). Ces sélecteurs génériques peuvent englober la plupart des rejets de nœuds, y compris les rejets de ComputeClass.
Vérifier tous les contrôleurs de charge de travail : configurez de la stratégie pour couvrir toutes les ressources du contrôleur de charge de travail (telles que Deployment, StatefulSet, DaemonSet, Job, et CronJob). Ne limitez vos vérifications aux ressources Pod.matchConstraints

Pour en savoir plus, consultez Restreindre l'accès à la modification et à la sélection des ComputeClass.

Fiabilité

Les sections suivantes fournissent des bonnes pratiques pour améliorer la fiabilité de l'autoscaling et de la migration des pods pour les ComputeClass, ce qui réduit le risque d'interruptions ou de pods bloqués.

Empêcher l'utilisation de sélecteurs de nœuds conflictuels

Les sélecteurs de nœuds de vos pods affectent l'emplacement où GKE place ces pods et, en mode Autopilot ou avec la création automatique de pools de nœuds, peuvent déclencher la création de pools de nœuds dans votre cluster. Si vous avez des pods qui sélectionnent une ComputeClass et utilisent des sélecteurs de nœuds pour demander des nœuds en conflit avec la configuration ComputeClass, GKE peut ne pas planifier les pods du tout.

Prenons l'exemple d'une ComputeClass qui ne demande que des instances à la demande. Si un pod sélectionne cette ComputeClass et sélectionne des VM Spot dans un sélecteur de nœuds, GKE ne peut pas planifier le pod, car la ComputeClass et le sélecteur de nœuds sont en conflit. Pour éviter ce problème, utilisez des méthodes telles que ValidatingAdmissionPolicies pour empêcher les pods qui sélectionnent des ComputeClass de sélectionner également des libellés de nœuds système. Pour en savoir plus, consultez Sélecteurs de nœuds pour les libellés de nœuds système.

Tester toutes les modifications apportées aux paramètres de migration active et d'autoscaling

Les paramètres de migration active et d'autoscaling d'une ComputeClass affectent directement la fréquence à laquelle GKE arrête vos pods pour effectuer des tâches telles que le déplacement de pods vers du matériel plus adapté et la consolidation des nœuds sous-utilisés. Les modifications apportées à ces paramètres dans une ComputeClass existante peuvent entraîner des interruptions de charge de travail inattendues. Avant d'appliquer des modifications à ces paramètres dans des ComputeClass existantes, testez les modifications dans un environnement de préproduction. Vous pouvez également utiliser des annotations pour protéger les charges de travail critiques contre l'éviction lors du scaling.

Tester les mises à jour de CRD ComputeClass avant les mises à niveau de cluster

GKE met régulièrement à jour la définition de ressource personnalisée (CRD) ComputeClass pour ajouter des champs, modifier le comportement des champs et résoudre les problèmes. Les ajouts et modifications de champs prennent généralement effet dans des versions GKE spécifiques. Avant de mettre à niveau vos clusters de production vers de nouvelles versions mineures ou des versions de correctif, vérifiez si les modifications apportées à la CRD entraînent des problèmes de charge de travail en suivant les consignes suivantes :

Testez la mise à niveau dans un environnement de préproduction.
Consultez les notes de version de GKE pour connaître les modifications ou les ajouts apportés à la CRD ComputeClass.
Consultez la page de référence de la CRD ComputeClass pour connaître les mises à jour des champs dans votre version de mise à niveau cible.

Utiliser des PodDisruptionBudgets pour améliorer la disponibilité des charges de travail

Les opérations ComputeClass qui entraînent des évictions de pods, telles que la migration active, respectent tous les PodDisruptionBudgets configurés. Par exemple, vous pouvez configurer un déploiement d'inférence pour qu'il dispose d'un PodDisruptionBudget qui nécessite que plus de 70% des pods soient disponibles. Lors de la migration active, si une éviction de pod enfreint ce budget, GKE n'évince pas le pod. Spécifiez des PodDisruptionBudgets pour les charges de travail telles que les suivantes :

Charges de travail sans état, telles que les déploiements d'inférence.
Charges de travail avec état répliquées, telles que les applications de base de données à haute disponibilité.

Ne comptez pas sur les PodDisruptionBudgets pour protéger les charges de travail qui doivent s'exécuter jusqu'à la fin, ne comportent qu'une seule instance ou dépendent de données persistantes locales. Spécifiez un budget qui équilibre la disponibilité des charges de travail et permet aux fonctions telles que les mises à niveau de se terminer.

Protéger les charges de travail critiques contre l'éviction

Si vous avez des charges de travail où chaque pod doit s'exécuter jusqu'à la fin avant d'être arrêté, ajoutez l'annotation cluster-autoscaler.kubernetes.io/safe-to-evict: "false" à la spécification de pod. Cette annotation empêche GKE d'évincer les pods lors des opérations d'autoscaling. Utilisez cette annotation pour protéger les pods qui ne peuvent pas tolérer les interruptions, telles que les charges de travail avec état à instance unique et les tâches par lot de longue durée.