linkerd-patterns について
Kubernetes 上の Linkerd サービスメッシュを運用するための、本番向けパターン集です。導入、トラフィック管理、セキュリティポリシー、マルチクラスター設定、監視、デバッグを扱います。
主な機能
- 01Linkerd の導入とクラスター検査
- 02自動インジェクションと mTLS 設定
- 03カナリア向けトラフィック分割
- 04ルート指標、リトライ、タイムアウト
- 05サーバーアクセス制御
- 06マルチクラスター設定とデバッグ
活用シーン
- 01Kubernetes に Linkerd サービスメッシュを導入
- 02カナリアリリースや A/B テストの設定
- 03ルート単位のリトライ、タイムアウト、指標の設定
- 04プロキシ状態、ID、TLS の確認
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ wshobson/ agents --skill linkerd-patternsインストール後、Claude Code で/linkerd-patternsを入力して読み込まれたか確認します。
詳細
Linkerd パターン
Kubernetes 向けの軽量でセキュリティ第一のサービスメッシュである Linkerd の本番環境向けパターンです。
このスキルを使用する場面
- 軽量なサービスメッシュをセットアップするとき
- 自動 mTLS を実装するとき
- カナリアデプロイメント用のトラフィックスプリットを構成するとき
- ルートごとのメトリクス用にサービスプロファイルをセットアップするとき
- リトライとタイムアウトを実装するとき
- マルチクラスターサービスメッシュ
中核となる概念
1. Linkerd のアーキテクチャ
┌─────────────────────────────────────────────┐
│ Control Plane │
│ ┌─────────┐ ┌──────────┐ ┌──────────────┐ │
│ │ destiny │ │ identity │ │ proxy-inject │ │
│ └─────────┘ └──────────┘ └──────────────┘ │
└─────────────────────────────────────────────┘
│
┌─────────────────────────────────────────────┐
│ Data Plane │
│ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │proxy│────│proxy│────│proxy│ │
│ └─────┘ └─────┘ └─────┘ │
│ │ │ │ │
│ ┌──┴──┐ ┌──┴──┐ ┌──┴──┐ │
│ │ app │ │ app │ │ app │ │
│ └─────┘ └─────┘ └─────┘ │
└─────────────────────────────────────────────┘
2. 主要なリソース
| リソース | 目的 |
|---|---|
| ServiceProfile | ルートごとのメトリクス、リトライ、タイムアウト |
| TrafficSplit | カナリアデプロイメント、A/B テスト |
| Server | サーバー側のポリシーを定義 |
| ServerAuthorization | アクセス制御ポリシー |
テンプレート
テンプレート 1: メッシュのインストール
対象クラスターと互換性のある CLI バージョンを使用してください。この例では Homebrew を使用しています。 その他のシステムについては、公式インストールガイドに従ってください。
# Install the CLI with Homebrew
brew install linkerd
linkerd version
# Validate cluster
linkerd check --pre
# Install CRDs
linkerd install --crds | kubectl apply -f -
# Install control plane
linkerd install | kubectl apply -f -
# Verify installation
linkerd check
# Install viz extension (optional)
linkerd viz install | kubectl apply -f -
テンプレート 2: 名前空間のインジェクト
# Automatic injection for namespace
apiVersion: v1
kind: Namespace
metadata:
name: my-app
annotations:
linkerd.io/inject: enabled
---
# Or inject specific deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
annotations:
linkerd.io/inject: enabled
spec:
template:
metadata:
annotations:
linkerd.io/inject: enabled
テンプレート 3: リトライ付きサービスプロファイル
apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
name: my-service.my-namespace.svc.cluster.local
namespace: my-namespace
spec:
routes:
- name: GET /api/users
condition:
method: GET
pathRegex: /api/users
responseClasses:
- condition:
status:
min: 500
max: 599
isFailure: true
isRetryable: true
- name: POST /api/users
condition:
method: POST
pathRegex: /api/users
# POST not retryable by default
isRetryable: false
- name: GET /api/users/{id}
condition:
method: GET
pathRegex: /api/users/[^/]+
timeout: 5s
isRetryable: true
retryBudget:
retryRatio: 0.2
minRetriesPerSecond: 10
ttl: 10s
テンプレート 4: トラフィックスプリット(カナリア)
apiVersion: split.smi-spec.io/v1alpha1
kind: TrafficSplit
metadata:
name: my-service-canary
namespace: my-namespace
spec:
service: my-service
backends:
- service: my-service-stable
weight: 900m # 90%
- service: my-service-canary
weight: 100m # 10%
テンプレート 5: サーバー認可ポリシー
# Define the server
apiVersion: policy.linkerd.io/v1beta1
kind: Server
metadata:
name: my-service-http
namespace: my-namespace
spec:
podSelector:
matchLabels:
app: my-service
port: http
proxyProtocol: HTTP/1
---
# Allow traffic from specific clients
apiVersion: policy.linkerd.io/v1beta1
kind: ServerAuthorization
metadata:
name: allow-frontend
namespace: my-namespace
spec:
server:
name: my-service-http
client:
meshTLS:
serviceAccounts:
- name: frontend
namespace: my-namespace
---
# Allow unauthenticated traffic (e.g., from ingress)
apiVersion: policy.linkerd.io/v1beta1
kind: ServerAuthorization
metadata:
name: allow-ingress
namespace: my-namespace
spec:
server:
name: my-service-http
client:
unauthenticated: true
networks:
- cidr: 10.0.0.0/8
テンプレート 6: 高度なルーティング用の HTTPRoute
apiVersion: policy.linkerd.io/v1beta2
kind: HTTPRoute
metadata:
name: my-route
namespace: my-namespace
spec:
parentRefs:
- name: my-service
kind: Service
group: core
port: 8080
rules:
- matches:
- path:
type: PathPrefix
value: /api/v2
- headers:
- name: x-api-version
value: v2
backendRefs:
- name: my-service-v2
port: 8080
- matches:
- path:
type: PathPrefix
value: /api
backendRefs:
- name: my-service-v1
port: 8080
テンプレート 7: マルチクラスターセットアップ
# On each cluster, install with cluster credentials
linkerd multicluster install | kubectl apply -f -
# Link clusters
linkerd multicluster link --cluster-name west \
--api-server-address https://west.example.com:6443 \
| kubectl apply -f -
# Export a service to other clusters
kubectl label svc/my-service mirror.linkerd.io/exported=true
# Verify cross-cluster connectivity
linkerd multicluster check
linkerd multicluster gateways
監視コマンド
# Live traffic view
linkerd viz top deploy/my-app
# Per-route metrics
linkerd viz routes deploy/my-app
# Check proxy status
linkerd viz stat deploy -n my-namespace
# View service dependencies
linkerd viz edges deploy -n my-namespace
# Dashboard
linkerd viz dashboard
デバッグ
# Check injection status
linkerd check --proxy -n my-namespace
# View proxy logs
kubectl logs deploy/my-app -c linkerd-proxy
# Debug identity/TLS
linkerd identity -n my-namespace
# Tap traffic (live)
linkerd viz tap deploy/my-app --to deploy/my-backend
ベストプラクティス
推奨事項
- すべての場所で mTLS を有効化する - Linkerd では自動的に有効になります
- ServiceProfile を使用する - ルートごとのメトリクスとリトライを取得できます
- リトライバジェットを設定する - リトライストームを防ぎます
- ゴールデンメトリクスを監視する - 成功率、レイテンシー、スループット
非推奨事項
- check を省略しない - 変更後は必ず
linkerd checkを実行してください - 過剰に構成しない - Linkerd のデフォルト設定は妥当です
- ServiceProfile を無視しない - 高度な機能を利用できるようになります
- タイムアウトを忘れない - ルートごとに適切な値を設定してください
コメント
Markdown 対応