AWS帳號快速辦理 AWS EKS網路外掛配置指南

AWS帳號快速辦理 第一章：先搞清楚你要解決什麼問題

在 EKS 叢集中談「網路外掛」，很多人第一反應是找一套宣傳看起來很強的工具：裝上、開啟、等它神奇工作。但實務上，網路外掛不是用來「補上運氣」，而是把你在雲端網路上本來就該處理的事情，變得更可預期：連得上、跑得穩、可觀測、可控管。

你需要先想清楚：你目前缺的是哪一塊？通常會落在幾個面向：

• Pod 與外界的連線策略：哪些流量能進、哪些流量能出？能不能做分段隔離？
• IP 與路由的管理方式：每個 Pod 要怎麼拿到可路由的 IP？用什麼方式把路由打到 VPC 網路？
• 負載均衡與入口：外部流量如何進入叢集？是透過 ALB/NLB/Ingress Controller，還是你有自建方案？
• 網路可觀測性：想知道流量走哪條路、出了什麼錯，怎麼查？
• 安全與網路政策：能否用 NetworkPolicy 做 L3/L4 隔離？是否要和既有企業規則整合？

當你把問題定義清楚，就能選擇「要裝哪種外掛、要怎麼配置」，而不是先裝再猜。

第二章：EKS 網路的基本骨架（你必須先看懂）

EKS 網路設計的骨架主要由 VPC、子網、路由表、安全群組（Security Group）與網路介面（ENI）組成。外掛是否能正常運作，很大一部分取決於這些基礎是否符合預期。

2.1 VPC 與子網的影響

EKS 叢集通常配置在多個可用區（AZ）。你要確保：

• AWS帳號快速辦理 公有子網（Public Subnet）：承載需要外部入口的元件，例如負載均衡或需要直接出網的服務。
• 私有子網（Private Subnet）：承載節點（Node Group）。節點若沒有公網路由，通常需要 NAT Gateway 才能拉映像或更新套件。
• 路由表：私有子網到 0.0.0.0/0 的路由是 NAT 還是 VPC 內路由，會影響出站連線品質。

外掛不會憑空改變路由表。若你期望 Pod 外連能用，實際還是要看 VPC 路徑是否通。

2.2 Security Group 與流量方向

很多人把連線問題全丟給網路外掛，但 EKS 的安全群組模型也要同步檢查。你必須釐清：節點安全群組允許哪些入站/出站？負載均衡安全群組是否允許到節點的目標端口？如果使用前端 LB，NLB/ALB 後續行為也會影響你看到的「連線失敗原因」。

簡單說：網路外掛能控制 Pod-to-Pod 或 Pod-to-Service 的策略，但外層的 SG 仍可能在第一時間擋下封包。

2.3 Pod IP 的來源：VPC CNI 的角色

在 AWS EKS，最常見的 CNI 是 Amazon VPC CNI。它的核心概念是：Pod 會直接取得 VPC 的 IP（透過 ENI 與分配策略），因此 Pod 與 VPC 之間能維持良好路由與可觀測性。

這也意味著：你要理解 ENI/IP 分配、子網可用 IP 數量、以及任務需要多少 Pod 才會觸發擴展或不足。

第三章：常見網路外掛類型與選型思路

網路外掛不是只有一類。你可能需要的是 CNI（處理 Pod 網路）、Ingress Controller（處理入口）、或是支援 NetworkPolicy 的方案（處理安全）。在 AWS 上，選型通常圍繞「原生整合度」和「你是否需要額外功能」。

3.1 CNI：Amazon VPC CNI 的典型用途

VPC CNI 在 AWS 環境下是最常見的選擇，優點是與 VPC 路由、Security Group、可用性區域的整合成熟。若你的目標是穩定、少走彎路，它通常是第一優先。

但你仍可能遇到兩類挑戰：IP 耗用與 ENI 配額（例如節點數增加後 IP 不足）、以及需要更細緻的網路政策/可觀測性時，可能希望搭配其他工具。

3.2 入口：Ingress Controller 與 Load Balancer

入口的網路外掛通常是 Ingress Controller。你可能會選擇：

