Kubernetes網絡原理深度解析

1 Kubernetes網絡模型

Kubernetes 網絡模型是其實現容器化應用高效通信的基礎框架。它致力于解決容器編排環境中復雜的網絡連通性、服務發現與負載均衡等問題，追求讓容器、Pod 等網絡端點像傳統主機網絡一樣簡潔、可預測地通信。其核心設計目標包括：各 Pod 擁有獨立且可直接訪問的 IP 地址，同一 Pod 內容器共享網絡命名空間，服務（Service）提供穩定網絡入口并實現負載分發，助力應用在集群內便捷通信與擴展。

2 Kubernetes網絡的實現機制

2.1 容器和容器之間的通信

同一 Pod 內的容器，因共享網絡命名空間（包括網絡協議棧、IP 地址、端口等資源），可通過 localhost 加端口的方式直接通信，就像傳統單機進程間通信一樣高效，無需額外網絡轉發開銷，利用共享的網絡資源快速交互數據。

2.2 Pod和Pod之間的通信

Pod 間通信需解決跨網絡命名空間、跨主機的問題。Kubernetes 依賴網絡插件（如 CNI 插件）構建集群網絡，讓每個 Pod 分配到集群內唯一 IP 。通信時，借助虛擬網絡設備（如網橋、隧道）、路由規則等，封裝、轉發數據包。 overlay 網絡方案會對 Pod 流量封裝后跨主機傳輸，再解封裝投遞；基于主機路由的方案則通過配置主機路由表，指引 Pod 流量在集群主機間正確轉發，保障不同主機上 Pod 能基于 IP 直接通信。

3 CNI網絡模型

3.1 CNI網絡模型簡介

CNI（Container Network Interface ）是容器網絡接口標準，為容器平臺（如 Kubernetes ）與網絡插件解耦提供規范。它定義了簡潔的 JSON 格式接口，讓容器運行時（如 containerd、runc ）能調用不同網絡插件，動態為容器配置網絡、分配 IP 等。借助 CNI，Kubernetes 無需關注網絡實現細節，可靈活對接 Flannel、Calico 等多樣網絡方案，適配不同集群網絡需求，推動容器網絡生態發展。

3.2 CNI網絡模型詳解

CNI 工作流程包含“添加網絡”與“刪除網絡”階段。“添加網絡”時，容器運行時調用 CNI 插件，傳遞容器網絡命名空間等信息，插件創建網絡設備（如 veth 對），一端接入容器命名空間，另一端連入主機網絡（或 overlay 網絡端點），分配 IP 并配置路由、防火墻規則等，完成容器網絡接入；“刪除網絡”則是反向操作，釋放網絡資源，確保集群網絡資源合理回收。同時，CNI 支持鏈式插件，可組合多個功能插件（如先做網絡隔離，再做 IP 分配），靈活擴展網絡功能。

4 開源容器網絡方案

4.1 Flannel插件的原理和部署示例

原理：Flannel 是經典 CNI 插件，為集群提供 overlay 網絡。它默認用 VXLAN 模式，為主機分配子網，每個主機上 Pod 從主機子網取 IP 。Pod 跨主機通信時，Flannel 守護進程（flanneld ）捕獲流量，封裝成 VXLAN 數據包，通過主機間 UDP 隧道傳輸，目標主機解封裝后投遞到目標 Pod 。還支持 host - gateway 模式，利用主機路由表轉發 Pod 流量，減少封裝開銷，提升性能。
部署示例：在 Kubernetes 集群，先下載 Flannel 資源清單（kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml ），清單會創建 DaemonSet ，在各節點運行 flanneld ，配置集群網絡參數（如 Pod 網段）。部署后，檢查 Pod 狀態（kubectl get pods -n kube-flannel ），確保正常運行，測試 Pod 跨主機通信，驗證網絡連通性。

4.2 Open vSwitch插件的原理和部署示例

原理：Open vSwitch（OVS ）是虛擬交換機，可靈活定義網絡流表規則。在容器網絡，它作為底層網絡設備，構建 overlay 網絡（如 GRE、VXLAN 隧道）。通過流表匹配數據包源目 IP、端口等，實現轉發、隔離、QoS 等功能。配合 Kubernetes ，OVS 可作為網絡插件底層支撐，為 Pod 提供網絡連接，基于流表精細控制 Pod 流量，適配復雜網絡策略場景。
部署示例：先在集群節點安裝 OVS 軟件包（如在 Ubuntu 用 apt install openvswitch-switch ）。然后部署基于 OVS 的 CNI 插件（如 Multus 配合 OVS 配置網絡），或使用專門集成 OVS 的網絡方案。通過配置 OVS 網橋、隧道端口，編寫 CNI 配置文件指定 OVS 網橋、IP 分配等，應用配置后，創建 Pod 測試網絡，利用 ovs-vsctl 命令查看流表、端口狀態，驗證網絡功能。

4.3 直接路由的原理和部署示例

原理：直接路由（Direct Routing ）摒棄 overlay 封裝，依賴主機路由表實現 Pod 跨主機通信。網絡插件為每個主機分配 Pod 子網，在主機上配置靜態路由，把其他主機 Pod 子網的流量發往對應主機物理網卡。借助 BGP 協議（如 Calico 的 BGP 模式），集群主機間自動交換路由信息，動態維護路由表，讓 Pod 流量基于物理網絡三層轉發，減少封裝延遲，提升網絡性能，適合對網絡效率要求高的場景。
部署示例：以 Calico 開啟直接路由模式為例，修改 Calico 配置，啟用 ipipMode: Never（關閉 IPIP 封裝），配置 BGP 鄰居（如集群主機間建立 BGP 連接）。部署 Calico 資源清單后，Calico 節點守護進程（calico-node ）會在主機配置路由規則，通過 BGP 協議同步路由。測試時，在不同主機 Pod 間 ping 或傳輸數據，查看主機路由表（ip route ），確認跨主機 Pod 路由正確，驗證直接路由效果。

4.4 Calico插件的原理和部署示例

原理：Calico 是強大的 Kubernetes 網絡方案，基于 BGP 協議和 Linux 路由實現網絡。它為每個 Pod 分配獨立 IP，利用主機路由表轉發流量，無需 overlay 封裝（也支持 IPIP 模式）。通過網絡策略（NetworkPolicy ），基于標簽精細控制 Pod 間訪問，如允許或拒絕特定命名空間、標簽的 Pod 通信。Calico 節點代理（calico-node ）負責維護路由、應用網絡策略，控制器組件管理網絡資源分配與策略同步，適配大規模集群網絡需求。
部署示例：使用官方資源清單部署，kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml 。部署后，檢查 calico-node Pod 狀態（kubectl get pods -n calico-system ）。配置網絡策略，例如創建一個策略，允許 app=web 標簽的 Pod 被 app=client 標簽的 Pod 訪問：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: allow-web-accessnamespace: default
spec:podSelector:matchLabels:app: webingress:- from:- podSelector:matchLabels:app: client

應用策略后，測試 Pod 間通信，驗證網絡策略生效情況。

5 Kubernetes網絡策略

5.1 網絡策略概述

Kubernetes 網絡策略（NetworkPolicy ）是實現 Pod 網絡訪問控制的核心機制，基于標簽選擇器，定義 Pod ingress（入站）和 egress（出站）流量規則。它能精細管控哪些 Pod 可與其他 Pod、服務甚至外部網絡通信，像設置白名單、黑名單，隔離敏感應用網絡，保障集群網絡安全，適配多租戶、微服務權限分離等場景。

5.2 Selector功能說明

Selector（選擇器）是網絡策略的關鍵，通過標簽匹配 Pod 。podSelector 用于選定受策略影響的 Pod 集合；ingress.from.podSelector 和 egress.to.podSelector 則指定流量來源或目標的 Pod 標簽。例如，策略中 podSelector: {matchLabels: {role: backend}} 選中所有帶 role=backend 標簽的 Pod ，ingress.from.podSelector: {matchLabels: {role: frontend}} 允許前端 Pod 訪問，利用標簽靈活、動態地定義網絡訪問關系。

5.3 為命名空間配置默認的網絡策略

可為命名空間配置默認網絡策略，控制該命名空間下未明確配置策略的 Pod 流量。創建默認拒絕策略，拒絕所有入站和出站流量：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: default-denynamespace: my-namespace
spec:podSelector: {}  # 匹配命名空間下所有PodpolicyTypes:- Ingress- Egressingress: []      # 無入站規則，默認拒絕egress: []       # 無出站規則，默認拒絕

后續為該命名空間內特定 Pod 配置允許規則，可覆蓋默認拒絕，實現“默認隔離，按需開放”，提升命名空間網絡安全性。

5.4 網絡策略應用示例

假設電商應用，有 frontend（前端）、backend（后端）、db（數據庫）Pod 。創建策略允許前端訪問后端，后端訪問數據庫，拒絕其他流量：

后端 Pod 策略（允許前端訪問）：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: backend-allow-frontendnamespace: default
spec:podSelector:matchLabels:app: backendingress:- from:- podSelector:matchLabels:app: frontend

數據庫 Pod 策略（允許后端訪問）：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: db-allow-backendnamespace: default
spec:podSelector:matchLabels:app: dbingress:- from:- podSelector:matchLabels:app: backend

前端、后端、數據庫的出站策略可按需配置，如限制后端只能訪問數據庫，通過網絡策略構建清晰、安全的應用網絡訪問鏈路。

5.5 網絡策略的一些特殊情況和功能限制

網絡策略僅在支持的網絡插件（如 Calico、Cilium ）下生效，若網絡插件不支持，策略配置無效。策略匹配是“與”邏輯，多個策略疊加需注意規則沖突。對同一 Pod ，入站規則需所有策略允許才放行，存在調試復雜問題。且網絡策略主要管控 Pod 間七層以下流量，對應用層協議（如 HTTP 路徑）精細控制能力有限，需結合服務網格（如 Istio ）等方案補充。