Présentation d'Autopilot

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Autopilot est un nouveau mode de fonctionnement dans Google Kubernetes Engine (GKE), conçu pour réduire les coûts opérationnels liés à la gestion des clusters, optimiser vos clusters pour la production et accroître la disponibilité de vos charges de travail. Le mode de fonctionnement fait référence au niveau de flexibilité, de responsabilité et de contrôle dont vous disposez sur votre cluster. Outre les avantages qu'offrent un plan de contrôle entièrement géré et l'automatisation des nœuds, GKE propose deux modes de fonctionnement :

  • Autopilot : GKE provisionne et gère l'infrastructure sous-jacente au cluster, y compris les nœuds et les pools de nœuds, ce qui vous permet de bénéficier d'un cluster optimisé sans intervention de votre part.
  • Standard : vous gérez l'infrastructure sous-jacente au cluster, ce qui vous offre toute flexibilité au niveau de la configuration des nœuds.

Avec Autopilot, vous n'avez plus besoin de surveiller l'état des nœuds ni de déterminer la capacité de calcul requise par vos charges de travail. Autopilot est compatible avec la plupart des API, outils et éléments du vaste écosystème Kubernetes. Vous restez dans GKE sans avoir à interagir avec les API, les CLI ou l'interface utilisateur de Compute Engine, car les nœuds ne sont pas accessibles via Compute Engine, comme c'est le cas en mode Standard. Vous ne payez que pour les ressources de processeur, de mémoire et d'espace de stockage demandées par vos pods pendant leur exécution.

Les clusters Autopilot sont préconfigurés avec une configuration de cluster optimisée, prête pour les charges de travail de production. Cette configuration simplifiée respecte les bonnes pratiques et les recommandations de GKE pour la configuration et la sécurité des clusters et des charges de travail. Certains de ces paramètres intégrés (décrits dans le tableau de comparaison Autopilot et standard) sont immuables et d'autres paramètres facultatifs peuvent être activés ou désactivés.

Autopilot est fourni avec un contrat de niveau de service qui couvre le plan de contrôle ainsi que vos pods. Avec Autopilot, étant donné que l'infrastructure sous-jacente est éliminée, vous pouvez vous concentrer sur l'API Kubernetes et sur vos déploiements. Autopilot utilise les exigences de ressources que vous définissez dans la spécification PodSpec et provisionne les ressources du déploiement telles que le processeur, la mémoire et les disques persistants.

Voici quelques raisons pour lesquelles vous pouvez utiliser le mode de fonctionnement Standard au lieu d'Autopilot :

  • Vous avez besoin d'un niveau de contrôle plus élevé sur la configuration de votre cluster.
  • Vos clusters doivent exécuter des charges de travail qui ne répondent pas aux contraintes d'Autopilot.
  • Vos charges de travail sont gourmandes en ressources de calcul. Les clusters Autopilot sont parfaits pour exécuter la plupart des charges de travail de production, mais les clusters standards peuvent mieux convenir aux charges de travail exigeantes en calcul qui nécessitent des plates-formes de calcul hautes performances.

Mise à l'échelle

Autopilot adapte automatiquement les ressources du cluster en fonction de vos spécifications de pod, afin que vous puissiez vous concentrer sur vos pods. Pour augmenter ou diminuer automatiquement le nombre de pods, vous pouvez mettre en œuvre l'autoscaling horizontal des pods à l'aide des métriques de processeur ou de mémoire standards de Kubernetes, ou utiliser des métriques personnalisées via Cloud Monitoring.

Plages de ressources autorisées

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.

Limites et restrictions des charges de travail dans Autopilot

Autopilot est compatible avec la plupart des charges de travail qui exécutent vos applications. Pour que GKE soit en mesure d'offrir la gestion des nœuds et une expérience de fonctionnement plus fluide, il existe certaines limites et restrictions par rapport à l'édition standard de GKE. Certaines de ces limites sont la traduction de bonnes pratiques en matière de sécurité, tandis que d'autres permettent une gestion sécurisée des clusters Autopilot. Les limites sur les charges de travail s'appliquent à l'ensemble des pods, y compris ceux lancés par des objets Déploiement, DaemonSets, ReplicaSets, ReplicationControllers, StatefulSets et CronJobs.

