service-mesh-expert
使用 Istio 和 Linkerd 設計服務網格架構
微服務需要安全、可觀察的通訊，同時避免複雜性。此技能提供 Istio 和 Linkerd 部署的專業指導，包含零信任網路和流量管理。
下載技能 ZIP
在 Claude 中上傳
前往 設定 → 功能 → 技能 → 上傳技能
開啟並開始使用
測試它
正在使用「service-mesh-expert」。 請求 mTLS 設定
預期結果:
逐步的 PeerAuthentication 和 DestinationRule 設定，以強制執行全集群的嚴格 mTLS，從寬鬆模式遷移路徑開始，並提供驗證命令以確認加密。
正在使用「service-mesh-expert」。 除錯服務連線問題
預期結果:
系統性故障排除清單，包括 sidecar 注入驗證、VirtualService 路由分析、授權策略衝突，以及帶有預期輸出的 istioctl 除錯命令。
安全審計
安全Static analysis flagged 4 patterns that are all false positives. Line 22 uses Markdown backticks for documentation reference, not shell execution. Lines 3, 46, and 60 contain no cryptographic code - they reference mTLS conceptually in documentation. This is a markdown-only skill with no executable code, external commands, or security risks.
品質評分
你能建構什麼
Kubernetes 平台工程師
部署具有 mTLS 強制執行和流量策略的 Istio 服務網格，適用於需要高可用性要求的生產微服務平台。
DevOps 團隊負責人
使用 Istio VirtualService 和 DestinationRule 設定實作具有流量分割和自動回滾功能的金絲雀部署。
安全架構師
設計零信任網路架構，使用 mTLS 和 AuthorizationPolicy 在所有命名空間中實施服務間驗證。
試試這些提示
協助我在 Kubernetes 集群上設定 Istio 服務網格。我有 3 個命名空間（dev、staging、prod），需要在服務間進行基本的 mTLS。安裝步驟和初始設定是什麼？
我需要將 90% 的流量路由到 version-1，10% 的流量路由到 payment 服務的 version-2。建立 Istio VirtualService 和 DestinationRule YAML 設定並附上說明。
為我的 order 服務設計斷路器設定，優雅地處理上游失敗。包含使用 Istio 的連線池設定、異常檢測和重試策略。
規劃跨越 AWS EKS 和 GCP GKE 的多集群 Istio 網格。包含跨集群服務發現、證書管理和兩個網格間流量聯邦的需求。
最佳實務
- 從 PERMISSIVE mTLS 模式開始，在驗證所有服務正確通訊後逐步遷移至 STRICT
- 在生產部署前實作斷路器和重試策略，而非在失敗發生後
- 使用命名空間層級的策略隔離，為每個環境應用不同的安全和流量規則
避免
- 在未先在寬鬆模式下測試的情況下啟用全集群嚴格 mTLS - 會導致立即的服務中斷
- 假設服務可靠而跳過斷路器設定 - 在負載下會發生級聯失敗
- 未監控實際 CPU 和記憶體使用量就過度配置 sidecar 資源 - 不必要地增加成本