What's changed: Created Professional Cloud Network Engineer Chapter 2 (Domain 2 "Implement": VPC/subnets/firewall rules-policies, VPC peering (non-transitive), Shared VPC and compute.networkUser, Private Google Access, VPC Service Controls perimeter, subnet expansion, static/Cloud Router dynamic routing, route priority/network tags, internal LB next hop, policy-based routing, Network Connectivity Center spokes/topologies/Private NAT/PSC propagation/CIDR filters, GKE = VPC-native/private clusters/authorized networks/DNS-based endpoint/Dataplane V2/IP masquerade/network policies/Pod-Service ranges).
2.2Network Connectivity Center and GKE clusters
Understand Network Connectivity Center spoke types (VPC/hybrid/producer), topologies (star/hub-and-spoke/mesh), Private NAT and PSC propagation, CIDR filters, VPC-native clusters (alias IPs), clusters with Shared VPC, private clusters and control-plane endpoints, authorized networks, DNS-based endpoints, Dataplane V2, SNAT/IP masquerade, network policies, and Pod/Service ranges.
This covers aggregating many networks and implementing GKE cluster networking. Centrally manage reachability with NCC, and configure GKE IPs, exposure, and policies correctly.
2.2.1Configuring Network Connectivity Center
Network Connectivity Center (NCC) connects spokes to a hub for centralized reachability. Spokes are VPC spokes (attach VPCs), hybrid spokes (VPN/VLAN attachments), and producer spokes (managed services). Choose star, hub-and-spoke, or mesh topology by requirement to achieve transitive reachability (which peering alone cannot). Configure NAT with Private NAT, service-publishing propagation with PSC propagation, narrow unwanted routes with CIDR range filters, and monitor/troubleshoot NCC. Map "transitive connectivity that peering can't build = NCC."
2.2.2Implementing GKE cluster networking
Build GKE as VPC-native clusters (alias IPs), optionally on Shared VPC. For security choose private clusters and private control-plane endpoints, limiting management with authorized networks or a DNS-based endpoint. Enable the eBPF-based Dataplane V2 for visibility and network policy. Control egress source translation with SNAT/IP masquerade policies, and define Pod-to-Pod allow/deny with GKE network policies. Allocate Pod ranges and Service ranges, adding additional Pod ranges if short. Configure in-cluster DNS with kube-dns / Cloud DNS / local DNS cache.
Common: requirement → means. E.g., "transitively aggregate many VPCs and hybrid" = NCC spokes; "attach VPN/VLAN to the hub" = hybrid spokes; "control Pod-to-Pod traffic" = GKE network policies (+ Dataplane V2); "private nodes" = private cluster; "limit control-plane management source" = authorized networks/DNS-based endpoint; "control egress source IP translation" = IP masquerade.
Watch the mix-ups: (1) GKE network policies (Pod-to-Pod L3/L4) vs Cloud NGFW/VPC firewall (VPC level) are different layers. (2) Undersized Pod/Service ranges block scaling—extend with additional Pod ranges. (3) Combine authorized networks and private endpoints to lock down management paths.
2.2.3Section summary
- NCC = VPC/hybrid/producer spokes for hub aggregation; transitive reachability peering can't build
- GKE = VPC-native (alias IPs)/private clusters/authorized networks/Dataplane V2
- Pod-to-Pod control = GKE network policies; egress source = IP masquerade; reserve Pod/Service ranges
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. To attach VPN/VLAN attachments and many VPCs to one hub for centrally managed transitive reachability, which is best?
Q2. To make a VPC-native GKE cluster using dedicated secondary ranges for Pods and Services, which mechanism?
Q3. To allow/deny GKE Pod-to-Pod traffic based on namespaces/labels, which mechanism?
Q4. To restrict management access to the GKE control plane to specific corporate IP ranges, which setting?
Q5. To control which source ranges get SNAT when GKE Pods egress externally, which do you use?