スキル service-mesh-expert
📦

service-mesh-expert

安全

Istio と Linkerd によるサービスメッシュアーキテクチャの設計

マイクロサービスには、複雑さのない安全で観察可能な通信が必要です。このスキルでは、ゼロトラストネットワーキングとトラフィック管理を備えた Istio と Linkerd のデプロイメントに関する専門的なガイダンスを提供します。

対応: Claude Codex Code(CC)
📊 70 十分
1

スキルZIPをダウンロード

2

Claudeでアップロード

設定 → 機能 → スキル → スキルをアップロードへ移動

3

オンにして利用開始

テストする

「service-mesh-expert」を使用しています。 mTLS 設定のリクエスト

期待される結果:

クラスター全体で厳格な mTLS を強制するための PeerAuthentication と DestinationRule の設定を段階的に提供します。まず許可モードからの移行パスから始め、暗号化を確認するための検証コマンドを含めます。

「service-mesh-expert」を使用しています。 サービス接続問題のデバッグ

期待される結果:

サイドカー注入の検証、VirtualService ルーティングの分析、認可ポリシーの競合、および期待される出力を含む istioctl デバッグコマンドを含む体系的なトラブルシューティングチェックリスト。

セキュリティ監査

安全
v1 • 2/25/2026

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.

1
スキャンされたファイル
61
解析された行数
0
検出結果
1
総監査数
セキュリティ問題は見つかりませんでした
監査者: claude

品質スコア

38
アーキテクチャ
100
保守性
87
コンテンツ
25
コミュニティ
100
セキュリティ
91
仕様準拠

作れるもの

Kubernetes プラットフォームエンジニア

高可用性要件を扱う本番マイクロサービスプラットフォームのために、mTLS 強制とトラフィックポリシーを備えた Istio サービスメッシュをデプロイします。

DevOpsチームリーダー

Istio VirtualService と DestinationRule 設定を使用し、トラフィック分割と自動ロールバックを備えたカナリアデプロイメントを実装します。

セキュリティアーキテクト

mTLS を使用したサービス間認証と全ネームスペース全体での AuthorizationPolicy 強制により、ゼロトラストネットワークアーキテクチャを設計します。

これらのプロンプトを試す

基本サービスメッシュ設定 
Kubernetes クラスターで Istio サービスメッシュを設定するのを手伝ってください。3 つのネームスペース（dev、staging、prod）があり、サービス間の基本的な mTLS が必要です。インストール手順と初期設定は何ですか？
トラフィックルーティング設定 
トラフィックの 90% を payment service の version-1 に、10% を version-2 にルーティングする必要があります。説明付きの Istio VirtualService と DestinationRule の YAML 設定を作成してください。
サーキットブレーカー実装 
上流の障害を適切に処理する order service 用のサーキットブレーカー設定を設計してください。Istio を使用して、接続プール設定、アウトライヤー検出、リトライポリシーを含めてください。
マルチクラスターフェデレーション 
AWS EKS と GCP GKE 全体でマルチクラスター Istio メッシュを計画してください。2 つのメッシュ間のクロスクラスターサービスディスカバリ、証明書管理、トラフィックフェデレーションの要件を含めてください。

ベストプラクティス

  • PERMISSIVE mTLS モードから開始し、すべてのサービスが正しく通信することを確認した後、徐々に STRICT に移行する
  • 障害が発生してからではなく、本番デプロイメント前にサーキットブレーカーとリトライポリシーを実装する
  • ネームスペースレベルのポリシー分離を使用して、環境ごとに異なるセキュリティとトラフィックルールを適用する

回避

  • 最初に許可モードでテストせずにクラスター全体で厳格な mTLS を有効にする - 即座にサービス中断を引き起こす
  • サービスが信頼できると仮定してサーキットブレーカー設定をスキップする - 負荷の下で連鎖障害が発生する
  • 実際の CPU とメモリ使用量を監視せずにサイドカーリソースを過剰プロビジョニングする - 不必要にコストが増加する

よくある質問

私のユースケースには Istio と Linkerd のどちらが適していますか？
Istio はより多くの設定オプションを提供しますが、複雑性も高くなります。Linkerd はリソースオーバーヘッドが低く、シンプルな mTLS と基本的な可観測性を提供します。複雑なルーティングが必要な場合は Istio を選択し、最小限の運用負荷で straightforward な mTLS が必要な場合は Linkerd を選択してください。
サービスメッシュはサービスに著しい遅延を追加しますか？
一般的なサイドカープロキシのオーバーヘッドは、mTLS とルーティングで 3-10ms です。Linkerd は通常 Istio（5-10ms）よりもオーバーヘッドが低く（2-5ms）、セキュリティと可観測性の利点はレイテンシコストを上回ることが多いです。ただし、本番デプロイメント前に特定のワークロードを測定してください。
非 Kubernetes ワークロードでサービスメッシュを使用できますか？
Istio は istio-vm 統合を通じて VM をサポートしており、ハイブリッドデプロイメントが可能です。Linkerd は Kubernetes が必要です。混合環境では、適切な VM サイドカープロキシ設定で Istio がより良い選択です。
サービスメッシュを介してデータベース接続をどのように処理しますか？
データベーストラフィックは通常、トラフィック除外ルールを使用してメッシュをバイパスします。データベースポートのサイドカーインターセプション除外を設定するか、適切な TLS origination で制御された外部アクセス用の egress ゲートウェイを使用します。
サービスメッシュのためにどのようなモニタリングを設定すべきですか？
サイドカープロキシの CPU とメモリ、リクエストレイテンシのパーセンタイル（p50、p95、p99）、エラーレート、mTLS 接続ステータス、設定同期の正常性を監視します。組み込みの Istio または Linkerd ダッシュボードを使用して Prometheus と Grafana と統合します。
問題のあるメッシュ設定をどのようにロールバックしますか？
バージョン管理された Istio 設定を Git に保存します。即座のロールバックのために以前のマニフェストバージョンで kubectl apply を使用します。重要な問題については、ネームスペースレベルでサイドカー注入を無効にし、一時的にメッシュをバイパスするためにポッドを再デプロイします。

開発者の詳細

作成者

sickn33

ライセンス

MIT

リポジトリ

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/service-mesh-expert

参照

main

ファイル構成

📄 SKILL.md