Google Cloud VPC 的 IP 定址 (Addressing)

簡介

IP 定址是每一位 Google Cloud 網路架構師在部署第一台 VM 之前就要做出的基礎設計決策。不像地端網路可以利用週末重新編號子網域，GCP 子網域的主要 IPv4 範圍一旦有執行個體存在就無法縮小，也無法修改——只能擴展。挑錯 RFC 1918 區塊、忽視 Google 保留範圍，或低估 GKE pod 範圍大小，都會變成跨季度的遷移專案。對 PCNE 考試而言，預期至少會有三到五題的關鍵在於：能否辨識哪個 CIDR 區塊在哪個情境下合法、別名範圍與對等 VPC 重疊會發生什麼事、IPv6 雙堆疊與 Cloud NAT 如何互動、以及 Private Service Access 範圍何時會吃掉可用位址空間。

RFC 1918 範圍及其在 GCP 中的位置

RFC 1918 定義了三個私有 IPv4 區塊，公網路由表絕不會攜帶：10.0.0.0/8、172.16.0.0/12 與 192.168.0.0/16。Google Cloud VPC 子網域三者皆可作為主要或次要範圍，但選擇對混合連線有架構上的影響。

10.0.0.0/8 — 大型企業的預設選擇

10.0.0.0/8 區塊提供 1,670 萬個位址，足以切出 /12 區域聚合，每個聚合可容納數百個子網域。Google 自己的 auto-mode VPC 預設子網域從 10.128.0.0/9（auto-mode 推出之後佈建的區域）和 10.140.0.0/20 之類的區塊取址。若你計劃要與多個企業 VPC 對等互連，或使用 Network Connectivity Center hub，請在 10.0.0.0/8 內每個區域保留 /13 或 /14，這樣你的聚合在 Cloud Router BGP 工作階段上仍然可以摘要化。

172.16.0.0/12 — 安全的中間選擇

172.16.0.0/12 區塊（約 100 萬個位址）最不容易與家用辦公室 VPN 和 AWS 預設 VPC（後者偏好使用 172.31.0.0/16）發生重疊。若 landing zone 之後要透過 Cloud VPN 或 Interconnect 連回早已耗盡 10.0.0.0/8 的地端，就請使用這個區塊。

192.168.0.0/16 — 僅限小型環境

192.168.0.0/16 區塊（65,536 個位址）對全新沙盒專案沒問題，但對任何需要 /14 pod 範圍 GKE 叢集的環境都太小。多數家用路由器預設使用 192.168.0.0/24 或 192.168.1.0/24，所以使用這個區塊保證會帶來客戶端 VPN 的麻煩。

Google Cloud 不允許使用的保留 IPv4 範圍

有幾個 IPv4 區塊是被 IETF 或 Google 保留作為內部基礎管線使用的。嘗試把它們設為子網域主要或次要範圍，要不就在 gcloud compute networks subnets create 時失敗，要不就會在執行個體上造成靜默損壞。

169.254.0.0/16 — 連結本地 (link-local)

連結本地區塊用於 Google metadata server（169.254.169.254）、Cloud VPN 與 Interconnect 上 Cloud Router 的 BGP 工作階段（169.254.0.0/16 是建議的 BGP 對等範圍），以及 VM 上各種 agent-to-host RPC。你不能把 169.254.0.0/16 設為子網域主要範圍，但你可以——而且必須——在 HA VPN 與 Partner Interconnect VLAN attachment 的 BGP 工作階段上使用它的 /30 切片。

100.64.0.0/10 — 電信級 NAT (RFC 6598)

這個區塊為電信級 NAT 保留，GKE 私人叢集的 master_ipv4_cidr_block 內部使用它，Shared VPC 上的 Cloud SQL 代理也使用它。部分 Google 服務（特別是 GKE 上的 IP-masquerade agent）會在流量跨越 100.64.0.0/10 時悄悄做轉譯。不要把這個區塊用在你自己的主要子網域範圍——它會與託管服務的實作衝突，並讓你失去與 Google 內部 API 的連線。

其他被封鎖或特殊的範圍

• 127.0.0.0/8 — 迴路位址，建立子網域時會被拒絕
• 224.0.0.0/4 — 多播位址，在 GCP VPC 中無法路由（Google Cloud 不支援 VPC 上的 IP 多播）
• 0.0.0.0/8 與 255.255.255.255/32 — broadcast/this-network，會被拒絕
• 35.199.192.0/19 — Google 控制的範圍，用於 Cloud DNS forwarding 與 Cloud SQL 私人連線；子網域不能與之衝突

