拡張ランタイムのコンテナ ワークロードをアップグレードする

Migrate to Containers バージョン 1.7.x および 1.8.x を使用して作成された既存のコンテナ ワークロードが存在する場合は、それらを変換して、簡素化された Linux サービス マネージャーを使用できます。この変換により、これらのコンテナを GKE Autopilot クラスタ上で実行できます。

変換を行うには、Dockerfile と、元の移行を行ったときに作成された deployment_spec.yaml ファイルを編集します。編集したら、コンテナのワークロードを Autopilot クラスタにデプロイできます。

コンテナ ワークロードの変換について

既存のワークロードを変換する手順は、ステートレス ワークロードまたはステートフル ワークロードのどちらを変換するかによって異なります。

ステートフル ワークロードは、状態情報を管理または保存するワークロードです。ステートフル ワークロードの場合、spec.containers.volumeMountsStatefulSet を使用することで、追加のボリュームをマウントすることがよくあります。volumeMounts 定義は保持し、/sys/fs/cgroup の定義は削除してください。詳細については、外部ボリュームのマウントをご覧ください。

既存のワークロードを変換する一般的なプロセスでは、以下を編集する必要があります。

  • Dockerfile

    • Migrate to Containers のバージョンを 1.15.0 に設定します。
    • logs.yaml ファイルをコンテナ イメージにコピーする 2 つの ADD コマンドを挿入します。
    • servicemanager_generate_config ユーティリティ用の RUN コマンドを挿入します。
  • deployment_spec.yaml ファイル

    • /sys/fs/cgrouphostPath 定義と volumeMounts 定義を削除します。
    • securityContext 定義を削除します。
    • readinessProbe 定義を削除します。
    • logs-config 用の mountPathconfigMap の定義はそのままにできますが、現在、ロギングは簡略化された Linux サービス マネージャーでは機能しません。

具体的な変換プロセスについては、以下のセクションをご覧ください。

ステートレス ワークロードを変換する

次の例は、ステートレス コンテナ ワークロードを変換する方法を示しています。

  1. deployment_spec.yaml ファイルを含む、既存の移行アーティファクトを含むディレクトリを探します。

  2. Dockerfile を編集して、プロダクト バージョンを設定し、logs.yaml ファイルをコピーして、servicemanager_generate_config ユーティリティを実行します。

    ...
    # Set the product version to 1.15.0:
    FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.15.0 as migrate-for-anthos-runtime
    
    ...
    
    ADD blocklist.yaml /.m4a/blocklist.yaml
    # Insert the ADD commands to copy the `logs.yaml` file to the container image:
    ADD logs.yaml /code/config/logs/logsArtifact.yaml
    ADD logs.yaml /code/config/logs/logs.yaml
    
    # Insert the RUN command for servicemanager_generate_config:
    RUN /servicemanager_generate_config build-all -o /.m4a/
    
    # Migrate to Containers image includes entrypoint
    ENTRYPOINT [ "/.v2k.go" ]
  3. エディタで deployment_spec.yaml ファイルを開きます。次に例を示します。

    vi  deployment_spec.yaml
  4. ファイル内で次のセクションを見つけて、指定された行を削除します。

    apiVersion: apps/v1 
    kind: Deployment
    metadata: 
      creationTimestamp: null 
      name: IMAGE_NAME  
          
        spec:
          containers:
          - image: gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL
            name: IMAGE_NAME
    # Delete the following lines:
            readinessProbe:
              exec:
                command:
                - /code/ready.sh
            resources: {}
            securityContext:
              privileged: true
            volumeMounts:
            - mountPath: /sys/fs/cgroup
              name: cgroups
            - mountPath: /code/config/logs
              name: logs-config
          volumes:
          - hostPath:
              path: /sys/fs/cgroup
              type: Directory
            name: cgroups
          - configMap:
              name: suitecrm-crddefault-logs
            name: logs-config
    # Stop the delete here.
  5. 次の行を追加して、HC_V2K_SERVICE_MANAGER 環境変数を設定します。

    spec:
      containers:
      - image: gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL
        name: IMAGE_NAME
    # Add the following lines:
        env:
          - name: HC_V2K_SERVICE_MANAGER
            value: "true"
  6. ファイルを保存します。

  7. ターゲット クラスタに Docker イメージ レジストリへの読み取りアクセス権が付与されていることを確認するで説明しているように、ターゲット クラスタに Docker イメージ レジストリへの読み取りアクセス権が付与されていることを確認します。

  8. 更新されたイメージをビルドし、更新されたバージョンタグで Container Registry に push して、ビルドが完了するのに十分な時間を確保します。次の例では、イメージは現在のディレクトリにあります。

    gcloud builds submit --timeout 4h --tag gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL .
  9. コンテナをデプロイします。

    kubectl apply -f deployment_spec.yaml

    deployment_spec.yaml で必要な変更を行わずにデプロイ仕様を Autopilot クラスタに適用すると、次の形式のエラー メッセージが表示されます。

    "Trying to run without root privileges is not possible. Did you try to use the new runtime? In that case please pass the environment variable HC_V2K_SERVICE_MANAGER=true to the pod"

  10. クラスタにデプロイされている Pod を表示します。

    kubectl get pods