Restrictions liées aux options d'hôte

Les valeurs hostPort et hostNetwork ne sont pas autorisées, car la gestion des nœuds est assurée par GKE. L'utilisation de volumes hostPath en mode écriture n'est pas autorisée, tandis que l'utilisation de volumes hostPath en mode lecture n'est autorisée que pour les préfixes de chemin /var/log/. L'utilisation d'espaces de noms d'hôte dans les charges de travail est interdite.

Limites des charges de travail Linux

Autopilot n'est compatible qu'avec les fonctionnalités Linux suivantes pour les charges de travail :

"SETPCAP", "MKNOD", "AUDIT_WRITE", "CHOWN", "DAC_OVERRIDE", "FOWNER",
"FSETID", "KILL", "SETGID", "SETUID", "NET_BIND_SERVICE", "SYS_CHROOT", "SETFCAP"

Dans GKE 1.21 et versions ultérieures, la fonctionnalité "SYS_PTRACE" est également compatible avec les charges de travail.

Sélecteurs de nœuds et affinité de nœuds

Les topologies à affinité zonale sont acceptées. L'affinité de nœuds et les sélecteurs de nœuds ne peuvent être utilisés qu'avec les clés suivantes : topology.kubernetes.io/region, topology.kubernetes.io/zone, failure-domain.beta.kubernetes.io/region, failure-domain.beta.kubernetes.io/zone, cloud.google.com/gke-os-distribution, kubernetes.io/os et kubernetes.io/arch. Certaines valeurs d'OS et d'architecture ne sont pas compatibles avec Autopilot.

Vous pouvez également utiliser des sélecteurs de nœuds et l'affinité de nœuds aux fins suivantes :

Pas de pods privilégiés

Le mode privilégié pour les conteneurs dans les charges de travail sert principalement à modifier des nœuds, par exemple à changer les paramètres du kubelet ou du réseau. Avec les clusters Autopilot, les modifications de nœuds ne sont pas autorisées. Ces types de pods ne sont donc pas autorisés. Cette restriction peut affecter certaines charges de travail d'administration.

Affinité et anti-affinité de pods

Bien que GKE gère les nœuds pour votre compte dans Autopilot, vous conservez la possibilité de planifier vos pods. Autopilot est compatible avec l'affinité de pods, ce qui vous permet de colocaliser les pods sur un même nœud pour améliorer l'efficacité du réseau. Par exemple, vous pouvez utiliser l'affinité de pods pour déployer des pods d'interface sur des nœuds dotés de pods de backend. L'affinité de pods ne peut être utilisée qu'avec les clés suivantes : topology.kubernetes.io/region, topology.kubernetes.io/zone, failure-domain.beta.kubernetes.io/region et failure-domain.beta.kubernetes.io/zone.

Autopilot est également compatible avec l'anti-affinité, ce qui vous permet de répartir les pods entre les nœuds de façon à éviter les points de défaillance uniques. Par exemple, vous pouvez utiliser l'anti-affinité de pods pour empêcher les pods d'interface d'être colocalisés avec des pods de backend.

Tolérances compatibles uniquement avec la séparation des charges de travail

Les tolérances ne sont disponibles que pour la séparation des charges de travail. Les rejets sont ajoutés automatiquement par le provisionnement automatique des nœuds si nécessaire.

Limites de sécurité dans Autopilot

Isolement du conteneur

Autopilot applique une configuration renforcée pour vos pods, qui offre une isolation de sécurité améliorée et limite l'impact des failles de fuite de conteneur sur votre cluster :

  • Le profil seccomp par défaut de l'environnement d'exécution du conteneur est appliqué par défaut à tous les pods de votre cluster.
  • L'autorisation de conteneur CAP_NET_RAW est supprimée pour tous les conteneurs. L'autorisation CAP_NET_RAW n'est généralement pas utilisée et a été la cible de plusieurs failles de fuite de conteneur. L'absence de CAP_NET_RAW peut entraîner un échec en cas d'utilisation de ping dans votre conteneur.
  • Workload Identity est appliqué et empêche tout accès des pods au compte de service Compute Engine sous-jacent et aux autres métadonnées de nœud sensibles.
  • Les services pour lesquels spec.ExternalIPs est défini sont bloqués pour assurer la protection contre CVE-2020-8554. Ces services sont rarement utilisés.
  • Les types de stockage StorageTypes suivants sont autorisés. Les autres types de stockage sont bloqués, car ils nécessitent des droits sur le nœud :

    "configMap", "csi", "downwardAPI", "emptyDir", "gcePersistentDisk", "hostPath",
    "nfs", "persistentVolumeClaim", "projected", "secret"
    