• 讓 Ingress Controller 驅動 ALB/NLB（視情境而定）
• 使用 Service 的 LoadBalancer 類型直接建立 LB
• 用 Gateway API 或其他方式管理入口

關鍵不是「哪個更潮」，而是你是否需要特定功能：例如路徑導流、TLS 終止、HTTP/2、會話維持、或更細粒度的健康檢查設定。入口層決定了外部怎麼進叢集，你的故障排查也會從這裡開始。

3.3 安全：NetworkPolicy 與外掛相依

在 Kubernetes 中，NetworkPolicy 的語意清楚，但真正能否生效要看你採用的 CNI 或額外的安全組件是否實作相容的資料平面能力。

若你使用僅靠「路由」就能滿足的環境，可能不需要太複雜。但在需要微分段（micro-segmentation）的系統，NetworkPolicy 幾乎是不可或缺的控制面。

第四章：Amazon VPC CNI 配置要點（把 Pod IP 跑穩）

以下內容以 Amazon VPC CNI 為主，因為它是 EKS 網路架構的核心組件之一。你不一定要改很多參數，但理解這些設定能讓你在遇到「突然沒 IP」「Pod 起不來」「節點擴容後抖動」時，不會只能重灌或猜。

4.1 IP 分配策略：要先問你怎麼估算 Pod 數

Pod 數量決定你需要多少 IP。IP 不是無限的，你的子網要有足夠可用 IP，節點的 ENI 也有配額。

在規劃階段，你要把：

• 節點類型（instance type）可以承載的 ENI/IPv4 數量
• 每個節點期望的最大 Pod 數（maxPods）
• 節點擴容上限（ASG scaling limit）
• 冗餘（例如升級、滾動更新期間的峰值）

一起算進去。只要其中一個假設錯了，IP 不足就會在壓力來臨時發生。

4.2 預留 IP：避免在高峰期直接失效

很多團隊踩的坑是：平時看起來正常，一遇到節點擴容或更新節點，Pod 就開始 Pending。原因通常是 IP 分配或 ENI 能力跟不上需求。

因此，設定預留（例如預分配或緩衝）能降低突發失敗機率。你不需要過度保守，但應該至少保留一段緩衝，確保調整節點時不會把整個叢集推進「無法分配」狀態。

4.3 節點自動擴容與 CNI 的同步思維

當你使用 Cluster Autoscaler 或 Karpenter 等工具時，節點擴容速度可能快於 IP 可用性或 ENI 的分配節奏。這並不是外掛的錯，而是整個系統需要協同。

你要做的事情是：把預期中的 Pod 峰值、節點擴容峰值、以及 CNI 可分配能力對齊。最好能在預演環境用壓測或至少以 staging 模擬擴容，確認 Pending 不會長時間出現。

AWS帳號快速辦理 4.4 參數變更的基本原則

網路參數一旦改動，可能影響大量 Pod。在生產環境要遵循三條原則：

• 小步快跑：一次只改一兩個相關參數。
• 觀測指標先定義：例如 Pod Pending、CNI 日誌錯誤、節點 ENI/IPv4 分配狀態。
• 回滾策略：要能在短時間內回到先前可用狀態。

很多事故不是因為改錯，而是因為改動後沒有明確觀測路徑，結果只好一直等。

第五章：入口與服務暴露：把流量從外面接進來

入口是最常被忽略、但最容易讓你誤判網路問題的地方。因為很多時候你以為是 Pod 網路不通，其實是 LB 配置或健康檢查規則導致流量沒有進到節點。

5.1 Ingress Controller 的基本流程

Ingress 的路徑大致是：

• 你在 Kubernetes 定義 Ingress 規則或使用 Gateway 物件
• Ingress Controller 讀取規則，建立對應的 ALB/NLB 與 target group
• LB 進行健康檢查（依你配置的 path/port/HTTP code 或 TCP 探測）
• 健康的目標才會收到流量

任何一段出問題，都會讓你在應用端看不到流量。此時你不該先怪 CNI。

5.2 服務與端口：目標是哪些 Pod 邏輯？

