Google PCNE: GKE, Containers en Applicatienetwerken — Studiegids

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

Onderdeel van de Google Professional Cloud Network Engineer — Studiegids. Oefen met geverifieerde antwoorden in het Google-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Google Kubernetes Engine (GKE) is nauw geïntegreerd met Google Cloud-netwerkmogelijkheden. Voor het ontwerpen van betrouwbare en veilige systemen is inzicht vereist in VPC-native IP-adressering, private control planes, egress, north-south- en east-west-verkeer, policy enforcement en multi-cluster-constructies. Dit gedeelte biedt richtlijnen voor ontwerp, operationele overwegingen en veelvoorkomende faalscenario’s voor containers en applicatienetwerken op Google Cloud.

GKE IP-architectuur en private clusters

VPC-native clusters

• Gebruiken alias-IP’s met twee secundaire bereiken in een VPC-subnet: één voor Pods (PodCIDR) en één voor Services (ServiceCIDR). Dit voorkomt op iptables gebaseerde SNAT op nodes, maakt container-native load balancing met NEG’s mogelijk en schaalt beter dan op routes gebaseerde clusters.
• Richtlijnen voor dimensionering:
  • Pods: wijs PodsPerNode × MaxNodes toe, plus extra ruimte (20-30%). Bijvoorbeeld, huidige 10 nodes × 20 Pods + groei naar 100 × 200 suggereert een /17 Pod-bereik; Services passen vaak in een /21 voor 2K+ services.
  • Services: elke ClusterIP verbruikt één IP; houd rekening met extra ruimte voor migraties van headless naar ClusterIP en voor add-ons.
• Faalscenario’s:
  • Uitputting van Pod-IP’s: Pods blijven in de status Pending of er verschijnen CNI/IPAM-fouten; schaal het secundaire Pod-bereik op of verlaag het maximale aantal pods per node en maak de nodes vervolgens opnieuw aan.
  • Uitputting van Service-IP’s: nieuwe Services kunnen geen ClusterIP toewijzen; breid het secundaire Service-bereik uit.
  • Overlappende alias-bereiken: het aanmaken van het cluster mislukt of er ontstaan routing blackholes; valideer dat er geen overlap is met andere subnets of peered VPC’s.

Private clusters, toegang tot het control plane en node egress

• Private clusters beperken het control plane-eindpunt tot een privaat RFC1918-adres dat alleen bereikbaar is vanuit uw VPC via producer peering. Nodes hebben geen externe IP-adressen nodig.
• Voor operators, kies uit:
  • Alleen een privaat eindpunt: het control plane is bereikbaar vanuit VPC-subnets en verbonden netwerken. Gebruik een bastion-host of Cloud Shell met Private Service Connect om het te bereiken.
  • Publiek eindpunt met Authorized Networks: stel het control plane beschikbaar op een publiek IP-adres, afgeschermd door specifieke bron-CIDR’s. Dit is handig maar verhoogt de blootstelling; gebruik dit alleen met strikte CIDR-scoping en sterke identiteitscontroles voor beheerders.
• Node egress:
  • Voorzie voor nodes zonder externe IP-adressen in uitgaand internetverkeer via Cloud NAT. Dit maakt OS-updates, het pullen van container-images van externe registries en toegang tot partner-API’s mogelijk, terwijl de nodes privaat blijven.
  • Voor toegang tot Google API’s en Artifact/Container Registry zonder externe IP-adressen, schakel Private Google Access (PGA) in op de subnets van de nodes. PGA lost verkeer naar Google API’s/registry op en routeert dit naar de edge van Google zonder publieke bron-IP’s. PGA heeft de voorkeur voor het pullen van images; combineer het met Cloud NAT als er ook uitgaand verkeer naar niet-Google-diensten nodig is.
  • Als u 0.0.0.0/0 via een firewall van een derde partij stuurt, schakel dan alsnog PGA in en voeg statische routes voor de Google API’s VIP-bereiken toe aan de standaard internetgateway om de firewall te omzeilen voor Google-services.

Schalen en IP-troubleshooting

