Cette page décrit les demandes de ressources maximales, minimales et par défaut que vous pouvez spécifier pour vos charges de travail Google Kubernetes Engine (GKE) et comment Autopilot modifie automatiquement ces requêtes pour maintenir leur stabilité.
Présentation des demandes de ressources dans Autopilot
Autopilot utilise les requêtes de ressources que vous spécifiez dans la configuration de votre charge de travail pour configurer les nœuds qui les exécutent. Autopilot applique des requêtes de ressources minimales et maximales en fonction de la classe de calcul ou de la configuration matérielle utilisée par vos charges de travail. Si vous ne spécifiez pas de requêtes pour certains conteneurs, Autopilot attribue des valeurs par défaut pour permettre à ces conteneurs de s'exécuter correctement.
Lorsque vous déployez une charge de travail dans un cluster Autopilot, GKE valide la configuration de la charge de travail par rapport aux valeurs minimales et maximales autorisées pour la classe de calcul sélectionnée ou la configuration matérielle (tels que les GPU). Si les requêtes sont inférieures au minimum, Autopilot modifie automatiquement la configuration de votre charge de travail pour que les requêtes soient comprises dans la plage autorisée. Si les requêtes sont supérieures au maximum, Autopilot rejette votre charge de travail et affiche un message d'erreur.
La liste suivante récapitule les catégories de demandes de ressources :
- Requêtes de ressources par défaut : Autopilot les ajoute si vous ne spécifiez pas vos propres requêtes pour les charges de travail.
- Nombre minimal et maximal de demandes de ressources : Autopilot valide les requêtes spécifiées pour s'assurer qu'elles sont dans les limites. Si vos requêtes dépassent les limites, Autopilot modifie vos requêtes de charge de travail.
- Séparation des charges de travail et requêtes de durée étendue : Autopilot possède différentes valeurs par défaut et différentes valeurs minimales pour les charges de travail que vous divisez ou pour les pods qui bénéficient d'une protection étendue avec l'éviction lancée par GKE.
- Demandes de ressources pour les objets DaemonSet : Autopilot possède des valeurs par défaut, minimales et maximales différentes pour les conteneurs des objets DaemonSet.
Comment demander des ressources
Dans Autopilot, vous demandez des ressources dans la spécification de pod. Les ressources minimales et maximales acceptées que vous pouvez demander varient en fonction de la configuration matérielle du nœud sur lequel les pods sont exécutés. Pour savoir comment demander des configurations matérielles spécifiques, reportez-vous aux pages suivantes :
- Choisir des classes de calcul pour les pods Autopilot
- Déployer des charges de travail GPU dans Autopilot
Demandes de ressources par défaut
Si vous ne spécifiez pas de demandes de ressources pour certains conteneurs d'un pod, Autopilot applique les valeurs par défaut. Ces valeurs par défaut sont adaptées à de nombreuses charges de travail de faible volume.
De plus, Autopilot applique les demandes de ressources par défaut suivantes, quelle que soit la classe de calcul sélectionnée ou la configuration matérielle :
Conteneurs dans DaemonSets
- Processeur : 50 mCPU
- Mémoire : 100 Mio
- Stockage éphémère : 100 Mio
Tous les autres conteneurs
- Stockage éphémère : 1 Gio
Pour en savoir plus sur les limites des clusters Autopilot, consultez la section Quotas et limites.
Requêtes par défaut pour les classes de calcul
Autopilot applique les valeurs par défaut suivantes aux ressources qui ne sont pas définies dans la spécification du pod pour les pods exécutés sur des classes de calcul. Si vous ne définissez qu'une seule des requêtes et laissez l'autre vide, GKE utilise le ratio processeur/mémoire défini dans la section Nombre minimal et maximal de requêtes pour définir la requête manquante sur une valeur conforme au ratio.
| Classe de calcul | Resource | Requête par défaut |
|---|---|---|
| Usage général | CPU | 0,5 processeur virtuel |
| Memory | 2 Gio | |
| Équilibrées | Processeur | 0,5 processeur virtuel |
| Memory | 2 Gio | |
| Performances | Processeur |
|
| Mémoire |
|
|
| Stockage éphémère |
|
|
| Scaling horizontal | Processeur | 0,5 processeur virtuel |
| Memory | 2 Gio |
Requêtes par défaut pour d'autres configurations matérielles
Autopilot applique les valeurs par défaut suivantes aux ressources qui ne sont pas définies dans la spécification des pods pour les pods qui s'exécutent sur des nœuds avec du matériel spécialisé, tels que les GPU :
| Matériel | Ressource | Demande totale de ressources par défaut |
|---|---|---|
GPU H100 (80 Go)nvidia-h100-80gb |
Processeur |
|
| Mémoire |
|
|
| Stockage éphémère |
|
|
GPU A100 (40 Go)nvidia-tesla-a100 |
processeur |
|
| Memory |
|
|
GPU A100 (80 Go)nvidia-a100-80gb |
processeur |
|
| Mémoire |
|
|
| Stockage éphémère |
|
|
GPU L4nvidia-l4 |
Processeur |
|
| Mémoire |
|
|
GPU T4nvidia-tesla-t4 |
Processeur | 0,5 processeur virtuel |
| Memory | 2 Gio |
Demandes de ressources minimum et maximum
Le nombre total des ressources demandées par votre configuration de déploiement doit être inférieur aux valeurs minimales et maximales autorisées par Autopilot. Les conditions suivantes s'appliquent :
- La requête de stockage éphémère doit être comprise entre 10 Mio et 10 Gio pour toutes les classes de calcul et configurations matérielles, sauf indication contraire. Pour les volumes plus importants, il est recommandé d'utiliser des volumes éphémères génériques qui offrent des fonctionnalités et des performances équivalentes au stockage éphémère, mais avec une flexibilité bien plus importante car ils peuvent s'utiliser avec n'importe quelle option de stockage GKE. Par exemple, la taille maximale d'un volume éphémère générique utilisant
pd-balancedest de 64 Tio. Pour les pods DaemonSet, les demandes de ressources minimales sont les suivantes :
- Clusters compatibles avec l'utilisation intensive : 1 mCPU par pod, 2 Mio de mémoire par pod et 10 Mio de stockage éphémère par conteneur dans le pod.
- Clusters non compatibles avec l'utilisation intensive : 10 mCPU par pod, 10 Mio de mémoire par pod et 10 Mio de stockage éphémère par conteneur dans le pod.
Pour vérifier si votre cluster est compatible avec l'utilisation intensive, consultez la page Utilisation intensive de la disponibilité dans GKE.
Le ratio processeur/mémoire doit être compris dans la plage autorisée pour la classe de calcul ou la configuration matérielle sélectionnée. Si le ratio processeur/mémoire se situe en dehors de la plage autorisée, Autopilot augmente automatiquement la ressource la plus petite. Par exemple, si vous demandez 1 vCPU et 16 Gio de mémoire (ratio 1:16) pour les pods exécutés sur la classe
Scale-Out, Autopilot augmente la demande de processeur à 4 vCPU, ce qui passe le ratio à 1:4.
Valeurs minimales et maximales pour les classes de calcul
Le tableau suivant décrit le ratio processeur:mémoire minimal, maximal et autorisé pour chaque classe de calcul compatible avec Autopilot :
| Classe de calcul | Ratio processeur:mémoire (processeur virtuel:Gio) | Resource | Minimum | Maximum |
|---|---|---|---|---|
| Usage général | Entre 1:1 et 1:6.5 | CPU | La valeur varie selon que votre cluster est compatible avec l'utilisation intensive, comme suit :
Pour vérifier si votre cluster est compatible avec l'utilisation intensive, consultez la page Utilisation intensive de la disponibilité dans GKE. |
30 vCPU |
| Mémoire | La valeur varie selon que votre cluster est compatible avec l'utilisation intensive, comme suit :
Pour vérifier si votre cluster est compatible avec l'utilisation intensive, consultez la page Utilisation intensive de la disponibilité dans GKE. |
110 Gio | ||
| Équilibrées | Entre 1:1 et 1:8 | processeur | 0,25 vCPU | 222 vCPU Si vous avez sélectionné la plate-forme de processeur minimale :
|
| Memory | 0,5 Gio | 851 Gio Si vous avez sélectionné la plate-forme de processeur minimale :
|
||
| Performances | N/A | Processeur | 0,001 vCPU |
|
| Mémoire | 1 Mio |
|
||
| Stockage éphémère | 10 Mio |
|
||
| Scaling horizontal | 1:4 | processeur | 0,25 vCPU |
|
| Memory | 1 Gio |
|
Pour savoir comment demander des classes de calcul dans vos pods Autopilot, consultez la section Choisir les classes de calcul pour les pods Autopilot.
Valeurs minimales et maximales pour les autres configurations matérielles
Le tableau suivant décrit le ratio processeur minimal/maximal et autorisé de la mémoire pour les pods exécutés sur des nœuds avec du matériel spécifique tel que des GPU. Sauf indication contraire, la capacité de stockage éphémère maximale est de 122 Gio dans les versions 1.28.6-gke.1369000 ou ultérieures et 1.29.1-gke.1575000 ou ultérieures. Pour les versions antérieures, la capacité de stockage éphémère maximale acceptée est de 10 Gio.
| Matériel | Ratio processeur:mémoire (processeur virtuel:Gio) | Resource | Minimum | Maximum |
|---|---|---|---|---|
GPU H100 (80 Go)nvidia-h100-80gb |
Non appliquée | CPU |
|
|
| Mémoire |
|
|
||
| Stockage éphémère |
|
|
||
GPU A100 (40 Go)nvidia-tesla-a100 |
Non appliquée | processeur |
|
La somme des requêtes de processeurs de tous les objets DaemonSet exécutés sur un nœud GPU A100 ne doit pas dépasser 2 processeurs virtuels. |
| Memory |
|
La somme des requêtes de mémoire de tous les objets DaemonSet exécutés sur un nœud GPU A100 ne doit pas dépasser 14 Gio. |
||
GPU A100 (80 Go)nvidia-a100-80gb |
Non appliquée | processeur |
|
La somme des requêtes de processeurs de tous les objets DaemonSet exécutés sur un nœud GPU A100 (80 Go) ne doit pas dépasser 2 processeurs virtuels. |
| Mémoire |
|
La somme des requêtes de mémoire de tous les objets DaemonSet exécutés sur un nœud GPU A100 (80 Go) ne doit pas dépasser 14 Gio. |
||
| Stockage éphémère |
|
|
||
GPU L4nvidia-l4 |
|
Processeur |
|
La somme des requêtes de processeurs de tous les objets DaemonSet exécutés sur un nœud GPU L4 ne doit pas dépasser 2 processeurs virtuels. |
| Mémoire |
|
La somme des requêtes de mémoire de tous les objets DaemonSet exécutés sur un nœud GPU L4 ne doit pas dépasser 14 Gio. |
||
GPU T4nvidia-tesla-t4 |
Entre 1:1 et 1:6.25 | processeur | 0,5 processeur virtuel |
|
| Memory | 0,5 Gio |
|
Pour savoir comment demander des GPU dans vos pods Autopilot, consultez la section Déployer des charges de travail GPU dans Autopilot.
Demandes de ressources pour la séparation des charges de travail et la durée étendue
Autopilot vous permet de manipuler le comportement de planification et d'éviction de Kubernetes à l'aide des méthodes suivantes :
- Utilisez des rejets et tolérances et des sélecteurs de nœuds pour vous assurer que certains pods ne sont placés que sur des nœuds spécifiques. Pour en savoir plus, consultez la page Configurer la séparation des charges de travail dans GKE.
- Utilisez l'anti-affinité de pod pour empêcher les pods de coexister sur le même nœud. Les requêtes de ressources par défaut et minimales pour les charges de travail qui utilisent ces méthodes afin de contrôler le comportement de la planification sont plus élevées que pour les charges de travail qui ne les utilisent pas.
- Utilisez une annotation pour protéger les pods contre l'éviction provoquée par des mises à niveau automatiques des nœuds et des événements de réduction de capacité pendant sept jours maximum. Pour en savoir plus, consultez la section Prolonger la durée d'exécution des pods Autopilot.
Si les requêtes spécifiées sont inférieures aux minimums, le comportement d'Autopilot change en fonction de la méthode utilisée, comme suit :
- Rejets, tolérances, sélecteurs et pods de durée prolongée : Autopilot modifie vos pods pour augmenter les requêtes lors de la planification des pods.
- Anti-affinité de pod : Autopilot rejette le pod et affiche un message d'erreur.
Le tableau suivant décrit les requêtes par défaut et les requêtes de ressources minimales que vous pouvez spécifier. Si une classe de configuration ou de calcul ne figure pas dans ce tableau, Autopilot n'applique pas de valeurs minimales ou par défaut spéciales.
| Classe de calcul | Ressource | Par défaut | Minimum |
|---|---|---|---|
| Usage général | CPU | 0,5 processeur virtuel | 0,5 processeur virtuel |
| Memory | 2 Gio | 0,5 Gio | |
| Équilibrées | Processeur | 2 vCPU | 1 vCPU |
| Memory | 8 Gio | 4 Gio | |
| Scaling horizontal | Processeur | 0,5 processeur virtuel | 0,5 processeur virtuel |
| Memory | 2 Gio | 2 Gio |
Conteneurs d'initialisation
Les conteneurs d'initialisation s'exécutent en série et doivent se terminer avant le démarrage des conteneurs d'application. Si vous ne spécifiez pas de demandes de ressources pour vos conteneurs d'initialisation Autopilot, GKE alloue le nombre total de ressources au pod à chaque conteneur d'initialisation. Ce comportement est différent de celui de GKE Standard, où chaque conteneur d'initialisation peut utiliser toutes les ressources non allouées disponibles sur le nœud sur lequel le pod est planifié.
Contrairement aux conteneurs d'application, GKE vous recommande de ne pas spécifier de demandes de ressources pour les conteneurs d'initialisation d'Autopilot, afin que chaque conteneur ait accès aux ressources complètes disponibles pour le pod. Si vous demandez moins de ressources que la valeur par défaut, vous limitez votre conteneur d'initialisation. Si vous demandez plus de ressources que les valeurs par défaut d'Autopilot, vous pouvez augmenter le montant facturé pendant la durée de vie du pod.
Définir des limites de ressources dans Autopilot
Kubernetes vous permet de définir requests et limits pour les ressources de votre spécification de pod. Le comportement de vos pods varie selon que votre limits est différent de votre requests, comme décrit dans le tableau suivant :
| Valeurs définies | Comportement d'Autopilot |
|---|---|
requests égal à limits |
Les pods utilisent la classe QoS Guaranteed.
|
requests défini, limits non défini |
Le comportement varie selon que votre cluster est compatible avec l'utilisation intensive, comme suit :
Pour vérifier si votre cluster est compatible avec l'utilisation intensive, consultez la page Utilisation intensive de la disponibilité dans GKE. |
requests non défini, limits défini. |
Autopilot définit requests sur la valeur de limits, qui est le comportement de Kubernetes par défaut.
Avant :
resources:
limits:
cpu: "400m"
Après :
resources:
requests:
cpu: "400m"
limits:
cpu: "400m" |
requests de moins que limits |
Le comportement varie selon que votre cluster est compatible avec l'utilisation intensive, comme suit :
Pour vérifier si votre cluster est compatible avec l'utilisation intensive, consultez la page Utilisation intensive de la disponibilité dans GKE. |
requests supérieur à limits |
Autopilot définit requests sur la valeur de limits.
Avant :
resources:
requests:
cpu: "450m"
limits:
cpu: "400m"
Après :
resources:
requests:
cpu: "400m"
limits:
cpu: "400m" |
requests non défini, limits non défini. |
Autopilot définit les valeurs par défaut de Le comportement de
Pour vérifier si votre cluster est compatible avec l'utilisation intensive, consultez la page Utilisation intensive de la disponibilité dans GKE. |
Dans la plupart des cas, définissez des demandes de ressources adéquates et des limites égales pour vos charges de travail.
Pour les charges de travail nécessitant temporairement plus de ressources que leur état stable, par exemple au démarrage ou pendant les périodes de trafic plus élevées, définissez des limites supérieures à vos requêtes pour permettre aux pods de passer en utilisation intensive. Pour en savoir plus, consultez la page Configurer l'utilisation intensive des pods dans GKE.
Gestion automatique des ressources dans Autopilot
Si les demandes de ressources spécifiées pour vos charges de travail se situent en dehors des plages autorisées, ou si vous ne demandez pas de ressources pour certains conteneurs, Autopilot modifie la configuration de votre charge de travail pour respecter les limites autorisées. Autopilot calcule les ratios de ressources et les exigences de scaling des ressources après avoir appliqué les valeurs par défaut aux conteneurs sans spécifier de requête.
- Requêtes manquantes : si vous ne demandez pas de ressources dans certains conteneurs, Autopilot applique les requêtes par défaut pour la classe de calcul ou la configuration matérielle.
- Ratio processeur/mémoire : Autopilot augmente la taille de la ressource la plus petite afin d'atteindre le ratio dans la plage autorisée.
- Stockage éphémère : Autopilot modifie vos requêtes de stockage éphémère afin d'atteindre la quantité minimale requise par chaque conteneur. La valeur cumulative des requêtes de stockage pour tous les conteneurs ne peut pas être supérieure à la valeur maximale autorisée. Autopilot réduit la requête si la valeur dépasse la valeur maximale.
- Requêtes inférieures aux valeurs minimales : si vous demandez moins de ressources que le minimum autorisé pour la configuration matérielle sélectionnée, Autopilot modifie automatiquement le pod pour demander au moins la valeur minimale de ressources.
Par défaut, lorsque Autopilot effectue le scaling automatique d'une ressource pour atteindre une valeur minimale ou par défaut des ressources, GKE alloue la capacité supplémentaire au premier conteneur dans le fichier manifeste du pod. Dans GKE 1.27.2-gke.2200 et versions ultérieures, vous pouvez indiquer à GKE d'allouer les ressources supplémentaires à un conteneur spécifique en ajoutant ce qui suit au champ annotations de votre fichier manifeste de pod :
autopilot.gke.io/primary-container: "CONTAINER_NAME"
Remplacez CONTAINER_NAME par le nom du conteneur.
Exemples de modification de ressources
L'exemple de scénario suivant montre comment Autopilot modifie la configuration de votre charge de travail pour répondre aux exigences de vos pods et conteneurs en cours d'exécution.
Conteneur unique avec un processeur inférieur à 0,05 vCPU
| Nombre de conteneurs | Demande initiale | Demande modifiée |
|---|---|---|
| 1 | Processeur : 30 mCPU Mémoire : 0,5 Gio Stockage éphémère : 10 Mio |
Processeur : 50 mCPU Mémoire : 0,5 Gio Stockage éphémère : 10 Mio |
Plusieurs conteneurs avec un processeur total inférieur à 0,05 vCPU
| Nombre de conteneurs | Demandes d'origine | Demandes modifiées |
|---|---|---|
| 1 | Processeur : 10 mCPU Mémoire : 0,5 Gio Stockage éphémère : 10 Mio |
Processeur : 30 mCPU Mémoire : 0,5 Gio Stockage éphémère : 10 Mio |
| 2 | Processeur : 10 mCPU Mémoire : 0,5 Gio Stockage éphémère : 10 Mio |
Processeur : 10 mCPU Mémoire : 0,5 Gio Stockage éphémère : 10 Mio |
| 3 | Processeur : 10 mvCPU Mémoire : 0,5 Gio Stockage éphémère : 10 Mio |
Processeur : 10 mCPU Mémoire : 0,5 Gio Stockage éphémère : 10 Mio |
| Total des ressources du pod | Processeur : 50 mCPU Mémoire : 1,5 Gio Stockage éphémère : 30 Mio |
Plusieurs conteneurs avec plus de 0,25 vCPU au total
Pour plusieurs conteneurs dont le nombre total de ressources est supérieur à 0,25 vCPU, le processeur est arrondi à des multiples de 0,25 vCPU, et le processeur supplémentaire est ajouté au premier conteneur. Dans cet exemple, le total cumulé en ressource de processeur d'origine est de 0,32 vCPU, modifié pour un total de 0,5 vCPU.
| Nombre de conteneurs | Demandes d'origine | Demandes modifiées |
|---|---|---|
| 1 | Processeur : 0,17 processeurs virtuels Mémoire : 0,5 Gio Stockage éphémère : 10 Mio |
Processeur : 0,35 processeurs virtuels Mémoire : 0,5 Gio Stockage éphémère : 10 Mio |
| 2 | Processeur : 0,08 processeurs virtuels Mémoire : 0,5 Gio Stockage éphémère : 10 Mio |
Processeur : 0,08 processeurs virtuels Mémoire : 0,5 Gio Stockage éphémère : 10 Mio |
| 3 | Processeur : 0,07 processeurs virtuels Mémoire : 0,5 Gio Stockage éphémère : 10 Mio |
Processeur : 0,07 processeurs virtuels Mémoire : 0,5 Gio Stockage éphémère : 10 Mio |
| 4 | Conteneur d'initialisation, ressources non définies | Va recevoir les ressources du pod |
| Total des ressources du pod | Processeur : 0,5 processeurs virtuels Mémoire : 1,5 Gio Stockage éphémère : 30 Mio |
Conteneur unique avec une mémoire trop faible pour le processeur demandé
Dans cet exemple, la mémoire est trop faible pour la quantité de processeurs (1 vCPU pour 1 Gio minimum). Le ratio minimal processeur/mémoire autorisé est de 1:1. Si le ratio est inférieur à cette valeur, la demande de mémoire est augmentée.
| Nombre de conteneurs | Demande initiale | Demande modifiée |
|---|---|---|
| 1 | Processeur : 4 processeurs virtuels Mémoire : 1 Gio Stockage éphémère : 10 Mio |
Processeur : 4 processeurs virtuels Mémoire : 4 Gio Stockage éphémère : 10 Mio |
| Total des ressources du pod | Processeur : 4 processeurs virtuels Mémoire : 4 Gio Stockage éphémère : 10 Mio |
Étape suivante
- Découvrez comment sélectionner des classes de calcul dans vos charges de travail Autopilot.
- Obtenez plus d'informations sur les classes de calcul Autopilot compatibles.
- Découvrez comment sélectionner des GPU dans vos pods Autopilot.