Règles de sécurité relatives aux pods

Autopilot applique des paramètres qui offrent une isolation améliorée pour vos conteneurs. La fonctionnalité Kubernetes PodSecurityPolicy n'est pas compatible avec les clusters Autopilot. Dans les versions de GKE antérieures à la version 1.21, OPA Gatekeeper et Policy Controller ne sont pas non plus compatibles.

Limites de sécurité dans Autopilot

Au niveau de la couche Kubernetes, le mode GKE Autopilot fournit l'API Kubernetes, mais supprime les autorisations nécessaires à l'utilisation de certaines primitives Kubernetes privilégiées, telles que des pods privilégiés, afin de limiter la capacité d'accès, de modification ou de contrôler directement la machine virtuelle (VM) des nœuds.

Ces restrictions ont été mises en place pour le mode GKE Autopilot afin d'empêcher les charges de travail de disposer d'un accès de bas niveau à la VM de nœud, pour que Google Cloud puisse proposer une gestion complète des nœuds et un contrat de niveau de service au niveau du pod.

Notre objectif consiste à empêcher tout accès involontaire à la machine virtuelle du nœud. Nous acceptons les envois à cet effet via l'Initiative Vulnerability Reward Program de Google et nous récompenserons les rapports, à la discrétion du panneau de récompense VRP de Google.

En raison de leur nature, les utilisateurs privilégiés, tels que les administrateurs de cluster, disposent d'un contrôle total sur tout cluster GKE. Pour respecter nos bonnes pratiques de sécurité, nous vous recommandons d'éviter d'attribuer des privilèges puissants GKE/Kubernetes et d'utiliser la délégation d'administrateur d'espace de noms dans la mesure du possible, comme décrit dans nos instructions sur l'architecture mutualisée.

Les charges de travail sur Autopilot continuent à bénéficier de la même sécurité que le mode GKE Standard, où les VM à locataire unique sont provisionnées dans le projet de l'utilisateur en vue d'une utilisation exclusive. À l'instar de la version standard, les charges de travail Autopilot d'un cluster peuvent être exécutées ensemble sur une VM dotée d'un noyau sécurisé par la sécurité, mais partagé.

Étant donné que le noyau partagé représente une limite de sécurité unique, GKE vous recommande si vous avez besoin d'une isolation importante, telle que des charges de travail à haut risque ou non approuvées, d'exécuter vos charges de travail sur des clusters GKE Standard à l'aide de GKE Sandbox afin d'assurer une protection multicouche.

Autres limites dans Autopilot

Demandes de signature de certificat

Vous ne pouvez pas créer de demandes de signature de certificat dans Autopilot.

Outils de surveillance externes

La plupart des outils de surveillance externes nécessitent un accès restreint. Les solutions de certains partenaires Google Cloud sont disponibles sur Autopilot, mais elles ne sont pas toutes compatibles. De plus, il n'est pas possible d'installer des outils de surveillance personnalisés sur les clusters Autopilot.

Services externes

Les services d'adresses IP externes ne sont pas autorisés sur les clusters Autopilot. Pour attribuer une adresse IP externe à un service, vous pouvez utiliser le type LoadBalancer Service, ou utiliser une entrée pour ajouter le service à une adresse IP externe partagée entre plusieurs services.

Espaces de noms gérés

L'espace de noms kube-system est géré, ce qui signifie qu'aucune des ressources de cet espace de noms ne peut être modifiée, et qu'il n'est pas non plus possible de créer de nouvelles ressources.

Aucune modification possible sur les nœuds

Vous ne pouvez pas modifier les nœuds Autopilot, par exemple pour apporter des modifications au type de machine sous-jacent si vos charges de travail comportent des exigences de calcul spécifiques.