Ingress 最終會依賴 Service。你要確認 Service 的 selector 是否正確對應到 Pod 的 labels、以及 Service port / targetPort 的對應關係。

常見錯誤包括：

• selector 寫錯或版本升級後 labels 改了
• targetPort 不存在，導致健康檢查永遠失敗
• 應用監聽在不同的 port 或只綁定 localhost

建議你在排查時按「從外到內」：先確認 LB target group 狀態，再確認節點上是否有對應端口轉發，最後再看 Pod 內部服務是否在 listen。

5.3 TLS 與憑證：避免把加密誤當成網路問題

若你啟用 TLS，憑證問題可能呈現為連線失敗或握手錯誤。這種情況看起來像網路阻擋，但本質是應用層或憑證鏈問題。

你可以用比較直接的方法排除：先測純 HTTP 或使用相同設定在 staging 確認 LB 的 listener 行為，避免在應用端與網路端同時猜測。

第六章：網路政策與安全落地：從需求到可驗證

NetworkPolicy 的價值在於可持續的安全控管。要把它落地，你不只要寫規則，還要能驗證規則是否真的生效。

6.1 先定義「允許與拒絕」的邊界

最常見的失敗方式是：規則寫得太複雜，導致團隊不知道改了什麼、會影響到什麼。建議採取分層策略：

• 先做最小可用：只阻擋明確不該互通的流量
• 再逐步收緊：從服務間通訊開始，逐步到 Pod 與 sidecar
• 最後才處理例外：例如管理介面、監控回呼、或第三方 webhook

同時要定義「預期通不通」的測試點，至少包含：app-to-db、app-to-cache、ingress-to-service、以及跨 namespace 的必要通訊。

6.2 認清資料平面責任歸屬

AWS帳號快速辦理 NetworkPolicy 是語意，但真正執行通常由 CNI 或安全外掛的資料平面完成。若你沒有在你的環境中啟用相容的資料平面能力，你會看到 NetworkPolicy 物件存在，但流量行為並不符合預期。

因此配置完成後，你要用行為驗證，而不只看 YAML。

6.3 用測試把規則「釘住」

建議做兩層驗證：

• 靜態驗證：檢查規則是否正確綁定 selector、命名空間、以及 port/protocol。
• 動態驗證：在允許/拒絕案例下進行連線測試，確認行為符合預期。

動態驗證可以用簡單工具（例如檢查 TCP 連線或在容器內執行探測）。你不需要昂貴的測試框架，但要做到可重複。

第七章：可觀測性與日誌：你得能回答「為什麼」

網路問題最難的是：它不是單點故障，而是一條路徑上多個元件共同決定結果。可觀測性不是額外負擔，而是讓你縮短修復時間。

7.1 先確定要看哪幾層

通常你可以依序看：

• 負載均衡與 target group（是否健康、轉發狀態）
• 節點與 kube-proxy（Service 轉發是否正常）
• CNI 相關狀態（IP 分配、路由程式、ENI 配額）
• AWS帳號快速辦理 Pod 內部服務（是否 listen、是否回應、是否被應用層擋住）
• 網路政策（允許/拒絕是否符合）

如果你缺少「路徑上的每一層證據」，修復就會變成猜。

7.2 日誌與事件：用時間線思考

Kubernetes 事件（events）和外掛日誌提供了時間線線索。當你遇到「突然失效」，你要問：失效前是否做了節點擴容？是否更新了 CNI 或 Ingress Controller？是否變更了路由或安全群組？

把時間線串起來，你會更快定位是設定變更引起，還是資源耗盡。

7.3 常見指標：Pending、重啟、與連線失敗率

在日常運維，你應追蹤：

• Pod Pending 數量與持續時間
• 節點 Ready/NotReady 次數
• CNI 或 Ingress Controller 的錯誤率
• 應用的 4xx/5xx 比例（入口層與應用層分開看）
• DNS 解析與延遲（如果應用依賴內部服務）

這些指標能幫你快速判斷是「連線不到」還是「連到了但回應不對」。

AWS帳號快速辦理 第八章：常見錯誤與排查路徑（照著走就會快）

下面提供一個實務上很常用的排查順序。你不用背答案，但要養成「先排外層、再排內層」的習慣。

