Google PCNE: GKE, conteneurs et mise en réseau des applications — Guide d'étude

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Fait partie du Google Professional Cloud Network Engineer — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Google, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

Google Kubernetes Engine (GKE) s’intègre étroitement avec le réseau Google Cloud. La conception pour la fiabilité et la sécurité nécessite de comprendre l’adressage IP natif du VPC, les plans de contrôle privés, le trafic sortant (egress), le trafic nord-sud et est-ouest, l’application des politiques et les constructions multi-clusters. Cette section fournit des conseils de conception, un raisonnement opérationnel et les modes de défaillance courants pour les conteneurs et le réseau applicatif sur Google Cloud.

Architecture IP de GKE et clusters privés

Clusters natifs du VPC

• Utilisent des adresses IP d’alias avec deux plages secondaires dans un sous-réseau VPC : une pour les Pods (PodCIDR) et une pour les Services (ServiceCIDR). Cela évite le SNAT basé sur iptables sur les nœuds, permet l’équilibrage de charge natif des conteneurs avec les NEG, et offre une meilleure scalabilité que les clusters basés sur des routes.
• Recommandations de dimensionnement :
  • Pods : allouez PodsPerNode × MaxNodes, plus une marge de manœuvre (20–30 %). Par exemple, 10 nœuds actuels × 20 Pods + une croissance jusqu’à 100 × 200 suggère une plage de Pods en /17 ; les Services tiennent souvent dans une plage /21 pour plus de 2000 services.
  • Services : chaque ClusterIP consomme une adresse IP ; prévoyez une marge de manœuvre pour les migrations de services headless vers ClusterIP et pour les modules complémentaires (add-ons).
• Modes de défaillance :
  • Épuisement des adresses IP des Pods : les Pods restent à l’état Pending ou des erreurs CNI/IPAM apparaissent ; étendez la plage secondaire des Pods ou réduisez le nombre maximal de pods par nœud, puis recréez les nœuds.
  • Épuisement des adresses IP des Services : les nouveaux Services ne parviennent pas à allouer de ClusterIP ; étendez la plage secondaire des Services.
  • Chevauchement des plages d’alias : la création du cluster échoue ou des trous noirs de routage se produisent ; validez l’absence de chevauchement avec d’autres sous-réseaux ou VPC appairés.

Clusters privés, accès au plan de contrôle et trafic sortant des nœuds

• Les clusters privés limitent le point de terminaison du plan de contrôle à une adresse privée RFC1918, joignable uniquement depuis votre VPC via l’appairage de producteur (producer peering). Les nœuds ne nécessitent pas d’adresses IP externes.
• Pour les opérateurs, choisissez :
  • Point de terminaison privé uniquement : le plan de contrôle est joignable depuis les sous-réseaux du VPC et les réseaux connectés. Utilisez un bastion ou Cloud Shell avec Private Service Connect pour l’atteindre.
  • Point de terminaison public avec des réseaux autorisés (Authorized Networks) : exposez le plan de contrôle sur une adresse IP publique, protégée par des CIDR sources spécifiques. C’est pratique mais augmente l’exposition ; à n’utiliser qu’avec un périmètre CIDR restreint et des contrôles d’identité d’administrateur stricts.
• Trafic sortant des nœuds (egress) :
  • Pour les nœuds sans adresse IP externe, fournissez un accès sortant vers Internet via Cloud NAT. Cela permet les mises à jour du système d’exploitation, le téléchargement d’images de conteneurs depuis des registres externes et l’accès aux API partenaires tout en gardant les nœuds privés.
  • Pour accéder aux API Google et à Artifact/Container Registry sans adresses IP externes, activez l’Accès Privé à Google (Private Google Access - PGA) sur les sous-réseaux des nœuds. PGA résout et route le trafic des API/registres Google vers le réseau périphérique de Google sans adresses IP sources publiques. PGA est la méthode privilégiée pour le téléchargement d’images ; combinez-le avec Cloud NAT si un trafic sortant non-Google est également requis.
  • Si vous envoyez le trafic 0.0.0.0/0 à travers un pare-feu tiers, activez tout de même PGA et ajoutez des routes statiques pour les plages d’adresses IP virtuelles (VIP) des API Google vers la passerelle Internet par défaut afin de contourner le pare-feu pour les services Google.

Mise à l’échelle et dépannage IP