Aucune conversion

Il n'est pas possible de convertir des clusters standards en mode Autopilot et vice-versa.

Aucune connexion externe entrante directe pour les clusters privés

Les clusters automatiques avec des nœuds privés ne disposent pas d'adresses IP externes et ne peuvent donc pas accepter directement les connexions entrantes. Si vous déployez des services sur un NodePort, vous ne pouvez pas accéder à ces services depuis l'extérieur du VPC, par exemple à partir d'Internet. Pour exposer en externe des applications dans des clusters Autopilot, utilisez les services. Pour en savoir plus, consultez la page Exposer des applications à l'aide de services.

Utilisation intensive des pods impossible

Pour les clusters standards, il est possible de configurer les pods afin d'exploiter la capacité inutilisée sur le nœud. Pour les clusters Autopilot, comme tous les pods ont des limites définies sur les demandes, l'utilisation intensive des ressources n'est pas possible. Il est important de s'assurer que la spécification du pod définit des ressources adéquates pour les demandes de ressources et ne repose pas sur l'utilisation intensive.

Aucune connexion SSH aux nœuds

Comme vous n'avez plus à provisionner ou gérer les nœuds dans Autopilot, il n'y a aucun accès SSH aux nœuds. GKE gère tous les aspects du fonctionnement des nœuds, y compris leur état et l'ensemble des composants Kubernetes qui s'y exécutent.

Vous pouvez toujours vous connecter à distance à vos conteneurs en cours d'exécution à l'aide de la fonctionnalité Kubernetes exec afin d'exécuter des commandes dans vos conteneurs pour le débogage, y compris en vous connectant à une interface système interactive, par exemple avec kubectl exec -it deploy/YOUR_DEPLOYMENT -- sh..

Limites de ressources

Dans un cluster Autopilot, chaque pod est traité comme un pod de classe QoS garantie, avec des limites égales aux demandes. Si vous n'avez pas défini de limites de ressources, Autopilot définit automatiquement des limites égales aux demandes. Si vous spécifiez des limites de ressources, celles-ci seront remplacées et définies sur des valeurs égales aux demandes.

Journalisation du port série

Les clusters Autopilot nécessitent l'activation de la journalisation du port série pour déboguer et dépanner vos nœuds. Si votre organisation Google Cloud dispose d'une règle d'administration qui applique la contrainte compute.disableSerialPortLogging, il est possible que les nouveaux nœuds ne soient pas provisionnés.

Demandez à votre administrateur des règles d'administration de supprimer cette contrainte dans les projets dotés de clusters Autopilot.

Limites des webhooks

Dans GKE version 1.21 ou ultérieure, vous pouvez également créer des webhooks d'admission dynamiques de mutation. Toutefois, Autopilot modifie les objets webhook de mutation afin d'ajouter un sélecteur d'espace de noms, qui empêche l'interception des ressources présentes dans les espaces de noms gérés (par exemple kube-system). De plus, les webhooks qui spécifient dans les règles une ou plusieurs des ressources suivantes (et l'une de leurs sous-ressources) seront refusés :

- group: ""
  resource: nodes
- group: ""
  resource: persistentvolumes
- group: certificates.k8s.io
  resource: certificatesigningrequests
- group: authentication.k8s.io
  resource: tokenreviews

Vous ne pouvez pas utiliser le jeton * (qui représente toutes les valeurs) dans le champ resources ou groups pour autoriser les ressources précédentes.

Limites d'usurpation d'identité utilisateur

Les versions 1.22.4-gke.1501 et ultérieures de GKE sont compatibles avec l'emprunt d'identité d'utilisateur pour tous les utilisateurs et groupes définis par l'utilisateur. Les utilisateurs et les groupes système tels que l'utilisateur kube-apiserver et le groupe system:masters ne peuvent pas être usurpés.

Aucune application Google Cloud Marketplace

Vous ne pouvez pas installer d'applications depuis Cloud Marketplace dans des clusters Autopilot.

Dépannage

Pour connaître la procédure de dépannage, consultez la page Résoudre les problèmes liés aux clusters Autopilot.

Étapes suivantes