IT 技書の森

サイドカーインジェクション

Kubernetes で Pod にサイドカーコンテナを自動的に注入し、横断的関心事を透過的に追加する仕組み

Kubernetesアーキテクチャ

サイドカーインジェクションとは

サイドカーインジェクション (Sidecar Injection) は、Kubernetes の Admission Webhook を使って、Pod の作成時にサイドカーコンテナを自動的に注入する仕組みである。開発者が Pod の定義を変更せずに、ログ収集、メトリクス、mTLS などの横断的関心事を透過的に追加できる。

Istio、Linkerd、AWS App Mesh などのサービスメッシュが代表的な利用例だ。

注入の仕組み

1. kubectl apply -f deployment.yaml
2. API Server が Pod 作成リクエストを受信
3. Mutating Admission Webhook がリクエストをインターセプト
4. Webhook がサイドカーコンテナの定義を Pod spec に追加 (JSON Patch)
5. 変更された Pod spec で Pod が作成される

[開発者の YAML]          [実際に作成される Pod]
containers:              containers:
  - name: app              - name: app
    image: myapp:1.0         image: myapp:1.0
                           - name: istio-proxy    ← 自動注入
                             image: envoy:1.28

Istio での設定

Namespace に istio-injection=enabled ラベルを付けると、その Namespace に作成される全 Pod に Envoy プロキシが自動注入される。

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    istio-injection: enabled

注入後の Pod 構成:

Pod
├── app (メインコンテナ)
│   └── localhost:3000 でリッスン
└── istio-proxy (自動注入されたサイドカー)
    ├── インバウンド/アウトバウンドトラフィックをインターセプト
    ├── mTLS による通信の暗号化
    ├── リトライ・タイムアウト・サーキットブレーカー
    ├── メトリクス収集 (Prometheus 形式)
    └── 分散トレーシング (Jaeger/Zipkin)

Kubernetes 1.28 のネイティブサイドカー

Kubernetes 1.28 で initContainers に restartPolicy: Always を指定するネイティブサイドカーが導入された。従来の Admission Webhook による注入とは異なり、Kubernetes 自体がサイドカーのライフサイクルを管理する。

initContainers:
  - name: log-collector
    image: fluentbit:2.1
    restartPolicy: Always  # ← ネイティブサイドカー

メリット:

  • メインコンテナより先に起動し、メインコンテナの終了後も動作する
  • ログ収集エージェントがメインコンテナの起動前からログを収集できる
  • Job の完了判定がサイドカーに影響されない

メリットとデメリット

メリット デメリット
アプリコードの変更不要 Pod のリソース消費が増加 (Envoy: 50〜100MB)
全 Pod に一貫した設定を適用 デバッグが複雑化 (ネットワークの問題がサイドカー起因か判別しにくい)
横断的関心事の一元管理 サイドカーの起動順序に依存する問題
セキュリティ (mTLS) の透過的な適用 Webhook の障害が Pod 作成をブロック

サイドカーインジェクションが不要なケース

すべてのサービスにサービスメッシュが必要なわけではない。サービス数が少ない (10 未満)、サービス間通信が単純、mTLS が不要な場合は、サイドカーのオーバーヘッドに見合わない。

サイドカーインジェクションについては関連書籍でも詳しく扱われている。

関連用語