• Monitor het verbruik van alias-IP’s op het niveau van het secundaire subnetbereik. Als de IP-druk toeneemt:
  • Vergroot de secundaire bereiken (voeg grotere bereiken toe, maak het cluster opnieuw aan of migreer workloads waar nodig).
  • Pas max-pods-per-node aan om een balans te vinden tussen IP-gebruik per node en scheduling-fragmentatie.
  • Ruim verlaten Services op; headless Services wijzen geen ClusterIP’s toe, maar het omzetten naar ClusterIP zal wel IP’s verbruiken.
• Plan voor multi-regionale groei met niet-overlappende secundaire bereiken om her-IP’en te voorkomen bij het gebruik van Shared VPC’s, VPC Peering of multi-cluster services.

Multi-cluster, service mesh en identiteit

Multi-cluster services en fleet-netwerken

• Registreer clusters in een fleet om Multi-Cluster Services (MCS) te gebruiken voor cross-cluster service discovery en load balancing. Exporteer services vanuit elk cluster; clients lossen één enkele DNS-naam op die wordt ondersteund door endpoints over clusters heen.
• Cross-cluster verkeerspatronen:
  • Zelfde VPC, verschillende subnets: verkeer loopt via privé RFC1918 met optimale kosten en latency.
  • Verschillende VPC’s: verbind met VPC Peering voor privé, eenvoudige connectiviteit zonder transitiviteit, of gebruik Cloud VPN/Cloud Router als organisaties verschillen of als versleuteling via het internet vereist is. Voor gecentraliseerd beheer stelt Shared VPC alleen de benodigde subnets beschikbaar aan serviceprojecten.
• Faalscenario’s:
  • Overlappende CIDR’s blokkeren de routering; zorg voor geen overlap tussen PodCIDR en ServiceCIDR voordat je peering of VPN instelt.
  • DNS split-horizon problemen kunnen cross-cluster resolutie verbreken; valideer zoekpaden en stub-domeinen.

Service mesh, oost-west en observability

• Implementeer een service mesh zoals Anthos Service Mesh voor:
  • mTLS met sterke workload-identiteit, verkeersbeleid (retries, timeouts, outlier-detectie) en traffic splitting.
  • Consistent oost-west beleid over clusters heen met mesh-federatie of multi-primary topologieën.
  • Rijke telemetrie: ‘golden signals’ per workload, request traces en beleidsaudits.
• Afwegingen:
  • Sidecars verhogen de resource-overhead; ambient of sidecarless modi kunnen de kosten verlagen, maar valideer de feature-pariteit.
  • Een mesh voegt control plane-afhankelijkheden toe; ontwerp voor HA control planes en ‘graceful degradation’.

Workload-identiteit, secrets en ’least privilege’

• Gebruik Workload Identity om Kubernetes Service Accounts (KSA’s) te koppelen aan Google service accounts (GSA’s), waardoor langlevende sleutels worden geëlimineerd. Annoteer de KSA met de GSA-e-mail en ken minimale IAM-rollen toe aan de GSA.
• Beheer van secrets:
  • Geef de voorkeur aan Secret Manager met de CSI-driver om secrets tijdens runtime te mounten; verwijder platte Kubernetes Secrets voor gevoelige data of versleutel ze ‘at rest’ met CMEK als ze behouden blijven.
  • Ken ’least-privilege’ toegang tot secrets en buckets toe op de GSA. Vermijd rollen op projectniveau; beperk de scope tot rollen op resourceniveau zoals storage.objectViewer waar van toepassing.

Overwegingen voor veerkracht en een veilig platformontwerp

• Regionale clusters voor hoge beschikbaarheid; spreid nodes over zones. Gebruik voor noord-zuid verkeer globale HTTP(S) load balancing voor de laagste latency voor wereldwijde gebruikers.
• Connectiviteit van de control plane: kies voor private control planes; vermijd publieke blootstelling tenzij strikt noodzakelijk met Authorized Networks.
• Egress: nodes zonder externe IP’s plus Cloud NAT en PGA balanceren beveiliging en functionaliteit.
• Observability: schakel firewall-logging, VPC Flow Logs en mesh-telemetrie in om beleidsmatige ‘drops’ of latency-pieken snel te diagnosticeren.

Praktisch Probleemscenario

Contoso Retail beheert twee private regionale GKE-clusters in us-east1 en europe-west1. Vereisten: geen externe IP’s op nodes, beveiligde ingress beperkt tot bedrijfs-CIDR’s, wereldwijde beschikbaarheid voor een storefront-service, het pullen van images zonder internetblootstelling, en cross-cluster failover voor de API-laag. Ze hebben eerder te maken gehad met uitputting van Pod IP-adressen tijdens een piek.

