Présentation de GKE Autopilot

Autopilot est un mode de fonctionnement géré dans Google Kubernetes Engine (GKE). Cette page décrit les avantages du mode Autopilot et fournit des informations sur la planification des clusters, le déploiement des charges de travail, et la configuration de la mise en réseau et de la sécurité. Les administrateurs, les architectes et les opérateurs peuvent utiliser ces informations pour prendre des décisions éclairées lorsqu'ils évaluent la compatibilité du mode Autopilot de GKE avec les exigences opérationnelles de leurs charges de travail conteneurisées.

Pour en savoir plus sur les différences entre les modes de fonctionnement dans GKE, consultez Comparer GKE Autopilot et Standard.

Qu'est-ce qu'Autopilot ?

GKE Autopilot est un mode d'opération dans GKE, dans lequel Google gère la configuration de votre infrastructure, y compris vos nœuds, le scaling, la sécurité et d'autres paramètres préconfigurés. Le mode Autopilot est optimisé pour exécuter la plupart des charges de travail de production et provisionner des ressources de calcul en fonction de vos fichiers manifestes Kubernetes.

Vous pouvez exécuter un cluster entier en mode Autopilot, de sorte que le cluster et toutes ses charges de travail suivent les bonnes pratiques et recommandations de GKE concernant le scaling, la sécurité, les mises à niveau et la configuration des nœuds. Vous pouvez également exécuter des charges de travail spécifiques en mode Autopilot dans des clusters GKE Standard. Cette option vous permet d'utiliser Autopilot dans des environnements où vous avez toujours besoin d'un contrôle manuel de votre infrastructure. Pour en savoir plus, consultez À propos des charges de travail en mode Autopilot dans GKE Standard.

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 Autopilot présentent 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 d'Autopilot simplifie les prévisions de facturation et l'attribution.
  • 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 transmission de tout le trafic réseau des pods via 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 un 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 ce canal.
  • Flexibilité gérée : si vos charges de travail comportent des exigences spécifiques en termes de matériel ou de ressources, telles que des GPU, vous pouvez définir ces exigences dans des ComputeClasses. Lorsque vous demandez une ComputeClass dans votre charge de travail, GKE utilise vos exigences pour configurer les nœuds de vos pods. Vous n'avez pas besoin de configurer manuellement le matériel pour les nœuds ou pour les charges de travail individuelles.
  • 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.

À propos de la plate-forme de calcul optimisée pour les conteneurs Autopilot

Dans GKE 1.32.3-gke.1927002 et versions ultérieures, Autopilot inclut une plate-forme de calcul spécialisée optimisée pour les conteneurs pour vos charges de travail. Cette plate-forme fonctionne bien pour la plupart des charges de travail à usage général qui ne nécessitent pas de matériel spécifique, telles que les serveurs Web et les jobs par lot à intensité moyenne.

La plate-forme de calcul optimisée pour les conteneurs utilise des nœuds GKE Autopilot qui peuvent être redimensionnés de manière dynamique pendant l'exécution. Elle est conçue pour effectuer un scaling à la hausse à partir de fractions de processeur avec un minimum d'interruption. Ce redimensionnement dynamique réduit considérablement le temps nécessaire pour provisionner une nouvelle capacité à mesure que vos charges de travail évoluent. Pour améliorer la vitesse de scaling et de redimensionnement, GKE gère également un pool de capacité de calcul préprovisionnée qui peut être automatiquement allouée aux charges de travail en réponse à une augmentation des demandes de ressources. Étant donné que la série de machines sous-jacente n'est pas fixe, les performances par processeur varient en fonction de la série de machines sur laquelle GKE planifie votre pod.

