理解 Google Cloud 中的網路維運
在 Associate Cloud Engineer (ACE) 的日常工作中，確保網路的穩定性與可達性是核心職責。這不僅涉及建立 VPC，還涉及管理網域名稱系統 (Cloud DNS)、處理私有網路的出站流量 (Cloud NAT)、管理靜態 IP 位址，以及確保負載平衡器 (Load Balancers) 能夠正確識別後端資源的健康狀況。
網路維運的目標是實現「高可用性」與「低延遲」，這需要對 Google Cloud 的網路組件有深入的理解。
白話文解釋
1. 城市的門牌與導覽 (圖書館類比)
- Cloud DNS: 就像圖書館的索引系統。你不需要背下書架的座標（IP 地址），只需要記住書名（網域名稱），系統就會告訴你在哪裡。
- 靜態 IP (Static IPs): 就像一個永久的門牌號碼。無論房子怎麼裝修（VM 重啟），地址永遠不變，快遞員（流量）永遠找得到。
2. 社區的安全大門 (交通號誌類比)
- Cloud NAT: 就像一個社區的出入口。居民（私有 VM）可以出去買東西（訪問網際網路），但陌生人不能直接從外面闖進居民家裡。
- 負載平衡器健康檢查 (Load Balancer Health Checks): 就像保全人員每隔幾分鐘就去敲敲門，確認住戶還平安。如果沒人應門，保全就會叫救護車（停止發送流量到該實例）。
3. 多功能傳輸工具 (瑞士刀類比)
- 任一播送 IP (Anycast IP): 就像一個神奇的電話號碼。不管你在世界的哪個角落撥打，Google 都會幫你接到離你最近的客服中心。
管理 Cloud DNS 區域與記錄
Cloud DNS 是 Google Cloud 提供的 100% 可用性服務。
區域 (Zones) 類型
- 公開區域 (Public Zones): 供網際網路上的任何人存取。
- 私有區域 (Private Zones): 僅在特定的 VPC 內部可見。
私有 DNS 區域 (Private DNS Zone) 是實現內部服務發現的最佳方式。你可以為生產環境建立 'prod.internal'，為開發環境建立 'dev.internal'，即便它們使用相同的子網路 IP 範圍也不會衝突。 Source ↗
記錄類型 (Record Types)
- A 記錄 (A Record): 將網域名稱對應到 IPv4 地址。
- AAAA 記錄 (AAAA Record): 對應到 IPv6 地址。
- CNAME 記錄 (CNAME Record): 網域名稱的別名。
- TXT 記錄 (TXT Record): 用於驗證網域名稱所有權（如 Google Workspace 驗證）。
DNS Peering Zone 與 Forwarding Zone 解決的問題不同，ACE 題目常拿此對比測試。當另一個 VPC 已經建立了 Private Zone（例如 db.internal），需要被本 VPC 解析時，使用 Peering Zone；當查詢必須離開 Google Cloud、透過 Cloud VPN 或 Interconnect 抵達地端 DNS 伺服器時，使用 Forwarding Zone。挑錯類型會出現 NXDOMAIN，即使底層連通性正常。
Source ↗
為 Google 託管服務（App Engine、Workspace、Sites）設定自訂網域時，建立 CNAME 記錄指向 ghs.googlehosted.com，不要硬寫 A 記錄 IP — Google 會輪替底層 IP，A 記錄會悄悄失效。可在同一個 managed zone 搭配 TXT 記錄完成網域所有權驗證與 SPF/DKIM 政策。
Source ↗
為私有實例配置 Cloud NAT
Cloud NAT 解決了私有 VM 需要存取網際網路的問題。
Cloud NAT (網路位址轉譯) 讓沒有外部 IP 地址的虛擬機實例能存取網際網路，以便下載更新或呼叫外部 API，同時保持 VM 的私密性。 Source ↗
- 優點：它不佔用 VM 的 CPU 資源，且不依賴特定的代理伺服器。
- 設定：你需要一個 Cloud Router 來承載 NAT 服務。
管理靜態與臨時 IP 地址
臨時 IP (Ephemeral IPs)
- 特性：當 VM 停止或刪除時，IP 就會被釋放。
- 定價：通常較便宜，甚至免費（當與執行的資源關聯時）。
靜態 IP (Static IPs)
- 特性：手動預留，永遠不變。
- 使用場景：對外服務的 Web 伺服器、防火牆白名單需求。
考試陷阱：預留但未使用的靜態 IP 費用比使用中的靜態 IP 更貴。這是為了鼓勵使用者釋放不必要的資源。 Source ↗
健康檢查與負載平衡器故障排除
負載平衡器依賴健康檢查來決定流量的去向。
健康檢查參數 (Health Check Parameters)
- 檢查間隔 (Check Interval): 每隔多久檢查一次（如 5 秒）。
- 逾時 (Timeout): 等待回應的時間（如 5 秒）。
- 健康閾值 (Healthy Threshold): 連續幾次成功才算健康（如 2 次）。
- 不健康閾值 (Unhealthy Threshold): 連續幾次失敗就算不健康（如 3 次）。
常見故障排除步驟
- 檢查防火牆：確保負載平衡器的探針 IP（Google 內部的特定範圍，如
130.211.0.0/22）被防火牆允許。 - 檢查應用程式狀態：確認伺服器上的 Nginx/Apache 正在執行。
- 檢查後端路徑：健康檢查的路徑（如
/healthz）是否返回 200 OK。
如果健康檢查失敗，負載平衡器會將該實例標記為 '不健康' (Unhealthy) 並停止發送新流量。這能防止使用者看到 502/504 錯誤。 Source ↗
全球與區域網路維運
- 全域資源 (Global Resources): Cloud DNS, 全球負載平衡器, VPC (邏輯上)。
- 區域資源 (Regional Resources): Cloud NAT, 靜態 IP, 區域負載平衡器。
透過 gcloud CLI 管理網路維運
# 建立一個私有 DNS 區域
gcloud dns managed-zones create my-internal-zone \
--dns-name=example.internal \
--description="Internal zone" \
--visibility=private \
--networks=my-vpc
# 預留靜態 IP
gcloud compute addresses create my-static-ip --region=us-central1
# 查看 NAT 統計資訊
gcloud compute routers get-status my-router --region=us-central1
使用 gcloud dns record-sets transaction start/add/execute 對單一 managed zone 進行原子性的多筆記錄變更，避免在批次更新時出現中間狀態（例如刪掉舊 A 記錄但新 CNAME 尚未生效）導致解析中斷。
Source ↗
網路維運最佳實踐
- 優先使用網域名稱而非 IP：這能讓你在後端遷移時不需要更改應用程式代碼。
- 分散負載平衡器後端：跨多個可用區 (Zone) 分佈實例。
- 監控 Cloud NAT 流量：如果 NAT 閘道丟包，可能需要增加連接埠 (Ports) 數量。
- 定期審計靜態 IP：釋放不再使用的 IP 以節省費用。
ACE 考試的常見場景
- 情境：你有一組位於私有子網路中的 VM，需要定期下載作業系統更新，但出於安全考慮不能有外部 IP。
- 解決方案：部署 Cloud NAT 並關聯到該子網路的 Cloud Router。
- 情境：你發現負載平衡器顯示所有後端都是不健康的，但你可以從另一台 VM 成功 ping 通它們。
- 解決方案：檢查防火牆規則，確保允許來自 Google 健康檢查探針 IP 的流量。
常見問題 (FAQ)
Q1: Cloud DNS 支援負載平衡嗎？ 答：支援透過 DNS 策略進行地理位置或權重分發。
Q2: 一個 Cloud NAT 實例可以服務多個 VPC 嗎？ 答：不行。Cloud NAT 綁定在特定的 VPC 內的 Cloud Router 上。
Q3: 為什麼預留的靜態 IP 會收費？ 答：這是為了防止使用者囤積 IP 地址資源。
Q4: 健康檢查可以使用 HTTPS 嗎？ 答：可以，健康檢查支援 HTTP, HTTPS, TCP, 和 SSL。
Q5: 什麼是 DNSSEC？ 答：這是一套為 DNS 提供身份驗證的安全擴展，防止 DNS 劫持和污染。
ACE 總結清單
- 明白公開區域 (Public Zone) 與私有區域 (Private Zone) 的區別。
- 掌握 Cloud NAT 的核心用途（私有 VM 出站）。
- 知道如何處理負載平衡器 (Load Balancer) 健康檢查失敗。
- 理解靜態 IP 的計費邏輯。
- 熟悉
gcloud dns與gcloud compute addresses指令。