Matt の 小天地網路線路排查案例：當你的 CDN 其實不是 CDN
本文分享一次 GCP 環境下的網路線路排查案例，從 nslookup、Global LoadBalancer 與 NEG 架構分析，發現所謂的 CDN domain 實際仍打到 Kubernetes nginx proxy，最終定位到 node 資源競爭問題並提出解法。
TL;DR
- 內部線路追查案例
- 問題根因：node 資源競爭導致 latency，client fallback 直接打到 server
背景
公司內部 RD 為了降低後端負載，在前端掛了 CDN。
但近一週仍發現 client 直接連 server 的 log，問題來源有兩種可能：
- CDN 掛掉
- client timeout (2s)，直接 fallback 連 server
問題追查流程
1. 確認網域解析
先透過 nslookup 檢查服務 domain：
- domain 對應到
34.x.x.x，屬於 GCP IP 範圍。 - 確認 IP 所屬服務為 Global LoadBalancer，其後端 (backend) 使用了 NEG (Network Endpoint Group) 架構。
進一步檢查才發現，所謂的 cdn domain 背後實際上：
- 請求仍打進 Kubernetes cluster。
- 經由 nginx proxy 再到指定資源倉庫。
2. 確認 nginx proxy 狀態
比對 RD 提出的異常時間點：
5/14 14:105/17 06:315/19 08:38
- 並不是所有時間點 log 都大量異常。
3. 觀察 metrics
檢查 CPU 使用狀況：
- 服務本身並無中斷。
- 但在部分時間點確實有 latency spike。
4. 檢查 node 資源
回頭檢查該服務所在 node：
- node 資源較為吃緊。
並檢查該服務資源配置：
- CPU 有設 request，卻沒設 limit。
👉 推測 root cause：
node 資源吃緊 → 服務競爭 → response latency → client timeout → fallback 直連 server。
解決方案
- 為 nginx proxy 補上資源 limit，避免與其他 pod 搶資源。
- 調整 node 資源配置，持續觀察是否改善。
📌 關鍵字：GCP、CDN、Global LoadBalancer、NEG、Kubernetes、Nginx Proxy、Troubleshooting、資源競爭、Latency、DevOps 網路排查
用 CRD 解決 GKE 資源不同步的問題
在 GKE 環境中，CI/CD pipeline 使用 kubectl set image 容易造成資源與 Helm Release 不同步。本文比較純腳本、--reuse-value、CRD 三種解法，並提供完整 CRD + CR YAML 範例，協助解決資源漂移問題。
7 分鐘快速理解 LLM、NLP 與 RAG：從基礎概念到實作範例
用 7 分鐘快速了解 LLM (大型語言模型)、NLP (自然語言處理) 與 RAG (檢索增強生成)，並附上 Python + Ollama + ChromaDB 的 RAG 範例程式，帶你理解如何透過 Embeddings 與向量資料庫優化 AI 回應。