• Surveillez la consommation d’adresses IP d’alias au niveau de la plage secondaire du sous-réseau. Si la pression sur les adresses IP augmente :
  • Augmentez la taille des plages secondaires (ajoutez des plages plus grandes, recréez le cluster ou migrez les charges de travail si nécessaire).
  • Ajustez le max-pods-per-node pour équilibrer l’utilisation des adresses IP par nœud par rapport à la fragmentation de la planification (scheduling).
  • Élaguez les Services abandonnés ; les services headless n’allouent pas de ClusterIP, mais leur conversion en ClusterIP consommera des adresses IP.
• Planifiez la croissance multi-régionale avec des plages secondaires qui ne se chevauchent pas pour éviter d’avoir à ré-adresser les IP lors de l’utilisation de VPC partagés (Shared VPCs), d’appairage de VPC (VPC Peering) ou de services multi-clusters.

Ingress, Gateway API, Services et politiques

Services et équilibreurs de charge

• Types de Service :
  • ClusterIP : accès uniquement au sein du cluster ; le trafic est-ouest utilise kube-proxy ou dataplane v2.
  • NodePort : alloue un port sur chaque nœud ; utilisé par de nombreux LB comme backend, mais évitez de l’exposer directement sur Internet.
  • LoadBalancer : provisionne un équilibreur de charge cloud. Les équilibreurs de charge L4 externes ou internes prennent en charge TCP/UDP ; l’affinité de session ClientIP assure la persistance (stickiness) sur plusieurs protocoles lorsque nécessaire.
• L’équilibrage de charge natif pour les conteneurs utilise les Network Endpoint Groups (NEG) afin que l’équilibreur de charge cible directement les IP:ports des Pods, améliorant ainsi la signalisation de l’état de santé et réduisant les sauts de nœud. Pour GKE, utilisez les GKE Pod NEGs (GCE_POD). D’autres types de NEG incluent VM_IP_PORT, Internet FQDN et PSC.
• GKE Ingress et Gateway API :
  • Ingress est stable pour le trafic nord-sud HTTP(S) avec l’équilibreur de charge HTTP(S) externe mondial de Google ou l’équilibreur de charge HTTP(S) interne régional. Le contrôleur programme automatiquement les vérifications de l’état de santé et les règles de pare-feu pour les schémas standards.
  • Gateway API fournit un modèle plus expressif avec les Gateways et les HTTPRoutes/TCPRoutes. Elle prend en charge les configurations multi-locataires (multi-tenant), le routage avancé et une spécification cohérente entre les environnements. Choisissez Gateway API pour pérenniser vos solutions ; utilisez Ingress lorsque la simplicité et la compatibilité sont primordiales.

Restriction des clients et vérifications de l’état de santé

• La restriction des clients à des plages sources spécifiques peut se faire au niveau L4 avec des règles de pare-feu VPC ciblant les instances backend ou au niveau L7 avec des politiques Cloud Armor sur les équilibreurs de charge HTTP(S).
• Autorisez toujours les plages sources du vérificateur de l’état de santé de Google vers les cibles backend ou les Pods afin que les vérifications de l’état de santé réussissent. Dans certains déploiements, GKE crée automatiquement des règles k8s-fw ; si vous ajoutez des règles restrictives, conservez des autorisations explicites pour les plages du vérificateur de l’état de santé.
• Approche exemplaire pour les backends L4 : étiquetez les nœuds avec « application » et créez une règle de pare-feu d’autorisation pour tcp:NodePort depuis les CIDR clients autorisés et les plages de vérification de l’état de santé de Google, ainsi qu’une règle de refus de priorité plus élevée pour toutes les autres sources avec journalisation pour observer les rejets.

Politiques réseau et dataplane v2

• Activez les NetworkPolicy de Kubernetes et utilisez GKE Dataplane V2 pour une application basée sur eBPF, améliorant ainsi les performances et la fidélité par rapport aux moteurs basés sur iptables.
• Posture de base :
  • Refusez par défaut le trafic sortant (egress) et entrant (ingress) pour les namespaces ; autorisez explicitement les flux de Pod à Pod et de Pod à Service.
  • Utilisez les namespace et podSelectors pour créer des niveaux de service (frontend, backend, data) et n’autorisez que les directions et les ports strictement nécessaires.
• Sécurisation de la communication entre services :
  • Pour une approche zero trust au sein du cluster, le mTLS est idéalement fourni par un maillage de services (service mesh) ; les NetworkPolicy gèrent les niveaux L3/L4 et ne peuvent pas authentifier les identités.
  • Pour le trafic nord-sud, attachez Cloud Armor aux LB HTTP(S) pour le WAF, la limitation de débit (rate limiting), et le mode prévisualisation afin de tester un refus sur des attaquants présumés sans perturber les utilisateurs.

Modes de défaillance et compromis