主要範圍與次要範圍 (Alias IPs)

一個子網域只擁有一個主要 IPv4 範圍，加上最多 30 個次要 IPv4 範圍。主要範圍提供最終會出現在 nic0（VM 內部的 eth0）上的位址。次要範圍提供別名 IP，這些別名 IP 指派給同一張 NIC，而不需要多新增 NIC。

主要範圍機制

主要範圍由 gcloud compute networks subnets create SUBNET --range=10.10.0.0/20 設定。每台子網域內的 VM 都會拿到一個主要 IPv4 位址。範圍可以擴展（gcloud compute networks subnets expand-ip-range），但永遠無法縮小。每個子網域有四個位址被 Google 保留：網路位址、預設閘道（.1）、倒數第二個（DHCP/控制平面）和廣播位址。因此 /29 僅產出 4 個可用 IP，而 /24 產出 252 個。

次要範圍與別名 IP 指派

次要範圍以 --secondary-range RANGE_NAME=CIDR 建立。它們從不直接出現在 VM 的 IP 路由表上——而是當你建立 VM 時，透過 --aliases RANGE_NAME:/24 或 --aliases /28 指派一個或多個別名 IP 區塊。該位址會被主機 hypervisor 經由 NAT 對映到 VM 的主要 NIC 上。從 VM 角度看，作業系統只看到 nic0 的主要位址；從 VPC 角度看，VM 擁有整個別名區塊。

GKE pods 與 services 的消耗

VPC-native（別名 IP）模式的 GKE 叢集需要在叢集子網域上配置兩個次要範圍：一個給 pods（預設 /14 = 262,144 位址），一個給 services（預設 /20 = 4,096 位址）。每個節點會從 pod 範圍切出一塊 /24，所以 /14 可以支撐高達 1,024 個節點、每節點 110 個 pod。PCNE 很愛測這道數學題：若考題說「客戶計劃 200 個節點、每節點 30 個 pod、加上 1,000 個 ClusterIP services」，pod 範圍至少要 /19（8,192 位址，考慮每節點切 /24），service 範圍至少要 /22。

外部 IP 位址：臨時 vs 靜態、區域 vs 全域

外部 IP 是公用 IPv4 位址，從網際網路路由到 Google Cloud 資源。它們有兩種生命週期和兩種作用域。

臨時外部 IP (Ephemeral)

資源建立時以 --address ephemeral 指派（或對 VM 省略此旗標）。資源停止或刪除時即釋出。臨時 IP 在掛載期間不收費，但對保留性沒有 SLA——Google 在每次重啟後可能回傳不同 IP。適用於短暫的開發 VM 與位於負載平衡器後方的無狀態後端。

靜態外部 IP

以 gcloud compute addresses create NAME --region=REGION（區域，給 VM NIC 和區域 LB）或 --global（全域，給全域 LB 和 Anycast）預留。一個保留的靜態 IP 在未使用時每小時收費 $0.004（約每月 $2.92），掛載到執行中資源時免費。「掛載即免費」這條規則很關鍵：掛載到已停止 VM 上的靜態 IP 仍會計費。

全域與區域靜態 IP 的差異

• 區域靜態 IP 錨定區域資源：VM 外部 IP、Cloud NAT 閘道（每區域每個 NAT 一或多個靜態 IP）、區域外部 Application Load Balancer、區域外部代理 Network Load Balancer。
• 全域靜態 IP 錨定全域資源：全域外部 Application Load Balancer、全域外部代理 Network LB，以及只在 Premium Tier 上承載 Google 骨幹的全域 Anycast IP。

BYOIP (Bring Your Own IP)

你可以把已經擁有、公網可路由的 IPv4（與 IPv6）前綴匯入 Google Cloud。IPv4 最小 /24，IPv6 最小 /48。Google 負責 BGP 通告；你保留 IP 信譽、白名單條目和 RDAP 紀錄。BYOIP 前綴會先被佈建（gcloud compute public-advertised-prefixes create），再切成委派前綴 (delegated prefixes)，再切成錨定特定資源的 public-delegated-prefixes-sub-prefixes。

預留靜態外部與預留內部

預留內部 IP 與預留外部 IP 是不同的 SKU 和不同的生命週期。

預留內部靜態位址