La plate-forme de calcul optimisée pour les conteneurs offre les avantages suivants :

  • La capacité de calcul correspond aux charges de travail : Autopilot ajuste de manière dynamique la capacité de calcul de la plate-forme de calcul optimisée pour les conteneurs en fonction de facteurs tels que le nombre de pods et la consommation de ressources. Par conséquent, la capacité de calcul du cluster correspond aux besoins de vos charges de travail.
  • Temps de scaling rapides : lors des événements de scaling à la hausse, GKE peut redimensionner dynamiquement les nœuds existants pour accueillir davantage de pods ou une consommation de ressources accrue. Ce provisionnement dynamique de la capacité signifie souvent que les nouveaux pods n'ont pas besoin d'attendre le démarrage de nouveaux nœuds. Le redimensionnement des nœuds n'est pas compatible avec les charges de travail Arm.
  • Compatibilité multi-architecture : la plate-forme de calcul optimisée pour les conteneurs est compatible avec les architectures x86 et Arm pour vos charges de travail à usage général. Par défaut, les charges de travail utilisent l'architecture x86. Vous pouvez exécuter des charges de travail sur la plate-forme Arm à usage général en spécifiant le sélecteur de nœud kubernetes.io/arch: arm64 ou en sélectionnant les ComputeClasses autopilot-arm ou autopilot-arm-spot.

Vous pouvez utiliser la plate-forme de calcul optimisée pour les conteneurs Autopilot de différentes manières :

Tarifs

La tarification d'Autopilot utilise différents modèles en fonction du type de matériel utilisé par vos pods, comme suit :

  • Pods Autopilot à usage général : les types de pods suivants utilisent un modèle de facturation basé sur les pods et sont classés comme pods à usage général :

    • Pods qui s'exécutent sur la plate-forme de calcul optimisée pour les conteneurs dans des clusters Autopilot ou des clusters standards.
    • Pods qui sélectionnent les ComputeClasses intégrées Balanced ou Scale-Out dans les clusters Autopilot.

    Pour en savoir plus, consultez la section "Charges de travail Autopilot à usage général" de la page Tarifs de Google Kubernetes Engine.

  • Charges de travail Autopilot qui sélectionnent du matériel spécifique : les pods qui sélectionnent du matériel spécifique (par exemple, des séries de machines Compute Engine, des accélérateurs matériels ou des ComputeClasses) utilisent un modèle de facturation basé sur les nœuds. Dans ce modèle, vous payez pour le matériel sous-jacent et une prime de gestion des nœuds.

    Pour en savoir plus, consultez la section "Charges de travail Autopilot qui sélectionnent du matériel spécifique" de la page Tarifs de Google Kubernetes Engine.

Clusters et charges de travail Autopilot

GKE vous permet d'utiliser le mode Autopilot pour des clusters entiers ou pour des charges de travail spécifiques dans vos clusters Standard. Les clusters Autopilot sont la méthode recommandée pour utiliser GKE, car l'ensemble du cluster utilise par défaut les bonnes pratiques de Google.

Cependant, certaines organisations ont des exigences de contrôle manuel ou de flexibilité qui nécessitent l'utilisation d'un cluster GKE Standard. Dans ce cas, vous pouvez toujours utiliser Autopilot pour des charges de travail spécifiques dans vos clusters standards, ce qui vous permet de bénéficier de nombreuses fonctionnalités Autopilot au niveau de la charge de travail.

Les sections suivantes vous expliquent comment planifier et créer des clusters Autopilot. Si vous disposez d'un cluster Standard et que vous souhaitez exécuter certaines de vos charges de travail en mode Autopilot, consultez À propos des charges de travail en mode Autopilot dans GKE Standard.

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.

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
  • Topologie et configuration de la mise en réseau
  • 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 utiliser en fonction de vos besoins, telles que des clusters avec mise en réseau privée.

La mise en réseau dans Kubernetes et dans le cloud est complexe. Avant de commencer à modifier les valeurs par défaut définies parGoogle Cloud , assurez-vous de bien comprendre les concepts de base de la mise en réseau. 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
  • Pour exposer vos applications sur Internet, utilisez les Services, qui vous permettent d'exposer une application s'exécutant dans un groupe de pods comme un service réseau unique.
  • Pour configurer les charges de travail afin qu'elles communiquent en toute sécurité avec les API Google Cloud , utilisez la fédération d'identité de charge de travail pour GKE.
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é réseau du cluster
  • Pour contrôler ou empêcher l'accès à votre cluster depuis le réseau Internet public, personnalisez l'isolation de votre réseau.
  • Pour limiter l'accès au plan de contrôle à des plages d'adresses IP spécifiques, utilisez des réseaux autorisés pour le plan de contrôle.
  • Pour contrôler le trafic des pods, utilisez des règles de réseau. L'application des règles de réseau est disponible avec GKE Dataplane V2, qui est activé par défaut dans les clusters Autopilot. Pour obtenir des instructions, consultez Règles de réseau.
