Il est possible qu'une partie ou l'ensemble des informations de cette page ne s'appliquent pas au Cloud de confiance S3NS. Pour en savoir plus, consultez Différences par rapport à Google Cloud.

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 remplacement 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 à suivre 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 consolidé 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 ComputeClasses dans vos clusters en fonction d'objectifs tels que l'optimisation 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.

Concevoir 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 remplacement des ComputeClasses et la possibilité de sélectionner des pools de nœuds créés manuellement et automatiquement pour prioriser certains résultats, comme la réduction des frais généraux 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 frais généraux manuels

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 des pools de nœuds, et peut réduire les coûts associés à la capacité de nœuds inactive et inutilisée.

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

Pour affiner vos nœuds de priorité la plus élevée et réduire la latence d'ordonnancement, utilisez une combinaison de pools de nœuds créés manuellement et de pools de nœuds créés 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 de priorité la plus élevée sont créés manuellement, vous pouvez ajuster 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 ont 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œud, des rejets de nœud, des réservations de capacité ou des configurations spéciales spécifiques, telles que des paramètres kubelet. Créez ces pools de nœuds avec autant de nœuds que vous estimez nécessaire pour vos pods. Dans votre ComputeClass, attribuez la priorité la plus élevée à ces pools de nœuds.
Pools de nœuds créés automatiquement : en tant que 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 de ComputeClass suivant 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 n'a plus de 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. Définir 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 correspondant à une règle de priorité dans la ComputeClass ne sont pas disponibles, 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 d'accélérateurs ou de calcul hautes performances qui dépendent d'un 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 correspondant à 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é 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 classe ComputeClass par défaut à toutes les charges de travail qui ne sélectionnent pas explicitement une classe 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 ComputeClass par défaut au niveau du cluster, n'ajoutez pas d'étiquettes de nœud ni de rejets pour d'autres ComputeClasses 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 comportant des libellés ou des rejets de nœuds pour d'autres ComputeClasses.

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 mutualisés 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 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 ComputeClasses. Vous pouvez activer le mode Autopilot dans n'importe quelle classe ComputeClass, même si vous disposez d'un cluster Standard. GKE exécute les charges de travail qui sélectionnent une classe de calcul 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 décrivent 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 arrête les pods sur les nœuds existants et crée des pods sur des nœuds de priorité supérieure. Si vous avez des charges de travail qui dépendent de données stockées dans un espace de 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 de volumes dynamique, 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 tenant compte de la topologie : si votre ComputeClass s'étend sur plusieurs générations de séries de machines, utilisez une StorageClass pour laquelle la sélection automatique du type de disque (parameters.type: dynamic) est activée et qui ne planifie que sur les nœuds compatibles avec les types de disques spécifiés. Par exemple, votre ComputeClass passe d'une série Hyperdisk uniquement, telle que C4, C4D ou N4, à une série Persistent Disk, telle que N2 ou N2D, en cas de contraintes de capacité zonale. Vous pouvez utiliser la StorageClass dynamic-rwo intégrée ou une StorageClass personnalisée. Vos charges de travail avec état peuvent ensuite basculer sur plusieurs générations d'instances Compute Engine, car l'autoscaler de cluster choisit de manière dynamique un type de disque compatible (hyperdisk-balanced ou pd-balanced) pour le nœud de remplacement provisionné.

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

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

Demander des séries 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 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 de 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 très 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 consommez ces réservations dans vos ComputeClasses. Les réservations de capacité augmentent la probabilité que du matériel soit disponible 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 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é de 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 les 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étecter. Après avoir 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 décrivent les 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 non planifiés et l'épuisement des quotas.

Restreindre l'accès de l'API aux 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 comptes 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.

Limiter 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 de 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 recherchent les configurations courantes suivantes :

Vérifiez tous les champs de sélection : une charge de travail peut sélectionner une ComputeClass à l'aide du champ 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.
Rechercher les contournements de tolérance générique : 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 ComputeClass.
Vérifier tous les contrôleurs de charge de travail : configurez le matchConstraints de la règle pour couvrir toutes les ressources de 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 des pods pour les ComputeClasses, ce qui réduit le risque d'interruption ou de blocage des pods.

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

Les sélecteurs de nœuds de vos pods ont une incidence sur l'emplacement où GKE place ces pods et, en mode Autopilot ou avec la création automatique de pools de nœuds, ils 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 de la ComputeClass, GKE risque de ne pas planifier les pods du tout.

Par exemple, prenons 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œ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 ComputeClasses de sélectionner également des étiquettes de nœud système. Pour en savoir plus, consultez Sélecteurs de nœuds pour les étiquettes 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 ont une incidence directe sur 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 préféré et la consolidation des nœuds sous-utilisés. La modification de ces paramètres dans une ComputeClass existante peut entraîner des interruptions inattendues de la charge de travail. Avant d'apporter des modifications à ces paramètres dans des 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 la 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 spécifiques de GKE. Avant de mettre à niveau vos clusters de production vers de nouvelles versions mineures ou 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 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 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 d'une migration active, si l'éviction d'un pod ne respecte pas ce budget, GKE n'évince pas le pod. Spécifiez des PodDisruptionBudgets pour les charges de travail 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 vous fiez pas aux PodDisruptionBudgets pour protéger les charges de travail qui doivent s'exécuter jusqu'à leur terme, qui n'ont 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 d'effectuer des fonctions telles que les mises à niveau.

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'expulser des pods lors des opérations d'autoscaling. Utilisez cette annotation pour protéger les pods qui ne tolèrent pas les interruptions, comme les charges de travail avec état à instance unique et les jobs par lot de longue durée.