サービスメッシュとトラフィックポリシー

1）なぜサービスメッシュ

• デフォルトのセキュリティ：mTLS、証明書の自動発行/回転、サービスID。
• トラフィックポリシー：L7ルーティング、カナリア/AVテスト、劣化と安定性。
• 観測可能性：メトリック、ログ、トレース、各コールのゴールド信号。
• 操作：すべての言語/フレームワークの統一ポリシー。

APIゲートウェイとの違い：ゲートウェイ-南北境界；mesh-クラスタ/組織内の東西。よく一緒に仕事をします。

2）建築： 平面とパターン

データプレーン：ポッド/VMトラフィックを傍受するサイドカープロキシ（Envoy/Linkerd-proxy/haproxy）。
Control Plane：設定（ルート、ポリシー、証明書）、ステータスの保存、サービスドライブの発行を行います。
アイデンティティ：通常SPIFFE IDおよび自動X。509証明書（SPIRE/組み込み CA）。
入力/終了ポイント：境界フローを監視するためのingress/egress-gateway。
実装モード：下の各サイドカー；新しい実装におけるノードごと/アンビエントモード。

3）セキュリティポリシーとゼロトラスト

1.デフォルトでmTLS-暗号化と相互認証をservis↔servisします。

• AuthN： trust only identities by CA mesh 'a （SPIFFE）。
• AuthZ：宣言的な「誰が誰に、どのように」ルール（RBAC/ABAC）。

3.分離および出口制御：

• 許可されたドメイン/サブネット；egress-gatewayを介した強制排出。
• 囲炉裏からの直接の結果をブロックします。

4.秘密の回転：短命の証明書、自動プロキシの再構成。

yaml apiVersion: security. istio. io/v1beta1 kind: PeerAuthentication metadata: { name: default, namespace: istio-system }
spec:
mtls: { mode: STRICT }

yaml apiVersion: security. istio. io/v1beta1 kind: AuthorizationPolicy metadata: { name: billing-allow, namespace: prod }
spec:
selector: { matchLabels: { app: billing } }
rules:
- from:
- source: { principals: ["spiffe://corp. local/ns/prod/sa/inventory"] }
to:
- operation: { ports: ["8080"], methods: ["POST"], paths: ["/proto. Billing/"] }

4）交通政策： 持続性およびルーティング

4.1タイムアウトとリトリート

タイムアウト：コールに設定する必要があります（接続/読み取り/全体）。
再試行：idempotent操作のみ；バックオフ+ジッタ；試行時間ごとの制限。

yaml apiVersion: networking. istio. io/v1beta1 kind: VirtualService metadata: { name: orders }
spec:
hosts: ["orders"]
http:
- route:
- destination: { host: orders, subset: v1, port: { number: 8080 } }
timeout: 5s retries:
attempts: 2 perTryTimeout: 2s retryOn: "5xx,connect-failure,reset"

4.2 サーキットブレーカーpoutlier検出

CB：同時リクエスト/接続を制限し、上流を保護します。
Outlier：エラー/レイテンシによって「悪い」インスタンスをスローします。

yaml apiVersion: networking. istio. io/v1beta1 kind: DestinationRule metadata: { name: orders }
spec:
host: orders trafficPolicy:
connectionPool:
http: { http1MaxPendingRequests: 1024, maxRequestsPerConnection: 100 }
outlierDetection:
consecutive5xxErrors: 5 interval: 5s baseEjectionTime: 30s maxEjectionPercent: 50

4.3カナリアと条件によって

重み付け-トラフィックはv1/v2の重みで分割されます。
ヘッダーベース：フラグ/クッキー/テナント→新しいバージョンに転送されます。
セッションアフィニティ：キーによるハッシュ（きちんとスケーリングされた）。

yaml http:
- match: [{ headers: { "x-experiment": { exact: "new" } } }]
route: [{ destination: { host: orders, subset: v2 } }]
- route:
- destination: { host: orders, subset: v1, weight: 90 }
- destination: { host: orders, subset: v2, weight: 10 }

4.4欠陥の注入および低下

ロバステストおよびSLOの遅延/エラー注入。

yaml fault:
delay: { fixedDelay: 300ms, percentage: { value: 10 } }
abort: { httpStatus: 503, percentage: { value: 1 } }

5）ネットワーク境界： 入出力および外部サービス

Ingress-gateway：メッシュ内の外部クライアントの唯一のエントリポイント。WAF/OIDC/ratelimitsとの統合。
Egress-gateway：許可されたホストのリスト、TLS検査、テレメトリー記録を含む中央出力。
ServiceEntry：外部SNI/ホストをメッシュの一部として宣言します（ポリシーとmTLSオリジネーションが適用されます）。

yaml apiVersion: networking. istio. io/v1beta1 kind: ServiceEntry metadata: { name: payments-external }
spec:
hosts: ["api. payments. com"]
ports: [{ number: 443, name: https, protocol: TLS }]
resolution: DNS location: MESH_EXTERNAL

6）マルチクラスター、マルチネットワーク、ハイブリッド

共有PKI/トラストドメイン：クラスタ間の単一のSPIFFE ID。
エンドポイント検出：リージョン間のサービスボール；ローカル優先度とフェイルオーバー。
ゾーンの分離：地域ごとの政策、制限、優先順位。
VM in mesh：レガシーシステム/ステートフルシステムをプロキシと同じポリシーに接続します。

7）観察可能性、SLOおよび操作

