Google PCNE: GKE、容器和应用网络 — 学习指南

By Laurynas Brazys · 23 August 2026 · #google #PCNE #certification #exam-prep #study-guide

属于 Google Professional Cloud Network Engineer — 学习指南. 使用经过验证的答案练习： Google 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

Google Kubernetes Engine (GKE) 与 Google Cloud 网络紧密集成。为了实现可靠性和安全性的设计，需要理解 VPC 原生 IP 地址、私有控制平面、出站流量、南北向和东西向流量、策略实施以及多集群架构。本节为 Google Cloud 上的容器和应用网络提供了设计指导、运维考量和常见的故障模式。

GKE IP 架构和私有集群

VPC 原生集群

使用别名 IP，在 VPC 子网中配置两个次要范围：一个用于 Pod (PodCIDR)，另一个用于 Service (ServiceCIDR)。这可以避免在节点上进行基于 iptables 的 SNAT，能够通过 NEG 实现容器原生负载均衡，并且比基于路由的集群具有更好的扩展性。
规模规划指南：
- Pod：分配 PodsPerNode × MaxNodes 的数量，并增加余量 (20–30%)。例如，当前 10 个节点 × 20 个 Pod，并计划增长到 100 × 200，建议使用 /17 的 Pod 范围；对于 2000 个以上的 Service，一个 /21 的范围通常足够。
- Service：每个 ClusterIP 消耗一个 IP；要考虑为从 Headless Service 迁移到 ClusterIP Service 以及附加组件留出余量。
故障模式：
- Pod IP 耗尽：Pod 保持 Pending 状态或出现 CNI/IPAM 错误；扩展 Pod 次要范围或减少每个节点的最大 Pod 数，然后重新创建节点。
- Service IP 耗尽：新的 Service 无法分配 ClusterIP；扩展 Service 次要范围。
- 别名范围重叠：集群创建失败或出现路由黑洞；验证范围是否与其他子网或对等 VPC 网络存在重叠。

私有集群、控制平面访问和节点出站流量

私有集群将控制平面端点限制为一个私有的 RFC1918 地址，该地址只能通过生产者对等网络从您的 VPC 内部访问。节点不需要外部 IP。
对于运维人员，可选择：
- 仅使用私有端点：控制平面可从 VPC 子网和连接的网络访问。使用堡垒机或通过 Private Service Connect 的 Cloud Shell 来访问它。
- 使用公共端点并配置授权网络：将控制平面暴露在一个公共 IP 上，并通过特定的源 CIDR 进行访问控制。这种方式很方便，但会增加暴露面；仅在严格限定 CIDR 范围并实施强有力的管理员身份控制时使用。
节点出站流量：
- 对于没有外部 IP 的节点，通过 Cloud NAT 提供访问互联网的出站流量。这允许节点在保持私有的同时，进行操作系统更新、从外部镜像仓库拉取容器镜像以及访问合作伙伴的 API。
- 要在没有外部 IP 的情况下访问 Google API 和 Artifact/Container Registry，请在节点子网上启用 Private Google Access (PGA)。PGA 会解析 Google API/注册中心流量并将其路由到 Google 的边缘网络，而无需使用公共源 IP。对于拉取镜像，首选 PGA；如果还需要访问非 Google 的出站流量，则将其与 Cloud NAT 结合使用。
- 如果通过第三方防火墙发送 0.0.0.0/0 流量，仍需启用 PGA，并为 Google API 的 VIP 范围添加指向默认互联网网关的静态路由，以绕过防火墙来访问 Google 服务。

扩展和 IP 问题排查

在子网次要范围级别监控别名 IP 的消耗情况。如果 IP 使用压力上升：
- 增加次要范围的大小（添加更大的范围，在需要时重新创建集群或迁移工作负载）。
- 调整每个节点的最大 Pod 数 (max-pods-per-node)，以平衡每个节点的 IP 使用量与调度碎片化问题。
- 清理废弃的 Service；Headless Service 不会分配 ClusterIP，但将其转换为 ClusterIP 类型会消耗 IP。
在使用 Shared VPC、VPC Peering 或多集群服务时，规划多区域增长时应使用不重叠的次要范围，以避免重新规划 IP 地址。