Observer le trafic réseau Kubernetes

Par défaut, Autopilot utilise GKE Dataplane V2 pour les métriques et l'observabilité .

Scaling

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.

Dans Autopilot, GKE effectue un scaling automatique de vos nœuds en fonction du nombre de pods présents dans le cluster. Si un cluster ne présente aucune charge de travail en cours d'exécution, Autopilot peut le réduire automatiquement à zéro nœud. Après le scaling à la baisse du cluster, il ne reste plus de nœuds dans le cluster et les pods système sont donc dans un état non programmable. Ce comportement est normal. Dans la plupart des clusters Autopilot nouvellement créés, vous remarquerez peut-être que les premières charges de travail que vous déployez prennent plus de temps à planifier. En effet, le nouveau cluster Autopilot démarre avec zéro nœud utilisable lors de sa création et attend que vous déployiez une charge de travail pour provisionner des nœuds supplémentaires.

Bonne pratique:

Pour effectuer le scaling automatique du nombre de pods de votre cluster, utilisez 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. De plus, Autopilot active l'autoscaling vertical des pods par défaut. Pour optimiser les requêtes de processeur des conteneurs tout en effectuant l'autoscaling des instances répliquées, vous pouvez utiliser le dimensionnement HPA avec VPA (preview). Pour apprendre à configurer le scaling horizontal en fonction de diverses métriques, consultez la section Configurer l'autoscaling horizontal des pods.

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 exécutez des charges de travail Autopilot dans vos clusters Standard, GKE applique diverses mesures de sécurité Autopilot à ces charges de travail dans la mesure du possible. Vous pouvez appliquer strictement des règles de sécurité Autopilot spécifiques à l'ensemble du cluster Standard. Si vous appliquez toutes les règles Autopilot disponibles, votre cluster Standard dispose d'un environnement opérationnel semblable à celui d'un cluster Autopilot.

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 accès aux adresses IP externes, configurez l'isolation de votre réseau.

Déployer des charges de travail en mode Autopilot

Vous pouvez exécuter des charges de travail Kubernetes compatibles en mode Autopilot afin que GKE gère le scaling, la planification efficace et l'infrastructure sous-jacente. Vous pouvez utiliser la plate-forme de calcul optimisée pour les conteneurs pour vos charges de travail à usage général, ou sélectionner du matériel spécifique pour vos charges de travail à l'aide d'une ComputeClass.

Vous pouvez exécuter ces charges de travail Autopilot de l'une des manières suivantes :

Pour accéder à un guide interactif dans la console Google Cloud concernant le déploiement et l'exposition d'une application dans un cluster Autopilot, cliquez sur Visite guidée :

Visite guidée

Le tableau suivant présente certaines exigences courantes et fournit des recommandations sur la marche à suivre :

