Google PCNE: Architecture VPC, sous-réseaux et planification des adresses — 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

Un Virtual Private Cloud (VPC) est un réseau mondial, logiquement isolé, qui s’étend à toutes les régions Google Cloud. Les sous-réseaux (subnets) sont des constructions régionales au sein d’un VPC et hébergent des plages d’adresses IP qui soutiennent Compute Engine, GKE et d’autres ressources. Une architecture VPC solide équilibre l’efficacité de l’adressage, la croissance et le contrôle opérationnel, tout en garantissant une connectivité à faible latence et économique pour les charges de travail intra- et inter-projets, ainsi que vers les API Google.

Portée du VPC, architecture des sous-réseaux et modes

• VPC global, sous-réseaux régionaux

  • Un seul VPC s’étend à toutes les régions. Les sous-réseaux sont créés par région et définissent des CIDR IPv4 primaires ainsi que des plages secondaires optionnelles. Les instances reçoivent des adresses IP des sous-réseaux régionaux mais peuvent communiquer en privé entre les régions au sein du même VPC par défaut.
  • Mode de routage dynamique
    • Régional : les Cloud Routers n’échangent des routes qu’avec les sous-réseaux de leur région.
    • Global : les Cloud Routers d’une région annoncent les routes apprises à toutes les régions. Privilégiez le mode global lorsque des charges de travail multi-régionales ou une sortie haute disponibilité (HA egress) sont nécessaires.

• Mode automatique vs mode personnalisé

  • Le mode automatique (auto mode) crée un sous-réseau par région avec des CIDR pré-assignés. C’est pratique pour des démarrages rapides mais manque de flexibilité à grande échelle. Il peut être converti en mode personnalisé (custom mode) ; la conversion est à sens unique.
  • Le mode personnalisé (custom mode) offre un contrôle total sur la création des sous-réseaux et le choix des CIDR. C’est le modèle recommandé pour la planification d’adresses en production, le VPC partagé (Shared VPC), le peering et la croissance.
  • Note de migration : après la conversion du mode automatique en mode personnalisé, les artefacts ou les modèles qui supposaient l’existence de sous-réseaux automatiques échouent souvent jusqu’à ce qu’ils soient explicitement mis à jour pour référencer les sous-réseaux personnalisés.

• Immuabilité et croissance des sous-réseaux

  • La région d’un sous-réseau est immuable ; vous ne pouvez pas déplacer un sous-réseau entre les régions.
  • Les plages IPv4 primaires peuvent être étendues sur place (élargissement du préfixe), ne peuvent pas être réduites, et ne doivent pas se chevaucher avec d’autres plages dans le VPC ou les réseaux connectés.
  • Les plages secondaires peuvent être ajoutées ou supprimées (sous réserve de leur utilisation), mais elles ne doivent pas non plus se chevaucher.

Planification de l’adressage : plages primaires/secondaires, IP d’alias, IPv6 et espace privé

• Plages IPv4 primaires et secondaires

  • Plage primaire : assigne les adresses des interfaces de VM (nic0 par défaut). Elle crée une route de sous-réseau générée par le système et est utilisée pour la plupart des communications internes.
  • Plages secondaires : associent des CIDR supplémentaires au sous-réseau et sont requises pour les clusters GKE en mode VPC-native. Les routes générées par le système pour les plages secondaires permettent la connectivité est-ouest pour les Pods et les Services.

• Adresses IP d’alias (Alias IPs)

  • Les adresses IP d’alias permettent à une carte réseau (NIC) de VM de posséder plusieurs adresses IP des plages primaires ou secondaires du sous-réseau, ce qui permet une politique stricte basée sur les IP, l’attribution d’IP de Pods pour GKE en mode VPC-native, et une utilisation efficace des adresses IP.
  • Pour GKE, planifiez de grands CIDR secondaires continus pour minimiser la fragmentation et les redimensionnements futurs. Exemple : pour 100 nœuds avec 200 Pods/nœud et 1500 Services, allouez une plage secondaire pour les Pods d’au moins /17 et pour les Services d’au moins /21 afin de laisser une marge de manœuvre.

