Google PCNE: GKE, Container und Anwendungsnetzwerke — Lernleitfaden

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

Teil des Google Professional Cloud Network Engineer — Lernleitfaden. Üben Sie mit verifizierten Antworten im Google-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Google Kubernetes Engine (GKE) ist eng in das Networking der Google Cloud integriert. Das Design für Zuverlässigkeit und Sicherheit erfordert ein Verständnis von VPC-nativer IP-Adressierung, privaten Steuerungsebenen, Egress-, Nord-Süd- und Ost-West-Traffic, Richtliniendurchsetzung und Multi-Cluster-Konstrukten. Dieser Abschnitt bietet Design-Anleitungen, betriebliche Überlegungen und häufige Fehlermodi für Container- und Anwendungs-Networking in der Google Cloud.

GKE-IP-Architektur und private Cluster

VPC-native Cluster

• Verwenden Alias-IPs mit zwei sekundären Bereichen in einem VPC-Subnetz: einen für Pods (PodCIDR) und einen für Services (ServiceCIDR). Dies vermeidet iptables-basiertes SNAT auf Knoten, ermöglicht Container-natives Load Balancing mit NEGs und skaliert besser als routenbasierte Cluster.
• Richtlinien zur Dimensionierung:
  • Pods: Weisen Sie PodsPerNode × MaxNodes zu, plus einen Puffer (20–30 %). Zum Beispiel deuten aktuelle 10 Knoten × 20 Pods + Wachstum auf 100 × 200 auf einen /17-Pod-Bereich hin; Services passen oft in einen /21-Bereich für mehr als 2.000 Services.
  • Services: Jeder ClusterIP verbraucht eine IP; berücksichtigen Sie einen Puffer für Migrationen von Headless zu ClusterIP und für Add-ons.
• Fehlermodi:
  • Erschöpfung der Pod-IPs: Pods bleiben im Status Pending oder es treten CNI/IPAM-Fehler auf; skalieren Sie den sekundären Pod-Bereich oder reduzieren Sie die maximale Anzahl an Pods pro Knoten und erstellen Sie dann die Knoten neu.
  • Erschöpfung der Service-IPs: Neue Services können keinen ClusterIP zuweisen; erweitern Sie den sekundären Service-Bereich.
  • Überlappende Alias-Bereiche: Die Cluster-Erstellung schlägt fehl oder es kommt zu Routing-Blackholes; stellen Sie sicher, dass es keine Überschneidungen mit anderen Subnetzen oder über Peering verbundenen VPCs gibt.

Private Cluster, Zugriff auf die Steuerungsebene und Node-Egress

• Private Cluster beschränken den Endpunkt der Steuerungsebene auf eine private RFC1918-Adresse, die nur aus Ihrer VPC über Producer Peering erreichbar ist. Knoten benötigen keine externen IPs.
• Für Betreiber gibt es folgende Optionen:
  • Nur privater Endpunkt: Die Steuerungsebene ist aus VPC-Subnetzen und verbundenen Netzwerken erreichbar. Verwenden Sie eine Bastion-Host oder Cloud Shell mit Private Service Connect, um darauf zuzugreifen.
  • Öffentlicher Endpunkt mit autorisierten Netzwerken: Macht die Steuerungsebene über eine öffentliche IP verfügbar, die durch bestimmte Quell-CIDRs geschützt ist. Dies ist praktisch, erhöht aber die Angriffsfläche; nur mit eng gefassten CIDR-Bereichen und starken Kontrollen für Admin-Identitäten verwenden.
• Node-Egress:
  • Für Knoten ohne externe IPs, stellen Sie ausgehenden Internetverkehr über Cloud NAT bereit. Dies ermöglicht Betriebssystem-Updates, das Pullen von Container-Images aus externen Registries und den Zugriff auf Partner-APIs, während die Knoten privat bleiben.
  • Für den Zugriff auf Google APIs und Artifact/Container Registry ohne externe IPs, aktivieren Sie Private Google Access (PGA) auf den Knoten-Subnetzen. PGA löst den Traffic zu Google APIs/Registry auf und leitet ihn an den Edge von Google weiter, ohne öffentliche Quell-IPs zu verwenden. PGA wird für das Pullen von Images bevorzugt; kombinieren Sie es mit Cloud NAT, wenn auch Egress-Verkehr zu Zielen außerhalb von Google erforderlich ist.
  • Wenn Sie 0.0.0.0/0 durch eine Drittanbieter-Firewall leiten, aktivieren Sie dennoch PGA und fügen Sie statische Routen für die VIP-Bereiche der Google APIs zum Standard-Internet-Gateway hinzu, um die Firewall für Google-Dienste zu umgehen.

