當 Kubernetes Networking 遇上電信：從 Multi-Network 到 DRA，KubeCon Europe 2026 這場 Panel 真正在吵什麼？

Kubecon RU 2026 Cloud-native Teleco Day — Plane talk

這篇不是單純的 session 筆記，而是我根據現場聽講、逐字稿校訂、會後討論整理之後，對這場 Kubernetes Networking: Present and Future 的一次系統性回顧。 如果要先講一句結論，那就是：Kubernetes networking 真正最麻煩的地方，從來都不是「多接一張網卡」而已，而是你一旦想把多網路（multi-networking）做成真正原生（native）能力，整個 Kubernetes 平台的假設就會一層一層跑出來找你算帳。

前言：這場 panel 為什麼值得聽？

老實說，很多人一看到 Kubernetes networking，腦中先浮出來的還是 Service、Ingress、Gateway API，頂多再加個 CNI。

但這場 panel 有趣的地方在於，它不是在講那種「雲上應用程式入口流量怎麼轉」的老題目，而是直接把問題往下挖到 low-level networking：

• 多網路（Multi-networking）
• secondary interface / secondary network
• DRA（Dynamic Resource Allocation，動態資源配置）
• NIC / PCI / NUMA 親和性
• topology-aware routing
• 以及最重要的：電信（telco）跟 AI/ML 為什麼突然在這件事上變成同一國的

這也是我覺得這場很值得記的原因。因為它不是在賣新概念，而是在處理一個很現實的問題：

Kubernetes 到底能不能把電信 workload 真正當成一等公民（first-class citizen）來處理？

而答案嘛……不是不行，但也絕對不是 PPT 一翻開就自動成功。

一、這場的核心主張：telco 跟 AI/ML 的共同語言，其實是 network interface

這場 panel 裡面我覺得最關鍵的一句話，幾乎可以當整場的主軸：

The network interface is the common theme for AI/ML and for telco.

這句話乍看平平無奇，但其實非常重要。

因為過去大家常常把 telco 跟 AI/ML 當成兩個不同世界：

• telco 在意的是 deterministic、jitter、bandwidth、placement、NUMA locality、PCI affinity、可預測性。
• AI/ML 在意的是 GPU、high throughput、device scheduling、resource topology、data path。

表面上看起來像兩組人在講不同語言，但這場 panel 提醒了一件事：當你把視角放到 network interface 這一層，兩邊其實在吵的是同一類問題。

因為不管你今天是 5G core、vRAN、user plane，還是 inference workload、accelerator-aware scheduling，你最後都會碰到這幾件事：

1. 這個 workload 需要某一種特定網路介面或裝置。
2. 這個裝置只存在於特定節點。
3. 它最好跟 CPU / memory / PCI device 落在對的位置。
4. 你不能只「排進去」就算了，還要顧到 self-healing、bandwidth、jitter，甚至 runtime 層的行為。

講白一點，電信跟 AI/ML 在這件事上的共同命運，就是大家都開始意識到：網路介面不是背景音樂，它本身就是資源（resource），甚至是裝置（device）。

而一旦你接受這個前提，DRA 出場就很合理了。

二、DRA 為什麼會突然變成 networking 的熱門字？

很多人對 DRA 的第一印象，還停留在：

啊，不就是給 GPU、FPGA、或某些 device resource 用的嗎？

但這場 panel 很清楚地指出來：network interface 也是 device。

這個轉折很關鍵。

因為一旦 network interface 被視為 device，你就不再只是用傳統「先有網路，再把 Pod 接上去」的心態看它，而是會開始思考：

• 它要怎麼被宣告（claim）？
• 誰來分配？
• scheduler 要不要知道？
• 它的 topology / locality 要怎麼進入決策？
• 它跟 container runtime、kubelet、driver 的關係怎麼串？

換句話說，DRA 在這裡之所以重要，不是因為它 magically 解決一切，而是因為它提供了一個比較像樣的基礎：

至少你終於可以不再把網路介面當成神祕的 Pod annotation + CNI 黑盒魔法，而是把它拉回 Kubernetes 資源管理的語境裡。

