Cette page a été traduite par l'API Cloud Translation.

À propos des charges de travail en mode Autopilot dans GKE Standard

Autopilot Standard

Vous pouvez utiliser ComputeClasses pour exécuter des charges de travail Google Kubernetes Engine (GKE) Autopilot dans vos clusters GKE en mode Standard. Cette page décrit les méthodes que vous pouvez utiliser pour exécuter vos charges de travail en mode Autopilot et vous aide à décider quand exécuter une charge de travail dans un mode spécifique.

Ces informations sont destinées aux personnes suivantes :

Architectes cloud qui souhaitent optimiser les coûts opérationnels dans les organisations.
Administrateurs de plate-forme qui souhaitent réduire les frais généraux liés à la gestion manuelle de l'infrastructure.
Ingénieurs en fiabilité des sites (SRE) qui souhaitent transférer la maintenance, les mises à niveau et le scaling de l'infrastructure vers Google Cloud lorsque cela est possible.

Vous devez déjà connaître les concepts suivants :

À propos de GKE Autopilot

Autopilot est un mode de fonctionnement de GKE dans lequel Google gère l'infrastructure de vos nœuds, le scaling, la sécurité et les fonctionnalités préconfigurées. Le mode Autopilot est optimisé pour exécuter la plupart des charges de travail de production dans un environnement qui applique les paramètres recommandés pour la sécurité, la fiabilité, les performances et l'évolutivité. Pour choisir entre le mode Autopilot et le mode Standard en fonction de vos besoins, consultez À propos des modes de fonctionnement GKE.

Vous pouvez utiliser le mode Autopilot de différentes manières :

Créer un cluster en mode Autopilot : Google gère l'intégralité du cluster et applique les bonnes pratiques en matière d'automatisation, de fiabilité, de sécurité et de coûts.
Exécuter des charges de travail en mode Autopilot dans des clusters Standard : vous déployez des ComputeClasses Autopilot et les sélectionnez dans les charges de travail. Google gère les nœuds que GKE crée pour ces charges de travail spécifiques. Vous contrôlez le cluster et pouvez exécuter vos propres pools de nœuds en plus des nœuds gérés par GKE.

À propos du mode Autopilot pour les ComputeClasses

Une ComputeClass est une ressource personnalisée Kubernetes qui définit une liste de configurations de nœuds, comme des types de machines ou des paramètres de fonctionnalités. Vous pouvez sélectionner des ComputeClasses spécifiques dans les spécifications de charge de travail Kubernetes. Lorsqu'une charge de travail qui sélectionne une ComputeClass a besoin d'un nouveau nœud, GKE tente de provisionner le nœud avec l'une des configurations déclarées par la ComputeClass. GKE essaie chaque configuration de la ComputeClass dans l'ordre et passe à la configuration suivante si la création du nœud échoue. Pour en savoir plus, consultez À propos des ComputeClasses personnalisées.

Pour exécuter des charges de travail Autopilot dans vos clusters GKE Standard, vous devez activer le mode Autopilot dans une ComputeClass et sélectionner cette ComputeClass dans des charges de travail spécifiques. Google gère tous les nouveaux nœuds que GKE provisionne pour ces charges de travail, de la même manière qu'il gère les nœuds dans les clusters Autopilot. La plupart des avantages et des fonctionnalités de sécurité du mode Autopilot s'appliquent à ces charges de travail et aux nœuds hôtes.

Les ComputeClasses en mode Autopilot offrent aux administrateurs de cluster une flexibilité supplémentaire pour choisir le niveau de contrôle souhaité sur des charges de travail et une infrastructure spécifiques de leur cluster, par exemple :

Vous pouvez laisser GKE gérer entièrement des charges de travail spécifiques en les exécutant en mode Autopilot.
Vous conservez un contrôle total sur les charges de travail et l'infrastructure qui n'utilisent pas le mode Autopilot, comme les pools de nœuds créés manuellement.
Vous pouvez définir une ComputeClass Autopilot comme classe par défaut pour votre cluster ou votre espace de noms. Les charges de travail s'exécutent alors en mode Autopilot, sauf si elles demandent explicitement une autre option.

Ces options permettent aux administrateurs de cluster de choisir le niveau et le champ d'application d'Autopilot.

