サイドカーコンテナ

FEATURE STATE: Kubernetes v1.33 [stable](enabled by default)

サイドカーコンテナは、同じPod内でメインのアプリケーションコンテナと共に実行されるセカンダリコンテナです。 これらのコンテナは、ロギング、モニタリング、セキュリティ、データ同期などの追加サービスや機能を提供することで、プライマリの アプリケーションコンテナ の機能を強化または拡張するために使用されます。 メインのアプリケーションコードを直接変更する必要はありません。

通常、Pod内にはアプリケーションコンテナが1つだけ含まれます。 例えば、ローカルWebサーバーを必要とするWebアプリケーションがある場合、ローカルWebサーバーがサイドカーであり、Webアプリケーション自体がアプリケーションコンテナです。

Kubernetesにおけるサイドカーコンテナ

Kubernetesは、サイドカーコンテナをInitコンテナの特殊なケースとして実装しています。 サイドカーコンテナはPod起動後も実行され続けます。 このドキュメントでは、Pod起動時にのみ実行されるコンテナを明確に指すために、通常のInitコンテナ という用語を使用します。

クラスターでSidecarContainersフィーチャーゲートが有効になっている場合(この機能はKubernetes v1.29以降デフォルトで有効です)、PodのinitContainersフィールドにリストされているコンテナに対してrestartPolicyを指定できます。 これらの再起動可能な サイドカー コンテナは、同じPod内の他のInitコンテナやメインアプリケーションコンテナから独立しています。 メインアプリケーションコンテナや他のInitコンテナに影響を与えることなく、これらを起動、停止、または再起動することができます。

また、Initコンテナやサイドカーコンテナとして定義されていない複数のコンテナでPodを実行することもできます。 これは、Pod内のコンテナがPod全体の動作に必要であるが、どのコンテナを最初に起動または停止するかを制御する必要がない場合に適しています。 また、コンテナレベルのrestartPolicyフィールドをサポートしていない古いバージョンのKubernetesをサポートする必要がある場合にも、この方法を使用できます。

アプリケーションの例

以下は、2つのコンテナを持つDeploymentの例で、そのうちの1つがサイドカーコンテナです:

application/deployment-sidecar.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: alpine:latest
          command: ['sh', '-c', 'while true; do echo "logging" >> /opt/logs.txt; sleep 1; done']
          volumeMounts:
            - name: data
              mountPath: /opt
      initContainers:
        - name: logshipper
          image: alpine:latest
          restartPolicy: Always
          command: ['sh', '-c', 'tail -F /opt/logs.txt']
          volumeMounts:
            - name: data
              mountPath: /opt
      volumes:
        - name: data
          emptyDir: {}

サイドカーコンテナとPodのライフサイクル

InitコンテナがrestartPolicyをAlwaysに設定して作成された場合、Podの全ライフサイクルを通じて起動し、実行され続けます。 これは、メインのアプリケーションコンテナから分離した補助的なサービスを実行する際に役立ちます。

このInitコンテナにreadinessProbeが指定されている場合、その結果はPodのready状態を判定するために使用されます。

これらのコンテナはInitコンテナとして定義されているため、通常のInitコンテナと同じ順序と順次実行の保証の恩恵を受けます。 これにより、複雑なPod初期化フローの際に、サイドカーコンテナと通常のInitコンテナを混在させることができます。

通常のInitコンテナと比較して、initContainers内で定義されたサイドカーコンテナは起動後も実行され続けます。 これは、Podの.spec.initContainers内に複数のエントリがある場合に重要です。 サイドカー形式のInitコンテナが実行状態になった後(kubeletがそのInitコンテナのstartedステータスをtrueに設定した後)、kubeletは順序付けられた.spec.initContainersリストから次のInitコンテナを起動します。 このステータスは、コンテナ内でプロセスが実行されておりStartup Probeが定義されていない場合、またはstartupProbeが成功した結果として、trueになります。

Podの終了時には、kubeletはメインのアプリケーションコンテナが完全に停止するまで、サイドカーコンテナの終了を引き延ばします。 その後、サイドカーコンテナはPodの仕様内で定義された順序と逆の順序でシャットダウンされます。 このアプローチにより、サイドカーコンテナは、そのサービスが不要になるまで、Pod内の他のコンテナをサポートし続けることが保証されます。

サイドカーコンテナを持つJob

Kubernetes形式のInitコンテナを使用してサイドカーコンテナを使用するJobを定義した場合、各Pod内のサイドカーコンテナは、メインコンテナが終了した後にJobが完了することを妨げません。