ステートフル ワークロードを変換する

次の例は、ステートフル コンテナ ワークロードを変換する方法を示しています。

  1. deployment_spec.yaml ファイルを含む、既存の移行アーティファクトを含むディレクトリを探します。

  2. Dockerfile を編集して、プロダクト バージョンを設定し、servicemanager_generate_config ユーティリティを実行します。

    ...
    # Set the product version to 1.15.0:
    FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.15.0 as migrate-for-anthos-runtime
    
    ...
    
    ADD blocklist.yaml /.m4a/blocklist.yaml
    # Insert the ADD commands to copy the `logs.yaml` file to the container image:
    ADD logs.yaml /code/config/logs/logsArtifact.yaml
    ADD logs.yaml /code/config/logs/logs.yaml
    
    # Insert the RUN command for servicemanager_generate_config:
    RUN /servicemanager_generate_config build-all -o /.m4a/
    
    # Migrate to Containers image includes entrypoint
    ENTRYPOINT [ "/.v2k.go" ]
  3. エディタで deployment_spec.yaml ファイルを開きます。例:

    vi  deployment_spec.yaml
  4. ファイル内の次の 3 つのセクションを見つけ、指定された行を削除します。

    apiVersion: apps/v1 
    kind: StatefulSet  
    ... 
    spec: 
      containers: 
      - image: gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL 
        name: IMAGE_NAME 
    # Delete the following lines:
        readinessProbe: 
          exec: 
            command: 
            - /code/ready.sh 
        resources: {} 
        securityContext: 
          privileged: true 
    # Stop the delete here.
        volumeMounts: 
    # Delete the following lines:
        - mountPath: /sys/fs/cgroup 
          name: cgroups 
    # Stop the delete here.
        - mountPath: /opt/suitecrm-7.10.5-0/mysql/data 
          name: data-pvc-0-1b12-d0af-48b3-9f5e-6c25fa5 
          subPath: opt/suitecrm-7.10.5-0/mysql/data 
      volumes:
    # Delete the following lines:
      - hostPath:
          path: /sys/fs/cgroup 
          type: Directory 
        name: cgroups 
    # Stop the delete here.
      - name: data-pvc-2-d0af-48b3-9f5e09c25fa5 
        persistentVolumeClaim: 
          claimName: data-pvc-0-1a2-d0af-48b3-9f5e-605fa5

    cgroupsvolumeMounts 定義と volumes の定義のみを削除し、残りの定義は残します。

  5. 次の行を追加して、HC_V2K_SERVICE_MANAGER 環境変数を設定します。

    spec: 
      containers: 
      - image: gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL
        name: IMAGE_NAME 
    # Add the following lines:
        env:
        - name: HC_V2K_SERVICE_MANAGER 
          value: "true" 
    # Stop the add here.
        volumeMounts: 
        - mountPath: /opt/suitecrm-7.10.5-0/mysql/data 
          name: data-pvc-0-1b12-d0af-48b3-9f5e-6c25fa5 
          subPath: opt/suitecrm-7.10.5-0/mysql/data 
      volumes:
      - name: data-pvc-2-d0af-48b3-9f5e09c25fa5 
        persistentVolumeClaim: 
          claimName: data-pvc-0-1a2-d0af-48b3-9f5e-605fa5
  6. ファイルを保存します。

  7. ターゲット クラスタに Docker イメージ レジストリへの読み取りアクセス権が付与されていることを確認するで説明しているように、ターゲット クラスタに Docker イメージ レジストリへの読み取りアクセス権が付与されていることを確認します。

  8. 更新されたイメージをビルドし、更新されたバージョンタグで Container Registry に push して、ビルドが完了するのに十分な時間を確保します。次の例では、イメージは現在のディレクトリにあります。

    gcloud builds submit --timeout 4h --tag gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL .
  9. コンテナをデプロイします。

    kubectl apply -f deployment_spec.yaml

    deployment_spec.yaml で必要な変更を行わずにデプロイ仕様を Autopilot クラスタに適用すると、次の形式のエラー メッセージが表示されます。

    "Trying to run without root privileges is not possible. Did you try to use the new runtime? In that case please pass the environment variable HC_V2K_SERVICE_MANAGER=true to the pod"

  10. クラスタにデプロイされている Pod を表示します。

    kubectl get pods