Skalierung und IP-Fehlerbehebung

• Überwachen Sie den Verbrauch von Alias-IPs auf der Ebene der sekundären Subnetzbereiche. Wenn der IP-Druck steigt:
  • Vergrößern Sie die sekundären Bereiche (fügen Sie größere Bereiche hinzu, erstellen Sie den Cluster neu oder migrieren Sie Workloads, wo erforderlich).
  • Passen Sie max-pods-per-node an, um die IP-Nutzung pro Knoten gegen die Fragmentierung beim Scheduling abzuwägen.
  • Entfernen Sie verwaiste Services; Headless Services weisen keine ClusterIPs zu, aber eine Umwandlung in ClusterIP verbraucht IPs.
• Planen Sie für multi-regionales Wachstum mit nicht überlappenden sekundären Bereichen, um eine Neu-Adressierung (Re-IP) bei der Verwendung von Shared VPCs, VPC Peering oder Multi-Cluster-Services zu vermeiden.

Ingress, Gateway API, Services und Richtlinien

Services und Load Balancer

• Service-Typen:
  • ClusterIP: Nur Zugriff innerhalb des Clusters; Ost-West-Traffic verwendet kube-proxy oder Dataplane v2.
  • NodePort: Weist jedem Knoten einen Port zu; wird von vielen LBs als Backend verwendet, aber vermeiden Sie die direkte Bereitstellung im Internet.
  • LoadBalancer: Stellt einen Cloud-Load-Balancer bereit. Externe oder interne L4-Load-Balancer unterstützen TCP/UDP; Sitzungsaffinität ClientIP sorgt bei Bedarf für Stickiness über mehrere Protokolle hinweg.
• Container-natives Load-Balancing verwendet Network Endpoint Groups (NEGs), sodass der Load Balancer direkt auf Pod-IP:Ports abzielt, was die Zustandsignalisierung verbessert und Knoten-Hops reduziert. Verwenden Sie für GKE die GKE Pod NEGs (GCE_POD). Andere NEG-Typen sind VM_IP_PORT, Internet FQDN und PSC.
• GKE Ingress und Gateway API:
  • Ingress ist stabil für Nord-Süd-HTTP(S)-Traffic mit dem globalen externen HTTP(S)-Load-Balancer oder dem regionalen internen HTTP(S)-Load-Balancer von Google. Der Controller programmiert Zustandsprüfungen und Firewall-Regeln für Standardmuster automatisch.
  • Die Gateway API bietet ein ausdrucksstärkeres Modell mit Gateways und HTTPRoutes/TCPRoutes. Sie unterstützt mandantenfähige Konfigurationen, erweitertes Routing und eine konsistente Spezifikation über Umgebungen hinweg. Wählen Sie die Gateway API für Zukunftssicherheit; verwenden Sie Ingress, wo Einfachheit und Kompatibilität wichtig sind.

Client-Einschränkung und Zustandsprüfungen

• Die Beschränkung von Clients auf bestimmte Quellbereiche kann auf L4 mit VPC-Firewall-Regeln, die auf Backend-Instanzen abzielen, oder auf L7 mit Cloud Armor-Richtlinien für HTTP(S)-Load-Balancer erfolgen.
• Erlauben Sie immer die Quellbereiche des Google Health Checkers für Backend-Ziele oder Pods, damit die Zustandsprüfungen erfolgreich sind. In einigen Deployments erstellt GKE automatisch k8s-fw-Regeln; wenn Sie restriktive Regeln hinzufügen, behalten Sie explizite Freigaben für die Health-Checker-Bereiche bei.
• Beispielhafter Ansatz für L4-Backends: Markieren Sie Knoten mit „application“ und erstellen Sie eine „allow“-Firewall-Regel für tcp:NodePort von erlaubten Client-CIDRs und den Google Health-Check-Bereichen sowie eine „deny“-Regel mit höherer Priorität für alle anderen Quellen mit aktiviertem Logging, um verworfene Pakete zu beobachten.

