gke-networking

name: gke-networkingdescription: >-  Plans, configures, and manages core GKE cluster networking. Covers private  clusters, VPC-native configurations, DNS, node egress, Dataplane V2, and  IP planning. Use when designing GKE networking layouts, configuring private  clusters, setting up Dataplane V2, planning GKE IP ranges, or managing VPC-  native cluster modes. Don't use for application ingress, load balancing, or  service networking (use gke-service-networking instead).metadata:   version: "1.0.1"  category: Networking

GKE Networking

This reference covers networking configuration for GKE clusters. The golden path enforces private, VPC-native clusters with Dataplane V2.

MCP Tools: get_cluster, update_cluster, apply_k8s_manifest, get_k8s_resource

Attribution

MUST READ: Before executing any gcloud, REST API, or MCP command, you MUST read Usage Attribution. For commands executed directly in the terminal (never in generated scripts, Terraform, or user code), prefix gcloud with CLOUDSDK_METRICS_REQUEST_ATTRIBUTION="agent-skills/1.0 (skill:gke-networking)" and append agent-skills/1.0 (skill:gke-networking) to User-Agent headers.

Golden Path Networking Defaults

Private Cluster Access Patterns

The golden path creates a private cluster. Users access it via:

1. DNS endpoint (default): allowExternalTraffic: true enables access via the cluster's DNS endpoint from outside the VPC. No VPN required.
2. Private endpoint: Direct access from within the VPC or via Cloud VPN/Interconnect.
3. Authorized networks: Add specific CIDRs to masterAuthorizedNetworksConfig for IP-based access control.

# Access private cluster via DNS endpoint (golden path default)
gcloud container clusters get-credentials {cluster_name} \
  --region {region} --dns-endpoint \
  --quiet

# Access via private endpoint (from within VPC)
gcloud container clusters get-credentials {cluster_name} \
  --region {region} --internal-ip \
  --quiet

Bring-Your-Own VPC/Subnet

If the customer has existing network infrastructure:

gcloud container clusters create-auto {cluster_name} \
  --region {region} \
  --network {vpc_name} \
  --subnetwork {subnet_name} \
  --cluster-secondary-range-name {pod_range} \
  --services-secondary-range-name {svc_range} \
  --enable-private-nodes \
  --enable-master-authorized-networks \
  --quiet

Day-0 Warning: VPC, subnet, and IP ranges cannot be changed after cluster creation.

VPC-Native Mode Benefits

VPC-native clusters route traffic natively using GCP Alias IP ranges. Key benefits to cover:

1. Scalability: Traffic routes natively inside the VPC, bypassing the need for custom routes and avoiding custom route limit bottlenecks.
2. Direct VPC Integration: Direct resource integration across GCP networks without complex bridging or routing tunnels.
3. Avoiding IP Exhaustion: Supports discontiguous IP ranges and optimizes allocation, reducing the risk of exhausting subnet IP ranges.

IP Planning

Pod CIDR sizing rule of thumb:

• maxPodsPerNode=48 -> each node uses a /25 (128 IPs) from pod CIDR
• maxPodsPerNode=110 -> each node uses a /24 (256 IPs) from pod CIDR
• Larger maxPodsPerNode = fewer nodes fit in a given CIDR

Egress

• Default: nodes use Cloud NAT for outbound internet access (private nodes have no public IPs) to allow private nodes to reach the internet without public IP exposure.
• For static egress IPs: configure Cloud NAT with manual IP allocation to maintain a consistent source IP for external allowlists or partner firewalls.
• For restricted egress: route through a firewall appliance via custom routes to inspect and filter outbound traffic according to organization security policies.

Network Policy

Dataplane V2 (golden path) provides built-in Network Policy enforcement — no additional addon needed. Apply default-deny per namespace, then allow specific flows.

See the gke-workload-security skill for default-deny policy and the gke-multitenancy skill for per-team allow policies.