• Conception RFC 1918 privée et gestion des adresses IP

  • Choisissez des blocs qui ne se chevauchent pas entre tous les VPC actuels et prévus, les réseaux sur site (on-premises) et ceux des partenaires. Réservez de grands blocs parents pour chaque environnement, puis découpez des sous-blocs prévisibles par région et par fonction.
  • Réservez de la capacité pour la croissance, les plages secondaires, les tampons de migration (double pile/double NAT temporaire) et les points de terminaison d’infrastructure (VIP d’ILB, points de terminaison PSC).
  • Évitez les blocs d’entreprise les plus courants si une connectivité avec des partenaires est probable ; ou segmentez avec du NAT pour résoudre les conflits.

• Planification IPv6

  • IPv6 externe : utilisez des adresses IPv6 externes globales sur les équilibreurs de charge globaux (global load balancers) pour l’accès client et la joignabilité anycast.
  • IPv6 interne : là où c’est disponible, activez les sous-réseaux à double pile (dual-stack) pour assigner des adresses IPv6 internes aux VM et ajustez les règles de pare-feu en conséquence. Planifiez les enregistrements DNS AAAA et assurez la parité avec la politique IPv4.
  • Conservez IPv4 pour les contrôles intra-cloud et les intégrations tierces ; introduisez IPv6 de manière incrémentale via les équilibreurs de charge et les sous-réseaux à double pile.

Opérations : expansion, haute disponibilité, accès privé, vérification et dépannage

• Contraintes d’expansion et de migration des sous-réseaux

  • Étendre sur place lorsqu’un sous-réseau approche de sa capacité ; valider l’absence de chevauchement avec tous les réseaux connectés et s’assurer que les plages secondaires dépendantes de GKE restent adéquates.
  • Si des plages se chevauchent entre organisations ou partenaires, utiliser le NAT ou une renumérotation par étapes. Vous ne pouvez pas appairer des VPC qui se chevauchent ni installer des routes dynamiques qui se chevauchent.

• Positionnement régional et haute disponibilité

  • Placer les sous-réseaux dans les régions les plus proches des utilisateurs et des données. Pour une base d’utilisateurs transatlantique, un seul VPC avec des sous-réseaux régionaux dans us-east1 et europe-west1 fournit une connectivité privée directe avec une latence optimale et sans frais de sortie à l’intérieur du VPC.
  • Répartir les charges de travail sur plusieurs zones ; utiliser des groupes d’instances gérés régionaux et des répartiteurs de charge internes/externes régionaux pour la tolérance aux pannes de zone.
  • Pour l’hybride, déployer deux Cloud Routers et rattachements par région ou emplacement de périphérie ; activer BFD là où il est pris en charge ; utiliser le routage dynamique global pour le basculement.

• Accès privé à Google et points de terminaison restreints

  • Activer PGA sur les sous-réseaux hébergeant des instances sans adresses IP externes.
  • Pour empêcher la sortie Internet générale tout en autorisant les API Google :
    • Router le trafic par défaut vers votre NGFW.
    • Ajouter des routes statiques plus spécifiques pour les VIP des API Google vers la passerelle Internet par défaut ou déployer des points de terminaison PSC vers les API Google.

  • Exemple :

undefined

• Vérification de la topologie et dépannage
  • Utiliser Network Intelligence Center :
    • Connectivity Tests pour valider l’accessibilité et simuler les décisions de routage, de pare-feu et de passerelle.
    • Performance Dashboard et Topology pour visualiser les chemins et leur état.
  • Journaux et télémétrie :
    • VPC Flow Logs pour observer les autorisations/refus et la latence par interface.
    • Firewall Rules Logging pour confirmer la correspondance des règles.
    • Journaux et état de Cloud NAT pour les problèmes de sortie sans IP externe.
    • Journaux du répartiteur de charge et des vérifications de l’état pour la disponibilité des backends.

  • Vérifications en CLI :

undefined

et

undefined

pour confirmer la politique effective. -

undefined

et

undefined

depuis des VM de test ; utiliser le packet mirroring pour une inspection approfondie si nécessaire.

Scénario de problème pratique

Le groupe Acme Retail a besoin d’un réseau Google Cloud multi-régional à faible latence avec un contrôle centralisé, un accès sans Internet aux API Google pour les instances privées, et une isolation stricte entre les départements qui n’ont pas besoin de communiquer. Certaines équipes exécutent GKE avec une forte densité de pods. Acme dirige également le trafic de sortie général via un pare-feu tiers, mais souhaite que le trafic des API Google évite ce pare-feu.