Vous pouvez laisser GKE gérer entièrement des charges de travail spécifiques en les exécutant en mode Autopilot.
Vous conservez un contrôle total sur les charges de travail et l'infrastructure qui n'utilisent pas le mode Autopilot, comme les pools de nœuds créés manuellement.
Vous pouvez définir une ComputeClass Autopilot comme classe par défaut pour votre cluster ou votre espace de noms. Les charges de travail s'exécutent alors en mode Autopilot, sauf si elles demandent explicitement une autre option.

Ces options permettent aux administrateurs de cluster de choisir le niveau et le champ d'application d'Autopilot.

Avantages des ComputeClasses Autopilot dans les clusters standards

L'exécution de certaines de vos charges de travail en mode Autopilot offre les avantages suivants :

Réduisez les coûts de gestion de l'infrastructure : Google met à niveau, gère, configure et ajuste des nœuds spécifiques pour vous.
Utiliser le modèle de tarification Autopilot : les charges de travail qui utilisent une ComputeClass Autopilot sont facturées selon le modèle de tarification Autopilot. Ce modèle tarifaire inclut la facturation par pod pour les charges de travail qui ne demandent pas de matériel spécifique. Pour en savoir plus, consultez la section Tarifs.
Améliorer le scaling et la sécurité : les charges de travail Autopilot bénéficient d'avantages tels que l'accès à la plate-forme de calcul optimisée pour les conteneurs, des contraintes de sécurité par défaut améliorées et l'autoscaling des nœuds en fonction des demandes de ressources. Les nœuds de ces charges de travail utilisent des fonctionnalités telles que les mises à niveau automatiques des nœuds et les réparations automatiques.
Améliorer la fiabilité : le contrat de niveau de service (SLA) de GKE inclut un objectif de niveau de service (SLO) de disponibilité des pods pour Autopilot.

De nombreux avantages sont également fournis par les clusters Autopilot, qui offrent également une expérience plus gérée que les clusters standards et incluent de nombreux avantages en termes de sécurité, de mise en réseau et de gestion des ressources. Pour en savoir plus, consultez la présentation d'Autopilot.

Sélection du matériel dans les ComputeClasses Autopilot

Dans les ComputeClasses Autopilot, vous pouvez sélectionner du matériel spécifique pour vos nœuds (comme des GPU ou des types de machines), ou vous pouvez laisser GKE placer les pods sur une plate-forme de calcul à usage général optimisée pour les conteneurs. L'option à usage général est recommandée pour la plupart des charges de travail de production qui ne nécessitent pas de matériel spécifique pour fonctionner correctement.

Le tableau suivant décrit ces options de configuration, comment en choisir une dans une ComputeClass et comment ce choix affecte votre modèle de facturation :

**Tableau 1.** Sélection du matériel dans les ComputeClasses Autopilot
Exigence de charge de travail	Configuration recommandée de ComputeClass	Modèle de facturation
Charges de travail à usage général	Utilisez une ComputeClass Autopilot avec la règle de priorité `podFamily` pour exécuter des charges de travail qui ne nécessitent pas de matériel spécifique sur la plate-forme de calcul optimisée pour les conteneurs Autopilot. Cette plate-forme convient aux charges de travail à usage général, comme les suivantes : Serveurs Web Jobs basés sur des événements Traitement par lot Pipelines CI/CD Les ComputeClasses Autopilot intégrées disponibles pour les clusters standards utilisent la règle de priorité `podFamily`.	Modèle de facturation basé sur les pods
Charges de travail nécessitant du matériel spécifique	Utilisez une ComputeClass qui utilise n'importe quelle règle de configuration matérielle disponible, telle que la règle `machineFamily` ou la règle `gpus`.	Modèle de facturation basé sur les nœuds

Configuration d'Autopilot dans ComputeClasses

Vous pouvez utiliser le mode Autopilot dans un cluster Standard en utilisant une ComputeClass Autopilot intégrée fournie par GKE ou en activant Autopilot dans n'importe quelle ComputeClass personnalisée que vous créez. Les sections suivantes décrivent chaque option.

Classes de calcul Autopilot intégrées

