サービスメッシュ：Istio、 Linkerd

サービスメッシュ： Istio、 Linkerd

1）サービスメッシュとは何ですか、そしてそれが必要なとき

Service Meshは、エンドツーエンドのmTLS、ルーティング、フォールトトレランス、およびコード書き換えなしのサービス間の可視性を提供するネットワークデータ/制御平面層です。

目的：

デフォルトのセキュリティ（ゼロトラスト、サービスID、アクセスポリシー）。
交通管理（カナリア/ブルーグリーン、A/B、影）。
信頼性（レトラ、タイムアウト、回路破壊）。
観測可能性（メトリック、ログ、トレイル）。
運用の標準化（コードとしてのポリシー、GitOps）。

メッシュを取るとき：

多言語とmTLS要件を備えた多くのマイクロサービス。
アプリケーションを変更することなく、高度なルーティング/実験シナリオが必要です。
ネットワークレベルで監査/ポリシー要件があります。

2）イスティオ対リンカード-簡単な比較

［アスペクト］	イスティオ	リンカード（Linkerd）
プロキシ	特使（L7）	rust-proxy （http/grpc）+ミニマリスト
インストールについて	IstioOperator/ヘルム	'linkerd install'/ヘルム
安全性について	mTLS、 AuthorizationPolicy、 PeerAuthentication、 WASM-фильтры	mTLSデフォルト、シンプルなポリシー（'policy'、 'server'、 'serverauthorization'）
トラフィックマネジメント	VirtualService、 DestinationRule、ゲートウェイ、EnvoyFilter	ServiceProfile、 TrafficSplit （SMI）、リトライ/タイムアウト
Observability	Prometheus、 Telemetry API、 Envoyアクセスログ、OpenTelemetry	'linkerd viz'（タップ/エッジ/ルート）、Prometheus、 OTEL統合
マルチクラスター	ネイティブマルチクラスター、東西ゲートウェイ	'linkerd multicluster'（ゲートウェイ+サービスミラー）
デプロイメントモデル	サイドカー・アンビエントメッシュ（ztunnel+waypoint）	サイドカー（Sidecar）
複雑さ	機能的に豊富で、難しく	シンプルで最小限のオーバーヘッド
拡張可能性	WASM/EnvoyFilter、外部承認者	より限定的だが予測可能

3）アーキテクチャと展開モデル

3.1サイドカーメッシュ（クラシック）

各Podはプロキシサイドカーを受け取ります。
長所：成熟度、完全なL7制御。
短所：CPU/RAMオーバーヘッド、枯渇/デバッグの複雑さ。

3.2 Istioの包囲された網

必要に応じてnode+waypointプロキシ（L7）上のztunnel （L4）。
長所：低コストと複雑さ、L7の段階的な包含。
短所：新しい、すべてのL7ケースがウェイポイントなしで利用可能ではありません。

4）アイデンティティとmTLS（ゼロトラスト）

4.1 SPIFFE/SPIREおよび証明書

各ワークアウトにはSPIFFE ID： 'spiffe：//クラスタが割り当てられます。ローカル/ns/NS/sa/SA'。
認証：サービス間の相互TLS。
キー回転-自動的に（短いTTL）。

4.2イスティオ（PeerAuthentication+DestinationRule）

yaml apiVersion: security. istio. io/v1 kind: PeerAuthentication metadata: { name: default, namespace: payments }
spec:
mtls: { mode: STRICT }
apiVersion: networking. istio. io/v1 kind: DestinationRule metadata: { name: payments-dr, namespace: payments }
spec:
host: payments. svc. cluster. local trafficPolicy:
tls: { mode: ISTIO_MUTUAL }

4.3 Linkerd-mTLSデフォルト

'linkerd install'+'linkerd inject'の後に有効になります。
クラスタ-独自のトラストアンカー、自動回転。

5）交通管理

5.1イスティオ：バーチャルサービス（ルート、カナリア）

yaml apiVersion: networking. istio. io/v1 kind: VirtualService metadata: { name: payments }
spec:
hosts: ["payments"]
http:
- route:
- destination: { host: payments, subset: v1 } # stable weight: 90
- destination: { host: payments, subset: v2 } # canary weight: 10 retries: { attempts: 2, perTryTimeout: 300ms }
timeout: 2s

DestinationRule （LB/CB）：

