Azure國際帳號 AKS網路插件配置方法

前言：為什麼網路插件決定了整體體驗

在 AKS 上跑起第一個容器通常不難，但只要你需要跨節點通訊、對外服務暴露、網路策略隔離、或是跟現有企業網路打通，就會發現「網路插件」幾乎決定了你後續要花多少時間維護。網路插件不只是把 Pod 接上網路，它還影響：Pod 的 IP 分配方式、Ingress/Load Balancer 的行為、DNS 與 Service 的解析路徑、NetworkPolicy 的實作，以及日後升級與排錯的難度。

因此本文會用務實的方式，帶你從「你到底在選什麼」開始，再到「如何設定才不踩雷」，最後給出常見問題的排查順序。你不需要先完全懂網路底層，但要能在看錯誤訊息時知道下一步該查哪裡。

第一章：AKS 的網路組件與你需要理解的概念

1.1 CNI 與網路插件是什麼

在 Kubernetes 世界裡，Pod 要取得網路能力主要依賴 CNI（Container Network Interface）。CNI 會負責把新 Pod 的網路接口接到正確的網路、配置路由與 IP、並處理必要的封包轉發。換句話說，當你在 AKS 裡談「網路插件」，通常就是在談 CNI 的實作或其部署模式。

在 AKS 中，常見的網路策略包括：使用預設網路（多數情況下能滿足基本需求）、以及在特定需求下使用其他解法或進行特定配置。你真正需要掌握的，是「AKS 叢集的網路模式」與「CNI 相關元件如何被叢集管理」。

1.2 Service、Ingress 與 Pod 網路的分工

很多新手在排錯時把事情混在一起：Pod 網路不通，但卻去查 Ingress 控制器；或是 Service 沒回應，卻檢查 Pod 的路由。要避免混亂，你可以用以下分工來思考：

• Pod 網路：Pod 之間（跨節點也包含）是否能互通，IP 是否合理，路由是否正確。
• Service 網路：Service 的 ClusterIP/DNS 是否正確、端點（Endpoint）是否被填入、負載平衡是否正常。
• Azure國際帳號 Ingress / 外部暴露：LoadBalancer / Ingress Controller 是否順利把外部流量導入到 Service。

網路插件多半影響 Pod 網路與 Service 的可達性，但它不直接等於 Ingress 的配置。知道這個邊界，你會更快定位問題。

1.3 網路策略 NetworkPolicy 的位置

NetworkPolicy 用來描述「哪些流量允許通過」。但它能否生效，取決於你的網路插件是否支援相應的策略能力，以及相關控制器是否已啟用。

如果你計畫使用 NetworkPolicy，請在規劃階段確認：你選的網路方案是否支援、支援到什麼程度、以及預期的「預設拒絕/預設允許」行為。不要等到資安需求上來時才臨時摸索，通常會造成反覆調整。

第二章：在建立 AKS 時做的關鍵決策

2.1 選擇網路模式：資源與目標驅動的取捨

建立 AKS 時，你會遇到幾個重要選項：例如網路模型（overlay/transparent 等概念）、Pod 的 IP 計算方式、以及與虛擬網路（VNet）怎麼整合。不同模式的差異會影響你是否需要額外的路由或網路地址轉換（NAT）設計。

Azure國際帳號 在做決策時，用「目標」而不是「偏好」來選：

• 若你的目標是快速上線、少改既有網路：優先選 AKS 預設並沿用建議的 CIDR 配置。
• 若你的目標是與既有企業網段細緻整合：要更慎重規劃 VNet/Subnet、路由與防火牆規則。
• 若你的目標是高隔離與可控的流量行為：確保網路插件對 NetworkPolicy 的支援符合你的需求。

2.2 CIDR 規劃：避免日後「地址打架」

AKS 叢集需要為 Pod、Service 留出 IP 範圍（CIDR）。規劃不當通常會在你快要上線時爆炸，例如：某個既有網段與 Pod 網段重疊，導致跨網路互通失敗；或 Pod IP 不足，導致擴容後節點新 Pod 無法取得地址。

Azure國際帳號 建議你在部署前先回答三個問題：

• 目前與未來會預留多少 Pod 數？（估算節點規模、HPA 可能性、預期工作負載）
• 公司其他網段是否已使用，哪些是「不可碰」的？
• 你是否需要對外（on-prem 或其他 VNet）建立路由？如果是，路由的目的地會指向 Pod CIDR 還是透過 NAT？

把這些想清楚，後面你配置網路插件時才會有正確的基底。

2.3 子網與節點規劃：節點的網路同樣重要

節點（Node）會跟你的 VNet/Subnet 綁定。節點網路會影響：節點與控制平面、節點到資料面（Pod）之間的連通性。若節點子網的規則（例如安全群組 NSG）過於嚴格，CNI 相關元件可能也會受到影響，導致 Pod 無法初始化或狀態一直卡住。