8.1 Pod Pending：先看 IP 與排程，再看節點資源

Pod 一直 Pending，常見原因包含：

• 節點沒有可用容量（CPU/Mem 或 maxPods 限制）
• IP 分配不足（CNI 無法給 Pod）
• 節點磁碟或其他資源限制

AWS帳號快速辦理 排查順序建議：

1. 查看 Pod 描述與事件（事件通常會直接提示是 IP 或排程）
2. 檢查節點是否 Ready，且是否在擴容/更新中
3. 查看 CNI 相關 DaemonSet 的狀態與日誌
4. 確認子網可用 IP 是否接近耗盡

8.2 入口連線失敗：先排 LB 再排 Pod

如果外部不能連到應用，優先做：

1. 確認 Ingress Controller 是否成功建立 LB/Listener 與 target group
2. 檢查 target group 的健康狀態（unhealthy 通常表示目標端口或路徑不符）
3. 確認 Service selector 與端口映射
4. 最後才檢查 Pod 網路與 NetworkPolicy

8.3 Pod-to-Pod 不能通：先檢查命名空間與 selector，再看策略

Pod-to-Pod 失敗通常和兩件事相關：Service/selector 是否正確，或 NetworkPolicy 是否阻擋了應允許的連線。

AWS帳號快速辦理 建議你用最小測試組合：

• 在兩個 namespace 各部署簡單服務與測試 Pod
• 只改一個方向的規則（例如只放行特定 port）
• 逐步定位是 selector 不匹配、還是策略語意不正確

8.4 變更後才發生：用回滾與差異確認

只要確定是變更後才出現，你就不要長時間把精力花在「假設」上。做：

• 回滾最近的 CNI/Ingress/策略設定
• 比對變更前後的事件與錯誤日誌
• 如果回滾有效，才回去細查是哪個參數造成

修復速度通常取決於你是否能快速縮小差異範圍。

第九章：配置落地的檢查清單（讓你每次都不會漏）

下面是一份可在上線前直接使用的檢查清單。你可以依團隊習慣調整，但核心精神是「把不確定性變小」。

9.1 前置條件

• VPC 子網 IP 容量足夠，且 NAT/路由策略符合出站需求
• 節點安全群組與 LB 安全群組規則一致，端口方向正確
• 節點類型與 maxPods 的估算能支撐預期 Pod 峰值

9.2 CNI 層

• CNI DaemonSet 狀態正常，無大量錯誤日誌
• 確認 Pod IP 能分配成功，且能路由至需要的目標
• AWS帳號快速辦理 節點擴容/縮容期間未出現長時間 Pending

9.3 入口層

• Ingress 規則與 Service 端口映射正確
• target group 健康檢查通過，且路徑/port 與應用一致
• TLS 憑證與 listener 行為與預期一致（含重導與狀態碼）

9.4 安全層

• NetworkPolicy 規則命名空間與 selector 正確
• 關鍵服務之間的允許通訊可測得（動態驗證通過）
• 拒絕案例確實阻擋，不會留下「看似有規則但實際沒生效」的空窗

9.5 可觀測性層

• 能在故障時快速定位：入口層、Service 轉發、CNI、Pod 內部服務
• 你知道該查哪些事件/哪些日誌，並能在預期時間內回收
• 至少有一套固定的排查順序，避免團隊各查各的

第十章：把網路外掛做成「可運維」而不是「可安裝」

真正的差別在於：你不只讓系統「上線」，還要讓它「可維護」。網路外掛配置之所以常被覺得痛苦，是因為它牽涉多個層級，而人容易只抓最顯眼那一層。

AWS帳號快速辦理 如果你願意用本文的思維——定義問題、理解骨架、按層排查、用行為驗證——你會發現很多問題並不神秘。它們只是把你原本就得面對的工程邏輯，換了一個更複雜但更可控的舞台。

最後給一句務實建議：每次配置或調整外掛，都要記錄「目標是什麼、改了什麼、觀測到什麼、下一步怎麼確認」。當這件事變成團隊習慣，你的 EKS 網路就會越來越穩，故障也會越來越好處理。