Présentation d'Autopilot


Présentation

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 ci-dessous) sont immuables ; 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.

Il existe deux raisons principales pour lesquelles vous pouvez préférer le mode de fonctionnement standard au mode 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.

Comparaison des modes Autopilot et Standard

Avec Autopilot, GKE gère de nombreux aspects complexes du cycle de vie de votre cluster. Le tableau suivant présente les options disponibles en fonction du mode de fonctionnement du cluster :

  • Préconfiguré : ce paramètre est intégré et vous ne pouvez pas le modifier.
  • Par défaut : ce paramètre est activé, mais vous pouvez le remplacer.
  • Facultatif : ce paramètre est désactivé, mais vous pouvez l'activer.
Options Mode Autopilot Mode standard
Type de cluster de base Disponibilité et version :

Préconfiguré : Régional
Par défaut : Version disponible standard
Disponibilité et version :

Facultatif :
Nœuds et pools de nœuds Gérés par GKE. Gérés, configurés et spécifiés par vous.
Provisionnement des ressources GKE provisionne les ressources de manière dynamique en fonction de votre spécification de pod. Vous pouvez provisionner manuellement des ressources supplémentaires et définir la taille globale du cluster. Configurez l'autoscaling de cluster et le provisionnement automatique des nœuds pour automatiser le processus.
Type d'image Préconfiguré : Container-Optimized OS avec Containerd Choisissez l'une des options suivantes :
Facturation Facturation par demande de ressources de pod (processeur, mémoire et stockage éphémère) Facturation par nœud (processeur, mémoire, disque de démarrage).
Sécurité Préconfiguré :
Facultatif :
Facultatif :
Mise en réseau Préconfiguré :
Par défaut :
  • Cluster public
  • Plages CIDR automatiques
  • Nom du réseau/sous-réseau
Facultatif :
Facultatif :
Mises à niveau, réparation et maintenance Préconfiguré :
Facultatif :
Identifiants d'authentification Préconfiguré : Workload Identity Facultatif :
Scaling Préconfiguré : Autopilot gère l'ensemble du scaling et de la configuration de vos nœuds.

Par défaut :
Facultatif :
Surveillance et journalisation Préconfiguré : suite des opérations Cloud pour GKE

Par défaut : journalisation du système et de la charge de travail

Facultatif : journalisation du système uniquement
Par défaut :
Facultatif : journalisation du système uniquement
Routage Préconfiguré : routage basé sur le pod. Groupes de points de terminaison du réseau (NEG) activés. Choisissez le routage des paquets basé sur le nœud (par défaut) ou le routage basé sur le pod.
Modules complémentaires de cluster Préconfiguré :
Par défaut :
Facultatif :

1 Configuration supplémentaire requise pour activer Cloud NAT sur un cluster.

Fonctionnalités de cluster non compatibles

Les fonctionnalités de cluster GKE suivantes ne sont pas compatibles avec les clusters Autopilot :

Instances Compute Engine

Sécurité

Modules complémentaires et intégrations

Scaling

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

Le tableau suivant répertorie les plages de ressources autorisées pour les pods Autopilot. Sauf indication contraire, toutes les valeurs s'appliquent à la somme de l'ensemble des demandes de ressources des conteneurs au sein du pod. Les processeurs virtuels des pods sont disponibles par incréments de 0,25 processeur virtuel. Outre les valeurs minimales, le ratio entre le processeur et la mémoire doit être compris entre 1 processeur virtuel:1 Gio et 1 processeur virtuel:6,5 Gio. Les ressources se trouvant en dehors des plages de ratio autorisées sont mises à l'échelle. Pour en savoir plus, consultez les sections Gestion des plages et des ratios de ressources et Exemples de limites de ressources.

Ressource Ressources minimales Ressources maximales
Pods normaux Pods DaemonSet Tous les pods
Processeur 250 mCPU 10 mCPU 28 processeurs virtuels2
Mémoire 512 Mio 10 Mio 80 Gio2
Stockage éphémère 10 Mio (par conteneur) 10 Mio (par conteneur) 10 Gio

2 Les limites maximales de processeur et de mémoire pour les pods standards sont abaissées de la somme totale des demandes de ressources de tous les pods DaemonSet.

Demandes de ressources du conteneur par défaut

Autopilot s'appuie sur les éléments que vous avez spécifiés dans votre configuration de déploiement pour provisionner des ressources. Si vous ne spécifiez pas de demandes de ressources pour un conteneur du pod, Autopilot applique des valeurs par défaut. Ces valeurs par défaut sont conçues pour donner aux conteneurs de vos pods une quantité moyenne de ressources, adaptées à de nombreuses charges de travail de faible volume.