gcloud compute addresses create NAME --subnet=SUBNET --addresses=10.10.0.50 --region=REGION 會從子網域主要範圍切出一個內部 IP，並把它標記為 RESERVED。該位址免費。用於內部負載平衡器前端、資料庫 VM 的靜態位址，或 service mesh egress 閘道。預留的內部位址可以防止 auto-allocator 之後把同一個 IP 派發給其他 VM。

預留外部靜態位址

gcloud compute addresses create NAME --region=REGION（不含 --subnet）預留一個公用 IP。未使用時 IP 會計費，每小時 $0.004。請務必拆除未使用的外部預留 IP 或把它釘到負載平衡器上，避免意外帳單。

IPv4 與 IPv6 雙堆疊

Google Cloud VPC 在每個子網域支援 IPv6 的三種模式：IPv4-only（預設）、IPv6-only（考試時點為 limited preview）和雙堆疊 (dual-stack)（建議在正式環境採用的 IPv6 路徑）。

啟用雙堆疊

gcloud compute networks subnets update SUBNET --stack-type=IPV4_IPV6 --ipv6-access-type=EXTERNAL（或 INTERNAL 用於 ULA）。Google 會從自己的位址池配發一個 /64 IPv6 範圍給每個子網域（內部子網域無法 BYOIPv6，但外部 /48 BYOIP 受支援）。每台具備雙堆疊 NIC 的 VM 從子網域的 /64 取得一個 IPv6 /96。

外部與內部 IPv6

• 外部 IPv6 使用全球可路由的 GUA 位址，由 Google 通告。流量透過 Cloud NAT64 出站，或直接經由 VM 的 /96。
• 內部 IPv6 使用來自 fd20::/20 的 ULA 位址。它們對 VPC 與對等 VPC 私有，永遠不會對網際網路通告。

Cloud NAT64 與 IPv6-only 後端

雙堆疊子網域允許 IPv6-only 的前端（行動電信網路、T-Mobile、Comcast IPv6）透過 Cloud NAT64 連到 IPv4 後端。在全域外部 Application LB 設置 IPv6 VIP；LB 會自動合成 IPv4 後端請求。對內部流量而言，當 ipv6Access = INTERNAL 且叢集啟用 IPv6 時，雙堆疊子網域讓 GKE pods 同時可以使用兩種協定。

Private Service Access (PSA) 範圍

Google 託管服務（Cloud SQL、Memorystore、Filestore、AlloyDB、Dataproc Metastore）透過 Private Services Access 連到你的 VPC，這需要你為服務提供者配置一個專屬的 CIDR 區塊。

配置 PSA 範圍

gcloud compute addresses create google-managed-services-RANGE --global --purpose=VPC_PEERING --addresses=10.200.0.0 --prefix-length=20 --network=VPC 預留 /20 讓 Google 把他們的服務 VPC 對等到你的網路。接著 gcloud services vpc-peerings connect --service=servicenetworking.googleapis.com --ranges=google-managed-services-RANGE 建立對等互連。

PSA 範圍的容量規劃

/24 PSA 範圍能支撐合計約 250 個 PSA-backed 服務執行個體。/20 可支撐約 4,000 個，是正式 landing zone 的建議預設值。PSA 範圍不能與任何子網域範圍、次要範圍或對等 VPC 範圍重疊——它們是從你的全域 CIDR 規劃切出來的。

為什麼 PSA 範圍耗盡是靜默失敗

當 PSA 範圍滿了，新的 Cloud SQL 執行個體會在建立時失敗並丟出語意不明的錯誤。Memorystore for Redis 執行個體則停留在 CREATING 狀態 30 分鐘後逾時。請務必把 PSA 範圍配置成現有需求的五倍，並用 gcloud services vpc-peerings list --network=VPC 監控消耗。

連結本地位址與 Cloud Router BGP

Cloud Router 在 Cloud VPN 通道與 Interconnect VLAN attachment 上建立 BGP 工作階段給對等路由器。這些工作階段運行於 169.254.0.0/16 的 link-local /30 或 /29 切片上。

建議的 BGP 對等 CIDR 配置方式

Google 建議把 169.254.0.0/16 切成每通道一個 /30。HA VPN 有兩條通道，所以為 tunnel 0 配置 169.254.0.0/30（Cloud Router 為 .1，peer 為 .2），tunnel 1 配置 169.254.0.4/30。Partner Interconnect 有四個 VLAN attachment 時，連續配置四個 /30 區塊。

為什麼 link-local 對考試很重要