Ingress、Gateway API、Services 和策略

服务和负载均衡器

Service 类型：
- ClusterIP：仅限集群内访问；东西向流量使用 kube-proxy 或 dataplane v2。
- NodePort：在每个节点上分配一个端口；被许多 LB 用作后端，但应避免直接暴露在互联网上。
- LoadBalancer：预配一个云负载均衡器。外部或内部 L4 负载均衡器支持 TCP/UDP；会话亲和性 ClientIP 可在需要时提供跨多种协议的粘性。
容器原生负载均衡使用 Network Endpoint Groups (NEGs)，使负载均衡器直接将 Pod 的 IP:端口作为目标，从而改善健康信号并减少节点跳数。对于 GKE，请使用 GKE Pod NEGs (GCE_POD)。其他 NEG 类型包括 VM_IP_PORT、Internet FQDN 和 PSC。
GKE Ingress 和 Gateway API：
- 对于使用 Google 全球外部 HTTP(S) 负载均衡器或区域内部 HTTP(S) 负载均衡器的 HTTP(S) 南北向流量，Ingress 是一个稳定的选择。控制器会为标准模式自动编程健康检查和防火墙规则。
- Gateway API 通过 Gateways 和 HTTPRoutes/TCPRoutes 提供了一个更具表现力的模型。它支持多租户配置、高级路由以及跨环境的一致规范。为了适应未来发展，请选择 Gateway API；在注重简单性和兼容性的场景下，请使用 Ingress。

客户端限制和健康检查

限制客户端到特定源范围，可以在 L4 层面通过针对后端实例的 VPC 防火墙规则实现，或在 L7 层面通过 HTTP(S) 负载均衡器上的 Cloud Armor 策略实现。
始终允许来自 Google 健康检查器源范围的流量访问后端目标或 Pod，以确保健康检查通过。在某些部署中，GKE 会自动创建 k8s-fw 规则；如果您添加了限制性规则，请保留对健康检查器范围的显式允许规则。
L4 后端的示例方法：为节点打上“application”标签，并创建一条防火墙规则，允许来自指定客户端 CIDR 和 Google 健康检查范围的流量访问 tcp:NodePort，同时创建一条更高优先级的拒绝规则来阻断所有其他源的流量，并启用日志记录以观察丢弃情况。

网络策略和 dataplane v2

启用 Kubernetes NetworkPolicy 并使用 GKE Dataplane V2 进行基于 eBPF 的策略强制执行，与基于 iptables 的引擎相比，可提高性能和精确性。
基线安全态势：
- 对命名空间默认拒绝所有出口和入口流量；显式允许 Pod 到 Pod 以及 Pod 到 Service 的流量。
- 使用 namespace 和 podSelectors 创建服务层级（如前端、后端、数据），并仅允许最小必要方向和端口的通信。
保护服务通信：
- 对于集群内的零信任，mTLS 最好通过服务网格来实现；NetworkPolicy 处理 L3/L4 流量，但无法验证身份。
- 对于南北向流量，将 Cloud Armor附加到 HTTP(S) LB 上，以实现 WAF、速率限制，并可使用预览模式在不影响用户的情况下测试对可疑攻击者的拒绝策略。

故障模式和权衡

过多或过于宽泛的 NetworkPolicies 可能导致意外的流量丢弃；通过分阶段部署、日志记录和策略解释工具进行验证。
依赖 NodePort 加外部防火墙规则的方案很脆弱；首选托管的负载均衡器和 Pod NEGs。
Gateway API 带来了更丰富的功能，但也要求控制器具有足够的成熟度以及团队对其有足够的熟悉度；应根据不同的发布渠道验证诸如基于标头的路由或 mTLS 直通等功能。

← 路由、Network Connectivity Center 和分段 · 所有领域 · 网络可观测性、可靠性和故障排除 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →