Cilium 入門指南：用 eBPF 打造高效能 Kubernetes 網路

前言

在 Kubernetes 叢集中，網路一直是最令人頭痛的環節之一。傳統的 CNI 外掛（例如 Flannel、Calico）大多依賴 iptables 來處理封包轉發與策略過濾，但隨著叢集規模與微服務數量的增長，iptables 規則會變得越來越龐大，效能瓶頸也隨之浮現。這時候就輪到 Cilium 登場了——它是一款基於 eBPF（Extended Berkeley Packet Filter） 技術打造的雲端原生 CNI 外掛，能在 Linux 核心層直接處理網路邏輯，徹底跳過傳統的 iptables 瓶頸。

這篇文章我會從 Cilium 的核心特色開始，一路聊到部署方式、架構元件，以及實際的工作流程，希望能幫助大家快速建立對 Cilium 的整體認識。

Cilium 核心特性一覽

eBPF 驅動的高效資料平面

Cilium 最大的亮點在於利用 eBPF 直接在 Linux 核心中執行封包處理邏輯。這代表什麼呢？傳統做法是封包從核心空間跑到用戶空間、處理完再送回去，來回切換非常耗費資源。而 Cilium 透過 eBPF 把邏輯塞進核心裡跑，省去這些來回開銷，搭配零拷貝轉發等最佳化手段，在高流量環境下表現相當亮眼。

eBPF 與 iptables 架構對比圖

eBPF 與 iptables 架構對比：Cilium 透過 eBPF 在核心層直接處理封包，省去 iptables 的逐條規則比對

多層級網路策略（L3/L4/L7）

Cilium 不只做基本的 IP + Port 層級（L3/L4）流量控制，它還能深入到應用層（L7），針對 HTTP、gRPC 等協定的請求路徑、方法甚至內容來制定存取規則。對於微服務架構來說，這種細粒度的策略控制簡直是救星。

層級	控制維度	典型應用場景
L3	IP 位址	限制特定來源 IP 的存取
L4	TCP/UDP 連接埠	只允許 80/443 埠的流量
L7	HTTP 路徑、gRPC 方法	僅允許 GET /api/v1/users

Hubble 可觀測性平台

Cilium 內建了一個叫做 Hubble 的可觀測性工具，能夠即時監控服務之間的網路流量、延遲和錯誤率。它還支援全鏈路追蹤，讓你可以一眼看出封包從哪裡來、經過哪些節點、最後到了哪裡，對於排查網路問題非常好用。

豐富的擴展能力與生態整合

Cilium 支援自訂 eBPF 程式，你可以根據業務需求來擴充網路功能。同時它也能與 Prometheus、Grafana、Istio 等主流雲端原生工具無縫整合，不會成為技術棧中的孤島。

跨雲與混合雲場景

Cilium 支援跨雲端和混合雲的 Kubernetes 叢集，能在不同環境中提供一致的網路安全策略和流量管理，對多雲架構的團隊來說是一大福音。

取代 kube-proxy 的負載均衡

Cilium 內建核心級的服務負載均衡功能，效能比傳統的 kube-proxy 高出不少。它與 Kubernetes 的 Service 資源協同運作，能自動處理 Pod 間的通訊與流量分配。

哪些場景適合使用 Cilium？

場景	說明
雲端原生微服務架構	需要嚴格流量控制和豐富可觀測性的環境
邊緣運算	低延遲需求，如 CDN 邊緣節點、IoT 裝置
高流量叢集	電商、串流媒體、金融服務等對吞吐量要求極高的場景
多租戶隔離	需要為不同租戶提供強隔離保障的平台

Cilium 部署實戰

使用 Helm 部署

官方文件可參考 Helm 安裝指南與快速入門。

# 新增 Helm repo
helm repo add cilium https://helm.cilium.io/
helm repo update

# 建立 namespace 並部署
kubectl create ns cilium-system || true
helm install cilium cilium/cilium --namespace cilium-system \
    --set ipam.mode=cluster-pool \
    --set ipam.operator.clusterPoolIPv4PodCIDRList="10.244.0.0/16" \
    --set ipam.operator.clusterPoolIPv4MaskSize=24

使用 Cilium CLI 部署