Autopilot applique ces valeurs par défaut aux ressources qui ne sont pas définies dans la spécification de pod.

Ressource Conteneurs dans les pods standards Conteneurs dans DaemonSets
Processeur 500 mCPU 50 mCPU
Mémoire 2 Gio 100 Mio
Stockage éphémère 1 Gio 100 Mio

Pour en savoir plus sur les limites des clusters Autopilot, consultez la section Quotas et limites.

Limites et restrictions sur les charges de travail

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"

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.

Absence du service Container Threat Detection

Autopilot n'est pas compatible avec Container Threat Detection.

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.

Valeurs par défaut et limites de ressources pour l'utilisation de l'anti-affinité de pods

Autopilot est compatible avec l'anti-affinité de pods, ce qui vous permet d'empêcher la colocalisation de deux pods sur le même nœud. Lorsque vous utilisez l'anti-affinité, Autopilot doit allouer des ressources de calcul supplémentaires afin de garantir la séparation adéquate des pods, telle que définie par la spécification PodSpec. Lorsque vous utilisez l'anti-affinité de pods, les limites par défaut et limites minimales de ressources sont plus élevées. Pour tous les conteneurs répertoriés dans la spécification PodSpec :

Ressource Valeur par défaut
Processeur 0,75 processeur virtuel
Mémoire 2 Gio
Stockage éphémère 1 Gio

Lorsque vous utilisez l'anti-affinité de pods, les mêmes règles et la même logique de limitation des ressources s'appliquent, mais avec des incréments de processeur virtuel plus élevés. Les processeurs virtuels des pods sont proposés avec un minimum de 0,5 processeur virtuel et des incréments de 0,5 processeur virtuel (arrondis à l'incrément le plus proche). Par exemple, si vous demandez un total de 0,66 processeur virtuel en moyenne (sur l'ensemble de vos conteneurs utilisant l'anti-affinité), votre spécification PodSpec est modifiée à l'admission et définie sur 1 processeur virtuel. Votre pod dispose d'un accès complet à la ressource supérieure, la ressource en excédent étant divisée entre les demandes de ressources de tous les conteneurs.

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.

Gestion des plages et des ratios de ressources

  • Incréments de processeurs virtuels des pods : les processeurs virtuels des pods sont disponibles par incréments de 0,25 processeur virtuel (arrondi). Par exemple, si vous demandez un total de 0,66 processeurs virtuels (sur l'ensemble de vos conteneurs), votre spécification PodSpec est modifiée à l'admission et définie sur 0,75. Votre pod dispose d'un accès complet à la ressource supérieure, la ressource en excédent étant divisée entre les demandes de ressources de tous les conteneurs. La valeur minimale est de 250 milliprocesseurs (mCPU). Les processeurs virtuels de DaemonSet sont proposés par incréments de 10 mCPU (arrondis à l'incrément le plus proche).

  • Plage de ratios entre la mémoire et le processeur : le ratio entre la mémoire (en Gio) et le processeur virtuel doit être compris entre 1 et 6,5 processeurs virtuels. Par exemple, vous pouvez utiliser un pod avec 1 processeur virtuel et 1 Gio de mémoire, ou 1 processeur virtuel et 6,5 Gio de mémoire, mais pas 1 processeur virtuel et 7 Gio de mémoire. Afin de répondre à la demande de ressources, GKE effectue un scaling à la hausse de la ressource la plus faible. Par exemple, si vous demandez 1 processeur virtuel et 7 Gio de mémoire, les éléments de votre PodSpec sont modifiés à l'admission en 1,25 processeur virtuel et 7 Gio de mémoire. De même, si vous demandez 1 processeur virtuel et 800 Mio de mémoire, les éléments de votre PodSpec sont modifiés en 1 processeur virtuel et 1 Gio de RAM, la ressource en excédent étant divisée entre les conteneurs.

Les exigences concernants les incréments et ratios entre processeur et mémoire, et le scaling potentiel des demandes de ressources, sont calculés après application des valeurs par défaut aux conteneurs ayant des demandes de ressources manquantes.

Les conteneurs sans demandes de ressources sont définis par défaut sur des capacités minimales de 500 mCPU et 1 Gio de mémoire. Pour les ressources de processeur et de mémoire, lorsque GKE effectue le scaling à la hausse d'une demande de ressource (par exemple, pour répondre à l'exigence de valeur minimale ou de ratio), la ressource en excédent est allouée de manière égale entre les conteneurs. Les valeurs arrondies sont réparties proportionnellement entre les conteneurs. Par exemple, un conteneur disposant de deux fois plus de mémoire que les autres conteneurs recevra deux fois plus de mémoire supplémentaire.

  • Stockage éphémère : la plage disponible est comprise entre 10 Mio et 10 Gio. Cela a des répercussions sur la couche du conteneur accessible en écriture et les installations d'emptyDir.