• Des NetworkPolicies trop nombreuses ou trop larges peuvent provoquer des rejets de paquets inattendus ; validez avec des déploiements progressifs, de la journalisation et des outils d’explication de politiques.
• S’appuyer sur NodePort et des règles de pare-feu externes est fragile ; préférez les équilibreurs de charge gérés et les Pod NEGs.
• Gateway API apporte des fonctionnalités plus riches mais nécessite une maturité du contrôleur et une familiarité de l’équipe ; validez les fonctionnalités comme le routage basé sur les en-têtes ou le mTLS passthrough pour chaque canal de publication (release channel).

Multi-cluster, maillage de services et identité

Services multi-clusters et mise en réseau de flottes

• Enregistrez les clusters dans une flotte pour utiliser les Multi-Cluster Services (MCS) pour la découverte de services et l’équilibrage de charge inter-clusters. Exportez les services de chaque cluster ; les clients résolvent un nom DNS unique soutenu par des points de terminaison (endpoints) répartis sur les clusters.
• Modèles de trafic inter-clusters :
  • Même VPC, sous-réseaux différents : le trafic transite via des adresses privées RFC1918 avec un coût et une latence optimaux.
  • VPC différents : connectez-vous avec VPC Peering pour une connectivité privée et simple sans transitivité, ou utilisez Cloud VPN/Cloud Router si les organisations diffèrent ou si un chiffrement est requis sur Internet. Pour une administration centralisée, le Shared VPC n’expose que les sous-réseaux nécessaires aux projets de service.
• Modes de défaillance :
  • Les chevauchements de CIDR bloquent le routage ; assurez-vous de l’absence de chevauchement entre PodCIDR et ServiceCIDR avant le peering ou la connexion VPN.
  • Les problèmes de DNS split-horizon peuvent interrompre la résolution inter-clusters ; validez les chemins de recherche (search paths) et les domaines de stub (stub domains).

Maillage de services, trafic est-ouest et observabilité

• Déployez un maillage de services tel que Anthos Service Mesh pour :
  • Le mTLS avec une identité de charge de travail (workload) forte, des politiques de trafic (réessais, délais d’attente, détection des points aberrants) et la répartition du trafic.
  • Une politique est-ouest cohérente entre les clusters avec une fédération de maillage ou des topologies multi-primaires.
  • Une télémétrie riche : signaux de référence (golden signals) par charge de travail, traces de requêtes et audits de politiques.
• Compromis :
  • Les sidecars augmentent la surcharge en ressources ; les modes ambiants ou sans sidecar peuvent réduire les coûts, mais il faut valider la parité des fonctionnalités.
  • Le maillage ajoute des dépendances au plan de contrôle ; concevez des plans de contrôle en haute disponibilité (HA) et une dégradation progressive (graceful degradation).

Identité des charges de travail, secrets et moindre privilège

• Utilisez Workload Identity pour mapper les comptes de service Kubernetes (KSA) aux comptes de service Google (GSA), éliminant ainsi les clés à longue durée de vie. Annotez le KSA avec l’e-mail du GSA et accordez des rôles IAM minimaux au GSA.
• Gestion des secrets :
  • Préférez Secret Manager avec le pilote CSI pour monter les secrets à l’exécution ; supprimez les Secrets Kubernetes en clair pour les données sensibles ou chiffrez-les au repos avec CMEK s’ils sont conservés.
  • Accordez un accès de moindre privilège aux secrets et aux buckets au niveau du GSA. Évitez les rôles à l’échelle du projet ; limitez la portée aux rôles au niveau de la ressource comme storage.objectViewer lorsque c’est applicable.

Considérations sur la résilience et la conception de plateforme sécurisée

• Clusters régionaux pour la haute disponibilité ; répartissez les nœuds sur plusieurs zones. Pour le trafic nord-sud, utilisez l’équilibrage de charge HTTP(S) global pour une latence minimale pour les utilisateurs mondiaux.
• Connectivité du plan de contrôle : choisissez des plans de contrôle privés ; évitez l’exposition publique sauf si c’est strictement nécessaire avec les Authorized Networks.
• Sortie (Egress) : les nœuds sans adresses IP externes, combinés à Cloud NAT et PGA, équilibrent sécurité et fonctionnalité.
• Observabilité : activez la journalisation du pare-feu, les VPC Flow Logs et la télémétrie du maillage pour diagnostiquer rapidement les rejets de politiques ou les pics de latence.

Scénario de problème pratique

