Flawless - Kubernetes AI SRE 自動運維控制平面

解決什麼

傳統 SRE 運維面臨"告警-人工排查-手動修復-事後復盤"的低效迴圈:告警系統只報問題不給方案,工程師需要手動收集日誌、檢查拓撲、猜測根因,修復後缺乏自動化驗證,事故經驗難以沉澱。Flawless 通過 AI Agent 將整個流程自動化:從 Kubernetes 告警觸發開始,自動收集 Pod 日誌、Workload 狀態、網路拓撲等證據,LLM 分析根因並生成修復預案,人工審批後執行變更(支援 Argo Rollouts 灰度釋出),最後通過 Prometheus SLO 驗證恢復效果,所有步驟可審計。這不是另一個"AI 聊天助手給建議",而是真正執行變更並驗證結果的閉環系統。

為何火

在 HN 上引發 304 點贊和 117 條討論(注意:討論的是同名 Rust 持久化執行引擎專案,與本 Python Kubernetes 專案不同),核心爭議在於"副作用標記"和 WebAssembly 沙箱的可靠性。本專案的火點在於:1) AI SRE 實戰落地,不是 Demo 而是包含真實 K3s 測試用例的生產級程式碼;2) 中國本地化友好,支援 Ollama 等本地 LLM、內建阿里雲/DaoCloud 映象加速、無需翻牆;3) 灰度釋出 + SLO 驗證,整合 Argo Rollouts 和 Prometheus AnalysisRun,自動回滾失敗變更;4) 可審計性,每個修復動作都有證據鏈、審批記錄和恢復證明。Windmill.dev 創始人在 HN 評論中認可其"輕量級持久化"設計,比傳統工作流引擎更適合基礎設施場景。

核心功能

• 智慧故障診斷:從 Kubernetes Events/Pod 日誌/Workload 狀態自動提取證據,LLM 分析根因(CrashLoop、OOMKilled、網路故障等),支援多 Pod 關聯診斷
• Skill 路由系統:內建可執行修復策略庫(如調整資源限制、修復許可權、回滾映象),根據根因自動匹配 Skill,支援自定義策略
• 人工審批門禁:高風險操作(如修改 securityContext、擴容副本)需雙重審批,支援爆炸半徑評估
• 灰度釋出整合:通過 Argo Rollouts 執行金絲雀部署,每批次執行 Prometheus AnalysisRun 驗證 SLI,失敗自動回滾並恢復 Deployment 模板
• 恢復驗證:修復後跟蹤新 Pod 日誌、Workload 收斂狀態、穩定性視窗,生成恢復證明報告
• 多叢集管理:支援 Rancher API 或直接上傳 kubeconfig,憑證 Fernet 加密儲存
• 可觀測性融合:整合 Prometheus/Loki/Tempo/Grafana,支援 Beyla 網路拓撲分析和 CMDB 關聯

安裝

前置條件:Docker、Kubernetes 叢集(K3s/K8s)、本地 LLM(推薦 Ollama)

# 1. 克隆倉庫
git clone https://github.com/William-Lu-stack/Flawless.git
cd Flawless

# 2. 配置環境變數
cp .env.example .env
# 編輯 .env:設定 LLM_API_BASE(如 http://localhost:11434/v1)、RANCHER_URL 或準備 kubeconfig

# 3. 國內網路構建映象(使用阿里雲映象加速)
docker build \
  --build-arg PYTHON_IMAGE=docker.m.daocloud.io/library/python:3.13-slim \
  --build-arg NGINX_IMAGE=docker.m.daocloud.io/nginxinc/nginx-unprivileged:stable-alpine3.23 \
  --build-arg DEBIAN_MIRROR=https://mirrors.aliyun.com/debian \
  --build-arg PIP_INDEX_URL=https://mirrors.aliyun.com/pypi/simple \
  -t flawless:latest .

# 4. 執行(需掛載叢集憑證和持久化目錄)
docker run -d \
  -p 8080:8080 \
  -v $(pwd)/.env:/app/.env \
  -v ~/.kube/config:/root/.kube/config:ro \
  -v /var/lib/flawless:/var/lib/flawless \
  flawless:latest

訪問 http://localhost:8080 進入控制台,在"叢集接入"頁面上傳 kubeconfig 或配置 Rancher。

適合誰

