GKE propose deux modes d’exploitation d’un cluster, qui déterminent jusqu’où va la gestion déléguée à Google au-delà du control plane.


Comparaison

StandardAutopilot
Node poolsGérés par l’utilisateur (machine type, taille, scaling config)Entièrement gérés par Google
Accès aux nœudsSSH possible, DaemonSets libresPas d’accès SSH, DaemonSets restreints
FacturationPar VM provisionnée (même sous-utilisée)Par ressources réellement demandées par les pods (vCPU, mémoire, stockage)
Sécurité par défautÀ configurer soi-mêmeDurcissement automatique : Workload Identity forcé, Shielded GKE Nodes, pas de pods privilégiés par défaut
FlexibilitéTotale (GPU custom, sysctls, kernel modules…)Limitée à ce que le mode Autopilot autorise
Node Auto-provisioningOptionnel (à activer)Natif et implicite
Cas d’usageCharges spécifiques (GPU custom, DaemonSets réseau, besoins kernel)Réduire l’opérationnel, équipes sans expertise infra dédiée

Ce qu’Autopilot automatise concrètement

  • Provisioning des nœuds : un pod en attente déclenche la création du nœud dimensionné exactement pour lui — pas de Node pool à pré-configurer.
  • Bin packing : Google optimise le placement des pods pour minimiser le nombre de nœuds facturés.
  • Sécurité : Workload Identity activé par défaut, pas de possibilité de désactiver le hardening de base (contrairement à Standard où c’est optionnel).
  • Maintenance : patchs de sécurité et de version appliqués sans intervention, avec des garanties de disruption limitée pour les workloads.

Quand choisir quoi

  • Autopilot par défaut pour la plupart des nouvelles charges : moins d’opérationnel, sécurité par défaut, facturation alignée sur l’usage réel.
  • Standard dès qu’un besoin sort du cadre managé : GPU spécifiques non supportés, DaemonSets d’infra (agents de sécurité, CNI custom), accès nœud nécessaire pour du debug bas niveau, ou optimisation fine des coûts par bin-packing manuel à grande échelle.

En relation avec