# 安裝 Cilium CLI
curl -L --remote-name https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz
tar xzvf cilium-linux-amd64.tar.gz
sudo mv cilium /usr/local/bin

# 部署 Cilium
kubectl create ns cilium-system || true
cilium install --namespace=cilium-system \
  --ipam=cluster-pool \
  --cluster-pool-ipv4-cidr=10.244.0.0/16 \
  --cluster-pool-ipv4-mask-size=24

部署驗證

部署完成後，可以透過以下指令確認狀態：

$ cilium status --wait
   /¯¯\
/¯¯\__/¯¯\    Cilium:         OK
\__/¯¯\__/    Operator:       OK
/¯¯\__/¯¯\    Hubble:         disabled
\__/¯¯\__/    ClusterMesh:    disabled
   \__/

DaemonSet         cilium             Desired: 2, Ready: 2/2, Available: 2/2
Deployment        cilium-operator    Desired: 2, Ready: 2/2, Available: 2/2

也別忘了跑一下連線測試：

$ cilium connectivity test
ℹ️  Monitor aggregation detected, will skip some flow validation steps
✨ [k8s-cluster] Creating namespace for connectivity check...
(...)
---------------------------------------------------------------------------------------------------------------------
📋 Test Report
---------------------------------------------------------------------------------------------------------------------
✅ 69/69 tests successful (0 warnings)

IPAM 模式怎麼選？

Cilium 提供兩種常見的 IPAM 模式，選擇哪一種取決於你的叢集規模和管理需求：

比較項目	Cluster-Pool 模式	Kubernetes 模式（預設）
IP 管理方式	Cilium 自行管理 Pod IP 池	由 kube-controller-manager 管理
靈活性	高，支援不同節點/區域的獨立 IP 池	低，無法細粒度管理
動態擴展	可動態調整 IP 池大小	受限於初始 CIDR 設定
額外依賴	需要 Cilium Operator	無額外依賴
適用叢集規模	大型（500+ 節點）	中小型（500 節點以下）
推薦場景	跨區域、多節點池的複雜網路	簡單網路規劃、快速部署

Cilium 架構全景

Cilium 的架構可以從官方的元件總覽圖來理解（參考 Component Overview）：

Cilium 架構總覽圖

Cilium 架構總覽：展示 Agent、Operator、eBPF、Hubble 等核心元件的互動關係

核心元件

元件	運行位置	主要職責
Cilium Agent	每個 K8s 節點	監聽 API Server、載入 eBPF 程式、執行 L3-L7 策略、服務發現與負載均衡
Cilium Operator	叢集層級	管理 Pod IP 池、維護 Agent 與 K8s 的整合、處理節點拓撲變化
Cilium CLI	管理端	安裝、設定、調試 Cilium；查看運行狀態與 eBPF 程式
CNI Plugin	每個節點	Pod 排程/終止時由 K8s 呼叫，負責網路介面設定
eBPF 程式	Linux 核心	路由轉發、網路策略、服務負載均衡、流量監控
Hubble	叢集層級	即時流量監控、服務間流量圖、延遲與錯誤率統計

Cilium 的工作流程

最後來看看 Cilium 從啟動到處理流量的完整流程：

初始化階段：Cilium Agent 啟動後，與 Kubernetes API Server 建立連線，開始監聽 Pod、Service、NetworkPolicy 等資源的變化。
策略配置階段：當使用者建立 NetworkPolicy 或 CiliumNetworkPolicy，Agent 會將策略轉譯並載入對應的 eBPF 程式到核心中。
流量處理階段：資料平面的 eBPF 程式對每個經過的封包進行路由決策、策略比對和負載均衡，全部在核心空間完成，不需要跳到用戶空間。
監控與分析階段：eBPF 程式在處理封包的同時收集流量數據，透過 Hubble 將資料視覺化呈現，方便運維團隊快速掌握叢集網路狀況。

小結

Cilium 作為新一代的 Kubernetes CNI 外掛，透過 eBPF 技術從根本上改變了容器網路的運作方式。如果你的叢集正面臨 iptables 規則爆炸、網路效能瓶頸，或是需要更細緻的 L7 層級流量控制，不妨試試 Cilium。搭配 Hubble 的可觀測性能力，相信能讓你的 Kubernetes 網路管理體驗提升不少。

前言