# **意圖驅動的宣告式自動化比較分析：Nephio 與 Kubernetes 動態資源分配的平行演進**
> 本文成果承蒙陽明交大「高等教育深耕計畫」113 學年度第 2 學期「職涯學習助學金－校外職訓」計畫支持
## **第一節：統一原則：從指令式命令到宣告式意圖**
在現代雲原生系統的複雜光譜中，一個根本性的轉變正在重新定義我們管理基礎設施和服務的方式。這個轉變的核心是從傳統的**指令式 (imperative)** 控制模型，轉向一個更為強大和抽象的**宣告式 (declarative)** 模型。
秀吉今仔日就是要帶大家來看這一趨勢的兩個前沿實例：專為電信網路功能 (Cloud-Native Network Functions, CNF) 設計的 Nephio 專案，以及 Kubernetes 內部的動態資源分配 (Dynamic Resource Allocation, DRA) 框架。您的理解完全正確：這兩者都代表了從指令式編程向宣告式編程的演進，實現了更高層次的抽象化。本文主要是要深入探討此一觀察，對這兩種技術的實現機制進行詳盡的比較分析。
### **典範轉移：從「如何做」到「是什麼」**
指令式與宣告式方法之間的根本區別，在於使用者與系統之間的溝通方式。
* **指令式模型**，如同傳統的腳本或程序化代碼，詳細描述了達成目標所需的**每一個步驟**。使用者必須明確指示「如何」執行一項任務，例如「首先，創建一個虛擬機；其次，安裝這個軟體包；接著，配置這個網路接口」。這種方法的缺點在於其脆弱性和對細節的依賴。任何環境的微小變化都可能導致腳本失敗，且擴展和維護這些詳細的指令集極其困難。
* **宣告式模型**，則是 Kubernetes 哲學的核心，它專注於描述系統的**最終狀態**。使用者只需宣告「什麼」是他們想要的最終結果，例如「我需要三個運行此映像的 Nginx 副本」。系統的控制迴圈（controllers）則負責持續監控當前狀態與期望狀態之間的差異，並自動採取必要行動來彌合這一差距。這種「主動協調 (active reconciliation)」的機制，使得系統具有自我修復能力和更高的韌性。
這一典範轉移在基礎設施管理領域體現為一個從「基礎設施即代碼 (Infrastructure-as-Code, IaC)」到「配置即資料 (Configuration-as-Data, CaD)」的演進光譜。
### **配置模型的演進光譜：從 IaC 到 CaD**
傳統的 IaC 工具，如 Terraform、Ansible 或 Pulumi，允許工程師使用高階語言（如 HCL、Python 或 TypeScript）以宣告式的方式來定義基礎設施的最終狀態。這比手動操作有著巨大的進步，其核心理念同樣是宣告式的。例如，Terraform 的狀態檔案（state file）本身就扮演了持久化「合約」的角色，記錄了基礎設施受管的狀態。
然而，傳統 IaC 實踐的挑戰在於**配置邏輯與配置數據的緊密耦合**。當配置需求變得極其複雜時（例如，管理橫跨數千站點、涉及數百萬參數的電信網路），IaC 經常退化為充滿條件判斷和複雜邏輯的範本（templates），例如 Helm charts。這種範本化方法在規模擴大時會迅速崩潰，導致「龐大且難以理解的參數列表」，使得持續協調和偵錯變得幾乎不可能。
與此相對，**配置即資料 (Configuration-as-Data, CaD)** 是一種更為嚴格的架構模式，它將配置視為**純粹的、結構化的、可序列化的資料**，通常遵循 Kubernetes 資源模型 (KRM) 的格式，並將其與操作這些資料的代碼完全分離。在這種模型中，YAML 或 JSON 檔案本身就是一個明確的、機器可讀的「事實」，而非執行邏輯的「指令」。所有用於解釋、轉換和協調這些資料的邏輯，都被封裝在外部的、獨立的控制器或 KRM 函式中。
### **為何此轉變對規模化與複雜性至關重要**
從以範本為中心的 IaC 實踐，到以資料為中心的 CaD 模式的轉變，是一種根本性的架構決策，直接影響到組織擴展其運營和團隊協作的能力。
在電信等大規模場景中，一個網路服務可能橫跨數千個站點，涉及數百萬個需要定義和管理的配置參數。試圖用單一的、包含複雜條件邏輯的範本來管理這種規模的系統是不切實際的。
CaD 通過將配置資料化和 API 化，徹底解決了這個問題。它將龐大的配置問題分解為更小的、可管理的、以資料為中心的單元。網路規劃、安全、計算基礎設施等不同團隊可以各自獨立地生成和管理標準化的 KRM 資料物件。這些物件隨後可以被自動化系統（如 Nephio 的控制器）以可組合、可預測的方式進行消費和組合。這種基於 GitOps 的 API 驅動流程，取代了手動協調，從而實現了可擴展的、去中心化的、自動化的協作。
本質上，向 CaD 的轉變是向建構一個「平台即 API (Platform as an API)」的模式邁進。在這個模式中，配置本身就是 API，為管理前所未有的複雜性和規模提供了堅實的基礎。Nephio 和 DRA 正是這一強大理念在不同領域的具體體現。
## **第二節：Nephio：雲原生網路功能的意圖驅動自動化**
Nephio 專案的誕生，是為了解決電信行業在向雲原生轉型過程中遇到的深刻而持久的挑戰。它不僅僅是一個工具，更是一種全新的自動化哲學，旨在將 Kubernetes 的宣告式能力從應用程式層擴展到整個網路服務和基礎設施堆疊。
### **電信自動化的挑戰：Nephio 的「為何」而生**
要理解 Nephio 的重要性，必須回顧網路功能虛擬化 (Network Functions Virtualization, NFV) 的歷史。從實體網路功能 (PNF) 到虛擬網路功能 (VNF) 的轉變，曾被寄予厚望，但現實卻充滿挑戰。
* **NFV 的遺留問題**：ETSI MANO 等早期標準框架主要是為虛擬機 (VM) 環境設計的，難以適應雲原生容器化網路功能 (CNF) 的動態特性。更重要的是，每個供應商都傾向於提供高度客製化的 VNF 包和管理工具，形成了所謂的「雪花 (snowflake)」式部署，導致嚴重的碎片化和整合困難。
* **「未被充分利用的雲」**：正如電信巨頭 TELUS 的案例研究所揭示的，僅僅將傳統的單體式 VNF 應用「平移」到雲上，會導致大部分雲價值（如彈性、韌性、API 驅動）未被利用。
* **失敗的自動化模式**：現有的自動化方案大多是「指令式的、發射後不管 (fire-and-forget)」的，極易產生「配置漂移 (configuration drift)」。此外，業界缺乏一個統一的自動化控制平面，導致自動化孤島。
為了解決這些根深蒂固的問題，Linux 基金會與 Google Cloud 聯合業界合作夥伴發起了 Nephio 專案。其核心使命是：
**建立一個以 Kubernetes 為統一控制平面的、開放的、意圖驅動的自動化框架**，從根本上簡化大規模、多廠商、多站點的網路服務部署和管理。
### **Nephio 意圖的實現機制：Nephio 的「如何」運作**
Nephio 通過一個精巧的、基於「配置即資料 (CaD)」原則的工具鏈，將高階的使用者意圖轉化為在目標集群上運行的具體配置。這個過程可以分解為幾個關鍵階段和核心組件。
#### **三層自動化堆疊**
Nephio 的自動化範疇覆蓋了三個相互關聯的層次，並為每一層都提供了基於 KRM 的一致性模型：
1. **雲基礎設施 (Cloud Infrastructure)**：自動化底層的計算、儲存和網路資源。
2. **工作負載（網路功能）資源 (Workload Resources)**：管理 CNF 的 Kubernetes 資源，如 Deployments、Services，以及 SR-IOV、HugePages 等特殊資源需求。
3. **工作負載（網路功能）配置 (Workload Configuration)**：管理 CNF 應用程式自身的配置。
#### **意圖 API 與資料模型**
使用者與 Nephio 系統的互動始於提交一個高階的自訂資源 (Custom Resource, CR)，這就是使用者意圖的宣告式表達。所有配置都被組織成結構化的、可版本化的 **kpt 套件 (packages)**，存儲在 Git 倉庫中，成為系統唯一的資料來源。
#### **驅動引擎：Porch 與 GitOps**
這個過程被稱為「渲染管線 (hydration pipeline)」：
1. **Porch — 套件協調器**：Porch 是 Nephio 的核心後端服務，一個 Kubernetes API 擴展，負責管理 kpt 套件的整個生命週期。它監聽 PackageVariant 資源。
2. **渲染與突變 (Mutation)**：Porch 控制器觸發渲染流程，通過 KRM 函式將通用的藍圖套件轉化為具體的部署套件。
3. **GitOps 交付**：渲染完成後，Porch 將部署套件提交至 Git 部署倉庫，GitOps 控制器（如 ConfigSync 或 FluxCD）自動同步並應用到目標集群。
#### **表格 1：Nephio 工具鏈 — 角色與職責**
| 組件 | 核心功能 | 在意圖工作流程中的角色 |
| :--- | :--- | :--- |
| **CRDs** | 定義高階意圖 API 的結構 | 捕獲觸發自動化管線的初始使用者意圖 |
| **KPT** | 將 Kubernetes 配置打包成可版本化、機器可操作的資料單元 | 為藍圖和部署實例提供「配置即資料」格式 |
| **Porch** | 伺服器端套件協調器 | 響應 PackageVariant 資源，執行渲染管線 |
| **KRM Functions** | 容器化的單一用途程式，用於轉換 KRM 資源 | Porch 管線中的「突變器」，執行詳細配置轉換 |
| **Gitea** | Git 伺服器，託管所有配置套件 | 承載藍圖倉庫（輸入）和部署倉庫（Porch 輸出） |
| **ConfigSync/FluxCD** | GitOps 控制器，將集群狀態與 Git 倉庫同步 | 最終執行者，將渲染後的套件應用到目標集群 |
### **操作 현실與採納挑戰**
儘管藍圖宏大，但任何成熟的技術評估都必須正視理論與實踐之間的差距。根據 Nephio R3 和 R4 的官方發布說明，當前版本存在以下顯著的局限性和已知問題：
| 局限性/已知問題 | 官方發布說明引述 | 對運維團隊的影響 |
| :--- | :--- | :--- |
| **手動網路配置** | "Provisioning of the VLAN interfaces on the nodes is currently performed manually." | 增加大規模部署時的運維開銷和人為錯誤風險，要求運維團隊維護獨立的 L2 網路自動化或手動流程。 |
| **有限的狀態反饋** | "Feedback of the workload deployments from the workload clusters to the management cluster is limited. You may need to connect directly to the workload cluster via kubectl to resolve any deployment issues." | 削弱了集中式管理和故障排查的能力，增加了問題定位的複雜性。 |
| **自動化管線的穩定性** | "Packages may take time to be approved... If they appear to have frozen, it may help to restart the Porch and the Nephio controllers..." | 表明核心工作流程可能存在穩定性問題，需要手動干預才能解決，這對追求全自動化運維構成了挑戰。 |
| **Git 供應商整合** | "Only Gitea works with automated cluster provisioning to create new repositories and join them to Nephio." | 對於已經標準化使用其他 Git 平台的企業而言，這是一個顯著的技術和流程整合障礙。 |
| **服務中斷風險** | "When the capacities of the UPF, SMF, and AMF NFs are changed, the free5GC operator on the workload cluster will instantiate a new POD... the pod will restart." | 對於需要高可用性的電信級服務而言，配置變更導致的服務重啟是不可接受的。 |
將這些現實挑戰納入分析，並非為了貶低 Nephio，而是為了提供一個更為全面和誠實的評估。這恰恰反映了專案正在攻堅的技術前沿領域。
## **第三節：動態資源分配 (DRA)：特殊硬體的意圖驅動控制**
與 Nephio 在宏觀層面重塑網路服務自動化相平行，Kubernetes 內部也在進行一場微觀層面的革命。動態資源分配 (Dynamic Resource Allocation, DRA) 的出現，標誌著 Kubernetes 對特殊硬體（如 GPU、FPGA、高性能網卡）的管理，也從初級的指令式模型演進為一個成熟的、意圖驅動的宣告式框架。
### **設備管理的挑戰：DRA 的「為何」而生**
在 DRA 出現之前，Kubernetes 使用設備插件框架 (Device Plugin Framework) 來管理特殊硬體。雖然這是一個重要的里程碑，但其設計過於簡單，很快就無法滿足日益複雜的需求。
* **設備插件框架的局限性**：核心機制是將特殊硬體作為整數計數器宣告給 Kubelet，例如 `nvidia.com/gpu`: 4。這種模型存在顯著的局限性：
* **缺乏參數化能力**：Pod 無法請求具有特定屬性（如記憶體大小、架構版本、MIG 配置）的 GPU。
* **無法精細化共享與切分**：Pod 要麼請求整個 GPU，要麼不請求，無法支持 GPU 切分實例。
* **安全風險**：插件通常需要高權限訪問設備檔案。
* **AI/ML 與 HPC 的驅動力**：隨著人工智慧、機器學習和高性能計算工作負載在 Kubernetes 上的普及，對更精細、更靈活的硬體管理需求變得空前迫切。DRA 正是為應對這些挑戰而設計。
### **DRA 意圖的實現機制：DRA 的「如何」運作**
DRA 的設計借鑒了 Kubernetes 的 `PersistentVolume` / `PersistentVolumeClaim` 模型，使其對熟悉 Kubernetes 的使用者非常直觀。
#### **意圖 API：ResourceClaim 與 API 版本演進**
在 DRA 模型中，Pod 在其 spec 中使用 resourceClaims 欄位來宣告資源需求。值得注意的是，DRA 的 API 正在快速演進。它最初在 v1.26 中以 alpha 特性引入，並在 v1.32 中晉升為 beta，當時使用的是 v1beta1 API。然而，為了簡化使用者體驗並為通用版本 (GA) 做準備，Kubernetes v1.33 引入了一個新的、經過改進的 **v1beta2** API。社群正積極推動使用者遷移到更新的版本。
> 配備結構化參數的動態資源分配 (DRA) 工具，預計在 2025 年 8 月發布的 v1.34 版本中達到穩定狀態。目前，該功能正處於設計與實現階段。[name=蔡秀吉]
以下是使用當前推薦的 v1beta2 API 的範例：
```yaml
# 正確的、基於 v1.33+ 的 DRA 範例
apiVersion: apps/v1
kind: Deployment
metadata:
name: dra-gpu-example
spec:
replicas: 1
selector:
matchLabels:
app: dra-gpu-example
template:
metadata:
labels:
app: dra-gpu-example
spec:
resourceClaims:
- name: gpu-claim
source:
resourceClaimTemplateName: gpu-claim-template
containers:
- name: my-container
image: nvidia/cuda:12.3.1-base-ubuntu22.04
command: ["nvidia-smi"]
resources:
claims:
- name: gpu-claim
---
# 使用 v1beta2 API 的 ResourceClaimTemplate
apiVersion: resource.k8s.io/v1beta2
kind: ResourceClaimTemplate
metadata:
name: gpu-claim-template
spec:
spec:
resourceClassName: gpu.nvidia.com
parametersRef:
apiGroup: gpu.dra.nvidia.com
kind: GpuClaimParameters
name: a100-mig-1g.5gb-parameters
```
#### **驅動引擎：調度器與 Kubelet 的精確分工**
DRA 的工作流程體現了 Kubernetes 將**集群級別的決策**與**節點級別的執行**嚴格分離的設計哲學。
1. **請求 (Request)**：使用者提交帶有 ResourceClaim 的 Pod，Pod 處於 Pending 狀態。
2. **調度 (Scheduling)**：此階段完全由 **kube-scheduler** 主導。它檢索所有 ResourceSlice 物件（由 DRA 驅動程式發布的可用硬體清單），根據 ResourceClaim 的要求過濾並評分節點。
3. **分配與綁定 (Allocation & Binding)**：kube-scheduler 選擇最優節點，在 ResourceClaim.status 中記錄分配結果，並將 Pod 綁定到該節點（設定 spec.nodeName）。
4. **準備 (Preparation)**：目標節點上的 **Kubelet** 介入。在啟動容器前，Kubelet 調用節點本地的 DRA 驅動程式的 gRPC 端點（如 NodePrepareResources）。
5. **注入 (Injection)**：DRA 驅動程式完成硬體配置，並將設備路徑、環境變數等資訊返回給 Kubelet，後者將其注入到容器中並啟動。
#### **表格 2：DRA API — 物件功能與互動**
| API 物件 | 類比 | 核心功能 | 在分配工作流程中的角色 |
| :--- | :--- | :--- | :--- |
| **DeviceClass** | StorageClass | 定義硬體類型及驅動程式 | ResourceClaim 引用，設定可分配資源類型參數 |
| **ResourceSlice** | PersistentVolume | 宣告節點上可用的具體設備 | kube-scheduler 篩選節點時提供庫存清單 |
| **ResourceClaim** | PersistentVolumeClaim | 描述對特定資源的請求 | kube-scheduler 嘗試滿足的請求物件 |
| **ResourceClaimTemplate** | — | 為每個 Pod 副本生成 ResourceClaim | 支持工作負載擴展時的動態分配 |
| **DRA Driver** | CSI Driver | 發現設備、創建 ResourceSlice、準備已分配設備 | 將 Kubernetes 與硬體設備橋接 |
## **第四節：進階比較分析：兩個宣告式系統的故事**
Nephio 和 DRA 雖應用領域和規模不同，但在宣告式自動化理念上高度一致。然而，深入到架構、運維和採納層面的權衡，則揭示了它們深刻的差異。
| 屬性 | Nephio | DRA (動態資源分配) |
| :--- | :--- | :--- |
| **主要目標** | 自動化多廠商網路服務及其底層基礎設施的端到端生命週期 | 為 Pod 提供靈活宣告式 API，請求並分配特殊硬體 |
| **操作範疇** | 宏觀：跨集群、跨雲、跨廠商的服務協調 | 微觀：單集群、單 Pod 的資源分配 |
| **API 穩定性與成熟度** | **演進中 (專案特定)**：API (CRDs) 由 Nephio 專案定義，相對穩定但與專案版本緊密耦合。 | **Beta 版，但 API 版本更迭迅速**：作為 Kubernetes 核心功能，其 API 版本（從 v1beta1 到 v1beta2）快速迭代，反映其仍在 beta 階段。 |
| **真理之源 (Source of Truth)** | **Git 倉庫**：以 kpt 套件形式存儲的 KRM 檔案是系統期望狀態的唯一真理之源。 | **Kubernetes API Server (etcd)**：所有 ResourceClaim, ResourceSlice 等物件的狀態都存儲在 etcd 中，是運行時的真理之源。 |
| **錯誤處理與可觀測性** | **反饋鏈路有限**：官方文檔承認從工作負載集群到管理集群的反饋有限，故障排查可能需要直接訪問邊緣節點。 | **原生 Kubernetes 機制**：分配失敗會體現在 Pod 事件中，ResourceClaim 的 status 欄位會報告分配結果。 |
| **採納複雜性 (工具鏈)** | **高**：需要部署和整合一個完整的 GitOps 工具鏈，包括 Porch, kpt, Git 伺服器, 和 GitOps 控制器。 | **中等**：需要在每個節點上安裝和配置對應的 DRA 驅動程式，驅動程式本身可能很複雜。 |
| **採納複雜性 (人員技能)** | **高**：要求團隊具備對電信網路、KRM、Kubernetes 控制器和 GitOps 哲學的深入理解。 | **高**：要求具備硬體驅動程式開發技能（通常是 Go 和 gRPC）、對特定硬體的深入了解，以及 Kubernetes 調度機制的知識。 |
| **主要故障域** | **配置渲染管線**：Porch 中的 KRM 函式執行失敗、Git 倉庫連接問題、GitOps 同步延遲或失敗。 | **資源調度與分配**：集群中沒有滿足條件的可用節點、DRA 驅動程式的 bug、硬體本身故障或配置錯誤。 |
## **第五節：綜合與未來展望：統一的宣告式堆疊**
Nephio 和 DRA 代表了雲原生自動化從宏觀到微觀的平行演進。它們可在一個統一的宣告式堆疊中互補協作，構建從業務意圖到底層硬體資源的完整鏈條。
### **生成式 AI 的催化作用**
關於生成式 AI (Generative AI) 的未來展望，已從概念性猜想，發展為有據可依的探索路徑。Linux 基金會發布的白皮書《Nephio and GenAI: Revolutionizing Cloud Native Network Automation》以及 TELUS 等行業領導者的概念驗證 (PoC)，都展示了其巨大潛力。
Nephio 的「配置即資料」(CaD) 模型與 GenAI 的能力形成了完美的協同效應。大型語言模型 (LLM) 的核心優勢之一就是生成結構化的文本，而 KRM 正是這樣一種高度結構化的資料格式。具體的應用場景包括：
* **AI 輔助的配置生成**：利用 LLM 從高階需求（甚至是自然語言描述）直接生成結構化的 KRM YAML 檔案，極大地降低了編寫複雜 KRM 的門檻。
* **Nephio AI 助手**：通過對話式交互來查詢系統狀態、觸發複雜的工作流程，甚至進行故障排查。
* **從遺留配置遷移**：利用 GenAI 分析傳統的、非 KRM 格式的配置文件，並將其自動轉換為 Nephio 可以理解的 KRM 套件。
### **端到端協同場景展望**
一個詳盡的端到端場景能最好地說明 Nephio 與 DRA 的協同價值：
1. **高階意圖的表達**：一位網路架構師通過一個 GenAI 驅動的「Nephio AI 助手」界面，輸入一個高階業務需求：「**在法蘭克福和阿什本的邊緣站點部署一個高吞吐量的 5G UPF 服務。該服務需要具備 SR-IOV 加速的網路介面，每個實例需分配 2 個虛擬功能 (VF)。**」
2. **Nephio 的宏觀編排**：
* AI 助手理解此意圖，並自動生成一個高階的 Nephio UPFDeployment 自訂資源 (CR)。
* Nephio 的控制器監聽到這個 CR，觸發其核心的自動化工作流程。
3. **配置渲染與 DRA 範本的生成**：
* 在 Porch 的渲染管線中，一個 KRM 函式被觸發。它不僅生成 UPF 相關的 Deployment、Service 等資源，更關鍵的是，它會根據意圖中對 SR-IOV 的要求，**動態生成一個 `resource.k8s.io/v1beta2` 版本的 `ResourceClaimTemplate`**。
* 這個 ResourceClaimTemplate 將被精確地配置為請求 SR-IOV 資源，並在參數中指定需要 2 個 VF。
4. **GitOps 的交付**：
* Porch 將包含所有必要 KRM 資源（包括 CNF 的 Deployment 和 DRA 的 `ResourceClaimTemplate`）的完整 kpt 部署套件，提交到對應站點的 Git 部署倉庫中。
* 各站點的 GitOps 控制器將這些 KRM 資源應用到本地集群。
5. **DRA 的微觀分配**：
* 在工作負載集群中，UPF 的 Pod 被創建，並引用了 ResourceClaimTemplate。
* kube-scheduler 接管，查找節點上由 SR-IOV DRA 驅動程式發布的 `ResourceSlice`，尋找一個既有足夠 CPU/Memory，又有可用 VF 的節點。
* 一旦找到合適的節點，調度器便將 2 個 VF 分配給該 Pod 的 `ResourceClaim`，並將 Pod 綁定到該節點。
* 最後，節點上的 Kubelet 調用 SR-IOV DRA 驅動程式，完成 VF 的準備工作，並將其網路設備資訊注入到 UPF 容器中。
這個場景完美地展示了 Nephio 和 DRA 如何在一個統一的宣告式堆疊中協同工作：Nephio 負責**宏觀的服務級編排**（定義「是什麼」服務及其依賴），而 DRA 則負責**微觀的資源級實現**（滿足這些依賴所需的具體硬體）。隨著這兩項技術的成熟和 GenAI 的融入，一個真正端到端的、從自然語言意圖到底層硬體執行的自動化未來正變得觸手可及。
:::spoiler **相關資料來源**
1. Complex Made Clear \- “The Network Complexity Crisis (2/3): How Open Source Is Redefining Telco Automation \- Vamsi Talks Tech， [https://www.vamsitalkstech.com/networking/complex-made-clear-the-network-complexity-crisis-2-3-how-open-source-is-redefining-telco-automation/](https://www.vamsitalkstech.com/networking/complex-made-clear-the-network-complexity-crisis-2-3-how-open-source-is-redefining-telco-automation/)
2. About Nephio， [https://r3.docs.nephio.org/docs/](https://r3.docs.nephio.org/docs/)
3. How to schedule workloads in Kubernetes \- Devtron， [https://devtron.ai/blog/how-to-schedule-workloads-in-kubernetes/](https://devtron.ai/blog/how-to-schedule-workloads-in-kubernetes/)
4. Breaking Barriers and Driving Innovation: A Conversation with Sana Tariq, Ph.D., Principal Architect at TELUS \- National Engineering Month， [https://nemontario.ca/2025/03/27/breaking-barriers-and-driving-innovation-a-conversation-with-sana-tariq-ph-d-principal-architect-at-telus/](https://nemontario.ca/2025/03/27/breaking-barriers-and-driving-innovation-a-conversation-with-sana-tariq-ph-d-principal-architect-at-telus/)
5. About – Nephio， [https://nephio.org/about/](https://nephio.org/about/)
6. Dynamic Resource Allocation in Kubernetes \- Blog by Saifeddine Rajhi， [https://seifrajhi.github.io/blog/k8s-dynamic-resource-allocation-dra/](https://seifrajhi.github.io/blog/k8s-dynamic-resource-allocation-dra/)
7. How CSPs Can Leverage Nephio to Integrate Telco Standards and Cloud Native Automation Principles Through Open Source， [https://nephio.org/wp-content/uploads/sites/6/2023/07/Nephio-Telus-CaseStudy-v4.pdf?hsCtaTracking=9dfabe15-a71f-43ed-a47a-4973f8489356%7C4d50251e-b3d3-416a-b9cc-538357f59c7d](https://nephio.org/wp-content/uploads/sites/6/2023/07/Nephio-Telus-CaseStudy-v4.pdf?hsCtaTracking=9dfabe15-a71f-43ed-a47a-4973f8489356%7C4d50251e-b3d3-416a-b9cc-538357f59c7d)
8. About Nephio \- Nephio Documentation， [https://docs.nephio.org/docs/](https://docs.nephio.org/docs/)
9. Install and use Porch \- Nephio Documentation， [https://docs.nephio.org/docs/porch/user-guides/install-and-using-porch/](https://docs.nephio.org/docs/porch/user-guides/install-and-using-porch/)
10. Infrastructure as Code (IaC) vs. Traditional Infrastructure Management \- AutoMQ， [https://www.automq.com/blog/infrastructure-as-code-iac-vs-traditional-infrastructure-management](https://www.automq.com/blog/infrastructure-as-code-iac-vs-traditional-infrastructure-management)
11. Porch documentation \- Nephio Documentation， [https://docs.nephio.org/docs/porch/](https://docs.nephio.org/docs/porch/)
12. An Intent-Driven Configuration and Deployment Automation for 5G Mobile Networks: GitOps and LLM Centric Approach， [https://conf.kics.or.kr/2024f/media?key=site/2024f/abs/0011-QZUMN.pdf](https://conf.kics.or.kr/2024f/media?key=site/2024f/abs/0011-QZUMN.pdf)
13. \[2504.13589\] Towards End-to-End Network Intent Management with Large Language Models \- arXiv， [http://www.arxiv.org/abs/2504.13589](http://www.arxiv.org/abs/2504.13589)
14. Kubernetes v1.33: New features in DRA， [https://kubernetes.io/blog/2025/05/01/kubernetes-v1-33-dra-updates/](https://kubernetes.io/blog/2025/05/01/kubernetes-v1-33-dra-updates/)
15. DRA API: remove v1beta1 support · Issue \#132275 \- GitHub， [https://github.com/kubernetes/kubernetes/issues/132275](https://github.com/kubernetes/kubernetes/issues/132275)
16. Nephio Release 2: Accelerating Cloud Native Network Automation， [https://nephio.org/nephio-release-2-accelerating-cloud-native-network-automation/](https://nephio.org/nephio-release-2-accelerating-cloud-native-network-automation/)
17. Dynamic Resource Allocation | Kubernetes， [https://v1-32.docs.kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/](https://v1-32.docs.kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/)
18. Nephio R4 Release Notes | Nephio Documentation， [https://docs.nephio.org/docs/release-notes/r4/](https://docs.nephio.org/docs/release-notes/r4/)
19. DRA: Resource Claim Status with possible standardized network interface data · Issue \#4817 · kubernetes/enhancements \- GitHub， [https://github.com/kubernetes/enhancements/issues/4817](https://github.com/kubernetes/enhancements/issues/4817)
20. Dynamic Resource Allocation (DRA) in Kubernetes: Transforming AI Workloads \- Adyog， [https://blog.adyog.com/2025/01/15/dynamic-resource-allocation-dra-in-kubernetes-transforming-ai-workloads/](https://blog.adyog.com/2025/01/15/dynamic-resource-allocation-dra-in-kubernetes-transforming-ai-workloads/)
21. What's new for scheduling, scalability, and performance in Kubernetes v1.33? \- Datadog， [https://www.datadoghq.com/blog/kubernetes-release-april-2025/](https://www.datadoghq.com/blog/kubernetes-release-april-2025/)
22. Dynamic Resource Allocation \- Kubernetes， [https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/](https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/)
23. Nephio and GenAI: Revolutionizing Cloud Native Network Automation \- Linux Foundation， [https://project.linuxfoundation.org/hubfs/LF%20Networking/LFN\_Nephio\_GenAI\_Whitepaper-REV-1.pdf?\_\_hstc=187396151.1732c1e41076eedf08ea09bcf8f7adcf.1721675705132.1740794677454.1743018730926.15&\_\_hssc=187396151.2.1743018730926&\_\_hsfp=971786542](https://project.linuxfoundation.org/hubfs/LF%20Networking/LFN_Nephio_GenAI_Whitepaper-REV-1.pdf?__hstc=187396151.1732c1e41076eedf08ea09bcf8f7adcf.1721675705132.1740794677454.1743018730926.15&__hssc=187396151.2.1743018730926&__hsfp=971786542)
24. DRA: structured parameters: network-attached resource · Issue \#124042 \- GitHub， [https://github.com/kubernetes/kubernetes/issues/124042](https://github.com/kubernetes/kubernetes/issues/124042)
:::
Sign in with Wallet
Connect another wallet