PCNE 會問「Cloud Router 與地端 ASR1000 之間的 BGP peering 位址可以使用哪個 IP 範圍？」——答案永遠落在 169.254.0.0/16 內。唯一例外是地端早已使用私有 ASN 搭配公網 IP peering，這並不常見。你也不能把 169.254.0.0/16 用於 VM 位址或任何子網域範圍。

多個 Cloud Router 上避免重疊

若單一 VPC 同時承載十條 Cloud VPN 通道與四個 Partner Interconnect VLAN attachment，每一個都需要自己不重疊的 169.254.0.0/16 /30 切片。一個簡單的慣例是把 169.254.0.0/24 配置給 HA VPN（64 個 /30，足夠 32 對通道），把 169.254.1.0/24 配置給 Interconnect VLAN attachment。Metadata server 位於 169.254.169.254/32，從 BGP 永遠無法觸及，所以 peering 範圍可以放在除了該單一位址以外的任何地方。

Cloud Router 自身的內部定址

Cloud Router 本身不消耗你子網域的位址——它位於 Google 的控制平面。它只消耗 link-local /30 來建立 BGP，並把你的子網域範圍向 peer 通告出去。這也是為什麼建立 Cloud Router 免費，只有底層 Cloud VPN 通道或 VLAN attachment 才會產生費用。

混合網路的 CIDR 規劃

連接多個 VPC、地端資料中心和若干 SaaS 合作夥伴的正式 landing zone 需要刻意的全域 CIDR 規劃。這一階段的錯誤最難修，因為每一個子網域、每一條 peering、每一條 Interconnect、每一個 Cloud SQL 執行個體都會被鎖死。

由上而下的聚合策略

1. 為整個 Google Cloud 保留一個 /8 或 /9 聚合（例如 10.0.0.0/9）。
2. 每個區域配置一個 /12（例如 us-central1 為 10.0.0.0/12，europe-west1 為 10.16.0.0/12）。
3. 每個 /12 內，每個環境（prod / staging / dev）配置一個 /16，再給 GKE pods 配置一個 /16。
4. 每個 /16 內，按層級（web / app / data）配置 /20 或 /22 子網域。

避免與地端重疊

在動工前先列出每一個地端 CIDR。把它對應到 GCP 規劃，並拒絕任何重疊。若地端已密集使用 10.0.0.0/8，就把 GCP 推到 172.16.0.0/12 或不重疊的 10.0.0.0/8 /12 切片。

提早為 GKE 規劃

GKE pod 範圍是單一最大宗的位址空間消耗者。為每個區域專門保留一個 /12 或 /13 給 pods 使用，避免之後子網域擴展時還要重新編號節點。

把規劃文件化並做版本控制

把 CIDR 規劃存在 Terraform 模組或共享 repo 的 YAML 裡。每一個新增子網域的 PR 都必須引用此規劃。這可以避免兩個團隊在同一個 Shared VPC 上配置重疊 /20 的常見情境。

Cloud Router 上的混合摘要化

Cloud Router 支援自訂路由通告搭配摘要化：gcloud compute routers update-bgp-peer PEER --advertisement-mode=CUSTOM --set-advertisement-ranges=10.0.0.0/12。對地端僅通告單一摘要 /12，而不是 50 個個別 /20 子網域，可以維持地端核心路由器的 RIB 較小，並避免撞到 Google 對 Cloud Router 每個 BGP 工作階段強制的 1000 條路由上限。Cloud Router 自身預設可從 peer 接收最多 100 條路由（可調至 1000），所以也請對方同樣摘要化。把摘要後的聚合與 CIDR 規劃並列文件化，避免未來工程師通告較細的 /20，讓流量被吸到錯誤的區域。

多區域容錯考量

為 us-central1 與 us-east1 之間設計 DR 時，每個區域的聚合不重疊，但要可以從同一個母前綴摘要化。若 us-central1 擁有 10.0.0.0/12、us-east1 擁有 10.16.0.0/12，兩者皆落在 10.0.0.0/11 內——合作夥伴設備上一條靜態路由就能到達任一區域。這個模式也讓 Cloud DNS routing policy 可以容錯轉移，不必重新通告前綴。

IPv6 也納入全域規劃

即使今天的工作負載是 IPv4-only，如果你有 BYOIPv6 /48 可用，請現在就先保留，並在每個區域至少一個子網域啟用 --stack-type=IPV4_IPV6 為將來鋪路。為既有子網域增加 IPv6 不需要 VM 停機，但在服務上線後才採用 BYOIPv6 就得重新錨定每個外部資源——比一開始就配置好痛苦得多。