Cas d'utilisation Ressources
Contrôler les propriétés de nœuds individuels lors du scaling d'un cluster Créez une ComputeClass personnalisée et demandez-la dans votre fichier manifeste de charge de travail. Pour en savoir plus, consultez À propos des ComputeClasses personnalisées.
Exécuter des charges de travail Autopilot dans un cluster Standard Utilisez une ComputeClass Autopilot dans le cluster Standard. Pour en savoir plus, consultez À propos des charges de travail en mode Autopilot dans GKE Standard.
Exécuter des charges de travail Arm Pour les charges de travail à usage général, demandez l'architecture Arm et la classe ComputeClass intégrée autopilot-arm ou autopilot-arm-spot. Pour des exigences matérielles spécifiques, demandez une série de machines dotée de processeurs Arm dans une ComputeClass personnalisée. Pour en savoir plus, consultez À propos des ComputeClasses personnalisées.
Exécuter des charges de travail d'IA/ML accélérées Demandez des GPU dans une ComputeClass ou dans le fichier manifeste de votre charge de travail. Pour en savoir plus sur la demande de GPU dans votre fichier manifeste de charge de travail, consultez Déployer des charges de travail GPU dans Autopilot.
Exécutez des charges de travail tolérantes aux pannes telles que les jobs par lot à moindre coût.

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 un minimum d'interruptions, telles que des serveurs de jeu ou des files d'attente de travail Dans les clusters Autopilot uniquement, spécifiez l'annotation cluster-autoscaler.kubernetes.io/safe-to-evict=false dans la spécification du 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 en savoir plus, consultez Prolonger la durée d'exécution des pods Autopilot.
Laissez les charges de travail passer en utilisation intensive au-delà de leurs requêtes s'il existe des ressources inutilisées disponibles sur l'ensemble des demandes de ressources de pod sur le nœud. Définissez une limits de ressources supérieure à votre requests ou ne définissez pas de limites de ressources. Pour en savoir plus, consultez Configurer le bursting des pods dans GKE.

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 optimisée pour les conteneurs Autopilot ou sur un matériel spécifique. 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/zone
  • kubernetes.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.

Bonne pratique:

Si vous utilisez topologySpreadConstraints avec l'autoscaling de cluster, nous vous recommandons de définir nodeTaintsPolicy: Honor. Ce paramètre permet de s'assurer que l'autoscaler de cluster simule correctement la migration des pods lors des événements de scaling à la baisse, ce qui évite les boucles de scaling potentielles. Sans ce paramètre, l'autoscaler peut réduire la capacité des nœuds d'une manière qui ne respecte pas les contraintes de répartition de la topologie, ce qui entraîne des événements de scaling à la hausse immédiats et une interruption de la charge de travail.

Le paramètre whenUnsatisfiable: ScheduleAnyway permet également d'éviter que les pods ne deviennent non programmables en cas de déséquilibres temporaires de la topologie, par exemple lors d'une défaillance de zone.

Gérer et surveiller vos clusters Autopilot

En mode 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 publication GKE. 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 le canal de publication standard, mais vous pouvez sélectionner un autre canal qui répond à vos besoins de stabilité et de fonctionnalité. Pour en savoir plus sur les canaux de publication, consultez la page À propos des canaux de publication.

GKE lance automatiquement les mises à niveau, surveille leur progression et suspend l'opération en cas de problème. 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 les périodes pendant lesquelles GKE ne peut pas lancer de mises à niveau automatiques, 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 qui n'est disponible que dans un version disponible plus récent, consultez 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 atténuer une faille récemment divulguée.

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

  • Métriques système
  • Métriques de charge de travail (de Google Cloud 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 et accéder à vos journaux GKE
  • Pour en savoir plus sur les types de journaux que nous collectons automatiquement, consultez la page Journaux collectés.
  • Pour accéder aux journaux et utiliser l'interface utilisateur de Cloud Logging dans la console Google Cloud , consultez Afficher vos journaux GKE.
  • Pour obtenir des exemples de requêtes que vous pouvez utiliser pour filtrer les journaux système et les journaux de charge de travail Kubernetes, consultez la section Requêtes associées à Kubernetes.
  • Pour obtenir des exemples de requêtes permettant de filtrer les journaux d'audit des activités d'administration et d'audit des accès aux données, consultez Informations sur les journaux d'audit GKE.
  • Pour configurer les journaux pour les environnements mutualisés, par exemple lorsque les équipes disposent d'espaces de noms spécifiques dans un seul cluster GKE, mais que chaque équipe possède son propre projet Google Cloud , consultez Journalisation mutualisée sur GKE.
Observer les performances de vos clusters GKE

Une surveillance efficace des performances de vos clusters peut vous aider à optimiser les coûts opérationnels 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 Résoudre les problèmes liés aux clusters Autopilot.

Étapes suivantes