Linkerd の ServiceProfile は、HTTP トラフィックに対するルート単位の可観測性・信頼性制御を可能にするカスタムリソースです。これにより、各エンドポイントごとのメトリクス収集、再試行ポリシー、タイムアウト設定が実現されます。

Linkerd プロキシは、着信 HTTP リクエスト（HTTPS 以外）の宛先サービスを、以下の順序で解析します：l5d-dst-override ヘッダー → :authority → Host。ポート番号（例：:8080）は自動除去され、残ったホスト名が完全修飾ドメイン名（FQDN）に正規化されます。例えば api.prod.svc.cluster.local という宛先は、prod 名前空間内の api サービスとマッチします。

サービスプロファイルの適用優先順位は、**送信元 Pod の名前空間**にあるプロファイルが、**宛先サービスの名前空間**にあるものより高くなります。この挙動により、外部サービスや他チーム管理のサービスに対しても、自チームの命名空間内で制御可能なプロファイルを定義できます。

ExternalName タイプのサービスの場合、プロファイル名には <service-name>.<namespace>.svc.cluster.local を使用します。たとえば以下のようなサービス定義があるとき：

apiVersion: v1
kind: Service
metadata:
  name: payment-gateway
  namespace: finance
spec:
  type: ExternalName
  externalName: gateway.payments.example.net

対応する ServiceProfile の名前は payment-gateway.finance.svc.cluster.local となります。

ルートへのリクエスト関連付けを検証するには、linkerd viz tap を利用します：

linkerd viz tap -n default deploy/frontend --headers | grep "req.*rt_route"

出力に rt_route=GET /users/{id} のようなアノテーションが含まれていれば、該当ルートが正しく認識されています。逆に、rt_route が一切表示されない場合は、プロファイルが未適用またはルート定義が不十分です。

OpenAPI 仕様からの自動生成

サービスが OpenAPI v2/v3（Swagger）仕様を提供している場合、--open-api オプションでプロファイルを一括生成できます：

linkerd profile \
  --open-api ./specs/user-service.openapi.yaml \
  user-service.default.svc.cluster.local \
  | kubectl apply -f -

生成された YAML には、すべてのパス・メソッド組み合わせに基づく routes 定義と、デフォルトの再試行・タイムアウト設定が含まれます。

Protocol Buffer からの生成

gRPC サービス向けには、.proto ファイルからルート定義を抽出可能です：

linkerd profile \
  --proto ./protos/user_service.proto \
  user-svc.production.svc.cluster.local \
  | kubectl apply -f -

このコマンドは、service UserService 内の各 RPC メソッドを POST /user.UserService/MethodName 形式のルートとして登録します。

リアルタイムトラフィック分析によるプロファイル作成

仕様書が存在しない場合でも、実際のトラフィックをサンプリングしてプロファイルを構築できます：

linkerd viz profile \
  -n staging \
  auth-svc.staging.svc.cluster.local \
  --tap deploy/auth-api \
  --tap-duration 15s \
  | kubectl apply -f -

この操作は、指定したデプロイメントから15秒間の HTTP リクエストをキャプチャし、出現頻度の高いパスとメソッドを基にルート定義を生成します。結果は最小限の再試行／タイムアウト設定とともに出力されます。

手動編集用テンプレートの取得

既存のプロファイルをベースにカスタマイズしたい場合は、空のテンプレートを生成できます：

linkerd profile \
  -n production \
  order-svc.production.svc.cluster.local \
  --template \
  > order-profile.yaml

生成される YAML には、routes 配列のプレースホルダーと、各ルートに適用可能な isRetryable、timeout、name フィールドの例が記載されています。編集後は通常通り kubectl apply で適用可能です。