Le stockage éphémère présente une demande minimale par conteneur. Par conséquent, si les demandes de stockage éphémère d'un conteneur sont inférieures au minimum, Autopilot augmente la demande pour atteindre ce minimum. Le stockage éphémère n'inclut pas de demande minimale par pod. Le stockage éphémère présente une demande maximale par pod, qui est cumulative sur l'ensemble des conteneurs. Si la valeur cumulée est supérieure à la valeur maximale, Autopilot effectue un scaling à la baisse de la demande vers ce maximum, tout en garantissant que le ratio des demandes entre les conteneurs reste le même.

Exemples de limites de ressources

Exemple 1 : Pour un conteneur unique avec une valeur minimale de moins de 250 mCPU :

Nombre de conteneurs Demandes de ressources d'origine Demandes modifiées
1 Processeur : 180 mCPU
Mémoire : 0,5 Gio
Stockage éphémère : 10 Mio
Processeur : 250 mCPU
Mémoire : 0,5 Gio
Stockage éphémère : 10 Mio
Total des ressources du pod Processeur : 250 mCPU
Mémoire : 0,5 Gio
Stockage éphémère : 10 Mio

Exemple 2 : Pour plusieurs conteneurs avec un minimum total de moins de 250 mCPU, Autopilot répartit le reste des ressources (jusqu'à 250 mCPU) de manière égale entre tous les conteneurs du pod.

Nombre de conteneurs Demandes de ressources d'origine Demandes modifiées
1 Processeur : 70 mCPU
Mémoire : 0,5 Gio
Stockage éphémère : 10 Mio
Processeur : 84 mCPU
Mémoire : 0,5 Gio
Stockage éphémère : 10 Mio
2 Processeur : 70 mCPU
Mémoire : 0,5 Gio
Stockage éphémère : 10 Mio
Processeur : 83 mCPU
Mémoire : 0,5 Gio
Stockage éphémère : 10 Mio
3 Processeur : 70 mCPU
Mémoire : 0,5 Gio
Stockage éphémère : 10 Mio
Processeur : 83 mCPU
Mémoire : 0,5 Gio
Stockage éphémère : 10 Mio
Total des ressources du pod Processeur : 250 mCPU
Mémoire : 1,5 Gio
Stockage éphémère : 30 Mio

Exemple 3 : Pour plusieurs conteneurs avec un minimum total de ressources supérieur ou égal à 250 mCPU, le processeur est arrondi à des multiples de 250 mCPU, et les ressources de processeur en excédent sont réparties sur tous les conteneurs proportionnellement à la demande d'origine. Dans cet exemple, le total cumulé en ressource de processeur est de 320 mCPU, arrondi et modifié à un total de 500 mCPU. L'excédent de 180 mCPU est réparti entre les conteneurs :

Nombre de conteneurs Demandes de ressources d'origine Demandes modifiées
1 Processeur : 170 mCPU
Mémoire : 0,5 Gio
Stockage éphémère : 10 Mio
Processeur : 266 mCPU
Mémoire : 0,5 Gio
Stockage éphémère : 10 Mio
2 Processeur : 80 mCPU
Mémoire : 0,5 Gio
Stockage éphémère : 10 Mio
Processeur : 125 mCPU
Mémoire : 0,5 Gio
Stockage éphémère : 10 Mio
3 Processeur : 70 mCPU
Mémoire : 0,5 Gio
Stockage éphémère : 10 Mio
Processeur : 109 mCPU
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 : 500 mCPU
Mémoire : 1,5 Gio
Stockage éphémère : 30 Mio

Exemple 4 : Pour un conteneur unique où le processeur est trop faible pour la quantité de mémoire (1 processeur virtuel pour 6,5 Gio maximum). Le ratio maximal processeur/mémoire autorisé est de 1:6,5. Si le ratio est supérieur à cette valeur, la demande de processeur est augmentée, puis arrondie si nécessaire :

Nombre de conteneurs Demandes de ressources d'origine Demandes modifiées
1 Processeur : 250 mCPU
Mémoire : 4 Gio
Stockage éphémère : 10 Mio
Processeur : 750 mCPU
Mémoire : 4 Gio
Stockage éphémère : 10 Mio
Total des ressources du pod Processeur : 750 mCPU
Mémoire : 4 Gio
Stockage éphémère : 10 Mio

Exemple 5 : Pour un conteneur unique où la mémoire est trop faible pour la quantité de processeur (1 processeur virtuel 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 Demandes de ressources d'origine Demandes modifiées
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 mCPU
Mémoire : 4 Gio
Stockage éphémère : 10 Mio

Exemple 6 : Pour un conteneur unique avec une valeur minimale de moins de 250 mCPU et où, après ajustement, le processeur est trop faible pour la quantité de mémoire (1 processeur virtuel pour 6,5 Gio au maximum).

Nombre de conteneurs Demandes de ressources d'origine Demandes modifiées
1 Processeur : 100 mCPU
Mémoire : 50 Mio
Stockage éphémère : 10 Mio
Processeur : 250 mCPU
Mémoire : 256 Mio
Stockage éphémère : 10 Mio
Total des ressources du pod Processeur : 250 mCPU
Mémoire : 256 Mio
Stockage éphémère : 10 Mio

Exemple 7 : Pour un conteneur unique avec des demandes de stockage éphémère supérieures à 10 Gio, la demande maximale autorisée pour le stockage éphémère est de 10 Gio. Si la demande est supérieure à la valeur maximale, elle se voit réduite à 10 Gio.

Nombre de conteneurs Demandes de ressources d'origine Demandes modifiées
1 Processeur : 250 mCPU
Mémoire : 256 Mio
Stockage éphémère : 11 Gio
Processeur : 250 mCPU
Mémoire : 256 Mio
Stockage éphémère : 10 Gio
Total des ressources du pod Processeur : 250 mCPU
Mémoire : 256 Mio
Stockage éphémère : 10 Gio

Exemple 8 : Pour plusieurs conteneurs avec des demandes de stockage éphémère supérieures à 10 Gio, toutes les demandes de stockage éphémère des conteneurs sont réduites afin d'amener la demande de stockage cumulative finale à une valeur de 10 Gio.

Nombre de conteneurs Demandes de ressources d'origine Demandes modifiées
1 Processeur : 250 mCPU
Mémoire : 256 Mio
Stockage éphémère : 5 Gio
Processeur : 250 mCPU
Mémoire : 256 Mio
Stockage éphémère : 2,94 Gio
2 Processeur : 250 mCPU
Mémoire : 256 Mio
Stockage éphémère : 6 Gio
Processeur : 250 mCPU
Mémoire : 256 Mio
Stockage éphémère : 3,53 Gio
3 Processeur : 250 mCPU
Mémoire : 256 Mio
Stockage éphémère : 6 Gio
Processeur : 250 mCPU
Mémoire : 256 Mio
Stockage éphémère : 3,53 Gio
Total des ressources du pod Processeur : 750 mCPU
Mémoire : 768 Mio
Stockage éphémère : 10 Gio

Limites de sécurité

Isolation 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. Les outils Kubernetes PodSecurityPolicy, OPA GateKeeper et Policy Controller ne sont pas compatibles avec les clusters Autopilot.

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

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.

Conteneurs d'initialisation

Les conteneurs d'initialisation s'exécutent en série avant le démarrage des conteneurs d'applications. Par défaut, GKE alloue à chaque conteneur d'initialisation la totalité des ressources à la disposition du pod.

Contrairement à vos autres conteneurs, GKE recommande de laisser les demandes de ressources non spécifiées pour les conteneurs d'initialisation afin que ceux-ci disposent de la totalité des ressources. Si vous définissez des ressources inférieures, votre conteneur d'initialisation est inutilement contraint. Si vous définissez des ressources plus élevées, vous risquez d'augmenter votre facture pour la durée de vie du pod.

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

Étant donné que GKE gère les nœuds pour vous dans le cadre des clusters Autopilot, vous ne pouvez pas les modifier.

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.

Aucun transfert de port

Les clusters Autopilot ne sont pas compatibles avec la commande kubectl port-forward.

Aucun accès SSH

Comme vous n'avez plus à provisionner ou gérer les nœuds dans Autopilot, il n'y a aucun accès SSH. 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.

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.

Limites des webhooks

Vous ne pouvez pas créer de webhooks d'admission de mutation personnalisés pour les clusters Autopilot, mais vous pouvez créer des webhooks de validation personnalisés.

Dépannage

Impossible de créer un cluster : 0 nœud enregistré

Lorsque vous créez un cluster Autopilot, il échoue et affiche l'erreur suivante :

All cluster resources were brought up, but: only 0 nodes out of 2 have registered.

Pour résoudre le problème, assurez-vous que le compte de service Compute Engine par défaut n'est pas désactivé. Exécutez la commande suivante pour vérifier :

   gcloud iam service-accounts describe SERVICE_ACCOUNT

Remplacez SERVICE_ACCOUNT par l'ID de compte de service numérique ou l'adresse e-mail du compte de service (par exemple, 123456789876543212345 ou my-iam-account@somedomain.com).

Étape suivante