下載技能 ZIP
在 Claude 中上傳
前往 設定 → 功能 → 技能 → 上傳技能
開啟並開始使用
測試它
正在使用「istio-traffic-management」。 建立具有 10% 流量的金絲雀部署
預期結果:
生成 VirtualService 進行加權路由（90% 穩定，10% 金絲雀），以及 DestinationRule 定義兩個帶有版本標籤的 subsets
正在使用「istio-traffic-management」。 為 orders 服務新增重試和超時
預期結果:
建立 VirtualService，包含 3 次重試、每次 3 秒超時，以及 orders 主機總體 10 秒超時
正在使用「istio-traffic-management」。 為 checkout 服務設定斷路器
預期結果:
生成 DestinationRule，包含連線池限制和異常檢測，包括 consecutive5xxErrors 和 baseEjectionTime
安全審計
安全All static analysis findings are false positives. The skill contains only YAML configuration templates and documentation for Istio traffic management. The 'external commands' flagged are bash commands in markdown documentation blocks (istioctl commands). The 'weak cryptographic algorithm' warnings are triggered by Istio API version strings (v1beta1) in YAML headers, not actual crypto. The 'hardcoded URLs' are legitimate links to official Istio documentation. No executable code, no security risks, no prompt injection attempts detected.
低風險問題 (1)
品質評分
你能建構什麼
平台工程師設定金絲雀部署
配置從穩定版本到金絲雀版本的漸進式流量轉移，包含加權路由和失敗時自動回滾。
DevOps 工程師實作韌性模式
新增斷路器、重試和超時以防止連鎖故障並提高服務可靠性。
SRE 偵錯流量路由問題
使用 istioctl 命令分析和驗證生產叢集中的 VirtualService 和 DestinationRule 配置。
試試這些提示
為 my-service 建立 VirtualService，根據 x-user header 路由流量。將 header 值為 'beta' 的使用者發送到 v2 subset，其他所有發送到 v1。
為 payment-service 設定金絲雀部署。將 95% 流量路由到穩定版本，5% 到金絲雀版本。包含帶有兩個 subsets 的 DestinationRule。
為 api-service 建立 DestinationRule，包含斷路器設定：最大 100 個連線、1000 個 HTTP 請求、連續 5 次錯誤後移除 pods、30 秒基礎移除時間。
設定從生產環境到 staging 環境的流量鏡像。鏡像 100% 請求到 v2 subset 進行測試，不影響即時流量。
最佳實務
- 在套用至生產環境前，始終使用 istioctl analyze 測試 Istio 配置
- 從簡單的 VirtualService 規則開始，逐步增加複雜性
- 部署新路由規則後，使用 Kiali 儀表板監控流量模式
- 使用有意義的 subset 名稱（stable、canary、v1、v2）並一致性地標籤服務
避免
- 不要配置無限制的重試 - 這可能導致連鎖故障
- 避免將流量鏡像到生產資料庫 - 僅鏡像到測試環境
- 切勿跳過 DestinationRules 中的 subset 驗證 - 未定義的 subsets 會導致路由失敗
- 不要立即使用 100% 金絲雀權重 - 始終從小百分比開始