引言
在雲原生生態系中，Kubernetes控制器的開發與維護一直是關鍵挑戰。尤其當面對如Config Connector這樣需要建立1000個控制器以管理Google Cloud API的複雜場景時，傳統工具如Terraform的「魔術機器」問題與擴展性限制，使得開發效率與系統穩定性面臨重大考驗。本文探討如何透過大型語言模型（LLMs）與創新工程實踐，解決這些挑戰，並建立可擴展的開發流程。
主要內容
技術定義與核心概念
Kubernetes控制器是用於監控與管理Kubernetes資源的控制器，其核心功能在於確保系統狀態與期望狀態一致。在Config Connector的場景中，需將Google Cloud REST API轉換為Kubernetes原生資源模型，這意味著需開發大量控制器以處理不同API端點。
LLMs（大型語言模型） 作為現代AI技術的代表，具備處理程式碼生成與邏輯推理的能力。透過LLMs，開發者可以將複雜的邏輯分解為多個簡單模組，並以「碼作為主要工件」（code as primary artifact）的概念，提升系統的可維護性。
關鍵特性與功能
- 分層問題分解：
將大規模控制器開發拆解為小問題，透過LLM處理較簡單任務（如生成測試案例），並逐步迭代。此方法降低單一系統的複雜度，使開發過程更易管理。
- 非確定性與驗證機制：
LLM的輸出具有非確定性，需透過重複執行或迭代改進確保結果一致性。同時，建立測試流程與驗證機制，確保生成的控制器符合需求。
- 工具鏈整合：
使用模板化提示與工具調用（如G-Cloud命令）協助LLM生成準確結果。透過XML包裝輸入/輸出，並利用HTTP日誌分析資源請求/回應模式，建立模擬環境。
實際應用案例與實作步驟
- Fuzzer設計與迭代改進循環：
以CRD（Custom Resource Definition）為基礎，透過結構化輸入數據生成fuzz gen工具，並利用LLM推測輸出結果。手動撰寫初始fuzzers並標註輸入/輸出範例，作為LLM生成下一案例的上下文。
- G-Cloud HTTP分析與Mock生成：
透過HTTP請求與回應日誌建立資源請求/回應模板，檢測404等錯誤碼作為流程中斷條件。利用LLM結合模板化與樣本數據生成mock，並透過AB測試驗證與真實系統的結果一致性。
- 元數據驅動流程：
初始步驟要求LLM生成千個資源的元數據（如Git分支、資源名稱、proto定義），並自動化處理大量資源。每步驟執行時間約10分鐘，並行處理成功與失敗案例。
技術優勢與挑戰
優勢：
- 透過LLM與分層問題分解，解決千個控制器生成的挑戰，並建立可擴展的開發流程。
- 以構建時執行LLM（而非運行時）提高結果可預測性，並透過工具鏈自動化生成與驗證減少人工幹預。
挑戰：
- LLM的非確定性可能導致結果不一致，需建立嚴格的測試與驗證機制。
- 編譯器錯誤修正需人類介入，但可透過LLM進行初步修正，並搭配驗證階段確保語法正確性。
總結
透過LLM生成Kubernetes控制器，結合fuzzing技術與迭代改進機制，成功突破傳統工具的限制，並建立可擴展的開發流程。關鍵在於分階段驗證、混合工具使用及人類審查，以確保生成的控制器符合需求並具備可維護性。未來隨著LLM技術持續進步，此方法將進一步提升開發效率與系統可靠性。