上一篇我們理解了 interface、IP 與 route。這一篇要更進一步，解釋子網路與 CIDR，並連結到 Kubernetes 的世界。

1. 什麼是子網路 (Subnet)

子網路是把一個大範圍的 IP 切成多個小區塊，讓管理與規劃更有彈性。

• 192.168.1.0/24 → 從 192.168.1.0 到 192.168.1.255。
• 192.168.2.0/24 → 從 192.168.2.0 到 192.168.2.255。

這兩個不會重疊，所以不同的區段可以清楚分開，方便公司內部分網（例如辦公室一區，伺服器一區）。

如果寫 /25：

• 192.168.1.0/25 → 192.168.1.0 到 192.168.1.127
• 192.168.1.128/25 → 192.168.1.128 到 192.168.1.255

👉 這就是把 /24 切成兩半，適合更小規模的子網劃分。

2. 為什麼不能重疊？

假設你有一個 service IP 範圍是 10.0.0.0/16，但你的 Pod IP 範圍也設成 10.0.0.0/16，結果會是：

• Kernel 不知道這個封包要送去 Pod 還是 Service。
• 最後就會亂掉，導致封包黑洞或流量錯誤轉送。

在企業內部常見的錯誤是：公司內網和 Kubernetes Pod 網段重疊，導致某些流量永遠無法到達，這也是很多初學者在自建 K8s cluster 時踩過的坑。

👉 所以 規劃網段 是 Kubernetes 管理裡一個很重要的功課。這部分通常會跟網管部門一起協調，避免與現有內網衝突。

3. CIDR 表示法快速解讀

CIDR (Classless Inter-Domain Routing) 的寫法是：

IP位址/位元數

• /24 = 256 個位址 (2^(32-24))
• /25 = 128 個位址
• /16 = 65536 個位址

👉 位元數越小，範圍越大；位元數越大，範圍越小。

實務上：

• 家用網路通常使用 /24 (夠一個小區域的設備使用)。
• 企業級可能會規劃 /16，方便劃分多個子網。
• Kubernetes 預設可能會用 /24 或 /16 當 Pod 與 Service 的範圍。

4. 延伸到 Kubernetes

在 Kubernetes 裡：

• 每個 Pod 都會拿到一個獨立的 IP，就像是一棟棟小房子。
• CNI (Container Network Interface) 是一個標準，規範了 Pod 網路要怎麼建立與配置。K8s 本身不處理網路細節，而是透過 CNI plugin 來做到：建立 veth pair、分配 IP、設定路由、更新 Node 的轉送規則。
• 常見的 CNI Plugin 包含 flannel、calico、cilium。它們的差異在於底層實作，例如 Flannel 偏向簡單封包封裝，Calico 提供更完整的網路政策與 BGP 支援，而 Cilium 則利用 eBPF 提升效能與安全控制。
• 每個 Node 上的路由表會記錄：這個 Pod IP 要透過哪個 Node 去找，這些資訊也是 CNI plugin 幫忙維護。
• Service ClusterIP 則是另一層虛擬 IP，由 kube-proxy 或 eBPF 技術來轉送流量。

👉 實際除錯時：

kubectl exec -it <pod> -- ip addr
kubectl exec -it <pod> -- ip route

這些基本的 Linux 指令，仍然是 K8s 網路問題排查的利器。

5. 常見實務情境

• 公司 VPN 與 Pod 網段衝突：VPN 可能用 10.0.0.0/8，結果 K8s 也用 10.0.0.0/16，導致 VPN 流量斷線。
• 多叢集互聯：要把兩個 K8s cluster 串接時，必須確保 Pod CIDR 不重疊，否則 cross-cluster traffic 會亂。
• Service IP 規劃：Service IP 範圍過小，可能導致 IP 用完。

小結 (下篇)

• /24 → 一個子網路有 256 個位址。
• /25 → 一個子網路有 128 個位址。
• 不同子網路不能重疊，否則會路由錯亂，這在 K8s 規劃中特別重要。
• CNI Plugin 幫忙管理 Pod 與 Node 之間的網路，並維護路由表。
• 在實務上，網段規劃是一門「基礎卻常見出錯」的功課。

理解這些基礎，就能更快看懂 K8s 的網路設計，從節點到 Pod，到 Service 到 Ingress，背後都是這些 Linux 網路觀念的延伸。未來如果你遇到 K8s 網路問題，不妨回頭先用 ip 指令檢查，往往能快速找到關鍵。