這件事對 telco 特別重要。

因為 telco 的世界本來就不是「有網路就好」，而是：

• 你要哪張 NIC
• 它在哪個 NUMA node
• 跟哪個 PCI root complex 靠得近
• bandwidth / latency / jitter 能不能守住
• routing、policy、DNS、service discovery 會不會在你切到 secondary network 後一起炸開

所以我會把這場 panel 對 DRA 的態度，總結成一句比較務實的話：

DRA 不是萬靈丹，但它至少不是拿膠帶把一切黏在 annotation 上。

這個差很多。

三、但也不要高興太早：DRA 不是終點，它頂多是第一步

這場裡面我很喜歡的一點是，講者沒有在那邊把 DRA 吹成一個「從此天下太平」的救世主。

相反地，他們其實講得很老實：DRA 是第一步，不是完整終局。

為什麼？

因為 Kubernetes multi-networking 真正難的地方，根本不只是在「拿到 interface」這件事。

你今天若只是要做到：

• 特定工作負載拿到特定 interface
• 排到有這種資源的節點
• 基本的資源宣告與分配

那 DRA 的確開始有戲。

但一旦你再往前走一步，想問下面這些問題，事情就立刻從「技術工程」變成「平台哲學 + 歷史包袱 + 相依爆炸」：

• secondary network 上的 Service 要怎麼原生化？
• DNS 要用哪個？
• resolv.conf 怎麼辦？
• NetworkPolicy 怎麼表示？
• load balancing 誰負責？
• Service discovery 還是不是沿用原本那套？
• kube-apiserver 的 Service 存取假設，會不會直接讓 Pod crash loop？

這也是這場 panel 最值得細嚼的一個提醒：

multi-networking 從來不是「多插一張網卡」這麼簡單，而是「你有沒有能力重想 Kubernetes 對 networking 的整體預設」。

這裡如果太樂觀，就很容易重蹈某些大而全平台的老路：

一開始覺得自己只是在補一個缺口，後來發現自己其實在重造半個平台宇宙。

嗯，這種劇本，電信界應該都不陌生。懂的都懂。

四、為什麼 multi-networking 這麼難？因為真正麻煩的是標準化，不是功能本身

這場 panel 還有一個很重要的觀點：multi-networking 最大的痛點，不是需求不存在，而是太難標準化。

這句話我覺得要劃重點。

因為今天在 ecosystem 裡面，不是沒有人把東西做出來。相反地，大家都做得出某種能跑的版本：

• Multus 可以跑
• 各家 CNI 可以跑
• Cilium 有它的做法
• OVN-Kubernetes 有它的做法
• 不同 vendor / cloud provider 也各有招式

所以問題從來都不是「做不做得出來」，而是：

你要怎麼把這些東西收斂成 core Kubernetes 裡可以攜帶、可以維護、可以移植（portable）、可以一致化（conformant）的東西？

這就是 hardest part。

講者在 panel 裡面給的方向，我覺得非常務實：

與其 top-down 直接定義整個多網路宇宙，不如 bottom-up 先把 interface 標準化

也就是說，不要一開始就想把每一家都不同的 network model、IPAM、service model、route model 一口氣收編。

因為那個做法太容易變成雲端封建時代下另一種 Kubernetes 版大一統幻想。

比較合理的方式是：

1. 先把 network interface 這個最低共識抽象清楚。
2. 讓它能進 scheduler、resource allocation、driver lifecycle。
3. 再逐步討論要不要長出更高階的 Service / Policy / DNS / Discovery 能力。

這個思路看似保守，但其實更有機會活下來。

因為它不是假裝所有人都已經同意世界觀，而是先抓住共通的最小交集。

而這種做法，我個人是買單的。

五、Multus 會不會被 DRA 取代？答案是：短期內別想太美

現場有一段我覺得超誠實，甚至有點好笑。

講者直接問大家：

• 現在還在 production 用 Multus 的有多少？
• 想立刻完全被 DRA 取代的有多少？

答案很現實：大家還是在用 Multus。

這點其實很重要。