Aanpak

1. Ontwerp VPC-native subnets met ruime secundaire ranges.

   • Reden: Wijs een /17 Pod-range en een /21 Service-range per regio toe om 100 nodes × 200 Pods/node en 1.500 services te dekken met 20–30% extra ruimte. Dit voorkomt herhaling van Pod IP-uitputting en vermijdt het opnieuw toewijzen van IP’s tijdens groei.

2. Maak private clusters met private control plane-endpoints.

   • Reden: Beperkt de blootstelling van de control plane tot de VPC. Operators maken verbinding via een bastion op een beheersubnet. Dit verkleint het aanvalsoppervlak in vergelijking met publieke endpoints met Authorized Networks.

3. Schakel Cloud NAT en Private Google Access in op node-subnets.

   • Reden: Nodes hebben geen externe IP’s maar moeten nog steeds images kunnen pullen van Artifact Registry en OS/package mirrors kunnen bereiken. PGA zorgt voor toegang tot Google API’s zonder publieke bron-IP’s; Cloud NAT handelt waar nodig niet-Google egress-verkeer af.

4. Implementeer globale HTTP(S)-ingress met behulp van de Gateway API met Pod NEGs.

   • Reden: Eén enkele globale anycast VIP verlaagt de latency voor wereldwijde gebruikers. GKE Pod NEGs sturen health checks rechtstreeks naar Pods en verbeteren de detectie van storingen. De Gateway API biedt een duidelijke scheiding tussen infra-Gateways en door de app beheerde Routes.

5. Beperk clienttoegang en sta health checks toe.

   • Reden: Koppel een Cloud Armor-beleid om alleen bedrijfs-CIDR’s toe te staan, met een ‘default deny’ en een preview-modus om nieuwe blokkades veilig te evalueren. Zorg er daarnaast voor dat VPC-firewallregels de bron-ranges van Google health checks naar de backend-NEGs toestaan, zodat de health checks groen blijven.

6. Pas NetworkPolicy toe met GKE Dataplane V2.

   • Reden: Standaard ingress en egress weigeren per namespace; sta alleen frontend-naar-backend en backend-naar-database poorten toe. Dataplane V2 handhaaft beleid efficiënt met eBPF, wat de ‘blast radius’ voor gecompromitteerde Pods verkleint.

7. Schakel Multi-Cluster Services in voor de hele fleet.

   • Reden: Exporteer de API-service in beide regio’s en publiceer één enkele DNS. Clients voeren automatisch een failover uit naar gezonde endpoints in andere clusters. Omdat beide clusters zich in dezelfde VPC bevinden met regionale subnets, blijft cross-regionaal verkeer privé en brengt het minimale overhead met zich mee.

8. Adopteer een service mesh voor oost-west beveiliging en observability.

   • Reden: Dwing mTLS af tussen services, voeg retry/timeout-budgetten toe en verkrijg per-route metrics en traces. Beleid op mesh-niveau vult NetworkPolicy aan: NetworkPolicy regelt de bereikbaarheid op L3/L4; de mesh authenticeert en autoriseert service-identiteiten op L7.

9. Verhard workload-identiteiten en secrets.

   • Reden: Koppel KSA’s aan GSA’s met een beperkte scope via Workload Identity; ken alleen noodzakelijke rollen toe, zoals storage.objectViewer voor rapport-fetchers. Lever credentials via de Secret Manager CSI om statische secrets in manifests te vermijden.

10. Implementeer ‘guardrails’ voor capaciteit en logging.

    • Reden: Stel max-pods-per-node zorgvuldig in om het IP-gebruik te balanceren. Monitor het gebruik van de secundaire range en VPC Flow Logs. Maak een expliciete ‘deny-all’ firewallregel met hoge prioriteit en logging op de applicatie-tag om onbedoeld clientverkeer zichtbaar te maken, terwijl toegestane paden behouden blijven.

Dit ontwerp levert ‘private-by-default’ clusters op met gecontroleerde noord-zuid toegang, veerkrachtige multi-cluster failover, een principiële ’least-privilege’ identiteit en een dataplane die schaalt zonder terugkerende IP-uitputting.

← Routing · Alle domeinen · Netwerkobservability →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →

Blader door Google →