Container Compute Service:Sidecar コンテナーの起動とシャットダウンシーケンスの構成

機能の説明

ACS シナリオでは、仮想ノードの制限により、Kubernetes DaemonSet 機能はサポートされていません。このような場合、DaemonSet を必要とするシナリオでは、Pod に Sidecar コンテナーを追加することで同様の効果を実現できます。ただし、Sidecar コンテナーのライフサイクルは Pod のライフサイクルから独立させることはできません。DaemonSet と同様の効果を実現するには、Sidecar コンテナーの起動とシャットダウンのシーケンスを構成する必要があります。これにより、Pod の作成時に Sidecar コンテナーがメインアプリケーションコンテナーの前に起動し、ジョブタイプの Pod 内のアプリケーションコンテナーがすでに終了している場合には Sidecar コンテナーが強制的に終了されることが保証されます。

これらのシナリオに対して、ACS は 2 つの方法で Sidecar コンテナーの起動とシャットダウンのシーケンスを構成することをサポートしています。

• ネイティブ Kubernetes Sidecar 宣言

  Kubernetes 1.29 以降のバージョンでは、デフォルトで ネイティブ Sidecar 宣言 がサポートされています。これは、Sidecar を Init コンテナー として構成し、restartPolicy を Always に設定することを含みます。

  説明

  ネイティブ Sidecar メソッドは、Sidecar コンテナーを特別な Init コンテナーとして実装します。Pod が起動すると、アプリケーションコンテナーは、正常に実行される前に Sidecar コンテナーの起動が完了するのを待つ必要があります。同時に、restartPolicy: Always 構成により、Sidecar コンテナーはメインアプリケーションコンテナーや他の Init コンテナーに影響を与えることなく、起動、停止、再起動が可能になります。

• ACS カスタム宣言

  Kubernetes 1.28 以前のバージョンでは、ACS は通常のコンテナーに特別な環境変数 __IS_SIDECAR__ を設定して、そのコンテナーが Sidecar であるかどうかをマークすることをサポートしています。

  重要

  ACS カスタム宣言メソッドは、通常のコンテナーを Sidecar として宣言することをサポートしており、Sidecar は他の通常のコンテナーの前に起動し、restartPolicy を Always に設定した原則に従って自動的にリトライします。同時に、ACS クラスターは Kubernetes の下位バージョン (1.28 以前) に対して互換性の調整を行い、コンテナーのステータスが更新されるようにしています。

  ただし、より高いバージョンや他のタイプの Kubernetes クラスターでは、コンテナーのステータス更新に関する Kubernetes の制限により、ACS カスタム宣言された Sidecar コンテナーの containerStatus と Pod ステータスは、失敗したリトライ後に Running に更新されません。実際の Pod ステータスをご参照ください。クラスターをバージョン 1.29 以降にアップグレードし、ネイティブ Kubernetes Sidecar 宣言メソッドを使用することをお勧めします。

構成手順

構成例

1. test-sidecar.yaml の内容例は次のとおりです。これは、2 つのコンテナーを含むジョブを作成することを示しています。app はアプリケーションコンテナーで、sidecar は Sidecar コンテナーです。

   ACS カスタム宣言

   apiVersion: batch/v1
   kind: Job
   metadata:
     name: test
   spec:
     template:
       metadata:
         labels:
           app: test
       spec:
         containers:
         - name: app
           image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/busybox:1.28
           command: ['sh', '-c', 'for i in $(seq 1 10);do echo "logging" >> /var/logs.txt; sleep 1; done']
         - name: sidecar
           image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/busybox:1.28
           command: ['sh', '-c', 'touch /var/logs.txt && tail -F /var/logs.txt']
           env:
           - name: __IS_SIDECAR__   # このコンテナーの環境変数を設定
             value: "true"          # このコンテナーを sidecar としてマーク
         restartPolicy: Never
     backoffLimit: 2

   ネイティブ Kubernetes Sidecar 宣言

   apiVersion: batch/v1
   kind: Job
   metadata:
     name: test
   spec:
     template:
       metadata:
         labels:
           app: test
       spec:
         initContainers:
         - name: sidecar
           image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/busybox:1.28
           command: ['sh', '-c', 'touch /var/logs.txt && tail -F /var/logs.txt']
           restartPolicy: Always  # このコンテナーを sidecar として宣言
         containers:
         - name: app
           image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/busybox:1.28
           command: ['sh', '-c', 'for i in $(seq 1 10);do echo "logging" >> /var/logs.txt; sleep 1; done']
         restartPolicy: Never
     backoffLimit: 2

2. 次のコマンドを実行してジョブを作成します。

   kubectl apply -f test-sidecar.yaml

3. ジョブの詳細と対応する Pod の詳細を表示して、環境変数の効果を確認します。

   • ジョブの実行が完了し、ステータスが Succeeded であることを確認します。

     kubectl describe job <job-name>

     以下に例を示します。

     

4. Sidecar コンテナーの詳細を表示して、コンテナーの起動シーケンスと実際の終了コードを確認します

   kubectl describe pod <pod-name>

   • コンテナーの起動シーケンスの例は次のとおりです。sidecar コンテナーが app コンテナーの前に起動することがわかります。これにより、アプリケーションのメインコンテナーが依存する sidecar 機能 (トラフィック転送など) が事前に準備されていることが保証されます。さらに、app コンテナーの実行が終了した後 (10 秒後)、sidecar コンテナーが強制的に強制終了され、ジョブ Pod が完了できることが保証されます。

     

   • 終了コードの例は次のとおりです。sidecar コンテナーが終了コード 0 で強制終了されていることがわかります。これにより、ジョブ Pod が正常に実行されたか失敗したかの判断を妨げないことが保証されます。