因為有時候社群一冒出新機制，大家很容易進入一種「新的一定比較對」的集體催眠。

但實務世界沒有那麼浪漫。

如果今天某一套東西雖然不完美、雖然有 pain point、雖然 sometimes 很阿雜，但它在 production 能跑、團隊也知道怎麼維護，那你就不可能只因為新的 API 比較漂亮，就明天全部翻船重來。

這也是 panel 對 migration path 最誠實的地方：

目前沒有一條對所有人都優雅、都低痛、都通用的 Multus → DRA 遷移路徑。

而且這種事情，本來就不可能靠少數 maintainers 在台上靈光一閃就解完。

它需要的是：

• 社群真的把 use case 拿出來
• 明確說 pain point 是什麼
• 哪些東西可以 tooling 化
• 哪些東西其實不值得抽象化

所以如果有人期待 DRA 一出來，Multus 明天就被掃進歷史灰燼，我只能說這種想法有點太香蕉芭樂了。

現實世界比較像是：

就這場逐字稿與現場互動來看，短期內看不出 Multus 會被立刻取代；DRA 則更像是持續演進中的方向，而不是已經收斂完成的答案。

六、會後討論才是真正的重頭戲：從 abstract API，走到 kubelet / CRI / NRI / CDI 的泥巴地

如果說 panel 本身是在畫戰略地圖，那會後討論就是大家把鞋子踩進泥巴裡，開始講「到底怎麼接」。

而這段對我來說超有價值，因為它直接讓抽象議題落到 runtime integration 的真問題上。

1. Required plugin 問題：我不是想 hack，我是想原生地告訴 kubelet「先等這個 plugin」

會後一開始就有人丟出一個很實務的需求：

他不是不能用 annotation，不是不能寫 webhook，也不是不能 out-of-band 硬搞；

而是他很清楚知道，如果 required plugin 的依賴關係沒有被 kubelet / runtime 原生理解，你最後得到的就不是設計，而是一堆 race condition。

這段討論把幾個關鍵名詞串得很清楚：

• CDI（Container Device Interface）
• CRI（Container Runtime Interface）
• NRI（Node Resource Interface）
• DRA driver
• kubelet

問題本質其實很簡單：

當 DRA driver 知道某個 required plugin 必須先到位時，Kubernetes 執行鏈能不能原生表達「先不要往下跑」？

這件事若沒有處理好，就會變成：

• driver 以為自己宣告了需求
• runtime 以為可以先啟動
• kubelet 以為只是一般資源分配
• 最後 Pod 開起來，但 network / plugin 還沒 ready
• 然後你開始 debug 地獄

這種問題最可怕的地方就是：它不是一定會炸，它是偶爾炸；而偶爾炸最難抓。

尤其在大規模節點環境下，race 不是 bug，race 是精神汙染。

2. ResourceClaimTemplate + opaque configuration：看似只是 template，實際上是在吵「API server 能不能早點懂」

另一段很精彩的，是針對 ResourceClaimTemplate、opaque configuration、Go template、device attributes 的討論。

這裡的痛點很經典：

• 你想在 claim 裡帶配置。
• 但配置裡又需要引用裝置分配後才知道的 attributes。
• 因此你只能先塞 template。
• 然後由 driver 去 render。
• 再想辦法在 runtime 前驗證。

這種設計不是不能用，但它的味道就很明顯：

就這段討論呈現，這層語意目前主要仍落在 driver 與 opaque configuration 那一側，而不是由 Kubernetes API server 直接理解。

也難怪現場會直接問：

• 能不能讓 API server 更早理解？
• validation 能不能往前提？
• CEL 能不能幫忙？
• 未來會不會有相關 KEP？

這種問題非常值得注意。因為它反映的是另一個更大的主題：

當 DRA 從「分配裝置」走向「描述裝置與配置之間的關係」時，Kubernetes API 的表達力到底夠不夠？

這不是小事。

因為如果每個 driver 最後都要自己發明一整套 template + validation + rendering dance，那久了之後，你得到的不會是統一生態，而是 driver-based 小王國聯盟。

