2026 年微服務網格（Service Mesh）輕量化趨勢：eBPF 技術取代 Sidecar 架構
第五，安全邊界的模糊。Sidecar 與業務容器共享網路命名空間，理論上業務容器可以繞過 Sidecar 直接對外發送流量，除非額外加上 iptables 規則或 NetworkPolicy 來阻擋。這意味著「所有流量都經過網格」是一個需要持續驗證的假設，而不是架構上的硬性保證。
1-3 為什麼「輕量化」成為 2026 年的主旋律
這五個限制指向同一個結論：Sidecar 架構的成本與 Pod 數量成正比，而且這條成本曲線在實務上往往比線性更陡。當企業從「容器化」走向「大規模容器化」，從數百個 Pod 走向數萬個 Pod，Sidecar 的成本就不再是零頭，而是必須重新設計架構的理由。
於是問題變成：有沒有一種方式，可以在不犧牲 L4/L7 治理能力的前提下，把「每 Pod 一個代理」的線性成本，換成「每節點一個元件」的固定成本？2026 年，產業給出的答案愈來愈一致：用 eBPF 把資料平面往核心推。
二、eBPF 技術解構：它為什麼能成為新一代服務網格資料平面
2-1 從核心出發：eBPF 的運作原理
eBPF（extended Berkeley Packet Filter）本質上是一種在 Linux 核心中執行沙箱化程式的能力。開發者用 C 或 Rust 撰寫一段小程式，透過 clang/LLVM 編譯成 eBPF 位元組碼，經過核心驗證器（verifier）檢查安全性之後，掛載到特定的掛鉤點（hook point）上執行。這些掛鉤點涵蓋網路堆疊的多個位置，包括 XDP（eXpress Data Path）、TC（Traffic Control）、以及 socket 層的 connect、sendmsg、recvmsg 等系統呼叫路徑。
關鍵在於：這些程式執行在核心空間，不需要把封包複製到使用者空間，也不需要進行 context switch。當封包進入網卡，eBPF 程式可以在極早的階段就做出分流決策——要轉發、要丟棄、要改寫標頭、要送往哪個 socket，全部可以在核心內完成。這種「在最接近硬體的位置做決策」的特性，正是它效能優勢的來源。
除了網路之外，eBPF 還可以用在安全與可觀測性領域：掛在 kprobe、tracepoint、uprobe 上採集核心或使用者態函數的執行資訊，或是掛在 LSM hook 上執行安全策略。這使得同一個技術底座可以同時支撐網路、安全與觀測三種能力，也讓服務網格的實作得以整合進單一資料平面。
2-2 Socket-Level 負載平衡：繞過 Netfilter 的關鍵一步
傳統 Service（ClusterIP）的實作方式是靠 kube-proxy 寫入 iptables 或 IPVS 規則。當 Pod 對 Service 發出連線，封包要先經過一長串 iptables 規則做 DNAT，才能找到後端的 Pod IP。規則數量會隨服務與端點數量成長，導致比對成本上升；封包也會完整走一遍 netfilter 與 conntrack，產生額外開銷。
eBPF 的做法截然不同。以 Cilium 的 socket-level load balancing 為例，它把 eBPF 程式掛在 socket 的 connect() 系統呼叫與 sendmsg() 路徑上。當應用程式呼叫 connect() 連向 Service 的 ClusterIP 時，eBPF 程式在核心內直接把目標位址改寫成後端 Pod 的 IP，然後才建立連線。結果是：封包從來不需要經過 iptables 的 DNAT 流程，也不需要額外一層代理轉發，就能到達正確的後端。
這種「在 socket 層完成服務發現與負載平衡」的機制，是 eBPF 服務網格能做到「無 Sidecar 也能做 L4 治理」的技術基礎。它同時也讓效能大幅改善：因為連線路徑變短、少了 netfilter 的規則比對與 conntrack 的狀態維護，延遲下降、CPU 用量減少。對於高連線數、短連線為主的微服務場景，這個差異尤其明顯。
2-3 核心層與 Sidecar 的本質差異
把兩種架構放在一起比較，差異不只是「有沒有 Envoy」，而是治理邏輯執行的位置完全不同。以下表格整理了幾個關鍵維度。
比較維度
Sidecar 架構
eBPF / Sidecarless 架構
執行位置
使用者空間的獨立代理行程
Linux 核心（部分搭配共享的使用者空間元件）
部署粒度
每個 Pod 一個 Sidecar
每個節點一組元件（ztunnel、Cilium Agent）
L4 處理
使用者空間代理轉發
核心內 socket 層直接轉發
L7 處理
每個 Pod 的 Envoy 負責
按需啟動共享的 L7 代理（如 waypoint）
資源成本模型
與 Pod 數量成正比
與節點數量成正比
升級方式
需滾動重啟業務 Pod
升級節點層 DaemonSet，業務無感
可觀測性
分散於每個 Sidecar
集中於節點層，可搭配核心事件
這張表點出核心概念：Sidecarless 架構把「與 Pod 數量成正比的成本」轉換成「與節點數量成正比的成本」。在一個 50 節點、3,000 Pod 的叢集裡，這代表治理元件的數量從 3,000 降到 50 左右——兩個數量級的差距。這正是「輕量化」在 2026 年被反覆討論的經濟基礎。
三、2026 年 Sidecarless 服務網格的三條技術路線
3-1 Cilium：把整個資料平面交給 eBPF 與核心
Cilium 是最早、也最徹底把 eBPF 當作資料平面基礎的專案。它原本是 CNI（容器網路介面），後來逐步長出服務網格能力：kube-proxy replacement（用 eBPF 取代 iptables 做 Service 負載平衡）、NetworkPolicy 與 L7 政策、Hubble 可觀測性、以及基於 Envoy 的 L7 代理能力。
它的架構特色是「核心優先」。當應用程式需要連到某個 Service，Cilium 的 eBPF 程式在 socket 層完成服務發現；只有當政策需要 L7 解析（例如 HTTP 路徑層級的授權、標頭改寫）時，才會把流量導入按需啟動的 Envoy。這意味著在不需要 L7 的場景下，流量完全不經過使用者空間代理，路徑長度與純核心轉發幾乎一致。
2026 年的 Cilium 已把 mTLS、身分驗證與 L7 政策整合進同一個資料平面，並以「每節點一個 Cilium Agent」取代數千個 Sidecar。對已經使用 Cilium 作為 CNI 的團隊來說，啟用網格功能幾乎只是打開開關，額外部署成本極低——這是它在實務上被大量採用的關鍵原因。
# 以 Helm 部署 Cilium 並啟用 kube-proxy replacement
helm upgrade cilium cilium/cilium \
namespace kube-system \
set kubeProxyReplacement=true \
set k8sServiceHost=<API_SERVER_IP> \
set k8sServicePort=<API_SERVER_PORT>
3-2 Istio Ambient Mesh：ztunnel 與 waypoint 的分層哲學
Istio 的路線不同。它沒有放棄 Envoy，而是把原本的 Sidecar 拆成兩層：L4 由每節點一個 ztunnel（zero-trust tunnel）負責，L7 則由按需部署的 waypoint proxy 處理。
ztunnel 是一個輕量的實作，負責 mTLS、身分驗證與 L4 授權。它以 DaemonSet 形式部署，每個節點一個，使用 HBONE（HTTP-Based Overlay Network Environment）在節點之間建立加密通道。因為它只處理 L4，不需要解析 HTTP 或 gRPC，資源佔用遠低於完整的 Envoy Sidecar。
waypoint proxy 則是一個可以按命名空間或服務部署的 Envoy 實例，只有在需要 L7 功能時才啟用——例如基於 HTTP 標頭的路由、路徑層級的授權、流量鏡像、故障注入。它的部署粒度可以由平台團隊決定：可以一個命名空間一個，也可以只針對真正需要 L7 治理的服務部署。
這種分層設計的價值在於：多數微服務之間的呼叫只需要 L4 的 mTLS 與身分驗證，這些由 ztunnel 處理即可；只有真正需要 L7 治理的服務才付出額外的代理成本。相較於「所有 Pod 都掛一個完整 Envoy」，資源效率明顯提升。
# 安裝 Istio 並啟用 Ambient 模式
istioctl install --set profile=ambient
將命名空間加入 Ambient 網格
kubectl label namespace default istio.io/dataplane-mode=ambient
針對需要 L7 治理的服務部署 waypoint
istioctl waypoint apply -n default
對既有 Istio 使用者而言，Ambient 模式最大的吸引力是遷移路徑。它可以與 Sidecar 模式在同一個網格內共存，團隊可以按命名空間逐步遷移，而不需要一次翻掉整個架構。這對於已經投入大量資源在 Istio 上的企業來說，是一個風險可控的演進方式。
3-3 其他陣營的跟進與差異化
除了 Cilium 與 Istio，其他專案也在 2026 年前後調整方向。Linkerd 長期以輕量著稱，它的代理以 Rust 撰寫，資源佔用本來就比 Envoy 低，因此「輕量化」對它而言更像是既有優勢的延伸，而非典範轉移；不過它也開始探索與 CNI 更深度整合、進一步降低每 Pod 代理成本的路線。
Kuma 與 Consul 則以多環境（VM 與 Kubernetes 混合）為主要賣點，在純 eBPF 路線上較為保守，多半透過與 Cilium 之類的 CNI 協作來補足資料平面的能力。至於雲廠商託管服務，則普遍在既有的網格產品中增加「無 Sidecar」選項，讓使用者可以按命名空間選擇資料平面模式。
可以觀察到的共同趨勢是：純 Sidecar 的「每個 Pod 一個完整代理」正在退場，取而代之的是「共享元件 + 按需 L7 代理」的組合。差別只在於共享元件的實作方式——是完全依賴 eBPF 與核心，還是保留一個輕量的使用者空間守護行程。
四、效能實測對比：輕量化到底省了多少？
4-1 資源佔用：從線性成長到固定成本
資源節省是最容易量化、也最容易被決策者理解的效益。根據公開基準測試與社群實測，一個閒置的 Envoy Sidecar 通常佔用約 30 到 80 MB 記憶體，以及十幾到數十 millicores 的 CPU 基線；而每節點一個的 ztunnel 或 Cilium Agent，記憶體大約落在 50 到 150 MB 區間，CPU 則依流量而定。
把數字放進一個具體場景：假設叢集有 50 個節點、3,000 個業務 Pod。
這是一個約略估算，實際數字會隨設定、流量與功能啟用情況而異，但數量級的差異是明確的。對雲端環境而言，這直接對應到每月帳單；對自建機房而言，這代表可以在同樣的硬體上承載更多業務工作負載。
4-2 延遲與吞吐量：socket 層轉發的優勢
延遲方面的改善來自兩個層面。第一是路徑長度：Socket 層負載平衡讓封包不必走完 netfilter 的規則鏈，也避開了部分 conntrack 的處理。第二是代理層數：在不需要 L7 的流量上，Sidecarless 架構可以完全省略使用者空間代理，少掉一次或兩次的上下文切換與資料複製。
Cilium 公開的基準測試顯示，在啟用 socket-level load balancing 的情況下，相較於傳統 iptables 模式的 kube-proxy，請求延遲與 CPU 使用率都有明顯改善，部分情境下的吞吐量提升可達 1.5 倍以上。Istio 官方對 Ambient 模式的說明也指出，ztunnel 因為只處理 L4，其 CPU 與記憶體足跡明顯低於完整 Sidecar。
需要提醒的是，這些數字高度依賴測試環境、連線模式（長連線或短連線）、協定（HTTP/1.1、HTTP/2、gRPC）與是否啟用 mTLS。團隊在做技術選型時，最好的做法是在自己的環境中建立可重現的基準測試，而不是直接套用別人的數字。
4-3 升級與維運：被低估的成本節省
其實最容易被低估的，是維運成本的降低。在 Sidecar 模式下，升級網格版本要滾動重啟所有業務 Pod，這牽涉到變更審核、排程協調與業務影響評估；在節點層架構下，升級的是 DaemonSet，業務 Pod 不需要重啟。這個差異在變更管理嚴格的企業裡，價值甚至高於 CPU 與記憶體的節省。
另一個隱形收益是可觀測性的集中化。當遙測資料由節點層元件統一產生，Prometheus 的抓取目標數量大幅下降，監控後端的負擔減輕，跨服務的關聯分析也更容易實現。對於已經被監控成本困擾的團隊來說，這是一個常被忽略但實際感受強烈的改善。
五、導入 eBPF 服務網格的六個實務挑戰
5-1 核心版本與發行版相容性
eBPF 的能力高度依賴 Linux 核心版本。較新的功能（例如更完整的 BTF 支援、某些 socket 層掛鉤、網路命名空間的進階操作）通常需要 5.10 甚至 5.15 以上的核心。若企業仍在使用核心版本極舊的發行版，基本上無法享受完整的 eBPF 能力。
CO-RE（Compile Once – Run Everywhere）與 BTF（BPF Type Format）的普及，大幅改善了跨核心版本的可移植性，但這仍然是一道門檻。實務上，團隊在評估 eBPF 網格時，第一步通常是盤點節點的核心版本與發行版，並規劃節點升級或替換工作節點映像。這一步往往比技術導入本身更耗時，也更容易被低估。
5-2 L7 解析與加密流量的天花板
eBPF 在 L4 的表現無可挑剔，但在 L7 就沒有那麼萬能。要在核心層解析 HTTP/2、gRPC 或 TLS 之後的應用層協定，技術上極其複雜，而且容易隨協定演進而失效。因此目前主流做法都是「L4 交給 eBPF，L7 交給按需的使用者空間代理」——這正是 Istio Ambient 的 waypoint 與 Cilium 的 Envoy 存在的理由。
換句話說，Sidecarless 並不等於「完全不需要代理」，而是「代理從每個 Pod 一個，變成需要時才有一個」。團隊在評估時必須清楚這條界線，才不會對架構有錯誤期待，也不會在導入後才發現某些 L7 功能仍需額外部署。
5-3 除錯與可觀測性思維的轉變
在 Sidecar 模式下，工程師習慣用 kubectl exec 進入 Sidecar，查看 Envoy 的 admin endpoint、存取日誌與設定檔。切換到 eBPF 架構後，這些工具不再存在——流量從來沒有進入使用者空間，自然也沒有 Envoy 的日誌。取而代之的是用 bpftool 觀察 eBPF 程式與 map、用 Hubble 之類的工具檢視流量，以及依賴核心的追蹤點。
這代表團隊需要重新建立除錯手法，也需要重新設計可觀測性。這不是技術上做不到，而是需要時間與教育訓練。許多企業在試點階段遭遇的阻力，其實都來自這裡，而不是效能或穩定性問題。
5-4 與既有 CNI、安全與監控工具的相容性
eBPF 服務網格通常需要對網路堆疊有較深的控制權，因此在多 CNI 並存的環境會遇到限制，某些託管 Kubernetes 服務也會限制 CNI 的替換。此外，一些依賴 iptables 規則、依賴封包在節點間可見性的安全工具（IDS/IPS、網路流量分析），在 eBPF 架構下可能會「看不到」流量，需要重新調整部署方式或改用支援 eBPF 的方案。
5-5 人才與生態成熟度
熟悉 eBPF 的工程師相對稀缺，多數平台團隊習慣的是 Kubernetes 與 Envoy 的抽象層。當問題發生在核心層，除錯門檻明顯提高。這也是為什麼 2026 年雖然 Sidecarless 討論熱度極高，實際採用仍以中大型、有專職平台團隊的企業為主。對資源有限的小型團隊而言，等待託管服務成熟、或是採用漸進式方案，往往是更務實的選擇。
5-6 政策一致性與混合架構的治理
如果企業採取漸進式遷移（部分服務用 Sidecar，部分用 Ambient 或 eBPF），就會出現混合架構。此時政策如何一致地下發、身分如何在兩套資料平面之間互通、可觀測性資料如何統一，都是必須事先設計的題目。這不是阻礙，但需要在架構規劃階段就納入考量，否則很容易演變成兩套並行的治理體系，反而增加長期維運負擔。
六、企業落地路徑圖：從評估到全面替換的五個階段
階段一：現況盤點與效益試算
這個階段的重點不是安裝任何東西，而是把數字算清楚。團隊需要盤點：目前叢集的節點數與 Pod 數、每個 Sidecar 的實際資源佔用、服務呼叫的延遲分布、升級網格的頻率與成本。有了這些基線數據，才能估算切換到節點層架構後可能帶來的資源節省與維運改善。
同時要確認節點的核心版本與發行版，評估是否需要先升級節點映像。這一步常常是整個專案最容易被低估的前置工作。
階段二：單一命名空間試點
選擇一個流量可控、業務影響較低的命名空間作為試點，導入 Cilium 的網格功能或 Istio Ambient 模式。這一階段的重點是驗證三件事：功能覆蓋是否足夠、效能是否符合預期、除錯手段是否可行。
建議在試點階段就建立可重現的基準測試，記錄延遲、吞吐量、CPU 與記憶體的前後對比。這些數據會是後續推廣時最有力的說服材料。
階段三：建立混合治理與可觀測性
試點成功後，通常會進入混合架構階段——部分服務使用新資料平面，部分仍使用 Sidecar。此時必須確保政策可以一致下發、身分可以互通、遙測資料可以整合。Istio 的 Ambient 模式在這方面有先天優勢，因為它與 Sidecar 模式共用同一套控制平面；Cilium 則需要與既有的 Istio 或政策系統做好整合。
階段四：擴大導入與自動化
當混合治理的流程穩定後，可以按命名空間或服務批次擴大導入。這個階段的重點是自動化：把命名空間標記、waypoint 部署、政策綁定、驗證與回滾都納入 CI/CD 流程，避免每次遷移都依賴人工操作。
階段五：汰換 Sidecar 與標準化
最後階段是把剩餘的 Sidecar 汰換掉，並把新的資料平面架構寫入平台標準。這包括更新部署模板、調整監控與告警規則、修訂除錯手冊與教育訓練教材。架構轉換真正的完成點，不是技術元件上線，而是團隊的工作方式也跟著改變。
七、結語：輕量化不是選項，而是規模化的必然
回顧服務網格的發展，Sidecar 架構在過去數年確實解決了微服務治理的核心難題，也讓 mTLS、流量路由、可觀測性成為平台的基本能力。它的價值不該被否定，但它的成本模型——與 Pod 數量成正比——在規模化之後成了難以承受的負擔。
eBPF 的成熟提供了另一條路。它把治理邏輯從使用者空間帶進核心，讓 L4 的服務發現、負載平衡與安全策略可以在最短路徑上完成，並把資源成本從「每個 Pod」轉換成「每個節點」。2026 年 Cilium 與 Istio Ambient 的成熟，讓這條路從概念驗證走向生產可用。
當然，這不代表 Sidecar 會在一夜之間消失，也不代表 eBPF 是萬靈丹。L7 治理仍需使用者空間代理，核心版本與工具鏈仍是門檻，除錯與人才也需要時間累積。務實的做法是：先盤點自己的規模與成本結構，再選擇適合的遷移路徑，而不是因為趨勢而倉促替換。
對於正在規劃 2026 年平台架構的團隊來說，可以記住一個簡單的判斷原則：當你的 Pod 數量讓 Sidecar 的資源成本開始出現在預算會議上時，就是該認真評估 eBPF 服務網格的時候了。輕量化不是時尚，而是規模化之後的必然選擇。
常見問題（FAQ）
Q1：Sidecarless 之後，還需要 Envoy 嗎？
需要，但數量大幅減少。多數實作仍保留使用者空間代理來處理 L7 功能，只是它從「每個 Pod 一個」變成「按需部署、多個服務共用」。Istio Ambient 的 waypoint 與 Cilium 的 Envoy 整合都是這個思路。
Q2：既有 Istio 使用者該選 Sidecar 還是 Ambient？
如果目前 Sidecar 架構運作穩定、規模不大，沒有急迫理由全面切換；但可以從新命名空間或新服務開始採用 Ambient 模式，逐步累積經驗。Istio 支援兩種模式共存，這讓遷移可以是漸進的，而不必是斷崖式的。
Q3：eBPF 服務網格在自建機房可行嗎？
可行，前提是節點核心版本足夠新。自建機房的挑戰通常不在 eBPF 本身，而在於節點映像的升級週期較長、變更流程較複雜。建議先在部分節點上建立可升級的標準映像，再逐步推廣。
Q4：效能量測該看哪些指標？
至少要看四類：延遲（P50、P95、P99）、吞吐量（RPS）、資源使用（代理層的 CPU 與記憶體）、以及升級維運時間（變更頻率與人工工時）。只看延遲很容易忽略資源與維運層面的巨大差異。
Q5：如果團隊沒有 eBPF 經驗，該從哪裡開始？
建議從 Cilium 的文件與 Hubble 可觀測性工具入手，先在測試叢集觀察流量與政策行為，再逐步嘗試 L4 政策與 mTLS。把 eBPF 當成一個需要學習的新工具鏈，而不是黑盒子，會讓導入過程順利許多。
服務網格的演進還沒結束。2026 年我們看到的，是一個從「每個 Pod 一個代理」走向「核心層與共享元件協作」的轉折點。這個轉折不會一夕完成，但方向已經相當清楚：輕量、可觀測、易維運，將會是下一代服務網格的基本要求，而 eBPF 正是實現這些要求最關鍵的技術底座。
```