因此你在配置網路插件時，不要只看 CNI 的參數，也要確認：

• 節點子網是否允許必要的管理與資料流量（至少要滿足 AKS 與 CNI 的預期通信）。
• 是否有自定義路由（UDR）或防火牆，可能阻斷封包路徑。
• DNS 解析與時間同步是否正常（某些網路插件在初始化時會依賴 DNS 或標記節點狀態）。

第三章：部署與配置網路插件的實作流程

不同團隊會用不同方式部署（建立叢集時選項、或是建立後套用設定）。以下以「可移植、可理解」的步驟敘述，讓你能依自己的環境對應。

3.1 建立 AKS：先確保基本網路能跑通

首先確保叢集建立成功，並確認基本網路功能已啟用。建立完成後，你可以先做幾個最小驗證：

• 節點是否 Ready。
• CoreDNS 是否正常運作（能否解析 Service 與外部域名）。
• 建立一個簡單的 Pod，觀察其網路狀態（IP 是否被成功分配）。
• 建立一個 ClusterIP Service，從另一個 Pod 測試連線。

如果這些都不穩，後面再談網路插件的深度配置會非常痛苦，因為你無法判斷是插件設定問題，還是基本網路就已不通。

3.2 配置網路插件相關元件：從需求出發

當你確定基礎網路通了，接著才進入網路插件配置。常見需求包含：

• 啟用/調整 Pod 網路模式，使其符合特定部署或連通性需求。
• 調整 IP 地址管理或路由行為。
• 啟用 NetworkPolicy 的支援能力，並設定其觀察與執行行為。
• 調整與叢集外部整合相關的參數（例如對接 Load Balancer、Ingress 或內部服務網段）。

配置方法可能透過：叢集建立參數、Kubernetes 叢集設定（例如 ConfigMap 或系統命名空間中的控制項）、以及對 CNI daemonset/控制器的調整。你的策略應該是「最小變更、可驗證」，也就是每次只改一個方向，並立即做驗證。

3.3 啟用 NetworkPolicy：先確認策略行為，再上強度

Azure國際帳號 如果你的網路插件支援 NetworkPolicy，建議採用逐步上線：

• 第一步先建立「觀察型」或寬鬆策略，確認規則能被正確套用（例如策略名稱能否生效、事件是否出現在相關指標/日誌中）。
• 第二步再逐步收緊允許清單，讓服務間通訊只保留必要流量。
• 最後再處理邊界案例：例如跨命名空間、跨節點延遲、或是 DNS/HTTP 的連通要求。

策略設錯最常見的症狀是「看似網路沒通」，但實際上是被策略擋掉。你需要習慣：當 Pod 之間連線失敗時，先檢查 NetworkPolicy，再檢查路由與安全群組。

3.4 暴露服務：把「外部流量」當作另一個網路層

當你配置完 Pod 網路後，接下來通常會做外部服務暴露。這裡要記住：Ingress/Load Balancer 的工作，依賴的是 Service 應用到的元件，而這些元件又依賴底層 Pod 網路能把流量導到正確端點。

建議的驗證順序：

1. 先用 ClusterIP 測試服務內部可達（Pod->Service->Pod）。
2. 再用 NodePort 或 Ingress 設定測試節點層與入口層可達。
3. 最後才上 LoadBalancer（或其他外部入口）。

如果最後一步失敗，通常你會卡在：外部到節點的連通性、NSG、防火牆、或地址與路由設定。這時你不應該一上來就推翻 CNI 設定，而是先確定 Service 端點正確、以及外部路徑是否能到節點。

第四章：常見坑與排查順序（比你以為的更重要）

4.1 Pod 卡在 ContainerCreating：先看 CNI 初始化

Pod 卡住通常是 CNI 初始化階段出了問題。你需要按順序做：

• 查看 Pod 的事件（Events），找是否提到 IP allocation、CNI failed、或與網路初始化相關的訊息。
• 檢查 CNI 相關 daemonset 或控制器的狀態（是否有重啟、是否有資源不足、是否有錯誤日誌）。
• 檢查節點子網與 NSG 是否擋住必要通信。
• Azure國際帳號 檢查 IP 是否真的還有剩餘（例如 Pod CIDR 耗盡）。

很多人會直接嘗試重建節點或整個叢集，卻沒有先看事件與 CNI 日誌。你越早看事件，越能快速定位。

4.2 Service 有建立但無法連線：先查端點再查策略

當你發現 Service 存在、DNS 可解析、但連線失敗，優先懷疑的是 Endpoint 沒有正確填入。你的排查順序：

• 確認 selector 標籤是否匹配到目標 Pod。
• 確認 Pod 狀態是否 Running、是否正常就緒（Ready）。
• 查看 NetworkPolicy（如果有啟用）。
• 最後才回頭檢查 Pod 網路路由是否正確。