電信人應該很熟這種感覺：表面上叫做標準，實際上每家都各自解讀。

七、DRANET 透露出來的訊息：不要做 uber driver，讓 driver 回到各自場景的邊界

會後還有一段我覺得很值得記：針對 DRANET 與 custom driver 的討論。

這裡有個非常務實的觀點：

不要把所有 networking use case 都塞進一個 uber driver。

這句話我非常同意。

因為 networking 尤其是 telco networking，天生就有很多環境特異性（environment-specific workflows）：

• 你的 cloud provider 不同
• route table 不同
• IPAM 模型不同
• interface setup 流程不同
• security / policy 假設不同
• 甚至你是不是跑在 AWS VPC 裡，都直接改變架構選擇

如果這時候還幻想搞出一個「超級萬能 driver」，最後大概率只會把 scope 越做越胖，然後一路長成另一個不好維護的怪物。

所以這裡的哲學其實跟前面 panel 的整體方向完全一致：

• 抓共同最小核心
• 保留 driver 的可擴展性
• 讓人能自己做 driver
• 能共用 repo / community benefit 就共用
• 但不要硬把所有 use case 壓成同一個模子

這種思維其實就是我一直很在意的那種「不要過度理想化系統設計」的態度。

你可以追求標準，但你不能假設世界本來就很整齊。

八、kernel 還是 eBPF？這場給的答案很務實：先活著，再優雅

另一段很有意思的，是有人問到某些實作細節到底是走 kernel 還是 eBPF。

Antonio 的回答很有味道，也很務實：偏向用 kernel，因為更 portable。

這個答案我其實滿欣賞的。

因為近年 eBPF 很容易被講成某種萬能神兵，彷彿只要你不用 eBPF，就代表你不夠 modern、不夠 cloud native、不夠酷。

但工程不是 cosplay。

真正的問題永遠還是：

• 你維護得起來嗎？
• 你搬平台時會不會壞？
• 你的收益真的大於成本嗎？

如果某個最佳化可以換到一點 performance，但代價是維護噩夢、跨平台破碎、debug 成本上升，那它就不一定真的是「最佳」。

這點對 telco 特別重要。

因為 telco 不是 demo-driven engineering。你今天不是為了在一張 benchmark 圖上多贏 8%，而是為了讓系統長期可運作、可維護、可落地。

講白一點：

先活著，再優雅；先可攜，再極限。

這句其實滿適合拿來當整場會後討論的副標。

九、我從這場學到的真正重點：Kubernetes networking 的未來，不是 API 越多越厲害，而是 abstraction 要收得夠準

如果要把這整個 session + 會後討論壓成一個核心觀察，我會這樣寫：

1. 真正的共同抽象不是「多網路」三個字，而是 network interface as a schedulable, configurable, portable resource

也就是說，與其把 multi-networking 當成一個很大的口號，不如先承認：

• 我們最先有機會做對的，是 interface 層。
• 我們最容易做壞的，是過早把整套 service model、DNS、policy universe 一次包下來。

2. DRA 的價值在於把網路從「附掛」拉回「資源治理」

這件事很重要。因為 Kubernetes 過去對這類需求，很多時候都比較像是：

• 有需求的人自己加 annotation
• 自己接 external plugin
• 自己搞 admission webhook
• 自己確保 runtime timing
• 自己收拾 race condition

這種方式不是不能活，但很難規模化，也很難讓社群形成真正一致的語意。

3. 真正卡住原生化的，是平台深層假設

像是：

• Service discovery
• kube-apiserver Service 存取
• ServiceAccount token
• DNS / resolv.conf
• routing
• NetworkPolicy
• protocol support

這些不是補一個 CRD 就會自然消失的問題。

4. 對 telco 來說，這場最重要的訊息不是「某個 feature 要來了」，而是「你該怎麼參與定義它」

這場 panel 跟會後最反覆傳達的，不是「我們已經全部做好了」，而是：

• 把 use case 拿出來
• 把 pain point 講清楚
• 把 issue 開出來
• 不要只抱怨 abstraction 不夠，還要提供你需要的語意邊界

