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

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

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

Istio や Linkerd などのサービスメッシュが代表的な利用例だ。AWS App Mesh も同じ仕組みを使っていたが、2026 年時点で新規の受付を終了し、2026 年 9 月 30 日にサポート終了が予定されているため、これから選ぶ構成には含めない。

注入の仕組み

Kubernetes の Mutating Admission Webhook を利用して、Pod の作成リクエストをインターセプトし、サイドカーコンテナの定義を自動的に Pod spec に追加する。開発者は自分の YAML にサイドカーを記述する必要がなく、Webhook が透過的に注入する。

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:              initContainers:
  - name: app              - name: istio-init     ← 自動注入 (iptables 設定)
    image: myapp:1.0         image: istio/proxyv2
                         containers:
                           - name: app
                             image: myapp:1.0
                           - name: istio-proxy    ← 自動注入
                             image: istio/proxyv2

注入が起きるのは Pod の作成時だけである。Namespace にラベルを付けても、すでに動いている Pod は書き換わらない - kubectl rollout restart などで Pod を作り直したときに初めてサイドカーが入る。書き換わる対象も Pod であって Deployment ではないため、kubectl get deployment のコンテナ列は 1 つのまま変わらず、注入されたかどうかは kubectl describe pod か Pod の READY 列 (1/1 が 2/2 になる) で見る。

トラフィックの割り込みは、プロキシを足すだけでは成立しない。Pod 内の iptables を書き換えて、アプリ宛の通信をプロキシ経由へ曲げる工程が必要になる。既定ではこれを注入時に追加される istio-init Init コンテナが行うため、NET_ADMIN と NET_RAW を持つ特権 Init コンテナを全ワークロードに配ることになる。この権限配布を避けたい場合は、ノードに 1 つだけ特権 Pod を置く Istio CNI ノードエージェントに肩代わりさせる (istio-init は不要になる)。

Istio での設定

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

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

Namespace 単位より細かい制御もラベルで行う。Pod 側に sidecar.istio.io/inject: "false" を付けるとその Pod だけ注入から外れ、無効を指示するラベルが 1 つでもあれば注入されない (無効側が勝つ)。コントロールプレーンのリビジョンを使っている構成では istio.io/rev=<リビジョン名> を使い、同じ Namespace に istio-injection と istio.io/rev が両方あるときは istio-injection が優先される。どちらのラベルも付いていない Pod は既定では注入されない。

Webhook を経由せず、マニフェストを手元で書き換える手段もある。istioctl kube-inject -f deployment.yaml はサイドカー入りのマニフェストを出力するので、注入結果をリポジトリに残したい場合や Webhook を有効にできない環境で使う。ただし自動注入と違って Istio を上げても追随しないため、アップグレードのたびに再注入する運用が要る。

注入後の Pod 構成:

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

ネイティブサイドカー (Kubernetes 標準機能)

initContainers に並べたコンテナへ restartPolicy: Always を付けると、Init コンテナの特殊形として Pod の生存期間中動き続けるサイドカーになる。Kubernetes 1.28 で SidecarContainers フィーチャーゲートの alpha として入り、1.29 で既定有効、1.33 で安定版になった。Admission Webhook による注入とは違い、注入する主体を用意せずに Kubernetes 自身がライフサイクルを管理する。

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

Init コンテナの特殊形であることが、そのまま挙動に出る。

起動順: initContainers の順序保証を受け継ぐ。kubelet はサイドカーが起動済みと判定された時点 (プロセスが動き出す、または startupProbe の成功) で次の Init コンテナへ進むため、通常の Init コンテナと混在させて「証明書を取得 → ログ収集を常駐 → アプリ起動」のように並べられる。ログ収集エージェントをここに置けば、メインコンテナの最初の 1 行から取りこぼさない。
終了順: Pod の終了時、kubelet はメインコンテナが完全に停止するまでサイドカーの終了を後回しにし、その後 Pod spec の記載と逆順に落とす。
終了猶予: メインコンテナが猶予時間を使い切った場合、サイドカーは SIGTERM の直後に SIGKILL を受け得る。Pod 終了時にサイドカーの終了コードが 0 以外になるのは正常な光景で、外部ツールでエラー扱いしない。
プローブ: 通常の Init コンテナでは働かないプローブが使える。サイドカーに readinessProbe を書くと、その結果が Pod の Ready 判定に入る。
Job: メインコンテナが終われば、サイドカーが動いていても Job は完了する。常駐プロセスを普通の containers に置くと Job が終わらない、という詰まりをここで外せる。

メリットとデメリット

メリット	デメリット
アプリコードの変更不要	Pod ごとにプロキシ分のリソースが増える (Istio 1.24 の公表値で、1,000 req/s・1 KB ペイロードのときサイドカー 1 つあたり約 0.20 vCPU・60 MB)
全 Pod に一貫した設定を適用	デバッグが複雑化 (ネットワークの問題がサイドカー起因か判別しにくい)
横断的関心事の一元管理	サイドカーの起動順序に依存する問題
セキュリティ (mTLS) の透過的な適用	Webhook を呼べないと Pod 作成自体が失敗する (ReplicaSet に `FailedCreate` が並ぶ)