Les offres GKE parlent d'ingénieur cloud GCP, de DevOps GCP ou de platform engineer. Les mêmes outils reviennent : Terraform, GitLab CI, Argo CD ou Flux, Prometheus et Grafana, parfois Config Connector ou Crossplane pour créer les ressources Google Cloud depuis Kubernetes. Le travail principal reste le cluster : mode Autopilot ou Standard, réseau VPC-native, identité des pods, mises à jour et sécurité des images.
Autopilot a changé l'entretien. Un candidat qui n'a connu que ce mode n'a jamais dimensionné un node pool ni réglé un autoscaler, mais il doit savoir déclarer des requests justes, puisqu'elles fixent la facture. À l'inverse, un profil Standard peut ignorer les compute classes, qui apportent le fonctionnement d'Autopilot dans un cluster Standard. L'entretien fait préciser quel mode la personne a exploité, et pourquoi ce choix.
Deux sujets reviennent dans les incidents. Avec Workload Identity Federation for GKE, deux clusters du même projet partagent les mêmes identités. Et la plage d'adresses des pods, choisie trop petite à la création, bloque l'ajout de nœuds. Le PDF couvre six axes et un cas de 20 minutes.
GKE et les services Google Cloud qui l'entourent
GKE Standard et Autopilot
Deux modes. En Standard, l'équipe crée et dimensionne ses node pools. En Autopilot, Google gère les nœuds et facture la plupart des pods selon leurs requests de CPU et de mémoire, avec des restrictions sur les pods privilégiés et sans accès aux nœuds. Les compute classes permettent aussi de lancer des charges en mode Autopilot dans un cluster Standard.
Workload Identity Federation for GKE
Le mécanisme qui donne aux pods des droits sur les API Google Cloud sans clé de compte de service. Le compte de service Kubernetes devient un principal IAM, à qui l'on accorde des rôles ou que l'on autorise à emprunter un compte de service IAM. Le serveur de métadonnées GKE, présent sur chaque nœud, distribue les jetons.
Réseau VPC-native et Dataplane V2
Les pods prennent leurs adresses dans une plage secondaire du sous-réseau. Par défaut, chaque nœud réserve un /24 pour ses pods, jusqu'à 110 pods, donc la taille de cette plage fixe le nombre maximal de nœuds. GKE Dataplane V2, basé sur eBPF et Cilium, applique les network policies.
GKE Gateway et load balancers
Le contrôleur GKE Gateway crée les load balancers de Google Cloud à partir des ressources Gateway et HTTPRoute : externes ou internes, régionaux ou globaux. GKE Ingress existe toujours. Les NEG envoient le trafic directement aux pods, sans passer par les nœuds.
Canaux de publication et maintenance
Rapid, Regular (par défaut), Stable ou Extended : le canal fixe le rythme des mises à jour automatiques. Les fenêtres de maintenance choisissent le moment, les exclusions bloquent un temps certains types de mise à jour. Extended garde une version mineure jusqu'à 24 mois, avec un coût pendant la période étendue. L'option sans canal disparaît le 14 juin 2027.
Artifact Registry et Binary Authorization
Artifact Registry stocke les images et l'analyse de vulnérabilités les examine. Binary Authorization refuse au déploiement les images qui n'ont pas été attestées par la chaîne de build.
Fleet, Config Sync et Policy Controller
Une fleet regroupe plusieurs clusters pour les gérer ensemble. Config Sync applique depuis Git les configurations communes, Policy Controller, basé sur Gatekeeper, les règles de sécurité. Ces fonctions venaient de GKE Enterprise, qui n'est plus une offre séparée depuis septembre 2025.
Cloud Service Mesh
Le service mesh managé de Google, basé sur Istio, qui s'appelait Anthos Service Mesh. Il chiffre le trafic entre services et donne des métriques par service. Beaucoup de clusters s'en passent : reste à savoir s'il était vraiment exploité.
Observabilité et sauvegarde
Cloud Logging et Cloud Monitoring sont actifs par défaut, Managed Service for Prometheus collecte les métriques au format Prometheus. Backup for GKE sauvegarde les objets et les volumes persistants.
Sur Free-Work, GKE apparaît dans des offres d'ingénieur cloud GCP, de DevOps GCP et d'architecte de software factory, avec Terraform, GitLab CI, Argo CD et souvent Go ou Python. Certaines demandent aussi d'écrire des opérateurs ou d'utiliser Crossplane et Cluster API, et le poste glisse alors vers le platform engineering. Pour un rôle de run, la pratique des mises à jour, des quotas et des incidents passe devant. Pour un rôle de construction, la conception du réseau et de l'IAM dans les projets Google Cloud. La certification Google Professional Cloud DevOps Engineer et la CKA servent de filtre, sans remplacer un cluster tenu en production.
Six domaines à couvrir avec un ingénieur GKE
- Choix entre Autopilot, Standard et compute classes
- Workload Identity Federation for GKE et IAM Google Cloud
- Plages d'adresses VPC-native et réseau
- Canaux de publication et mises à jour
- Exposition par Gateway et load balancers
- Sécurité de la chaîne d'images et supervision
Les premières questions d'entretien GKE
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Un nouveau cluster doit héberger une vingtaine de services web et un traitement de nuit sur GPU. Autopilot ou Standard ?
Une bonne réponseIl part des contraintes. Autopilot convient aux services web : pas de nœuds à gérer, des pods facturés selon leurs requests, une sécurité renforcée par défaut. Les GPU se demandent par compute class ou par sélecteur, avec une facturation fondée sur le nœud. Standard s'impose si l'on a besoin de pods privilégiés hors liste autorisée, de réglages du noyau, du canal Extended ou d'agents qu'Autopilot refuse. Il cite les compute classes, qui placent des charges en mode Autopilot dans un cluster Standard, et rappelle qu'en Autopilot une request mal réglée se paie directement.
Signal d'alerte« Autopilot, c'est pour les petits projets », ou « Standard est toujours moins cher », sans parler des requests ni des restrictions.
Question 2 · senior
Les clusters de développement et de production sont dans le même projet Google Cloud. Un pod de développement a pu lire un bucket de production. Comment est-ce possible ?
Une bonne réponseAvec Workload Identity Federation for GKE, tous les clusters d'un projet partagent le même pool d'identités, PROJECT_ID.svc.id.goog. Un compte de service Kubernetes qui a le même namespace et le même nom est la même identité pour IAM, quel que soit le cluster. Correctifs : un projet par environnement ou par niveau de confiance, des noms de namespaces distincts, ou des conditions IAM qui limitent l'accès à un cluster. Il accorde les rôles sur le bucket, pas sur le projet.
Signal d'alerte« Le pod a dû trouver une clé quelque part », sans connaître le partage d'identité. Ou des clés JSON de compte de service par cluster comme solution.
Question 3 · confirmé
L'autoscaler ne peut plus ajouter de nœuds faute d'adresses dans la plage des pods, créée en /20. Que se passe-t-il, et que faites-vous ?
Une bonne réponseAvec 110 pods maximum par nœud, chaque nœud réserve un /24 de la plage des pods. Un /20 contient seize /24, donc seize nœuds, même si chacun ne fait tourner que dix pods. Solutions : ajouter une plage de pods supplémentaire sur un nouveau node pool, baisser le maximum de pods par nœud pour les nouveaux pools (64 pods prennent un /25, 32 un /26), ou recréer le cluster avec une plage plus large. Il vérifie aussi la plage principale, celle des nœuds.
Signal d'alerteAgrandir la plage principale du sous-réseau, qui ne règle rien pour les pods, ou demander une hausse de quota de nœuds.
Question 4 · confirmé
Une mise à jour automatique est prévue pendant une période où aucune interruption n'est acceptable. Comment la contrôlez-vous sans sortir le cluster de son canal ?
Une bonne réponseUne fenêtre de maintenance pour les créneaux habituels, et une exclusion pour la période sensible : « No upgrades » jusqu'à 90 jours, ou « No minor upgrades » et « No minor or node upgrades » jusqu'à la fin de support de la version. Il sait qu'aucune exclusion ne retient un cluster au-delà de la fin de support, et que les clusters hors canal n'ont droit qu'à « No upgrades ». Il ajoute la stratégie de mise à jour des nœuds et des PodDisruptionBudgets.
Signal d'alerte« Je désactive les mises à jour automatiques », ce que GKE ne permet pas pour le plan de contrôle. Ou sortir du canal, option supprimée en juin 2027.
Question 5 · confirmé
Vous devez exposer une API en HTTPS sur internet et un service interne pour d'autres équipes. Comment faites-vous avec GKE Gateway ?
Une bonne réponseDeux Gateway avec des GatewayClass différentes : une classe externe gérée (gke-l7-global-external-managed ou sa version régionale) pour l'API publique, la classe interne gke-l7-rilb pour le service interne. Les équipes créent leurs HTTPRoute dans leurs namespaces. Certificats par Certificate Manager ou certificats gérés par Google, Cloud Armor attaché par une GCPBackendPolicy, health checks réglés par une HealthCheckPolicy. Le trafic arrive directement aux pods par les NEG.
Signal d'alerteUn Service LoadBalancer par API avec une IP publique, sans TLS ni filtrage.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Poste GKE, les questions fréquentes
Un profil qui n'a connu qu'Autopilot peut-il tenir un cluster Standard ?
Avec un temps d'adaptation. Il connaît les requests, Workload Identity Federation for GKE, Gateway et les canaux de publication, soit la plus grande partie du quotidien. Il lui manque le dimensionnement des node pools, les réglages de l'autoscaler, les stratégies de mise à jour des nœuds et le dépannage au niveau du nœud. Sur un parc en Standard, les questions sur l'autoscaler et sur la plage des pods montrent vite l'écart.
Faut-il chercher d'abord un expert Google Cloud ou un expert Kubernetes ?
Pour un poste GKE, Kubernetes d'abord, avec une bonne pratique de l'IAM et du réseau Google Cloud. Un spécialiste Kubernetes venu d'EKS ou d'AKS apprend vite Workload Identity Federation for GKE et les plages secondaires. Un profil Google Cloud sans pratique de Kubernetes aura plus de mal avec les montées de version, l'ordonnancement et le dépannage des pods. Pendant l'entretien technique, au moins deux axes portent sur Kubernetes lui-même.
Combien de temps dure le test technique d'un ingénieur GKE ?
Trente à quarante-cinq minutes suffisent, en direct. Un cas de conception, comme dimensionner les plages d'adresses et choisir Autopilot ou Standard, puis un diagnostic à partir d'événements et de journaux. Le cluster à monter chez soi sur un projet personnel est à écarter : c'est long, payant pour la personne, et peu représentatif. Chaque choix se commente à voix haute.
Que vaut la certification Professional Cloud DevOps Engineer pour un poste GKE ?
Elle atteste une connaissance des pratiques SRE et des services Google Cloud de livraison et de supervision, GKE compris. Elle reste valable deux ans. Elle ne prouve pas qu'une personne a dimensionné une plage de pods, mené une montée de version ou traité un incident de production. C'est un signal sur un CV junior, et l'expérience réelle se vérifie par des situations précises.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
