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

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

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

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

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

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

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

  • Dockerfile

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

  • deployment_spec.yaml ファイル

    • /sys/fs/cgroup の hostPath 定義と volumeMounts 定義を削除します。
    • securityContext 定義を削除します。
    • readinessProbe 定義を削除します。
    • logs-config 用の mountPath と configMap の定義はそのままにできますが、現在、ロギングは簡略化された 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

    cgroups の volumeMounts 定義と 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 つ）を追加します。

次のステップ