1. Construire un seul VPC partagé (Shared VPC) dans un projet hôte en mode personnalisé avec routage dynamique global, et créer des sous-réseaux régionaux dans us-east1 et europe-west1 avec des plages secondaires réservées pour GKE.

• Justification : Un seul VPC fournit une connectivité privée, sans frais, inter-régionale sur des adresses RFC1918 pour une efficacité optimale. Le mode personnalisé et le routage dynamique global permettent une planification IP précise et la propagation des routes multi-régionales.

2. Partager uniquement les sous-réseaux spécifiques nécessaires avec le projet de service de chaque département ; créer trois projets de service (Ventes, Finance, Marketing) et n’exposer que les sous-réseaux requis à chacun.

• Justification : Le partage par sous-réseau limite le rayon d’impact et l’exposition des routes, renforçant l’isolation tout en permettant des opérations centralisées. L’IAM délégué permet aux administrateurs réseau centraux de gérer les pare-feu et les routes, tandis que les équipes applicatives déploient les charges de travail de manière indépendante.

3. Pour les départements qui doivent communiquer, appairer leurs VPC dédiés ou les placer dans les mêmes sous-réseaux du VPC partagé ; pour les départements isolés, s’abstenir d’appairer et ne pas partager de sous-réseaux qui se chevauchent.

• Justification : L’appairage (peering) fournit une connectivité privée à faible latence avec une surcharge opérationnelle minimale. La non-transitivité exige des connexions maillées explicites uniquement là où c’est nécessaire, ce qui préserve l’isolation par défaut.

4. Activer l’Accès privé à Google (Private Google Access) sur tous les sous-réseaux partagés et déployer des points de terminaison Private Service Connect vers les API Google ; conserver la route par défaut vers un pare-feu tiers, et ajouter des routes statiques plus spécifiques pour les VIP des API Google vers la passerelle Internet par défaut.

• Justification : PGA et PSC permettent la consommation des API sans passer par Internet depuis des VM privées. Les routes plus spécifiques garantissent que le trafic des API contourne le NGFW tandis que le trafic de sortie Internet non-Google continue de passer par le chemin d’inspection.

5. Allouer des CIDR primaires et secondaires avec une marge de croissance : pour GKE, dimensionner une plage secondaire pour les pods (par exemple, /17) et une plage secondaire pour les services (/21) par région à fort trafic ; utiliser des adresses IP d’alias pour les pods et les services et créer des clusters VPC-natifs liés à ces plages.

• Justification : Les plages secondaires et les adresses IP d’alias préviennent l’épuisement des adresses IP des nœuds et permettent une planification dense. Le dimensionnement pour la demande future évite les redimensionnements perturbateurs et la renumérotation des plages secondaires.

6. Mettre en œuvre la haute disponibilité (HA) pour le trafic hybride et des appliances : déployer deux Cloud Routers et un VPN HA ou une Interconnexion selon les besoins ; lorsqu’il est nécessaire de diriger le trafic via une appliance virtuelle, utiliser une route personnalisée plus spécifique avec le saut suivant (next hop) défini sur un répartiteur de charge interne régional ou une instance avec le transfert IP activé et une applicabilité limitée par des tags.

• Justification : La haute disponibilité en périphérie assure la continuité en cas de panne. La portée des routes par tags évite le hairpinning accidentel du trafic et permet uniquement aux instances sélectionnées de traverser le chemin de l’appliance.

7. Vérifier et opérer avec les Connectivity Tests de Network Intelligence Center, les VPC Flow Logs et le Firewall Rules Logging ; appliquer des politiques de pare-feu basées sur l’identité en utilisant des comptes de service et maintenir des enregistrements IPAM avec des tampons réservés par région et par fonction.

• Justification : La vérification proactive prévient les pannes lors des changements. Les politiques basées sur l’identité sont plus robustes que les approches basées uniquement sur les tags. La discipline IPAM empêche les chevauchements qui bloqueraient l’appairage ou supprimeraient des routes apprises.

Tous les domaines · Règles de pare-feu →

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

Parcourir Google →