gke-networking
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).
摘要
- 用途
- 为 GKE 创建以私有集群和 VPC 原生模式为基础的网络基准,并说明集群地址配置、DNS、对外流量及网络政策如何配合。
- 使用时机
- 当你需要比较私有控制平面的访问方式、规划 Pod 与 Service 地址范围、集成既有 VPC 或子网络,或设计对外流量与集群内流量控管时使用。
- 输出结果
- 提供建议的网络设置、集群访问方式与指令、IP 范围规划指引,以及对外连接和网络政策的设置选项。
上游变更(6 条,最新收录 2026-09-21)
6aa329d Add gke-workload-security and rename gke-security to gke-platform-security 将 Network Policy 说明中有关预设拒绝原则的参照,从 `gke-security` 更新为 `gke-workload-security`。 48378f5 Rescope gke-networking and add gke-service-networking. Refined evaluation benchmarks for both skills. 将技能重新聚焦于内核集群网络,移除入口与服务网络相关内容,并扩充 VPC 原生模式及输出流量说明。 4ce85f5 Update GKE skills to clarify Autopilot defaults, VPC-Native benefits, and Backup for GKE best practices: - gke-cluster-creation: Add warning and operational details when deviating to GKE Standard mode. - gke-networking: Document benefits of VPC-Native mode (scalability, direct VPC integration, avoiding IP exhaustion). - gke-golden-path: Update defaults table to include loggingConfig. - gke-backup-dr: Add best practices for stateful backups (quiescing, CSI snapshots, service terminology). 添加 VPC 原生模式的效益章节,涵盖扩充性、直接 VPC 集成及降低 IP 耗尽风险。 c75b500 Restructure the YAML frontmatter in all SKILL.md files to nest the 'category' field under the 'metadata:' block. The 'category' field is used to organize the skills in the README.md 将 Networking 类别字段移至技能 YAML 前置数据的 `metadata` 区块中。 5d9d054 Refactor GKE basic skill into individual skills 添加 GKE 网络技能文档,涵盖私有集群预设设置与访问、VPC/IP 规划、入口与输出流量、网络原则、Cloud Armor、SSL 及 PSC。 npx skills add "lettucebo/Skills#v2.2.0@gke-networking" --full-depth ⚠ v2.2.0 发布后即可使用
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
Golden Path Networking Defaults
| Setting | Golden Path Value | Day-0/1 | Notes |
|---|---|---|---|
privateClusterConfig.enablePrivateNodes |
true |
Day-0 | Nodes have no public IPs |
masterAuthorizedNetworksConfig.privateEndpointEnforcementEnabled |
true |
Day-0 | Control plane only reachable via private endpoint or DNS |
controlPlaneEndpointsConfig.dnsEndpointConfig.allowExternalTraffic |
true |
Day-0 | Allows DNS-based access from outside VPC |
networkConfig.datapathProvider |
ADVANCED_DATAPATH (Dataplane V2) |
Day-0 | eBPF-based, built-in Network Policy |
networkConfig.dnsConfig.clusterDns |
CLOUD_DNS |
Day-0 | Managed DNS, more reliable than kube-dns |
networkConfig.enableIntraNodeVisibility |
true |
Day-1 | VPC Flow Logs for intra-node traffic |
ipAllocationPolicy.autoIpamConfig.enabled |
true |
Day-0 | Automatic IP range management |
ipAllocationPolicy.createSubnetwork |
true |
Day-0 | Auto-create dedicated subnet |
defaultMaxPodsConstraint.maxPodsPerNode |
48 |
Day-0 | Conservative default; 110 for high density |
Private Cluster Access Patterns
The golden path creates a private cluster. Users access it via:
- DNS endpoint (default):
allowExternalTraffic: trueenables access via the cluster's DNS endpoint from outside the VPC. No VPN required. - Private endpoint: Direct access from within the VPC or via Cloud VPN/Interconnect.
- Authorized networks: Add specific CIDRs to
masterAuthorizedNetworksConfigfor 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:
- Scalability: Traffic routes natively inside the VPC, bypassing the need for custom routes and avoiding custom route limit bottlenecks.
- Direct VPC Integration: Direct resource integration across GCP networks without complex bridging or routing tunnels.
- Avoiding IP Exhaustion: Supports discontiguous IP ranges and optimizes allocation, reducing the risk of exhausting subnet IP ranges.
IP Planning
| Resource | Golden Path | Notes |
|---|---|---|
| Pod CIDR | /17 (auto) |
~32K pod IPs; size based on maxPodsPerNode |
| Service CIDR | /20 (auto) |
~4K service IPs |
| Node subnet | auto-created | /20 recommended for growth |
| Max pods/node | 48 | Each node gets a /25 pod range; set to 110 |
| : : : for /24 per node : |
Pod CIDR sizing rule of thumb:
maxPodsPerNode=48-> each node uses a/25(128 IPs) from pod CIDRmaxPodsPerNode=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-securityskill for default-deny policy and thegke-multitenancyskill for per-team allow policies.