What's changed: Created Professional Cloud Network Engineer Chapter 1 (Domain 1 "Design and plan": network tiers/HA/DR/scale/Shared VPC/VPC peering/Network Connectivity Center/IAM; IPAM/subnets/IPv6/PUPI/Private NAT/DNS topology/global-regional dynamic routing/MTU; hybrid-multicloud = Dedicated/Partner/Cross-Cloud Interconnect/HA VPN/Direct Peering/hybrid DNS/MACsec; GKE design = VPC-native/secondary ranges/private clusters/authorized networks).
1.2Hybrid/multicloud and GKE design
Understand hybrid connectivity (Dedicated/Partner Interconnect, Cloud VPN, SD-WAN), multicloud connectivity (Cloud VPN, Cross-Cloud Interconnect), Direct Peering vs Verified Peering Provider, cross-region HA/DR, hybrid DNS topology (forwarding/inbound policies/DNS peering), interconnect encryption (MACsec/HA VPN over Interconnect), and GKE network design (VPC-native, secondary ranges, private clusters, control-plane access).
Choose hybrid/other-cloud connectivity by bandwidth, latency, SLA, and encryption requirements. And because mistakes in GKE IP design force rebuilds later, decide it correctly up front.
1.2.1Choosing hybrid/multicloud connectivity
For on-prem links needing high bandwidth, low latency, and an SLA, choose Dedicated Interconnect (your own physical link to Google) or Partner Interconnect (via a partner); for a simple encrypted tunnel use Cloud VPN (prefer HA VPN, 99.99% SLA). Reach other clouds with Cross-Cloud Interconnect or Cloud VPN. If you only need public access to Google services, consider Direct Peering / Verified Peering Provider. Design cross-region HA/DR with redundant Interconnect/VPN and global dynamic routing. Build hybrid name resolution as a hybrid DNS topology: Cloud DNS forwarding zones, inbound server policies, and DNS peering for bidirectional resolution. When interconnect encryption is required, use MACsec or HA VPN over Cloud Interconnect.
1.2.2GKE network design
Base GKE on VPC-native clusters (alias IPs), allocating secondary ranges for Pods and Services on the subnet. Scale ceilings are set by the allocated IP space, so size node/Pod/Service counts and reserve ranges accordingly. For security, choose private clusters (no external IPs on nodes) and private control-plane endpoints, and limit management with authorized networks or a DNS-based endpoint. Design load balancing with container-native LB (NEGs) and GKE Gateway/Ingress. Map "Pods/Services = secondary ranges" and "no external IP on nodes = private cluster."
Common: requirement → means. E.g., "high-bandwidth, low-latency on-prem link with SLA" = Dedicated/Partner Interconnect; "simple encrypted tunnel, 99.99% SLA" = HA VPN; "dedicated link to another cloud" = Cross-Cloud Interconnect; "bidirectional DNS between on-prem and cloud" = forwarding zones + inbound policy (+ DNS peering); "encrypt the interconnect" = MACsec/HA VPN over Interconnect; "Pod/Service IPs" = secondary ranges; "private nodes" = private cluster.
Watch the mix-ups: (1) Choose Interconnect (dedicated, high bandwidth/SLA) vs Cloud VPN (encrypted tunnel, simple) by requirements. (2) Classic VPN is legacy—use HA VPN (99.99% SLA) for new work. (3) Undersized GKE secondary ranges hit scale ceilings—size them at design time.
1.2.3Section summary
- On-prem = Interconnect (bandwidth/SLA) or HA VPN (encrypted); other cloud = Cross-Cloud Interconnect
- Hybrid DNS = forwarding zones/inbound policy/DNS peering for bidirectional resolution; encrypt interconnect = MACsec/HA VPN
- GKE = VPC-native (alias IPs)/secondary ranges; private = private cluster + authorized networks
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. To link on-prem and Google Cloud with high bandwidth, low latency, and an SLA via your own colocation, which is best?
Q2. For a simple encrypted tunnel to on-prem with a 99.99% SLA, which is best?
Q3. To give GKE Pods and Services dedicated IP ranges as a VPC-native cluster, which mechanism?
Q4. To keep GKE nodes without external IPs and restrict control-plane management to specific IPs, which design?
Q5. To build bidirectional hybrid DNS where on-prem resolves Cloud DNS private zones and vice versa, which means?