Cette page décrit le mode Autopilot de fonctionnement dans Google Kubernetes Engine (GKE) et vous fournit des ressources que vous pouvez utiliser pour planifier, configurer et gérer vos clusters.
Qu'est-ce qu'Autopilot ?
GKE Autopilot est un mode d'opération dans GKE, dans lequel Google gère la configuration de votre cluster, y compris vos nœuds, le scaling, la sécurité et d'autres paramètres préconfigurés. Les clusters Autopilot sont optimisés pour exécuter la plupart des charges de travail de production et provisionner des ressources de calcul en fonction de vos fichiers manifestes Kubernetes. La configuration simplifiée respecte les bonnes pratiques et recommandations de GKE concernant la configuration, l'évolutivité et la sécurité des clusters et des charges de travail. Pour obtenir la liste des paramètres intégrés, reportez-vous au tableau de comparaison Standard et Autopilot.
Tarifs
Vous ne payez que pour le processeur, la mémoire et l'espace de stockage demandés par vos charges de travail lors de l'exécution sur GKE Autopilot.
La capacité inutilisée n'est pas facturée sur vos nœuds, car GKE les gère. Les pods système, les coûts du système d'exploitation et les charges de travail non planifiées ne vous sont pas facturés. Pour en savoir plus sur la tarification, consultez la page Tarifs d'Autopilot.
Avantages
- Concentrez-vous sur vos applications : Google gère l'infrastructure, de sorte que vous pouvez vous concentrer sur la création et le déploiement de vos applications.
- Sécurité : les clusters ont une configuration renforcée par défaut, avec de nombreux paramètres de sécurité activés par défaut. GKE applique automatiquement les correctifs de sécurité à vos nœuds lorsqu'ils sont disponibles, conformément à tous les calendriers de maintenance que vous avez configurés.
- Tarification : le modèle de tarification Autopilot simplifie les prévisions de facturation et l'attribution, car il est basé sur les ressources demandées par vos pods.
- Gestion des nœuds : Google gère les nœuds de calcul. Vous n'avez donc pas besoin de créer de nouveaux nœuds pour adapter vos charges de travail, ni de configurer des mises à niveau et des réparations automatiques.
- Scaling : lorsque vos charges de travail subissent une charge élevée et que vous ajoutez des pods pour gérer le trafic, par exemple avec l'autoscaling horizontal des pods de Kubernetes, GKE provisionne automatiquement de nouveaux nœuds pour ces pods, et développe automatiquement les ressources de vos nœuds existants en fonction des besoins.
- Planification : Autopilot gère la création de packages pour les pods à votre place. Vous n'avez donc pas besoin de réfléchir au nombre de pods en cours d'exécution sur chaque nœud. Vous pouvez contrôler davantage l'emplacement des pods à l'aide de mécanismes Kubernetes tels que la topologie d'affinité et de répartition des pods.
- Gestion des ressources : si vous déployez des charges de travail sans définir de valeurs de ressources telles que le processeur et la mémoire, Autopilot définit automatiquement les valeurs par défaut préconfigurées et modifie vos demandes de ressources au niveau de la charge de travail.
- Mise en réseau : Autopilot active par défaut certaines fonctionnalités de sécurité réseau, telles que la garantie que tout le trafic réseau des pods passe par vos règles de pare-feu de cloud privé virtuel, même si le trafic est dirigé vers d'autres pods dans le cluster.
- Gestion des versions : tous les clusters Autopilot sont enregistrés dans une version disponible GKE, ce qui garantit que votre plan de contrôle et vos nœuds s'exécutent sur les dernières versions qualifiées dans cette version.
- Flexibilité gérée : si vos charges de travail comportent des exigences spécifiques en termes de matériel ou de ressources, telles qu'un processeur ou une mémoire élevés, Autopilot propose des classes de calcul préconfigurées conçues pour ces charges de travail. Vous demandez la classe de calcul dans votre déploiement au lieu de devoir créer manuellement des nœuds qui s'appuient sur des types de machines et du matériel personnalisés. Vous pouvez également sélectionner des GPU pour accélérer les charges de travail, telles que les applications par lot ou IA/ML.
- Réduction de la complexité opérationnelle : Autopilot réduit les frais d'administration de la plate-forme en supprimant la nécessité de surveiller en permanence les nœuds, le scaling et la planification des opérations.
Autopilot est fourni avec un contrat de niveau de service qui couvre à la fois le plan de contrôle et la capacité de calcul utilisée par vos pods.
Planifier vos clusters Autopilot
Avant de créer un cluster, planifiez et concevez votre architecture Google Cloud. Dans Autopilot, vous demandez du matériel dans les spécifications de votre charge de travail. GKE provisionne et gère l'infrastructure correspondante pour exécuter ces charges de travail. Par exemple, si vous exécutez des charges de travail de machine learning, vous demandez des accélérateurs matériels. Si vous développez des applications Android, vous demandez des processeurs Arm.
Planifiez et demandez des quotas pour votre projet ou votre organisation Google Cloud en fonction de l'échelle de vos charges de travail. GKE ne peut provisionner l'infrastructure de vos charges de travail que si votre projet dispose d'un quota suffisant pour ce matériel.
Tenez compte des facteurs suivants lors de la planification :
- Taille et échelle estimées du cluster
- Type de charge de travail
- Topologie et utilisation des clusters
- Mise en réseau et configuration
- Configuration de la sécurité
- Gestion et maintenance des clusters
- Déploiement et gestion des charges de travail
- Journalisation et surveillance
Les sections suivantes fournissent des informations et des ressources utiles à prendre en compte.
Mise en réseau
Lorsque vous créez un cluster Autopilot avec une mise en réseau publique, les charges de travail du cluster peuvent communiquer entre elles et avec Internet. Il s'agit du mode de mise en réseau par défaut. Google Cloud et Kubernetes fournissent diverses fonctionnalités et capacités de mise en réseau supplémentaires que vous pouvez exploiter en fonction de votre cas d'utilisation, telles que des clusters avec mise en réseau privée.
La mise en réseau dans Kubernetes et dans le cloud est complexe. Assurez-vous de bien comprendre les concepts de base de la mise en réseau avant de commencer à modifier les valeurs par défaut définies par Google Cloud. Le tableau suivant fournit différentes ressources pour mieux comprendre la mise en réseau dans GKE en fonction de votre cas d'utilisation :
| Cas d'utilisation | Ressources |
|---|---|
| Comprendre le fonctionnement de la mise en réseau dans Kubernetes et GKE |
Après avoir étudié le modèle de mise en réseau, réfléchissez aux exigences de votre organisation concernant la mise en réseau et la sécurité du réseau. Choisissez les fonctionnalités de mise en réseau GKE et Google Cloud qui répondent à ces critères. |
| Planifier la configuration de mise en réseau GKE | Nous vous recommandons de comprendre les quotas de mise en réseau pour GKE, tels que les points de terminaison par service et les limites de requêtes API. Les ressources suivantes vous aideront à planifier des aspects spécifiques de votre configuration réseau :
|
| Exposer vos charges de travail |
|
| Exécuter des services connectés hautement disponibles dans plusieurs clusters | Utilisez des services multiclusters (MCS). |
| Équilibrer la charge du trafic entrant |
|
| Configurer la sécurité du réseau du cluster |
|
| Observer le trafic réseau Kubernetes |
|
Mise à l'échelle
L'exploitation efficace d'une plate-forme à grande échelle nécessite une planification et une réflexion approfondie. Vous devez tenir compte de l'évolutivité de votre conception, qui correspond à la capacité de vos clusters à se développer tout en respectant les objectifs de niveau de service (SLO). Pour obtenir des conseils détaillés à la fois pour les administrateurs de la plate-forme et pour les développeurs, consultez les consignes liées à la création de clusters évolutifs.
Vous devez également prendre en compte les quotas et limites de GKE, en particulier si vous envisagez d'exécuter de grands clusters avec des milliers de pods potentiellement.
Scaling des charges de travail Autopilot
Dans Autopilot, GKE effectue un scaling automatique de vos nœuds en fonction du nombre de pods présents dans le cluster. Pour effectuer le scaling automatique du nombre de pods de votre cluster, nous vous recommandons d'utiliser un mécanisme tel que l'autoscaling horizontal des pods de Kubernetes, qui permet d'effectuer un scaling des pods en fonction des métriques intégrées de processeur et de mémoire, ou des métriques personnalisées de Cloud Monitoring. Pour apprendre à configurer le scaling en fonction de diverses métriques, consultez la section Optimiser l'autoscaling des pods en fonction des métriques.
Sécurité
Les clusters Autopilot activent et appliquent les bonnes pratiques et les paramètres de sécurité par défaut, y compris de nombreuses recommandations de la section Renforcer la sécurité des clusters et la Présentation de la sécurité GKE.
Si vous souhaitez en savoir plus sur les mesures de renforcement Autopilot et sur la mise en œuvre de vos exigences de sécurité spécifiques, consultez la section Mesures de sécurité dans Autopilot.
Créer un cluster
Une fois que vous avez planifié votre environnement et compris vos exigences, créez un cluster Autopilot. Les nouveaux clusters Autopilot sont des clusters régionaux dont l'adresse IP est accessible au public. Chaque cluster inclut des mesures de renforcement de base, ainsi qu'un scaling automatique et d'autres fonctionnalités. Pour obtenir la liste complète des fonctionnalités préconfigurées, consultez la section Comparer GKE Autopilot et Standard.
Si vous souhaitez créer le cluster sans adresse IP publique, créez un cluster privé à la place.
Déployer des charges de travail sur Autopilot
Pour déployer une charge de travail sur un cluster Autopilot en cours d'exécution, écrivez un fichier manifeste Kubernetes et appliquez-le au cluster. Par défaut, les clusters Autopilot sont optimisés pour exécuter la plupart des charges de travail de production.
Pour accéder à un guide interactif dans la console Google Cloud concernant le déploiement et l'exposition d'une application, cliquez sur Visite guidée :
Certaines de vos charges de travail peuvent avoir des exigences matérielles spécifiques, telles que des charges de travail de ML nécessitant des accélérateurs matériels ou des tests d'applications mobiles nécessitant une architecture Arm. Autopilot comprend des classes de calcul configurées par Google Cloud pour exécuter des charges de travail ayant des exigences de calcul particulières. Lors du déploiement de ces charges de travail, demandez une classe de calcul dans le fichier manifeste. Secondé par des machines spécialisées, Autopilot provisionne automatiquement les nœuds, gère la planification et alloue du matériel.
Le tableau suivant présente certaines exigences courantes et fournit des recommandations sur la marche à suivre :
| Cas d'utilisation | Ressources |
|---|---|
| Exécuter des charges de travail Arm | Demandez la classe de calcul Scale-Out et l'architecture arm64 dans votre fichier manifeste. Pour obtenir des instructions, consultez la section Déployer des charges de travail Autopilot sur l'architecture Arm. |
| Exécuter des charges de travail d'IA/ML accélérées | Demandez des GPU dans votre fichier manifeste. Pour obtenir des instructions, consultez la section Déployer des charges de travail GPU dans Autopilot. |
| Exécuter des charges de travail nécessitant une capacité de calcul ou de mémoire élevée | Demandez la classe de calcul Balanced. Pour obtenir des instructions, consultez la section Choisir les classes de calcul pour les pods Autopilot. |
| Exécuter des charges de travail nécessitant un scaling horizontal plus efficace de la capacité CPU et des calculs monothread par cœur | Demandez la classe de calcul Scale-Out. Pour obtenir des instructions, consultez la section Choisir les classes de calcul pour les pods Autopilot. |
| Exécuter des charges de travail tolérantes aux pannes telles que les tâches par lot à moindre coût | Spécifiez les pods Spot dans le fichier manifeste. Pour obtenir des instructions, consultez la section Exécuter des charges de travail tolérantes aux pannes à moindre coût avec des pods Spot. Vous pouvez utiliser n'importe quelle classe de calcul ou configuration matérielle avec les pods Spot. |
| Exécuter des charges de travail nécessitant des interruptions minimales, telles que des serveurs de jeu ou des files d'attente de travail | Spécifiez l'annotation cluster-autoscaler.kubernetes.io/safe-to-evict=false dans la spécification de pod. Les pods sont protégés contre l'éviction provoquée par des mises à niveau automatiques des nœuds ou des événements de réduction de capacité pendant sept jours maximum.
Pour obtenir des instructions, consultez la section Prolonger la durée d'exécution des pods Autopilot. |
Autopilot vous permet de demander des ressources de processeur, de mémoire et de stockage éphémères pour vos charges de travail. Les plages autorisées varient selon que vous souhaitez exécuter vos pods sur la plate-forme de calcul à usage général par défaut ou sur une classe de calcul.
Pour en savoir plus sur les demandes de ressources de conteneur par défaut et les plages de ressources autorisées, consultez la page Demandes de ressources dans Autopilot.
Séparation de la charge de travail
Les clusters Autopilot sont compatibles avec l'utilisation de sélecteurs de nœuds et de l'affinité des nœuds pour configurer la séparation des charges de travail. La séparation des charges de travail est utile lorsque vous devez indiquer à GKE de placer des charges de travail sur des nœuds répondant à des critères spécifiques, tels que des libellés de nœuds personnalisés. Par exemple, vous pouvez indiquer à GKE de planifier des pods de serveur de jeu sur des nœuds portant le libellé game-server, et d'éviter de programmer d'autres pods sur ces nœuds.
Pour en savoir plus, consultez la page Configurer la séparation des charges de travail dans GKE.
Planifier des pods dans des zones spécifiques à l'aide de la topologie zonale
Si vous devez placer des pods dans une zone Google Cloud spécifique, par exemple pour accéder aux informations sur un disque persistant Compute Engine zonal, consultez la section Placer les pods GKE dans des zones spécifiques.
Affinité et anti-affinité de pods
Utilisez l'affinité et l'anti-affinité de pods pour colocaliser les pods sur un seul nœud ou pour que certains pods évitent d'autres pods. L'affinité et l'anti-affinité de pods indiquent à Kubernetes de prendre une décision de planification basée sur les libellés des pods exécutés sur les nœuds d'un domaine de topologie spécifique, tel qu'une région ou une zone spécifique. Par exemple, vous pouvez indiquer à GKE d'éviter de planifier des pods d'interface avec d'autres pods d'interface sur les mêmes nœuds afin d'améliorer la disponibilité en cas de panne.
Pour obtenir des instructions et plus de détails, consultez la section Affinité et anti-affinité de pods.
Dans GKE, vous pouvez utiliser l'affinité et l'anti-affinité de pods avec les libellés suivants dans topologyKey :
topology.kubernetes.io/zonekubernetes.io/hostname
Contraintes de répartition de la topologie des pods
Pour améliorer la disponibilité de vos charges de travail à mesure que Kubernetes adapte le nombre de pods, vous pouvez définir des contraintes de répartition de la topologie des pods. Cela permet de contrôler la manière dont Kubernetes répartit vos pods sur les nœuds d'un domaine de topologie, tel qu'une région. Par exemple, vous pouvez indiquer à Kubernetes de placer un nombre spécifique de pods de session de serveur de jeu dans chacune des trois zones Google Cloud de la région us-central1.
Pour obtenir des exemples, des détails et des instructions, consultez la page Contraintes de répartition de la topologie des pods.
Gérer et surveiller vos clusters Autopilot
Dans Autopilot, GKE gère automatiquement les mises à niveau et la maintenance des clusters pour le plan de contrôle et les nœuds de calcul. Les clusters Autopilot disposent également de fonctionnalités intégrées pour surveiller vos clusters et vos charges de travail.
Mises à niveau des versions de GKE
Tous les clusters Autopilot sont enregistrés dans un canal de distribution. Dans les canaux de publication, GKE gère la version Kubernetes du cluster, en équilibrant la disponibilité des fonctionnalités et la stabilité des versions en fonction du canal. Par défaut, les clusters Autopilot sont enregistrés dans la version disponible standard, mais vous pouvez sélectionner une autre version répondant à vos besoins en matière de stabilité et de fonctionnalités. Pour en savoir plus sur les versions disponibles, consultez la page À propos des versions disponibles.
GKE lance automatiquement les mises à niveau, surveille la progression et met en pause l'opération si des problèmes surviennent. Vous pouvez contrôler manuellement le processus de mise à niveau de différentes manières :
- Pour contrôler à quel moment GKE peut effectuer des mises à niveau automatiques, créez des intervalles de maintenance. Par exemple, vous pouvez définir l'intervalle de maintenance la nuit avant la réinitialisation hebdomadaire de votre jeu multijoueur afin que les joueurs puissent se connecter lors de la réinitialisation sans interruption.
- Pour contrôler à quel moment GKE ne peut pas lancer de mises à niveau automatiques pendant une période spécifique, utilisez des exclusions de maintenance. Par exemple, vous pouvez définir une exclusion de maintenance lors du Black Friday et du Cyber Monday afin que vos clients puissent effectuer leurs achats en toute tranquillité.
- Pour obtenir une nouvelle version avant le début des mises à niveau automatiques, mettez à niveau manuellement le plan de contrôle. GKE rapproche la version du nœud de la version du plan de contrôle au fil du temps.
- Pour obtenir une version de correctif disponible uniquement dans un canal de publication plus récent, consultez la page Exécuter des versions de correctif à partir d'un canal plus récent. Par exemple, vous pouvez avoir besoin d'une version de correctif spécifique pour limiter une divulgation de failles récente.
Surveiller vos clusters Autopilot
Cloud Logging, Cloud Monitoring et Google Cloud Managed Service pour Prometheus sont déjà activés sur les clusters Autopilot.
Les clusters Autopilot collectent automatiquement les types de journaux et de métriques suivants, conformément aux bonnes pratiques de Google pour la collecte de télémétrie :
Journaux pour Cloud Logging
- Journaux système
- Journaux de charge de travail
- Journaux d'audit pour les activités d'administration
- Journaux d'audit des accès aux données
Métriques pour Cloud Monitoring
- System metrics
- Métriques de charge de travail (depuis Managed Service pour Prometheus)
Aucune configuration supplémentaire n'est requise pour activer la journalisation et la surveillance. Le tableau suivant vous indique comment interagir avec les données de télémétrie collectées en fonction de vos besoins :
| Cas d'utilisation | Ressources |
|---|---|
| Comprendre vos journaux GKE et y accéder |
|
| Observer les performances de vos clusters GKE | Une surveillance efficace des performances de vos clusters peut vous aider à optimiser les coûts d'exploitation de vos clusters et de vos charges de travail.
|
| Surveiller la stratégie de sécurité de vos clusters | Utilisez le tableau de bord de stratégie de sécurité pour auditer vos charges de travail en cours d'exécution par rapport aux bonnes pratiques de GKE, rechercher les failles dans vos systèmes d'exploitation de conteneurs et packages de langages, et obtenir des recommandations d'atténuation des risques exploitables. Pour en savoir plus, consultez la section À propos du tableau de bord de stratégie de sécurité. |
Dépannage
Pour connaître les étapes de dépannage, consultez la page Résoudre les problèmes liés aux clusters Autopilot.