yaml apiVersion: networking. istio. io/v1 kind: DestinationRule metadata: { name: payments }
spec:
host: payments subsets:
- name: v1 labels: { version: v1 }
- name: v2 labels: { version: v2 }
trafficPolicy:
loadBalancer: { simple: LEAST_CONN }
outlierDetection:
consecutive5xx: 5 interval: 5s baseEjectionTime: 30s maxEjectionPercent: 50

5.2 Linkerd： ServiceProfile+TrafficSplit

yaml apiVersion: linkerd. io/v1alpha2 kind: ServiceProfile metadata:
name: payments. default. svc. cluster. local spec:
routes:
- name: POST /withdraw condition:
method: POST pathRegex: "/withdraw"
isRetryable: true timeout: 2s apiVersion: split. smi-spec. io/v1alpha2 kind: TrafficSplit metadata: { name: payments }
spec:
service: payments backends:
- service: payments-v1 weight: 90
- service: payments-v2 weight: 10

6）入力/出力およびAPIゲートウェイ

Istio Gateway （ingress/egress）-着信/発信トラフィック、TLS終了、mTLSパススルーを制御します。
Linkerdは既存の入力コントローラ（NGINX/Contour/Traefik）で動作します。egress-NetworkPolicy/egress-gateway-patternsを介して。
排出ポリシー：ドメインのホワイトリスト、SNIポリシー、直接インターネット禁止。

7）承認とポリシー

7.1 Istio AuthorizationPolicy （RBAC/ABAC）

yaml apiVersion: security. istio. io/v1 kind: AuthorizationPolicy metadata: { name: allow-withdraw, namespace: payments }
spec:
selector: { matchLabels: { app: payments } }
action: ALLOW rules:
- from:
- source:
principals: ["spiffe://cluster. local/ns/api/sa/gateway"]
to:
- operation:
methods: ["POST"]
paths: ["/withdraw"]
when:
- key: request. auth. claims[role]
values: ["cashout"]

7.2 Linkerdポリシー（サーバ+サーバ認証）

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

8）観測可能性およびテレメトリー

8.1メトリクス

Istio Telemetry API→Prometheus： 'istio_requests_total'、 'istio_request_duration_milliseconds_bucket'、 'istio_tcp_received_bytes_total'。
Linkerd viz： 'request_total'、レイテンシp50/p95/p99、 'success_rate'。

8.2トレイルとログ

W3Cトレースコンテキストをプッシュします。
Istio/Envoy→OTLP-OpenTelemetry Collector；Linkerd-サイドカーロガー/アプリSDK経由。

8.3つのインスタンス

ジャンプツートレースの期間ヒストグラムにtrace_idを追加します。

9）レート制限、WAF、カスタムフィルター

Istio：ローカルレート制限のEnvoyFilter/WASM、 eksternal-rate-limit service （Redis）、およびWAFロジック（Lua/WASM）。
Linkerd：限られたネイティブサポート；rate limit-ingress/gatewayレベル。

10）マルチクラスター

Istio：東西ゲートウェイ、共有PKIまたはトラストバンドル、ServiceEntry、 Federation経由のサービスディスカバリ。
Linkerd： 'linkerd multicluster link'、 gateway per cluster、 service-mirror： linkerd multicluster link。

ユースケース：アセットリージョン、トラフィックローカリゼーション、フェデレーションゼロトラスト。

11）性能および費用

サイドカーメッシュ：PodあたりCPU/RAMオーバーヘッド、レイテンシの増加（通常は定常状態でホップあたり+1-3 ms）。
アンビエント（Istio）： L4の消費量が少なく、L7がオンになっています。
Linkerd：軽量プロキシは一般的にオーバーヘッドが少なく、極端なL7機能が少ない。
練習：前/後p95/CPU測定して下さい、低下のためのSLOのゲートを保って下さい。

12）安全性

どこでもmTLS、短いTTL、自動回転。
Policy as Code （OPA/Gatekeeper、 Kyverno） for 'authorizationPolicy： ALLOW all' prohibitions。
秘密-CSI/Vaultを介して、マニフェストではありません。
出力制御：deny-by-default、明示的なallow-lists。
環境（prod/stage）のトラストドメインを分離します。

13）リリースとSLOゲートとの統合

