雲原生運算基金會（CNCF）於 2026 年 11 月 5 日發文，宣布 kpt 工具鏈正式發布 v1.0.0[1]。這個專案在預覽（pre-release）狀態停留多年，社群在過去十二個月集中穩定 API、棄用未使用的功能，並把 Porch（Package ORCHestration）服務重新納入 kpt 組織，令整條工具鏈置於同一治理架構之下。CNCF 形容，這代表 kpt 已準備好被廣泛採用。
以組態即資料為本
kpt 針對 Kubernetes 應用程式的組態套件管理，核心原則是「組態即資料」（config as data）[1]。所有內容以 KRM 資源表達，開發者可以宣告式地操作與驗證組態，再由 kpt 把通用 KRM 轉換成針對特定站點或應用程式的可部署模型。官方強調，這種做法可以重現資源操作過程，不受範本（templating）語言限制，同一套件能在不同環境重複渲染，不必為每個站點維護一堆範本檔案。工具鏈亦提供描述操作與驗證步驟的框架，讓組態改動本身可以版本化及審核，減少人手比對 YAML 的需要。
Porch 回歸與規模化編排
單機使用的 kpt 提供輕量的組態套件管理，Porch 則負責大規模編排，支援零接觸（zero-touch）的 GitOps 流程[1]。Porch 原本獨立發展，現已重新整合回 kpt 組織，社群認為在統一治理下，kpt 才稱得上完整的 GitOps 套件管理系統。官方指出，這套組合的模組化程度足以嵌入任何既有工作流程，從小型團隊的單一叢集，到大型企業跨多個站點的部署，都可以用同一套套件定義處理，而編排步驟本身亦以 KRM 描述，與應用程式組態採用同一套語言。
升級與採用建議
踏入 1.0 之後，kpt 所有元件都被官方認定為穩定，API 進入承諾期，專案表明日後的變更會盡量保持向後兼容[1]。仍在 pre-1.0 版本的用戶，應先按官方遷移指引更新 CLI 與套件格式，並檢查是否有依賴已被棄用的功能，特別是自行包裝過 kpt 指令的 CI 流程。專案每週三歐洲中部時間下午二時舉行視像會議，開發與討論集中於 GitHub 的 kptdev 組織，問題與功能建議亦在該處追蹤。對已採用其他 GitOps 工具的團隊而言，kpt 1.0 提供的是另一條以 KRM 為中心、不依賴範本語言的選擇，是否遷移可取決於現有流程對範本與繼承機制的依賴程度。