白話文解釋（Plain English Explanation）

公寓大樓比喻 — 內部與外部 IP

想像一棟大型公寓大樓，有上千個單位。你的內部 IP 是你的單位編號（402 室）：大樓裡每個人都用它找你、郵局靠它分信，但外面的世界沒辦法直接撥到你。大樓的前台總機號碼就是外部 IP：世界各地的來電者都撥同一個號碼，由前台接待（Google 的 Cloud NAT 或 1 對 1 forwarding rule）把電話轉到你的單位。靜態外部 IP 像是付月租把電話號碼留在電話簿上，就算沒人在家也維持；臨時外部 IP 則像大樓在新住戶搬入時臨時指派的號碼，搬走後就回收。

城市規劃比喻 — CIDR 範圍與聚合

為 GCP 設計 CIDR 就像規劃一座新城市。你先宣告市界（你的 /8 全域聚合）、然後是行政區（區域 /12）、社區（子網域 /20）、最後是個別建地（VM）。若兩個行政區在地圖上重疊，分信機就會混淆、包裹就會消失——這正是 Cloud Router 在兩個對等 VPC 通告重疊前綴時會做的事。GKE pod 範圍是一個永遠長得比你預期快的市郊大社區：第一天就劃大一點，否則之後就要拆房子才能加新街道。PSA 範圍像是預留給公用事業（Google 託管服務）的工業園區——早點圍起來，住宅區才不會擠進來。

辦公大樓電話系統 — 別名 IP 與次要範圍

擁有別名 IP 範圍的 VM 就像辦公桌上一支主要電話線，後面接上一整排分機號碼，公司不必再多買桌子就能對外發放。每支分機（別名 IP）都響在同一個實體電話（VM 的 nic0）上，但來電者看到的是不同號碼。GKE 用這招讓每個容器都有可路由的位址，卻仍跑在同一台 VM 上。子網域上的次要範圍就是辦公大樓事先預留的分機號碼區段——若你只配 100 個分機而公司成長到 1,000 人，就得把全公司重新編號。這就是為什麼 pod 範圍的大小要正確規劃。

常見問題 (FAQs)

我可以在不重建 VM 的情況下更改 VM 的內部 IP 嗎？

不行。主要內部 IP 在 VM 建立時就綁定。你隨時可以透過 gcloud compute instances network-interfaces update 新增或移除別名 IP，但主要 IP 要更換就必須刪除並重建執行個體（或拆卸並重新掛載 nic0，效果相同）。

預留的內部 IP 要付費嗎？

不必。預留的內部靜態位址不論是否掛載都是免費的。只有預留的外部位址未掛載時會計費，每小時 $0.004（約每月 $2.92 每個 IP）。

我可以把 100.64.0.0/10 用在自己的子網域嗎？

技術上 API 會讓你在那裡建立子網域，但你會與 GKE 私人叢集 master CIDR、Cloud SQL 代理範圍以及 IP-masquerade agent 衝突。把 100.64.0.0/10 視為 Google 託管服務保留範圍，自己改用 RFC 1918 或 BYOIP-PUPI。

GCP 上我能建立的最小子網域是多少？

/29（8 個位址，扣掉 Google 保留的 network/gateway/DHCP/broadcast 後可用 4 個）。IPv6 子網域固定為 /64。最大主要 IPv4 範圍是 /8，但實務上到 /20 時 API 回應大小就會開始造成困擾。

我要怎麼把既有的地端 IPv4 範圍帶到 Google Cloud（BYOIP）？

先開啟支援案件，透過 RPKI 或 Letter of Authorization 驗證所有權，然後 gcloud compute public-advertised-prefixes create 建立母區塊（最小 /24），切出 public-delegated-prefixes，再掛到資源上。Google 會在 24 小時內開始 BGP 通告該前綴。IPv4 可通告的最小區塊是 /24，IPv6 是 /48。

為什麼我的 Cloud SQL 執行個體建立時失敗、訊息是「no available IP」？

配給 servicenetworking.googleapis.com 的 PSA 範圍耗盡了。執行 gcloud services vpc-peerings list --network=VPC 檢視目前配置，再以 gcloud compute addresses update 與 gcloud services vpc-peerings update --force 擴大 PSA 範圍。下次重試 Cloud SQL 建立就會成功。