這點我很認同。

因為標準不是神諭，標準通常是社群把一堆痛點揉久了，最後才磨出來的最大公約數。

十、回到 Nephio / O-RAN / cloud-native telco，我的幾個延伸思考

這裡開始就是我自己的 mur mur 了。這一節屬於作者延伸推論，不是 panel 講者的原話。

我會覺得這場不只是 Kubernetes networking 的 panel，它其實也很適合拿來回頭照 Nephio、O-RAN、甚至 cloud-native telco 整體架構。

第一，telco 想要的從來不只是「能部署」，而是「能以正確資源拓撲部署」

這句話很重要。

因為很多人談雲原生電信時，常常太快把焦點放在：

• Helm chart 有沒有包好
• GitOps 流程順不順
• operator 能不能把 Pod 拉起來

但對真正吃效能、吃時延、吃 topology 的 telco workload 而言，拉起來只是起點，不是答案。

真正的問題是：

• 拉在哪？
• 靠近誰？
• 綁哪張卡？
• 走哪條路？
• 控制面與資料面怎麼分？
• secondary network、service model、policy 能不能跟著對上？

這正是這場在提醒的。

第二，平台越往底層走，越不能用「畫大餅整合一切」的方式設計

這也是我一直覺得 Nephio 很需要警惕的地方。

如果今天你在 interface、driver、runtime、scheduler、service、policy、IPAM 都還沒收斂共識，就急著想把所有 use case 一次打包成一套宏大框架，那最後很可能會重演某些歷史上很熟悉的劇情。

簡單講就是：

不要太早長成另一個難以駕馭的總指揮中心。

第三，observability 跟 feedback loop 仍然是最後的保命符

這點雖然不是這場唯一焦點，但我覺得可以跟我以前寫 Nephio / AI 的觀察接起來。

因為當系統進入這種：

• DRA driver
• kubelet
• CRI / NRI / CDI
• 多網路
• DNS / routing / policy
• driver-specific workflow

全部纏在一起的狀態時，如果沒有足夠 observability，你根本不知道你是在設計系統，還是在養一個會偶爾發瘋的黑盒子。

而這在 telco 場景特別危險。

因為 telco 系統不是出錯了再慢慢猜就好，有些時候它就是直接影響整個業務路徑。

結語：Kubernetes networking 的未來，不是更炫，而是更誠實

說了這麼多，我自己對這場最終的感想反而很簡單：

Kubernetes networking 的未來，未必是 API 越長越華麗、功能越包越多，而是大家終於比較誠實地面對：哪些東西能共通、哪些東西不該硬統一、哪些抽象值得進 core、哪些該留在 ecosystem。

這種誠實，其實比任何華麗 roadmap 都重要。

因為對電信來說，最怕的從來不是功能還沒來，而是大家明明還沒收斂，卻先把話講得太滿。

而這場 panel + 會後討論最有價值的地方，就在於它沒有跟你畫那種「明年就全部原生支援」的虎爛大餅。

它反而很明白地說：

• DRA 很重要，但不是全部。
• Multi-networking 很需要，但很難原生化。
• Multus 仍然會活一段時間。
• Service / DNS / Policy / protocol 這些才是真正的大魔王。
• 如果你有 use case，不要只當旁觀者，請把它帶進社群。

這樣的討論，我認為才是真正有機會把事情做成的討論。

最後秀吉純 mur： 雲原生世界有時候很愛把 abstraction 講得很夢幻，彷彿你只要命名得夠漂亮，系統就會自動變優雅。但 networking 尤其是 telco networking，不太吃這一套。你少想清楚一層依賴，未來就多一層 debug 地獄。

所以這場最值得帶走的，也許不是某一個 feature 名字，而是一種態度： 先抓準共同核心，再往上長；先把可攜性與可維護性顧住，再談萬能抽象。

如果 Kubernetes networking 真的能往這個方向前進，那它對 telco 才不只是「看起來很有希望」，而是真的有機會變成能落地、能維護、能長期演進的基礎能力。讓我們繼續看下去。