Contoso Retail exploite deux clusters GKE régionaux privés dans us-east1 et europe-west1. Exigences : pas d’adresses IP externes sur les nœuds, un trafic entrant (ingress) sécurisé limité aux CIDR de l’entreprise, une disponibilité mondiale pour un service de vitrine (storefront), le tirage d’images (image pulls) sans exposition à Internet, et un basculement inter-clusters pour la couche API. Ils ont déjà subi un épuisement des adresses IP des pods lors d’une montée en charge.

Approche

1. Concevoir des sous-réseaux VPC-native avec des plages secondaires généreuses.

   • Justification : Allouer une plage /17 pour les pods et une plage /21 pour les services par région pour couvrir 100 nœuds × 200 pods/nœud et 1 500 services avec une marge de 20 à 30 %. Cela prévient la récurrence de l’épuisement des adresses IP des pods et évite un re-adressage IP pendant la croissance.

2. Créer des clusters privés avec des points de terminaison de plan de contrôle privés.

   • Justification : Limite l’exposition du plan de contrôle au VPC. Les opérateurs se connectent via un bastion sur un sous-réseau de gestion. Cela réduit la surface d’attaque par rapport aux points de terminaison publics avec Authorized Networks.

3. Activer Cloud NAT et Private Google Access sur les sous-réseaux des nœuds.

   • Justification : Les nœuds n’ont pas d’adresses IP externes mais doivent quand même tirer des images depuis Artifact Registry et atteindre les miroirs de l’OS/des paquets. PGA garantit l’accès aux API Google sans adresses IP sources publiques ; Cloud NAT gère le trafic sortant non-Google selon les besoins.

4. Implémenter un trafic entrant (ingress) HTTP(S) global en utilisant la Gateway API avec des NEG de pods.

   • Justification : Une seule VIP anycast globale réduit la latence pour les utilisateurs du monde entier. Les NEG de pods GKE envoient les vérifications de santé (health checks) directement aux pods et améliorent la détection des défaillances. La Gateway API offre une séparation nette entre les Gateways d’infrastructure et les Routes appartenant aux applications.

5. Restreindre l’accès client et autoriser les vérifications de santé.

   • Justification : Attacher une politique Cloud Armor pour n’autoriser que les CIDR de l’entreprise, avec un refus par défaut et un mode aperçu (preview) pour évaluer de nouveaux blocages en toute sécurité. De plus, s’assurer que les règles de pare-feu VPC autorisent les plages sources des vérifications de santé Google vers les NEG de backend pour que les vérifications de santé restent au vert.

6. Appliquer des NetworkPolicy avec GKE Dataplane V2.

   • Justification : Refuser par défaut le trafic entrant et sortant par espace de noms (namespace) ; n’autoriser que les ports du frontend vers le backend et du backend vers la base de données. Dataplane V2 applique les politiques efficacement avec eBPF, réduisant le rayon d’impact (blast radius) pour les pods compromis.

7. Activer les Multi-Cluster Services sur l’ensemble de la flotte.

   • Justification : Exporter le service API dans les deux régions et publier un DNS unique. Les clients basculent automatiquement vers les points de terminaison sains à travers les clusters. Comme les deux clusters sont dans le même VPC avec des sous-réseaux régionaux, le trafic inter-régional reste privé et n’entraîne qu’une surcharge minimale.

8. Adopter un maillage de services pour la sécurité est-ouest et l’observabilité.

   • Justification : Appliquer le mTLS entre les services, ajouter des budgets de réessai/délai d’attente, et obtenir des métriques et des traces par route. La politique au niveau du maillage complète la NetworkPolicy : la NetworkPolicy contrôle l’accessibilité L3/L4 ; le maillage authentifie et autorise les identités de service au niveau L7.

9. Renforcer les identités des charges de travail et les secrets.

   • Justification : Mapper les KSA à des GSA à portée restreinte via Workload Identity ; n’accorder que les rôles nécessaires tels que storage.objectViewer pour les services qui récupèrent des rapports. Fournir les informations d’identification via le CSI de Secret Manager pour éviter les secrets statiques dans les manifestes.

10. Mettre en place des garde-fous pour la capacité et la journalisation.

    • Justification : Définir max-pods-per-node de manière réfléchie pour équilibrer l’utilisation des adresses IP. Surveiller l’utilisation des plages secondaires et les VPC Flow Logs. Créer une règle de pare-feu explicite de haute priorité deny-all avec journalisation sur le tag de l’application pour faire apparaître le trafic client non intentionnel tout en préservant les chemins autorisés.

Cette conception aboutit à des clusters privés par défaut avec un accès nord-sud contrôlé, un basculement multi-cluster résilient, une identité basée sur le principe du moindre privilège, et un plan de données qui peut évoluer sans épuisement récurrent des adresses IP.

← Routage · Tous les domaines · Observabilité du réseau →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Google →