GKE configure des ComputeClasses Autopilot spécifiques pour vous. Vous pouvez sélectionner ces classes Autopilot intégrées dans n'importe quel cluster éligible. Les ComputeClasses Autopilot intégrées aux clusters standards utilisent la règle de priorité podFamily pour exécuter les pods sur la plate-forme de calcul optimisée pour les conteneurs. Pour en savoir plus, consultez À propos des ComputeClasses intégrées dans GKE.

Classes de calcul Autopilot personnalisées

Vous pouvez activer Autopilot dans n'importe quelle ComputeClass personnalisée que vous gérez. Cette option est utile si vos charges de travail ont des exigences matérielles spécifiques. Le champ autopilot de la ressource personnalisée ComputeClass vous permet d'activer ou de désactiver Autopilot dans une ComputeClass spécifique.

Pour activer Autopilot dans une ComputeClass existante, vous devez la supprimer, mettre à jour la configuration, puis recréer la ComputeClass dans votre cluster. Vos modifications s'appliquent à tous les nouveaux nœuds que GKE crée pour les charges de travail que vous déployez après avoir mis à jour la ComputeClass Autopilot.

Pour savoir comment activer Autopilot dans vos classes de calcul personnalisées, consultez Sélectionner du matériel spécifique pour vos pods Autopilot.

Tarifs

La tarification de GKE Autopilot s'applique aux nœuds et aux charges de travail que GKE crée pour une ComputeClass Autopilot. Le tableau suivant décrit le modèle de facturation qui s'applique aux différentes configurations ComputeClass Autopilot dans vos clusters en mode Standard.

**Tableau 3.** Tarifs des ComputeClasses Autopilot
Modèles de facturation pour différentes configurations ComputeClass
Modèle de facturation basé sur les pods	Le modèle de facturation basé sur les pods s'applique aux classes de calcul Autopilot qui utilisent la règle de priorité `podFamily` au lieu de sélectionner des machines ou du matériel spécifiques. Les ComputeClasses Autopilot intégrées, qui utilisent la règle `podFamily`, utilisent le modèle de facturation basé sur les pods.
Modèle de facturation basé sur les nœuds	Le modèle de facturation basé sur les nœuds s'applique aux classes de calcul Autopilot qui demandent explicitement des configurations de nœuds spécifiques, telles que les instances N2 ou les GPU.

Les tarifs Autopilot ne s'appliquent qu'aux charges de travail et aux nœuds qui utilisent une ComputeClass Autopilot. Votre cluster en mode Standard et tous les autres pools de nœuds que vous exécutez continuent d'utiliser la tarification du mode GKE Standard.

Paramètres préconfigurés pour les nœuds gérés par Autopilot

Avant d'activer le mode Autopilot dans vos ComputeClasses, sachez à quoi vous attendre des nœuds que GKE crée pour exécuter les charges de travail Autopilot. Google configure des fonctionnalités et des contraintes de sécurité spécifiques dans les nœuds Autopilot. Par conséquent, les charges de travail qui se déploient et fonctionnent correctement dans vos nœuds en mode Standard peuvent être refusées par le mode Autopilot si elles ne répondent pas à ses exigences de sécurité.

Le tableau suivant décrit les configurations de fonctionnalités qui remplacent les paramètres correspondants de votre cluster Standard. Si une configuration ne figure pas dans ce tableau, les nœuds Autopilot utilisent le paramètre du cluster Standard. Par exemple, la fédération d'identité de charge de travail pour GKE ne figure pas dans ce tableau, ce qui signifie que le paramètre de fédération d'identité de charge de travail pour GKE du cluster Standard s'applique aux nœuds Autopilot créés par GKE.