Netzwerkrichtlinien und Dataplane v2

• Aktivieren Sie Kubernetes NetworkPolicy und verwenden Sie GKE Dataplane V2 für die eBPF-basierte Durchsetzung, was die Leistung und Genauigkeit im Vergleich zu iptables-basierten Engines verbessert.
• Grundlegende Sicherheitskonfiguration:
  • Standardmäßiges Verbieten (Default Deny) von ausgehendem (Egress) und eingehendem (Ingress) Traffic für Namespaces; explizites Erlauben von Pod-zu-Pod- und Pod-zu-Service-Datenflüssen.
  • Verwenden Sie Namespace- und podSelectors, um Service-Ebenen (Frontend, Backend, Daten) zu erstellen und nur die minimal notwendigen Richtungen und Ports zu erlauben.
• Sichere Service-Kommunikation:
  • Für Zero Trust innerhalb des Clusters wird mTLS am besten durch ein Service Mesh bereitgestellt; NetworkPolicy behandelt L3/L4 und kann keine Identitäten authentifizieren.
  • Für Nord-Süd-Traffic, binden Sie Cloud Armor an HTTP(S)-LBs an, um WAF, Ratenbegrenzung und einen Vorschaumodus zu nutzen, mit dem ein „Deny“ für verdächtige Angreifer getestet werden kann, ohne die Benutzer zu stören.

Fehlermodi und Kompromisse

• Zu viele oder zu weit gefasste NetworkPolicies können zu unerwarteten Paketverlusten führen; validieren Sie dies mit gestaffelten Rollouts, Logging und Tools zur Richtlinienerklärung.
• Sich auf NodePort plus externe Firewall-Regeln zu verlassen, ist fehleranfällig; bevorzugen Sie verwaltete Load Balancer und Pod NEGs.
• Die Gateway API bietet umfangreichere Funktionen, erfordert aber ausgereifte Controller und Vertrautheit im Team; validieren Sie Funktionen wie Header-basiertes Routing oder mTLS-Passthrough pro Release-Channel.

Multi-Cluster, Service Mesh und Identität

Multi-Cluster-Dienste und Flotten-Networking

• Registrieren Sie Cluster in einer Flotte, um Multi-Cluster Services (MCS) für clusterübergreifende Service Discovery und Lastenausgleich zu nutzen. Exportieren Sie Dienste aus jedem Cluster; Clients lösen einen einzigen DNS-Namen auf, der von Endpunkten über mehrere Cluster hinweg unterstützt wird.
• Clusterübergreifende Traffic-Muster:
  • Gleiche VPC, unterschiedliche Subnetze: Der Traffic fließt über private RFC1918-Adressen mit optimalen Kosten und Latenzzeiten.
  • Unterschiedliche VPCs: Verbinden Sie mit VPC Peering für private, einfache Konnektivität ohne Transitivität, oder verwenden Sie Cloud VPN/Cloud Router, wenn sich die Organisationen unterscheiden oder eine Verschlüsselung über das Internet erforderlich ist. Für eine zentralisierte Verwaltung stellt Shared VPC nur die benötigten Subnetze für Serviceprojekte bereit.
• Fehlermodi:
  • Überlappende CIDRs blockieren das Routing; stellen Sie sicher, dass es keine Überschneidungen zwischen PodCIDR und ServiceCIDR gibt, bevor Sie Peering oder VPN einrichten.
  • DNS-Split-Horizon-Probleme können die clusterübergreifende Auflösung stören; validieren Sie Suchpfade und Stub-Domains.

Service Mesh, Ost-West-Traffic und Observability

• Stellen Sie ein Service Mesh wie Anthos Service Mesh bereit für:
  • mTLS mit starker Workload-Identität, Traffic-Richtlinien (Wiederholungsversuche, Timeouts, Ausreißererkennung) und Traffic-Splitting.
  • Konsistente Ost-West-Richtlinien über Cluster hinweg mit Mesh-Föderation oder Multi-Primary-Topologien.
  • Umfassende Telemetrie: Golden Signals pro Workload, Request-Traces und Richtlinien-Audits.
