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 de nœud et les priorités de secours que Google Kubernetes Engine (GKE) utilise pour créer des nœuds lors de l'autoscaling. Vous pouvez créer des ComputeClasses en fonction de stratégies et d'exigences de charge de travail spécifiques. Ce document présente les bonnes pratiques pour concevoir et implémenter des ComputeClasses dans vos clusters. Vous devez déjà connaître les ComputeClasses personnalisées. Pour obtenir un aperçu complet de toutes les bonnes pratiques GKE, consultez Bonnes pratiques pour GKE.

Conception de ComputeClass

Les sections suivantes présentent les bonnes pratiques pour concevoir et implémenter des ComputeClasses dans vos clusters en fonction d'objectifs tels que la maximisation de la flexibilité, de l'efficacité, de la disponibilité et des performances de la capacité de calcul. Les ComputeClasses fonctionnent avec les pools de nœuds créés manuellement et automatiquement.

Concevez chaque ComputeClass en fonction d'une stratégie

Concevez chaque ComputeClass pour atteindre un objectif spécifique pour vos charges de travail, vos équipes ou votre organisation. Utilisez le comportement de secours des ComputeClasses et la possibilité de sélectionner des pools de nœuds créés manuellement et automatiquement pour privilégier certains résultats, comme la réduction des efforts manuels ou l'amélioration des performances de planification. Les sections suivantes décrivent les stratégies courantes.

Améliorer la disponibilité des ressources et réduire les tâches manuelles

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 besoins 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œuds inutilisée et inactive.

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. Comme 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 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 étiquettes de nœuds, des rejets de nœuds, des réservations de capacité ou des configurations spéciales telles que des paramètres kubelet spécifiques. Créez ces pools de nœuds avec autant de nœuds que vous estimez que vos pods auront besoin. Dans votre ComputeClass, attribuez la priorité la plus élevée à ces pools de nœuds.
Pools de nœuds créés automatiquement : en dernier recours, utilisez 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 à ceux que vous avez 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 de nouveaux 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 souvent.

Définir explicitement le comportement de scaling en dernier recours

Le champ whenUnsatisfiable contrôle ce qui se passe si GKE ne peut pas répondre aux exigences d'une règle de priorité dans une classe de calcul. Pour éviter tout comportement inattendu après une mise à niveau de version, spécifiez explicitement une valeur pour ce champ dans chaque ComputeClass. Définir une valeur aide les utilisateurs de ComputeClass à 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 aucun nœud correspondant à une règle de priorité dans la ComputeClass n'est disponible, GKE effectue un scaling à la hausse des 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 de calcul hautes performances ou d'accélérateurs qui dépendent de matériel spécifique, comme les GPU ou certaines séries de machines Compute Engine, spécifiez la valeur DoNotScaleUp. Si aucun nœud correspondant à une règle de priorité dans la ComputeClass n'est disponible, 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é ne 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'applications 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 classe ComputeClass par défaut au niveau du cluster, n'ajoutez pas de libellés ni de rejets de nœud pour d'autres classes ComputeClass aux pools de nœuds existants du 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 ComputeClasses 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 multitenants ou si vous souhaitez séparer les charges de travail qui s'exécutent sur du matériel spécialisé, configurez des ComputeClasses 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é comme les 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 ComputeClasses. 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 présentent les bonnes pratiques à suivre pour réduire les perturbations 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 met fin aux pods sur les nœuds existants et crée des pods sur les nœuds de priorité supérieure. 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 perturbations, car les pods perdent l'accès aux données persistantes. Pour éviter ce problème, désactivez la migration active pour les ComputeClasses destinées aux charges de travail avec état.

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

Utilisez des ressources StorageClass pour améliorer la fiabilité de la planification des charges de travail avec état de différentes manières :

Créer des volumes uniquement après la création du pod : si vous utilisez le provisionnement dynamique de volumes, spécifiez la valeur WaitForFirstConsumer dans le champ volumeBindingMode 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 utilisant le PersistentVolumeClaim correspondant. GKE provisionne le PersistentVolume dans la même zone que le nœud qui exécute le pod.
Utilisez des StorageClasses compatibles avec la topologie : si votre ComputeClass s'étend sur plusieurs générations d'une série de machines (par exemple, C4 et C3), utilisez une StorageClass pour laquelle l'option de sélection automatique du type de disque est activée et qui planifie uniquement 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.