因為 Endpoint 這一步錯了，你怎麼調網路插件都救不了。

4.3 跨節點延遲高或不穩：觀察路由與封包路徑

有些問題不是「完全不通」，而是不穩或延遲高。這種情況常與路由、節點網路設定或外部設備（防火牆/路由器/加密）有關。排查方式要偏向「觀察」：

• 比較同節點 Pod 與跨節點 Pod 的延遲與吞吐差異。
• 檢查是否有自定義路由或策略導致封包繞路。
• 檢查節點之間的通訊是否受 NSG 或其他規則影響。

如果你把焦點只放在 CNI 參數，可能會忽略更根本的網路路徑問題。

4.4 升級或變更後才出現問題：回到「兼容性」

Azure國際帳號 升級 AKS、變更網路模式、或更新網路插件後才出現故障，通常是兼容性或設定漂移造成。例如：你原本依賴某些默認行為，但更新後默認值改了；或你在某個地方做了局部調整，結果與新版本的預期不一致。

這時候的排查順序：

• 列出變更清單：什麼時候改了什麼。
• 對照版本差異：至少要確認 CNI/控制器與 Kubernetes 版本的相容。
• 查看網路插件系統元件的日誌，找「設定解析」或「能力不支援」等訊息。
• 把最近變更回滾到上一個可用狀態（只要可行）。

重點是：不要只看新錯誤，要抓住「錯誤從哪次變更後開始」。

Azure國際帳號 第五章：一個可靠的落地策略（讓你不靠運氣）

5.1 先做基準測試，再談優化

在你改任何網路插件或相關參數之前，先用一組固定測試建立基準。基準可以包含：

• Pod 到 Service 的連線成功率與延遲。
• 跨節點 Pod 的延遲（簡單 ping/HTTP 探測即可）。
• 外部訪問（若有）從入口到服務的可達性。
• NetworkPolicy 的預期規則是否能生效（建立最小測試集）。

之後每改一次配置，你都能知道是改善還是破壞，並把不確定性降到最低。

5.2 用「最小變更」方式調參

網路插件配置很容易出現「改了 A，結果 B 也跟著變」。因此你應該遵循最小變更：

• 每次只改一項設定（例如 CIDR、策略、或某個網路元件參數）。
• 修改後立即觀察 Pod 狀態、相關控制器日誌、以及必要的連線測試。
• 把變更與驗證結果記錄下來，至少記錄測試時間與狀態。

這樣你不需要依賴直覺猜測原因，而是靠證據。

5.3 把「可回退」當成必需品

當你正在做網路插件調整，尤其涉及隔離策略或外部連通性時，請預先規劃回退方式。你可以做到：

• 保留上版配置或導出現有設定（至少在變更前留檔）。
• Azure國際帳號 在測試環境先跑通，再上到正式環境。
• 如果必須在正式環境改，先選低流量時間窗，並準備回滾步驟。

沒有回退，你就會在故障發生時陷入「只能繼續猜」的局面，這也是網路相關工程最常見的代價。

第六章：示範性驗證清單（你可以照著做）

6.1 建立後的基本自檢

• kubectl 連線正常（控制平面與本地憑證）。
• 節點都 Ready。
• CoreDNS 可解析內外網域（視你的網路策略而定）。
• Pod 能成功取得 IP，並能彼此連通（至少同命名空間、跨節點各驗一次）。

6.2 網路插件變更後的驗證

• CNI 相關 daemonset/控制器狀態正常，無持續重啟。
• 新啟動 Pod 能正常進入 Running/Ready。
• Service 端點正確（Endpoints 有填入）。
• 若有啟用 NetworkPolicy：符合預期的服務通訊成功、被拒的通訊確實失敗。
• 若有外部入口：從外部到服務的流程可通（包含 DNS/負載平衡/入口規則）。

6.3 觀察與日誌：你要看的是「關鍵訊息」

很多人打開一堆日誌卻找不到重點。你可以用「關鍵詞」降低成本：

• 看事件中的 CNI failure、IP allocation failure、route 或 policy 相關字眼。
• 看網路插件元件日誌中的初始化錯誤、參數解析錯誤、或能力不支援訊息。
• 看節點層是否有異常網路狀態（例如節點重啟或網卡錯誤）。

結語：把網路配置當作工程，而不是儀式

AKS 網路插件配置的難點不在於「知道某個設定」，而在於你如何把網路當成一個可驗證、可回退、可追蹤的工程流程。你只要抓住幾個原則：先確保基礎網路可用、用清楚的排查順序定位問題、每次最小變更並立刻驗證，就能顯著降低踩雷機率。

最後提醒一句：當你遇到問題時，不要先急著改大方向。先回到驗證清單，先看事件與日誌，再逐步縮小範圍。網路問題雖然看似複雜，但其實常常都有線索，只是你用對順序才能抓到。