• Abwägungen:
  • Sidecars erhöhen den Ressourcen-Overhead; Ambient- oder Sidecarless-Modi können die Kosten senken, aber prüfen Sie die Feature-Parität.
  • Ein Mesh fügt Abhängigkeiten von der Control Plane hinzu; entwerfen Sie für HA-Control-Planes und eine kontrollierte Leistungsreduzierung (graceful degradation).

Workload-Identität, Secrets und Least Privilege

• Verwenden Sie Workload Identity, um Kubernetes Service Accounts (KSAs) auf Google Service Accounts (GSAs) abzubilden und so langlebige Schlüssel zu eliminieren. Annotieren Sie den KSA mit der GSA-E-Mail und gewähren Sie dem GSA minimale IAM-Rollen.
• Verwaltung von Secrets:
  • Bevorzugen Sie Secret Manager mit dem CSI-Treiber, um Secrets zur Laufzeit zu mounten; entfernen Sie einfache Kubernetes Secrets für sensible Daten oder verschlüsseln Sie sie im Ruhezustand (at rest) mit CMEK, falls sie beibehalten werden.
  • Gewähren Sie auf GSA-Ebene den Zugriff auf Secrets und Buckets nach dem Least-Privilege-Prinzip. Vermeiden Sie projektweite Rollen; beschränken Sie den Geltungsbereich auf Rollen auf Ressourcenebene wie storage.objectViewer, wo anwendbar.

Überlegungen zu Resilienz und sicherem Plattformdesign

• Regionale Cluster für hohe Verfügbarkeit; verteilen Sie die Knoten auf mehrere Zonen. Für Nord-Süd-Traffic verwenden Sie globales HTTP(S)-Load-Balancing für die geringste Latenz für globale Benutzer.
• Konnektivität der Control Plane: Wählen Sie private Control Planes; vermeiden Sie die öffentliche Erreichbarkeit, es sei denn, dies ist mit Authorized Networks zwingend erforderlich.
• Egress: Knoten ohne externe IPs in Kombination mit Cloud NAT und PGA schaffen ein Gleichgewicht zwischen Sicherheit und Funktionalität.
• Observability: Aktivieren Sie Firewall-Logging, VPC Flow Logs und Mesh-Telemetrie, um Richtlinienverstöße (Policy Drops) oder Latenzspitzen schnell zu diagnostizieren.

Praktisches Problemszenario

Contoso Retail betreibt zwei private regionale GKE-Cluster in us-east1 und europe-west1. Anforderungen: keine externen IPs auf den Knoten, sicherer Ingress, der auf Unternehmens-CIDRs beschränkt ist, globale Verfügbarkeit für einen Storefront-Dienst, Image-Pulls ohne Internetzugang und clusterübergreifendes Failover für die API-Ebene. Bei einem früheren Lastanstieg kam es zu einer Erschöpfung der Pod-IP-Adressen.

Vorgehensweise

1. Entwerfen Sie VPC-native Subnetze mit großzügigen sekundären Bereichen.

   • Begründung: Weisen Sie pro Region einen /17-Pod-Bereich und einen /21-Service-Bereich zu, um 100 Knoten × 200 Pods/Knoten und 1.500 Dienste mit 20–30 % Puffer abzudecken. Dies verhindert ein erneutes Auftreten der Pod-IP-Erschöpfung und vermeidet eine Neu-Adressierung (re-IP) während des Wachstums.

2. Erstellen Sie private Cluster mit privaten Control-Plane-Endpunkten.

   • Begründung: Beschränkt die Erreichbarkeit der Control Plane auf die VPC. Operatoren verbinden sich über eine Bastion-Host in einem Management-Subnetz. Dies reduziert die Angriffsfläche im Vergleich zu öffentlichen Endpunkten mit Authorized Networks.