• SRE/平臺工程團隊:需要自動化 Kubernetes 故障處理,減少夜間告警人工介入
• 中小型技術團隊:沒有專職 SRE,希望 AI 輔助運維決策和執行
• 私有化部署場景:資料敏感不能用雲服務,需要本地 LLM + 自託管可觀測性棧
• 灰度釋出重度使用者:已使用 Argo Rollouts,需要 AI 自動分析 SLO 並決策回滾

不適合:1) 純公有云託管服務(如 EKS Fargate)無 Kubernetes API 訪問;2) 需要商業授權的生產環境(PolyForm Noncommercial 禁止商用);3) 期望零配置開箱即用(需要配置 LLM、叢集憑證、Prometheus 等)。

社群評價

HN 討論主要圍繞同名 Rust 持久化執行引擎專案,但技術理念有相通之處:

正面觀點:

• Windmill.dev 創始人認可"輕量級持久化"設計,認為比傳統工作流引擎(如 Temporal)更適合基礎設施場景,因為不需要為每個步驟儲存完整狀態
• 動畫演示清晰展示了核心原理(故障檢測 → 證據收集 → AI 分析 → 人工審批 → 執行修復 → 驗證恢復)
• WebAssembly 沙箱機制提供了"預設防呆"能力,副作用必須顯式宣告

爭議點:

• 副作用標記的可靠性:如果開發者使用非 Flawless 名稱空間的函式(如標準庫 RNG),系統能否檢測到副作用?
• WASM 生態限制:需要使用 flawless:: 名稱空間的函式而非整個 Rust 生態,更像"使用 Rust 語法的指令碼執行時"
• 與 Temporal 的對比:Temporal 聯合創始人曾建立 Amazon Flow Framework(2009)和 Azure Durable Task Framework(2014),技術血統深厚

本 Python 專案的中立評估:程式碼活躍(4天前更新至 5.0.9),包含真實 K3s 測試用例(如 CrashLoop 修復、許可權提升、灰度釋出驗證),文件詳盡(中文技術材料 + Argo Rollouts 配置指南),但缺乏正式 release 標籤和廣泛社群驗證,建議先在測試環境試用。

選型對比

vs PagerDuty/Opsgenie(商業告警平臺):

• Flawless:開源自託管,AI 自動分析根因並執行修復,支援本地 LLM
• PagerDuty:SaaS 服務,主要做告警聚合和排班,依賴人工處理

vs Temporal(工作流引擎):

• Flawless:專注 Kubernetes 運維場景,內建 Skill 庫和灰度釋出,輕量級持久化
• Temporal:通用工作流引擎,需要自己編寫業務邏輯,重量級狀態儲存

vs Keptn/Argo Rollouts(漸進式交付):

• Flawless:AI 驅動的全流程自動化(診斷 + 修復 + 驗證),整合 Argo Rollouts
• Keptn:專注交付流程編排,不包含故障診斷和自動修復

取捨:Flawless 適合"希望 AI 自動處理 80% 常見故障"的團隊,但 PolyForm Noncommercial 許可禁止商用;若需商業授權或更成熟生態,考慮 Temporal + 自建 AI 層。

已知坑

1. 許可證限制:PolyForm Noncommercial 明確禁止商業用途,不能用於盈利性生產環境或 SaaS 服務,需評估法律風險
2. LLM 依賴:診斷質量依賴 LLM 能力,小模型(如 Qwen2.5:7B)可能誤判複雜故障,建議用 14B+ 模型
3. Prometheus 強依賴:灰度釋出驗證需要 Prometheus + AnalysisTemplate,若無可觀測性棧需先搭建
4. 憑證管理:kubeconfig 加密需要 Fernet 金鑰,生產環境必須放 Kubernetes Secret 而非 .env 檔案
5. 多叢集複雜度:Rancher API 超時或 CMDB 降級可能導致證據收集卡住(5.0.3 已最佳化為按需探測)
6. 恢復驗證邊界:5.0.8 修復了"舊 Pod 被刪除後無法跟蹤新 Pod"的問題,但仍需人工確認最終恢復狀態
7. 國內網路:Dockerfile 預設拉取國外映象,必須用 --build-arg 指定國內映象源,否則構建失敗
8. 文件語言混雜:README 中英文混排,部分高階配置(如 Skill 自定義)文件不全

來源:GitHub README + 專案技術文件 + HN 社群討論(注意區分同名 Rust 專案)