'requests_total'、 'request_duration_ms {p50、 p95、 p99}'、 '5xx_rate'、 'retry_attempts'、 'cb_state'、 'mTLS_authz_denied'。
アクセスログ：構造、'traceparent'、 'user/tenant'、 'response_flags'。
トレース：ヘッダーの自動注入（W3C Trace Context）、サンプリング、ホップレベルでのスパン。
SLO：ルート上のp99/エラー （service→service）によるターゲット。
アラート：'5xx'スパイク、'reset' rise、 'outlier_ejections'、 mTLS劣化（ハンドシェイク障害）。

8）性能および費用

• 粒度：必要に応じて政治を含める。どこでも重いフィルターをオンにしないでください。
• プール：パス（クリティカル/バックグラウンド）を異なるルートと制限に分割します。
• プロファイリング：「コールド」ルートのp99、テレメトリー量（レートリミットログ/トレイル）。
• サポートされていて適切な場合は、アンビエントモード/サイドカーレスモードを検討してください。

9）安全性とコンプライアンス

必要最小限のアクセス：方向と方法を明示的に許可します。
ネイムスペース/テナントに関するポリシー：ネットワーク/承認境界。
キー回転/AC：計画および緊急事態；短いTTL証明書。
PII/secrets：ログ/トラックのマスキング；ワイヤーの/atの残りの暗号化。
監査：誰、いつ、どのポリシーが変更されたか;二段階の騒動。

10） K8s層との統合

メッシュポリシーは、置き換えではなく、NetworkPolicyを補完します。
ingress/egress-gatewayでは、以下のレベルでPodSecurity/PSAをハングアップできます。
NRA/オートスケーリング： リトレイ/CB-負荷を変更することを考慮してください。
リリースプラン：VirtualService+自動SLOプロモーションによるカナリアウェイト。

11）実装チェックリスト

• Trust bounds definedとSTRICT mTLS enabled。
• AuthZポリシーが有効になっています：誰に、どのポート/メソッドに。
• タイムアウト/リトライとアウトリエ検出が設定され、idempotentパスが定義されます。
• カナリアルートとロールバックプランが登録されています。fault-injection-非prodでのみ。
• 外部依存関係は、egress-gatewayとServiceEntryを介して導出されます。
• メトリック、ログ、トレースが設定されています。p99/5xx/CBのダッシュボードとアラート。
• テナントごとのクォータ/制限/名前空間が利用可能です。
• 準備されたランブック：証明書のリーク、CAの失敗、上流の劣化、大量503/RESET。
• マルチクラスタプラン（共有PKI、ローカル優先順位、DRシナリオ）。
• テスト日（ゲーム日）：ドロップコントロールプレーン、停止サイドカー、ネットワークブレイク、有毒な上流。

12）アンチパターン

ルートの在庫とSLO→高価な複雑さのない「どこでも、一度に」メッシュ。
すべてのメソッドのデフォルトのリトレイ→エフェクトの重複とトラフィックの雪崩。
無効なmTLSは「一時的に」→永久に残ります。
gateway→data leakage/unaccounted dependenciesのないEgress。
すべてのサービスに1つのグローバルポリシー→偽のセキュリティと偽陽性。
ゼロ観察可能性：メッシュが含まれていますが、メトリック/トレイルを収集しないでください-意味を失います。

13）クイックレシピ

Linkerd： サーバでmTLSとポリシーを有効にする

yaml apiVersion: policy. linkerd. io/v1beta1 kind: Server metadata: { name: billing, namespace: prod }
spec:
podSelector: { matchLabels: { app: billing } }
port: 8080 apiVersion: policy. linkerd. io/v1beta1 kind: ServerAuthorization metadata: { name: billing-allow-inventory, namespace: prod }
spec:
server: { name: billing }
client:
meshTLS:
identities: ["inventory. prod. serviceaccount. identity. linkerd. cluster. local"]

領事（L7インテント+スプリッター）

hcl
Kind = "service-router"
Name = "orders"
Routes = [{
Match { HTTP { PathPrefix = "/v1" } }
Destination { Service = "orders" }
}]
Kind = "service-splitter"
Name = "orders"
Splits = [
{ Weight = 90, ServiceSubset = "v1" },
{ Weight = 10, ServiceSubset = "v2" }
]

14） FAQ

メッシュには小さなチームが必要ですか？
場合3-5サービス-より頻繁にはありません。良い進入と回復力ライブラリから始めましょう。mTLS-default、 uniform policy、およびコード変更なしでトレースが必要な場合にメッシュを接続します。

費用を制御する方法か？
クリティカルパスのオーバーヘッド（CPU/RAM/レイテンシ）を測定し、不要なフィルタをオフにし、ログ/トレイルの量を減らし、安全な場所でサイドカーなしでモードを使用します。

メッシュと手動で設定されたプロキシを干渉することは可能ですか？
はい。ただし、二重ルーティング/重複レトレイは避けてください。単一の場所は真です-制御平面。

より重要なのは、セキュリティとパフォーマンスですか？
デフォルトはセキュリティ（mTLS、 AuthZ）です。パフォーマンスは、接続プールのチューニング、アウトリエ検出、ターゲットルートによって達成されます。

15）合計

Service Meshは、サービス間のネットワークを、暗号化とアイデンティティ、微細なルーティングとレジリエンス、テレメトリーとクォータという統一的なポリシーを持つプログラマブルなレイヤーに変えます。クリティカルパスから始め、STRICT mTLSと明示的なAuthZをオンにし、タイムアウト/リトレイ/CBを設定し、エグゼクティブを制御し、p99と5xxを測定し、ゲーム日数を費やします。その後、メッシュは信頼性とリリースのスピードのアンプになり、驚きの源ではありません。