3. Aktivieren Sie Cloud NAT und Private Google Access auf den Knoten-Subnetzen.

   • Begründung: Die Knoten haben keine externen IPs, müssen aber dennoch Images aus der Artifact Registry pullen und Betriebssystem-/Paket-Spiegelserver erreichen. PGA stellt den Zugriff auf Google-APIs ohne öffentliche Quell-IPs sicher; Cloud NAT übernimmt bei Bedarf den Egress-Traffic zu Zielen außerhalb von Google.

4. Implementieren Sie globalen HTTP(S)-Ingress mit der Gateway API und Pod NEGs.

   • Begründung: Eine einzige globale Anycast-VIP reduziert die Latenz für weltweite Benutzer. GKE Pod NEGs senden Health Checks direkt an die Pods und verbessern die Fehlererkennung. Die Gateway API bietet eine saubere Trennung zwischen Infrastruktur-Gateways und anwendungseigenen Routes.

5. Beschränken Sie den Client-Zugriff und erlauben Sie Health Checks.

   • Begründung: Hängen Sie eine Cloud Armor-Richtlinie an, um nur Unternehmens-CIDRs zuzulassen, mit einer standardmäßigen Ablehnung (Default Deny) und einem Vorschaumodus, um neue Blockierungen sicher zu bewerten. Stellen Sie außerdem sicher, dass die VPC-Firewallregeln die Quellbereiche der Google Health Checks zu den Backend-NEGs zulassen, damit die Health Checks grün bleiben.

6. Wenden Sie NetworkPolicy mit GKE Dataplane V2 an.

   • Begründung: Standardmäßiges Ablehnen (Default-Deny) von Ingress und Egress pro Namespace; erlauben Sie nur die Ports von Frontend zu Backend und von Backend zu Datenbank. Dataplane V2 setzt Richtlinien effizient mit eBPF durch und verkleinert so den Explosionsradius (Blast Radius) für kompromittierte Pods.

7. Aktivieren Sie Multi-Cluster Services über die Flotte hinweg.

   • Begründung: Exportieren Sie den API-Dienst in beiden Regionen und veröffentlichen Sie einen einzigen DNS-Namen. Clients führen automatisch ein Failover zu fehlerfreien Endpunkten in anderen Clustern durch. Da sich beide Cluster in derselben VPC mit regionalen Subnetzen befinden, bleibt der regionenübergreifende Traffic privat und verursacht minimalen Overhead.

8. Führen Sie ein Service Mesh für Ost-West-Sicherheit und Observability ein.

   • Begründung: Erzwingen Sie mTLS zwischen Diensten, fügen Sie Budgets für Wiederholungsversuche/Timeouts hinzu und erhalten Sie Metriken und Traces pro Route. Richtlinien auf Mesh-Ebene ergänzen NetworkPolicy: NetworkPolicy steuert die Erreichbarkeit auf L3/L4; das Mesh authentifiziert und autorisiert Dienstidentitäten auf L7.

9. Härten Sie Workload-Identitäten und Secrets.

   • Begründung: Bilden Sie KSAs über Workload Identity auf eng gefasste GSAs ab; gewähren Sie nur notwendige Rollen wie storage.objectViewer für Report-Fetcher. Stellen Sie Anmeldeinformationen über den Secret Manager CSI bereit, um statische Secrets in Manifesten zu vermeiden.

10. Implementieren Sie Leitplanken (Guardrails) für Kapazität und Logging.

    • Begründung: Legen Sie max-pods-per-node sorgfältig fest, um die IP-Nutzung auszugleichen. Überwachen Sie die Auslastung der sekundären Bereiche und die VPC Flow Logs. Erstellen Sie eine explizite deny-all-Firewallregel mit hoher Priorität und Logging für das Anwendungs-Tag, um unbeabsichtigten Client-Traffic aufzudecken, während die erlaubten Pfade erhalten bleiben.

Dieses Design führt zu standardmäßig privaten (private-by-default) Clustern mit kontrolliertem Nord-Süd-Zugriff, resilientem Multi-Cluster-Failover, einer prinzipienbasierten Least-Privilege-Identität und einer Dataplane, die ohne wiederkehrende IP-Erschöpfung skaliert.

← Routing · Alle Domänen · Netzwerk-Observability →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Google durchsuchen →