変換後のタスク

既存の移行を、簡素化された Linux サービス マネージャーを使用するように変換したら、次のように変更できます。

  • 移行されたワークロードで使用されるサービスを更新します。
  • 新しいサービスを追加します。

どちらの場合も、Dockerfile を編集してから、コンテナ イメージを再ビルドする必要があります。

サービスの更新

このセクションでは、Dockerfile を編集して、移行されたワークロードの /etc/systemd に加えられた変更に基づいて、コンテナ内の services-config.yaml ファイルを更新します。

既存のサービスへ変更を加えるために、コンテナ イメージを更新するには:

  1. Dockerfile 内に servicemanager_generate_config コマンドを追加します。

    ...
    FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.15.0 as migrate-for-anthos-runtime
    
    ...
    
    ADD blocklist.yaml /.m4a/blocklist.yaml
    
    # Use the update command for servicemanager_generate_config to update the configuration:
    RUN /servicemanager_generate_config update -u /.m4a/
    
    # Migrate to Containers image includes entrypoint
    ENTRYPOINT [ "/.v2k.go" ]
  2. 更新されたイメージをビルドし、更新されたバージョンタグで Container Registry に push して、ビルドが完了するのに十分な時間を確保します。次の例では、イメージは現在のディレクトリにあります。

    gcloud builds submit --timeout 4h --tag gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL .
  3. 新しくビルドされたイメージをデプロイします。

    kubectl set image deployment/myWorkload my-app=gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL --record

サービスの追加

コンテナ イメージにサービスを追加するには:

  1. Dockerfile 内に servicemanager_generate_config コマンドを追加します。

    ...
    FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.15.0 as migrate-for-anthos-runtime
    
    ...
    
    ADD blocklist.yaml /.m4a/blocklist.yaml
    
    # This example adds the redis-server service.
    # Add the following lines to install redis-server.
    RUN apt-get update && apt-get -y install redis-server
    
    # Use the servicemanager_generate_config add command to add
    # redis-server to the configuration:
    RUN /servicemanager_generate_config add redis-server -u /.m4a/
    
    # Migrate to Containers image includes entrypoint
    ENTRYPOINT [ "/.v2k.go" ]
  2. 更新されたイメージをビルドし、更新されたバージョンタグで Container Registry に push して、ビルドが完了するのに十分な時間を確保します。次の例では、イメージは現在のディレクトリにあります。

    gcloud builds submit --timeout 4h --tag gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL .
  3. 新しくビルドされたイメージをデプロイします。

    kubectl set image deployment/myWorkload my-app=gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL --record

servicemanager_generate_config 構文

servicemanager_generate_config ユーティリティでは、次のオプションが使用できます。

  • build-all -o /.m4a/: 移行を再ビルドし、構成を m4a ディレクトリに書き込みます。ディレクトリの名前を変更しないでください。

    最初に移行を変換して、簡素化された Linux のサービス マネージャーを使用するときに、この形式のコマンドを使用します。

  • update -u /.m4a/: m4a ディレクトリにある既存のサービスのリストを更新します。ディレクトリの名前を変更しないでください。

  • add SERVICE_NAME -u /.m4a/: 移行にサービス名を追加し、構成を m4a ディレクトリに書き込みます。ディレクトリの名前を変更しないでください。

    複数のサービスを追加するには、複数の RUN /servicemanager_generate_config コマンド(サービスごとに 1 つ)を追加します。

次のステップ