カナリア/ブルーグリーンはメッシュルートで実装されています（例を参照）。
Argo Rollouts AnalysisTemplateのメトリクス分析（Prometheus/SpanMetrics）-Hitchhiking/Rollback at burn-rate/p95/5xx。
Grafanaでのリリースの注釈：比較'version=stable' canary'。

14）アンチパターン

メッシュ「どこでも、一度に」→インフラストラクチャショックを含める。
プロキシ→TSDB/ログストレージのオーバーロードからメトリック/ログのカーディナリティを無視します。
mTLSをPERMISSIVE/opaqueモードで永遠に残す。
ゲートウェイ/アプリケーションの代わりにEnvoyFilter内で複雑なWAF/ビジネスロジックを作成してみてください。
出口ポリシーなし-インターネット漏洩/コンプライアンスバイパス。
'：15000'デバッグを外側に開いたプロキシ。

15）実装チェックリスト（0-60日）

0-15日

モデル選択：ロードプロファイルによるSidecar vs Ambient （Istio ）/Linkerd。
mTLS STRICT、 1-2クリティカルサービスの基本的な承認ポリシーを有効にします。
基本的なルート（タイムアウト/再試行）、RED/SLOダッシュボード。

16-30日

Canary/TrafficSplit、ホットトラックの外れ検出/回路破壊。
OTELの統合：trails+Exemplars；警告バーンレート。
エグレスゲートウェイとドメインホワイトリスト；deny-by-defaultを指定します。

31-60日

マルチクラスタリンク（必要に応じて）、フェデレーションの信頼。
AuthorizationPolicy/ServerAuthorizationとしてのポリシー。
ゲームデイ：インシデントとルート/ポリシーのロールバックのシミュレーション。

16）成熟度の指標

mTLS （STRICT/自動回転）カバレッジ≥サービスの95％です。
カナリア/プログレッシブリリースによるトラフィックのシェア≥ 80％です。
平均オーバーヘッドp95<ベースラインの+5％（最適化後）。
0無許可でオープンエグレス、基本的なAuthZで100％サービス。
RCA「スケジュールからトラックへ」≤ 2分（p50）。

17）「暗号としての政治」の例"

ゲートキーパー（prodの禁止PERMISSIVE）

yaml apiVersion: constraints. gatekeeper. sh/v1beta1 kind: K8sIstiomTLSStrict metadata: { name: deny-permissive-prod }
spec:
match:
kinds: [{ apiGroups: ["security. istio. io"], kinds: ["PeerAuthentication"] }]
namespaces: ["prod-"]
parameters:
allowedModes: ["STRICT"]

Kyverno （VS/DR必須ラベル）

yaml apiVersion: kyverno. io/v1 kind: ClusterPolicy metadata: { name: require-mesh-labels }
spec:
rules:
- name: vs-dr-labels match:
any:
- resources:
kinds: ["VirtualService","DestinationRule"]
validate:
message: "owner and service labels required"
pattern:
metadata:
labels:
owner: "?"
service: "?"

18）運用上のヒント

バージョンポリシーとルート（semver）、 GitOpsによるプロモーション。
プロキシの可視性：個々の「プロキシ飽和」ダッシュボード（CPU/ヒープ、リトライ、429/503）。
Cardinality budget：ラベル'route'、 'code'、 'destination'-テンプレートのみ。
ネットワーク制限/名前空間クォータ（NetworkPolicy/LimitRange）。
コマンドドキュメンテーション：runbook 「mTLS routes/policy/keysをロールバックする方法」。

19）結論

IstioとLinkerdは同じことをしています-クロスサービス通信の安全性、信頼性、可視性を標準化しますが、異なる深さと所有コストで行います。

豊富なL7機能と柔軟なポリシーが必要です。
シンプルさと小さなオーバーヘッドが必要です-Linkerdを取ります。

任意のメッシュを選択：デフォルトでmTLSを有効にし、ルーティングをコードとして管理し、メトリクスをトラックに関連付け、エグレスを閉じ、SLOゲートをリリースに追加します。その後、ネットワーク層は「ブラックボックス」でなくなり、変化の安定性と速度の予測可能なツールになります。

サービスメッシュ：Istio、 Linkerd

16-30日

31-60日

Kyverno （VS/DR必須ラベル）

お問い合わせ

迅速な連絡

動画はまもなく更新されます

現在、私たちはプロジェクトで非常に多忙です