ALB 架构与后端选择：Cloud Run、NEG 和 URL mask
验证：未记录
- 适用版本
- 未记录
- 验证范围
- 尚未登记验证记录。
返回 全局 ALB 实验。ALB（Application Load Balancer）是处理 HTTP/HTTPS 请求的应用负载均衡器。这里以 Cloud Run 后端说明各个对象的职责。
先读懂一条请求的路径#
用户请求域名
→ DNS 解析到 ALB 的 IP
→ Forwarding rule：监听 IP + 端口
→ Target HTTP(S) proxy：处理客户端连接，HTTPS 时使用证书
→ URL map：按域名和路径选择后端
→ Backend service：后端转发、安全与日志配置
→ Serverless NEG：引用某 Region 的 Cloud Run 服务
→ Cloud Run：入口与调用身份检查，转发到 Revision 实例
→ 容器应用Frontend 汇总 IP、端口、协议和证书；Backend service 保存后端转发配置；NEG（Network Endpoint Group）引用实际目标。Backend service 与 Cloud Run / Kubernetes Service 是不同资源。ALB 概览
先选 Global 还是 Regional#
| 决策 | Global external ALB | Regional external ALB |
|---|---|---|
| 入口与处理 | 全球外部 IP，基于 Google Front Ends（GFE，Google 托管前端代理） | 区域外部 IP，指定 Region 的托管 Envoy 代理处理请求 |
| 后端位置 | 可配置多个 Region 的后端，也可只接一个 Region | 本文 Cloud Run 场景中 ALB、NEG、服务需在同 Region |
| VPC 代理地址 | 无需你提供代理专用 subnet | 必须有该 VPC、Region 的 Proxy-only subnet |
| 选择理由 | 全球访问入口、多 Region 后端；本系列主实验采用它 | 需要明确区域处理边界等场景；见区域型子页 |
Global ALB 也使用 Envoy 支持部分高级功能；全球入口不自动复制 Cloud Run 到其他 Region。类型与支持范围
控制台从 Network services → Load balancing → Create load balancer 进入，选择 Application Load Balancer、Public facing / External，再选择全局或区域部署模式。Cloud Run ingress 中的 ALB 勾选框不会替你创建负载均衡器。
Backend type 按运行平台选择#
| 实际后端 | 通常使用的类型 | 描述目标的方式 |
|---|---|---|
| Compute Engine VM 实例组 | Instance group | 一组 VM；另配服务端口和健康检查 |
| GKE Pod 等具体 IP/端口 | Zonal NEG | 具体网络 endpoint，通常由 GKE 集成管理 |
| Cloud Run | Serverless NEG | Region + Cloud Run 服务引用 |
| 外部公网服务 | Internet NEG | 公网域名或 IP |
| Cloud Storage 静态资源 | Backend bucket | 引用存储桶，要求 LB 类型支持 |
Cloud Run 实例动态扩缩容，应通过 Serverless NEG 引用服务，无须登记容器 IP，也不用把 run.app 当作 Internet NEG。Serverless NEG
控制台在 Backend configuration → Create backend service → Backend type: Serverless network endpoint group 中创建/选择 NEG，再选 Region、Cloud Run、具体 Service。只有一个服务时使用 Service name，不填 URL mask。
Serverless NEG 与目标 Cloud Run 服务同 Region。 本实验在同 Project；Regional Backend service 只能关联一个 Serverless NEG，Global 可跨 Region 关联但每 Region 最多一个。它不用 VM 后端的端口映射、health check 和容量参数。
三段协议不要混为一谈#
| 连接段 | 如何配置 |
|---|---|
| 客户端 → ALB | Frontend 选择 HTTP:80 或 HTTPS:443；HTTPS 需要入口证书 |
| ALB → Cloud Run 平台 | 由平台管理加密传输；Serverless NEG 的 Backend service protocol 字段被忽略 |
| 平台 → 容器入口 | 通常是 HTTP，应用监听 0.0.0.0:$PORT；使用 HTTP/2 等能力需满足对应运行契约 |
Console 后端 HTTPS 保持默认即可；CLI 的 --protocol=HTTP 在 Serverless NEG 路径被忽略，不表示明文回源。Frontend 协议独立选择。后端协议、容器 TLS
URL map 与 URL mask#
URL map 按域名/路径选 Backend service，例如 /api/* → api-backend；未匹配请求进入默认后端。
URL mask 是 Serverless NEG 的模板，从 URL 提取服务名或 traffic tag，使一个 NEG 可引用符合命名规则的多个服务。
| mask | 请求示例 | 提取结果 |
|---|---|---|
example.com/<service> |
https://example.com/orders/list |
service = orders |
<service>.example.com |
https://users.example.com/profile |
service = users |
<tag>.<service>.example.com |
https://candidate.orders.example.com/ |
service = orders，tag = candidate |
<service>、<tag> 是模板占位符。服务必须真实存在，并符合 NEG 的项目、区域等约束；tag 指 Cloud Run Revision 的流量标签，不是 Docker 镜像 tag。
URL mask 不创建 DNS/证书，也不自动重写路径；应用须处理收到的路径。需要重写时核对 LB/后端支持，DNS 指向 ALB，证书覆盖实际主机名。URL mask
单服务实验直接选择 Service name；服务命名无规律或各服务需不同安全策略时，采用多个 Backend service + URL map 通常更明确。
Proxy-only subnet 为什么存在#
Proxy-only subnet 为指定 VPC、Region 中 Google 托管的 Envoy 代理预留内部地址，不需要你维护代理 VM。
- 地址只供代理使用，不用于普通 VM、Cloud Run 容器或 ALB 公网入口。
- 区域型使用
REGIONAL_MANAGED_PROXY目的，ACTIVE表示当前使用的代理 subnet 角色。 - 同一 VPC、Region 中相应类型的代理负载均衡器共享它，已有合适的 ACTIVE subnet 可复用。
- 至少
/26，官方建议从/23起步；需要与现有网络及互联地址规划兼容。
Global external ALB 的代理地址由 Google 基础设施管理，无需用户地址池；cross-region internal ALB 是另一种架构，仍需代理 subnet。
Cloud Run Serverless NEG 无须从代理 subnet 到容器的 VM firewall 规则，VM 后端则需配置。见 Regional 实验与 Proxy-only subnet。
安全能力分别放在哪一层#
| 能力 | 作用 |
|---|---|
| Cloud Run ingress | 允许哪些网络入口，不是指定 ALB 的白名单 |
| Cloud Run IAM | 调用者是否能调用服务 |
| IAP | Google 托管的身份访问代理，可为员工访问提供登录控制；配置位置要与方案一致 |
| Cloud Armor | 对 ALB 请求执行 WAF、限流等安全策略，不代替业务登录 |
| Binary Authorization | 部署时检查镜像策略，不控制 HTTP 调用者 |
| TLS 证书 | 加密并认证 HTTPS 服务端身份，不授予应用访问权限 |
本系列公开 hello 实验在 ingress 限制下授予匿名调用；内部员工应用另见 IAP，入口策略见 Cloud Armor，证书管理见 Certificate Manager。