Sur GKE, Google exploite et met à jour le Control Plane à la place de l’utilisateur : kube-apiserver, etcd, kube-scheduler et kube-controller-manager tournent sur une infrastructure managée, invisible et non accessible en SSH — contrairement à un cluster self-managé (kubeadm, on-prem) où ces composants doivent être déployés et patchés manuellement.


Zonal vs Régional

Cluster zonalCluster régional
Réplicas du control plane1 (dans une seule zone)3 (répartis sur 3 zones d’une région)
RésiliencePanne de zone = cluster indisponible pour l’admin (les workloads continuent de tourner)Tolère la perte d’une zone entière
SLA GooglePlus faibleCouvert par le SLA GKE (99.95%)
CoûtMoindreLégèrement supérieur (réplication du control plane)
RecommandationDev / testProduction

Release channels

GKE gère les mises à jour de version de Kubernetes via des canaux de publication, qui déterminent la fréquence et la stabilité des versions poussées automatiquement :

CanalCadenceStabilitéUsage typique
RapidNouvelles versions dès leur sortieLa plus récente, moins éprouvéeTest des dernières fonctionnalités
RegularQuelques semaines après RapidÉquilibre stabilité / fraîcheurDéfaut recommandé pour la prod
StablePlusieurs mois après RapidLa plus éprouvéeCharges critiques, changement minimal
  • Le master et les node pools suivent le canal choisi ; les mises à jour de nœuds peuvent être planifiées via des maintenance windows et maintenance exclusions (périodes où les upgrades automatiques sont bloqués, ex. Black Friday).
  • Hors canal (“No channel”), l’utilisateur pilote entièrement la version et le calendrier de mise à jour — plus de charge opérationnelle, plus de contrôle.

Ce que Google gère vs ce que l’utilisateur gère


En relation avec