以下は、2つのコンテナを持つJobの例で、そのうちの1つがサイドカーコンテナです:

application/job/job-sidecar.yaml 
apiVersion: batch/v1
kind: Job
metadata:
  name: myjob
spec:
  template:
    spec:
      containers:
        - name: myjob
          image: alpine:latest
          command: ['sh', '-c', 'echo "logging" > /opt/logs.txt']
          volumeMounts:
            - name: data
              mountPath: /opt
      initContainers:
        - name: logshipper
          image: alpine:latest
          restartPolicy: Always
          command: ['sh', '-c', 'tail -F /opt/logs.txt']
          volumeMounts:
            - name: data
              mountPath: /opt
      restartPolicy: Never
      volumes:
        - name: data
          emptyDir: {}

アプリケーションコンテナとの違い

サイドカーコンテナは、同じPod内で アプリケーションコンテナ と並行して実行されます。 ただし、サイドカーコンテナは主要なアプリケーションロジックを実行するのではなく、メインアプリケーションに補助的な機能を提供します。

サイドカーコンテナは独自の独立したライフサイクルを持ちます。 アプリケーションコンテナとは独立して、起動、停止、再起動できます。 これは、メインアプリケーションに影響を与えることなく、サイドカーコンテナを更新、スケール、またはメンテナンスできることを意味します。

サイドカーコンテナは、プライマリコンテナと同じネットワークおよびストレージ名前空間を共有します。 このように共存することで、密接に相互作用しリソースを共有できます。

Kubernetesの観点からは、サイドカーコンテナのグレースフルな終了はそれほど重要ではありません。 他のコンテナが、割り当てられたグレースフルな終了時間をすべて消費した場合、サイドカーコンテナはグレースフルに終了する時間を持つ前に、SIGTERMシグナルに続いてSIGKILLシグナルを受信します。 そのため、サイドカーコンテナにおいては、Pod終了時の0以外の終了コード(0は正常終了を示します)は正常なものであり、一般的に外部ツールによって無視されるべきです。

Initコンテナとの違い

サイドカーコンテナはメインコンテナと並行して動作し、その機能を拡張して追加のサービスを提供します。

サイドカーコンテナは、メインのアプリケーションコンテナと同時に実行されます。 サイドカーコンテナはPodのライフサイクル全体を通じてアクティブであり、メインコンテナとは独立して起動および停止できます。 Initコンテナとは異なり、サイドカーコンテナは、ライフサイクルを制御するためのProbeをサポートしています。

サイドカーコンテナは、メインのアプリケーションコンテナと直接やり取りできます。 これは、Initコンテナと同様に常に同じネットワークを共有し、オプションでボリューム(ファイルシステム)も共有できるためです。

Initコンテナはメインコンテナが起動する前に停止するため、InitコンテナはPod内のアプリケーションコンテナとメッセージを交換できません。 データの受け渡しは一方向です(例えば、InitコンテナがemptyDirボリューム内に情報を配置することはできます)。

サイドカーコンテナのイメージを変更してもPodは再起動されませんが、コンテナの再起動はトリガーされます。

コンテナ内でのリソース共有

Initコンテナ、サイドカーコンテナ、アプリケーションコンテナの実行順序を考慮すると、リソース使用に関して以下のルールが適用されます:

  • すべてのInitコンテナで定義された特定のリソース要求または制限のうち、最も高い値が実効Init要求/制限となります。 いずれかのリソースにリソース制限が指定されていない場合、これが最も高い制限と見なされます。
  • リソースに対するPodの実効要求/制限は、Podのオーバーヘッドと以下のうち高い方の合計です:
    • すべての非Initコンテナ(アプリケーションコンテナとサイドカーコンテナ)のリソース要求/制限の合計
    • リソースに対する実効Init要求/制限
  • スケジューリングは実効要求/制限に基づいて行われます。 これは、InitコンテナがPodのライフタイム中には使用されない初期化用のリソースを予約できることを意味します。
  • Podの実効QoS tierのQoS(サービス品質) tierは、Initコンテナ、サイドカーコンテナ、アプリケーションコンテナすべてに対するQoS tierです。

クォータと制限は、実効Pod要求と制限に基づいて適用されます。

サイドカーコンテナとLinux cgroup

Linuxでは、Podレベルのコントロールグループ(cgroup)に対するリソース割り当ては、スケジューラーと同様に、実効的なPod要求/制限に基づいて行われます。

次の項目

最終更新 January 18, 2026 at 2:07 AM PST: [ja] Update content/ja/docs/concepts/workloads/pods/sidecar-containers.md (#53639) (4ee66ed699)