Concevez votre infrastructure pour la flexibilité, l'efficacité et la disponibilité de la capacité de calcul

Les sections suivantes présentent les bonnes pratiques pour améliorer la flexibilité, l'efficacité et la disponibilité de la capacité de calcul dans ComputeClasses, 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. À moins que vous ne dépendiez strictement d'un type de machine spécifique, sélectionnez une série de machines à l'aide du champ machineFamily. 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 la configuration de nœud de votre choix.

Utiliser des réservations de capacité pour le matériel demandé

Si vos charges de travail reposent sur du matériel très demandé, comme des TPU ou des GPU hautes performances, créez des réservations de capacité Compute Engine pour le matériel et utilisez-les dans vos ComputeClasses. Les réservations de capacité améliorent la probabilité de disponibilité du matériel dans votre région ou zone, ce qui vous aide à accroître la flexibilité, l'efficacité et la disponibilité de la capacité de calcul. Pour consommer une réservation dans une ComputeClass sans affecter le comportement de secours, 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 ignorer les règles de priorité ComputeClass et revenir au matériel à la demande. Pour en savoir plus, consultez 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 l'utiliser 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 ComputeClasses dans vos clusters. Ces mesures sont importantes, car les ComputeClasses 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 perturbations de la charge de travail, des frais d'utilisation des ressources imprévus et l'épuisement du quota.

Restreindre l'accès à l'API pour les configurations ComputeClass

Les charges de travail peuvent utiliser des ComputeClasses 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 de ComputeClasses aux mêmes principaux qui peuvent créer, modifier et supprimer des nœuds dans vos clusters. Pour contrôler l'accès aux ComputeClasses, utilisez des règles RBAC.

Restreindre la disponibilité de 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 ComputeClasses sont des ressources à 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 ValidatingAdmissionPolicies pour contrôler l'ensemble des ComputeClasses 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 ComputeClasses qui créent des accélérateurs. Vérifiez que vos ValidatingAdmissionPolicies vérifient les configurations courantes suivantes :

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

Pour en savoir plus, consultez Limiter l'accès pour modifier et sélectionner des ComputeClasses.

Fiabilité

Les sections suivantes présentent les bonnes pratiques à suivre pour améliorer la fiabilité de l'autoscaling et de la migration de pods pour les ComputeClasses, ce qui réduit le risque de perturbations ou de blocage des pods.

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 qui entrent en conflit avec la configuration ComputeClass, il est possible que GKE ne planifie pas du tout les pods.

Prenons l'exemple d'une ComputeClass qui ne demande que des instances à la demande. Si un pod sélectionne cette ComputeClass et des VM Spot dans un sélecteur de nœud, GKE ne peut pas planifier le pod, car la ComputeClass et le sélecteur de nœud sont en conflit. Pour éviter ce problème, utilisez des méthodes telles que ValidatingAdmissionPolicies pour empêcher les pods qui sélectionnent des ComputeClasses 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 et d'autoscaling actifs

Les paramètres de migration active et d'autoscaling d'une ComputeClass ont une incidence directe sur la fréquence à laquelle GKE met fin à vos pods pour effectuer des tâches telles que le déplacement des pods vers du matériel plus adapté et la consolidation des nœuds sous-utilisés. Si vous modifiez ces paramètres dans une ComputeClass existante, cela peut entraîner des perturbations inattendues des charges de travail. Avant d'appliquer des modifications à ces paramètres dans les ComputeClasses existantes, testez-les 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 de correctifs, vérifiez si les modifications apportées au CRD entraînent des problèmes de charge de travail en suivant les consignes ci-dessous :

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 au CRD ComputeClass.
Consultez la page de référence du CRD ComputeClass pour connaître les modifications apportées aux champs dans la version cible de la mise à niveau.

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 exige que plus de 70% des pods soient disponibles. Lors d'une migration active, si l'éviction d'un pod enfreint ce budget, GKE ne l'évince pas. 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 à disponibilité élevée.

Ne comptez pas sur les PodDisruptionBudgets pour protéger les charges de travail qui doivent s'exécuter jusqu'à la fin, qui ne comportent qu'une seule instance ou qui s'appuient sur des données persistantes locales. Spécifiez un budget qui équilibre la disponibilité de la charge 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 du 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 perturbations, comme les charges de travail avec état à instance unique et les jobs par lot de longue durée.