**Tableau 4.** Paramètres préconfigurés pour les nœuds Autopilot
Fonctionnalité	Paramètre standard au niveau du cluster	Paramètre de nœud géré par Autopilot
Mises à niveau et maintenance des nœuds	Configurable : Réparation automatique des nœuds Mise à jour automatique des nœuds Stratégie de mise à niveau des nœuds	Préconfiguré : Réparation automatique des nœuds : activée Mise à niveau automatique des nœuds : activée Stratégie de mise à niveau des nœuds : Mises à niveau par pics avec des paramètres préconfigurés
Autoscaling	Configurable : Profil d'autoscaling	Profil d'autoscaling `optimize-utilization` préconfiguré
Mise en réseau	VPC natif ou basé sur le routage	Nécessite un cluster de VPC natif
Sécurité	Configurable : Compte de service IAM de nœud Niveaux d'accès Démarrage sécurisé	Préconfiguré : Compte de service IAM du nœud : utilise le compte de service pour le provisionnement automatique des nœuds. Champs d'application de l'accès : utilise les champs d'application de l'accès pour le provisionnement automatique des nœuds. Démarrage sécurisé : activé Contraintes de sécurité des nœuds : configurations de sécurité Autopilot intégrées, appliquées au mieux.
Système d'exploitation du nœud	Configurable : Image de nœud Configuration du système de nœud Mode cgroup de Linux	Préconfiguré : Image de nœud : Container-Optimized OS avec containerd Configuration du système de nœud : configurable uniquement avec le champ `nodeSystemConfig` ComputeClass. Mode cgroup : v2
Disque de démarrage du nœud	Configurable : Type de disque de démarrage Taille du disque de démarrage	Configurable : Type de disque de démarrage : utilise la valeur du champ ComputeClass `storage.bootDiskType`. Si ce champ n'est pas défini, GKE définit le type de disque de démarrage comme suit : Si la ComputeClass utilise des règles `podFamily`, GKE utilise un disque `pd-balanced`. Si la ComputeClass n'utilise pas de règles `podFamily`, GKE utilise le type de disque de démarrage par défaut pour le cluster. Taille du disque de démarrage : GKE utilise la valeur du champ `storage.bootDiskSize` de la classe de calcul. Si ce champ n'est pas défini, GKE définit la taille du disque de démarrage comme suit : Si vous définissez une taille de disque de démarrage par défaut pour le provisionnement automatique des nœuds, GKE utilise cette valeur. Si vous ne définissez pas de taille de disque de démarrage par défaut pour le provisionnement automatique des nœuds, GKE utilise la taille par défaut du cluster.
Métadonnées de nœud	Tags Resource Manager pour les règles de pare-feu : les modifications apportées aux tags au niveau du cluster n'affectent pas les nœuds existants.	Tags Resource Manager pour les stratégies de pare-feu : les modifications apportées aux tags au niveau du cluster affectent les nœuds existants.

Demandes de ressources pour les charges de travail Autopilot

Pour que les charges de travail Autopilot s'exécutent efficacement, GKE applique certaines valeurs minimales et maximales pour les demandes de processeur, de mémoire et de stockage éphémère dans vos pods. GKE applique également des demandes par défaut aux pods qui ne demandent pas explicitement l'une de ces ressources. Les valeurs spécifiques des exigences minimales, maximales et par défaut en termes de ressources dans les charges de travail GKE Autopilot varient en fonction du type de matériel utilisé par vos pods.

Pour le stockage éphémère, la valeur par défaut si vous ne demandez pas de stockage éphémère est la même pour toutes les classes de calcul et sélections matérielles. Pour en savoir plus, consultez Demandes de ressources par défaut.

Le tableau suivant fournit des liens vers les exigences en termes de processeur et de mémoire pour vos requêtes de pods, en fonction du type de matériel :

**Tableau 5.** Exigences en termes de processeur et de mémoire pour Autopilot
Type de ressource	Requêtes minimales et maximales	Requêtes par défaut
Pods à usage général Règle de priorité `podFamily`	Consultez la ligne "Usage général" du tableau Valeurs minimales et maximales pour les ComputeClasses.	Consultez la ligne "Usage général" dans le tableau Requêtes par défaut pour les ComputeClasses.
GPU et TPU	Dépend du type et de la quantité d'accélérateur matériel. Pour en savoir plus, consultez Valeurs minimales et maximales de la classe de calcul Accelerator.	Dépend du type et de la quantité d'accélérateur matériel. Pour en savoir plus, consultez Demandes par défaut pour les accélérateurs.
Types et familles de machines Compute Engine spécifiques	Minimum : aucune valeur minimale pour le processeur ou la mémoire. Maximum : la valeur maximale correspond à la capacité de ressources de l'instance Compute Engine.	Pour tout type ou famille de machines Compute Engine, les requêtes par défaut dans la ligne "Usage général" du tableau Requêtes par défaut pour les ComputeClasses.