GKE 网络：IP、入口与访问控制

适用：Autopilot / Standard 的普通 IPv4、VPC-native 网络。创建步骤见 Autopilot 或 Standard；VPC 基础见 VPC 与 subnet。本页不覆盖多网卡 Pod 或 IPv4/IPv6 dual-stack；尤其不能把下方 IPv4 Pod CIDR 的 /24 块计算直接套给 IPv6。需要双栈时从 VPC-native 地址模型 的 IPv6 部分选择集群与 subnet 配置。

先区分三种网络流量#

kubectl 能连接控制面，不代表应用入口可达；私有节点也不代表应用没有公网入口。 控制面 endpoint、Service/Ingress 和 Pod 出站是三条独立路径。

VPC、 subnet 和 Zone 如何对应#

在基本的单网络配置中，集群选择一个 VPC 和同 Region 的 subnet。节点从该 subnet 取得内部 IP，不同 Zone 的节点可以使用同一个区域 subnet。

VPC：orders-enterprise（全局）
└─ asia-east1 Region 的 subnet orders-gke
   ├─ 主范围：10.64.0.0/24 → 节点、私网管理机
   ├─ 次要范围 orders-pods：10.68.0.0/18 → Pod 地址池
   └─ 次要范围 orders-services：10.69.0.0/22 → 本例 Service 地址池

asia-east1-a 的节点 → 使用 orders-gke
asia-east1-b 的节点 → 也使用 orders-gke

上图沿用 Standard 实验；secondary ranges 属于同一个 subnet。规划时检查本 VPC 与互联网络的地址重叠。

Regional 集群提供控制面跨 Zone 冗余；业务跨 Zone 副本仍由节点位置和 Pod 调度决定。

Node、Pod、Service 的 IP 分别做什么#

VPC-native / alias IP 将 Pod 地址池按节点划分，以别名 IP 接入 VPC；subnet 路由由平台维护，无须逐 Pod 配置。访问仍受 firewall 和网络策略约束。VPC-native

ClusterIP 是集群数据面转发到 Pod 的虚拟入口，不绑定某台 VM 网卡。集群外访问应使用内部/外部 LB 等受支持入口。

本例指定 orders-services；GKE 也支持平台管理的 Service 范围，例如 Google 私有用途的 34.118.224.0/20，不表示公网暴露。IP 地址说明

为什么 Pod 网段要比节点网段大#

节点需要完整的 Pod 地址块。在 Standard 中，每节点上限为默认 110 Pod 时通常分配 /24；/18 可分 64 块，须计入全部 node pool 和升级临时节点（surge）。调整每节点 Pod 上限会改变地址需求；Autopilot 使用平台规则。容量规划

Pod 如何通过 Service 访问另一个应用#

Service selector用标签选择后端 Pod；EndpointSlice 保存服务发现到的后端 endpoint。应用正常提供服务的 Pod 才应参与转发，readiness（就绪检查）用于判断是否可以接流量。

客户端 Pod
  → web.demo.svc.cluster.local（集群 DNS）
  → Service ClusterIP:80
  → 数据面选择就绪 endpoint
  → Pod IP:8080

同 namespace 可用 web，跨 namespace 可用 web.demo；完整域名取决于集群域配置。这里的集群 DNS解析 Service，与管理 API 的 DNS endpoint 分开。网络架构

集群外如何访问应用#

Ingress在这里是 Kubernetes API 对象，不是 Cloud Run 的 ingress 开关。Gateway API 用 Gateway、HTTPRoute 等对象分开描述入口和路由；选择的 GatewayClass 决定实际 GKE 负载均衡器能力和范围。

GKE 用 Zonal NEG 登记 Pod IP/端口，需要云端健康检查及 firewall；Cloud Run 使用 Serverless NEG。Pod readiness 与云端健康检查是两项检查。

控制器管理的 LB 应通过 Kubernetes 清单修改；Console 手改可能被覆盖。操作见 GKE Ingress；通用 Gateway API 页使用 Envoy Gateway，非 GKE 托管 Gateway 步骤。对象关系见 ALB。

私有节点与控制面入口分别配置#

get-credentials --internal-ip 选择内部入口，不建立私网路由；--dns-endpoint 选择已启用的 DNS 入口。可通过 IAP 登录独立管理 VM（runner）执行 kubectl，也可使用已有 VPN 路径。

DNS endpoint 使用 IAM 等访问控制，不套用 IP endpoint 的 Authorized networks 规则；internal IP endpoint 还须核对 regional/global access 限制。具体选择见 控制面 endpoint、网络隔离。

Pod 出站：内网、Google API 与互联网#

SNAT / IP masquerade 转换源地址。依目标和集群配置，接收方可能看到 Pod IP、Node IP 或 NAT 外部 IP；配置来源白名单前先确认实际源地址。

Standard 示例的 --nat-custom-subnet-ip-ranges="$SUBNET:ALL" 纳入该 subnet 的主、次要范围。镜像拉取查节点身份与出口；业务 API 调用查工作负载身份。详见 Cloud NAT、私网连接。

VPC 防火墙、NetworkPolicy 与 Dataplane V2#

Dataplane V2 是 GKE 托管数据面，负责转发、Service 和 NetworkPolicy 执行；启用它不会自动创建默认 Deny policy，namespace 也不自动隔离网络。

默认拒绝出站时须放行实际 DNS、数据库和 API 依赖；Pod/Service 策略按 Dataplane V2 支持的 selector 与 ipBlock 规则设计。Autopilot 托管数据面，Standard 用 --enable-dataplane-v2 选择，均不应重复安装 CNI。Dataplane V2、NetworkPolicy

将网络参数对应到规划#

完整命令及每 Zone 节点数量见 Standard 实验。

从哪个位置执行排障命令#

先配置目标 kubeconfig，并核对 context；以下 kubectl 在具备控制面访问路径的机器上执行。查看当前节点位置、Pod 地址和服务 endpoint：

kubectl config current-context
kubectl get nodes -o wide -L topology.kubernetes.io/zone
kubectl get pods -A -o wide
kubectl get services -A
kubectl get endpointslices -A
kubectl get networkpolicies -A

按故障 namespace 和 Service 缩小查询范围。

从可运行 gcloud 的终端只读查看集群和 subnet：

# 设置为实际目标，不会创建新资源。
PROJECT_ID=REPLACE_PROJECT_ID
CLUSTER=REPLACE_CLUSTER
REGION=REPLACE_REGION
SUBNET=REPLACE_SUBNET

gcloud container clusters describe "$CLUSTER" \
  --project="$PROJECT_ID" --region="$REGION" \
  --format='yaml(network,subnetwork,ipAllocationPolicy,privateClusterConfig,controlPlaneEndpointsConfig,masterAuthorizedNetworksConfig)'
gcloud compute networks subnets describe "$SUBNET" \
  --project="$PROJECT_ID" --region="$REGION" \
  --format='yaml(ipCidrRange,secondaryIpRanges,privateIpGoogleAccess)'

port-forward 成功不验证 LB、ClusterIP 或出站 NAT 路径。网络排障