Linux VM の移行計画をカスタマイズする

移行計画を実行する前に、計画を確認して、必要に応じてカスタマイズしてください。移行計画の詳細は、ソース VM からワークロード コンテナ アーティファクトを抽出する際や、コンテナ イメージを本番環境のクラスタなどの他のクラスタにデプロイする際に使用する Kubernetes Deployment ファイルを生成するために使用されます。

このページでは、移行計画の内容と、移行を実行してデプロイ アーティファクトを生成する前に考慮すべきカスタマイズの種類について説明します。

始める前に

このトピックでは、すでに移行プランを作成し、移行計画ファイルが作成されていることを前提としています。

移行計画を編集する

ファイル システムをコピーして分析すると、指定した出力パス（ANALYSIS_OUTPUT_PATH/config.yaml）に新しく作成されたディレクトリに移行計画が作成されます。

この移行計画を必要に応じて編集し、変更を保存します。

移行計画の詳細とコメントを確認して、必要に応じて情報を追加します。特に、次のセクションに関する編集を検討してください。

移行から除外するコンテンツを指定する

デフォルトでは、Migrate to Containers は、GKE のコンテキストに関係のない一般的な VM コンテンツを除外します。このフィルタはカスタマイズできます。

filters フィールド値には、移行から除外する必要があるパスが一覧表示されます。このパスは、コンテナ イメージの一部にはなりません。フィールドの値には、転送するファイルとスキップするファイルを指定する rsync フィルタルールが一覧表示されます。各パスとファイルの前にマイナス記号が付いていると、リスト内のアイテムを移行から除外する必要があることを示しています。リストは YAML の行の順序で処理され、除外または登録はその順序で評価されます。

rsync フィルタルールの詳細をご確認ください。

サイズが大きすぎて Docker イメージに含めることができないファイルは、YAML ファイルに一覧表示されます。これにより、検討対象となるファイルが 1 GB を超える場合はフラグが設定されます。Docker イメージのサイズが大きすぎるか、15 GB を超えると、移行中に障害が発生する可能性があります。

YAML リストを編集して、パスを追加または削除できます。以下の YAML の例をご覧ください。これには、除外の例と、大きなファイルやスパース ファイルの通知が含まれています。インライン ガイダンスに沿って、次のいずれかの操作を行います。

• 検出されたフォルダを除外するには、コメントを解除してグローバル フィルタのセクションに配置します。
• 検出されたフォルダを永続ボリュームに移動するには、コメントを解除してデータフォルダ セクションに配置します。

同様に、検出されたスパース ファイルも除外または移動できます。

  global:
    # Files and directories to exclude from the migration, in rsync format.
    filters:
      - "- *.swp"
      - "- /etc/fstab"
      - "- /boot/"
      - "- /tmp/*"
      - "- /var/log/*.log*"
      - "- /var/log/*/*.log*"
      - "- /var/cache/*"

    ## The data folders below are too large to be included in the docker image.
    ## Consider uncommenting and placing them under either the global filters
    ## or the data folder section.
      # - '- /a' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)
      # - '- /a/c' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)

    ## Sparse files will fail the run of a docker image. Consider excluding the below
    ## detected files and any other sparse files by uncommenting and placing them in 
    ## the global filters section, or export them to a persistent volume by specifying
    ## them in the data folder section.
      # - '- /a/b' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)
      # - '- /a/d' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)

コンテナ イメージの名前を設定する

image セクションの name の値は、コンテナに使用される移行済みの VM から作成されたイメージの名前を定義します。別の名前を使用する場合は、この値を変更できます。

image:
     # Review and set the name for runnable container image.
     name: linux-system

サービスリストをカスタマイズする

デフォルトでは、Migrate to Containers は VM をコンテナに移行するときに、VM 上の不要なサービスを無効にします。これらのサービスにより、移行後のコンテナで問題が発生することがあります。また、これらのサービスがコンテナのコンテキストで不要になることもあります。

Migrate to Containers によって自動的に無効にされないサービスも無効にすることもできます。

• Migrate to Containers は、サービスを自動的に検出してそのリストを移行計画に追加しますが、この中には無効にできるサービスもあります。たとえば、ssh やウェブサーバーなどのサービスは、移行後のワークロードで不要となることがあります。サービスが不要かどうかはご自身で判断してください。必要に応じて、移行計画を編集してこれらのサービスを無効にします。

• Migrate to Containers は、ソース VM で実行されているサービスをすべてリストに追加するわけではありません。たとえば、オペレーティング システムに関連するサービスは省略します。必要に応じて、移行計画を編集して移行先のコンテナで無効にするサービスのリストを追加することもできます。

systemServices フィールドには、Migrate to Containers によって検出されたサービスのリストを指定します。次に例を示します。

    systemServices:
    - enabled: true|false
      name: service-name
      probed: true|false
    - enabled: true|false
      name: service-name
      probed: true|false
      ...

サービスを無効にするには、enabled を false に設定します。

Migrate to Containers では、オペレーティング システムに関連するサービスなど、ソース VM で実行されているすべてのサービスが一覧表示されるわけではありません。ただし、リストにサービスを追加することは可能です。たとえば、service2 と cron サービスを無効にするには、次のコマンドを実行します。

    systemServices:
    - enabled: true
      name: service1
      probed: false
    - enabled: false
      name: service2
      probed: false
    - enabled: false
      name: cron
      probed: false

移行を実行して移行アーティファクトを生成すると、Migrate to Containers によって blocklist.yaml ファイルが作成されます。このファイルには、移行計画の設定に基づいて無効にするコンテナ サービスが列挙されています。次に例を示します。

service_list:
- name: disabled-services
  services:
  # Because you used systemServices above to disabled service2 and cron:
  - service2
  - cron

無効化されているサービスのリストを変更するには:

• 移行計画のサービスのリストを編集します。
• 移行を実行して、更新された blocklist.yaml を含む移行アーティファクトを再生成します。

また、移行を実行して移行アーティファクトを生成すると、blocklist.yaml ファイルを直接編集して、Skaffold を使用してコンテナ イメージをビルドしてデプロイできます。

サービス エンドポイントをカスタマイズする

移行計画には、移行されたワークロードによって提供される Kubernetes Service の作成に使用されるポートとプロトコルを定義する endpoints 配列が含まれます。エンドポイント定義を追加、編集、削除して移行計画をカスタマイズできます。

エンドポイント ポートを取得するには、ポートをリッスンしているプログラムを確認します。

sudo netstat --programs --listening --tcp --udp [--sctp]

Service エンドポイントごとに、移行計画に次の定義を追加します。

    endpoints:
    - port: PORT_NUMBER
      protocol: PORT_PROTOCOL
      name: PORT_NAME

ここで

• PORT_NUMBER は、サービスへのリクエストがルーティングされるコンテナのポート番号を指定します。
• PORT_PROTOCOL には、HTTP、HTTPS、TCP などのポート プロトコルを指定します。すべてのプロトコルの一覧については、サポートされているプロトコルをご覧ください。
• PORT_NAME には、サービス エンドポイントへのアクセスに使用する名前を指定します。Migrate to Containers は、生成されたエンドポイント定義ごとに一意の PORT_NAME を生成します。

たとえば、Migrate to Containers は次のエンドポイントを検出します。

  endpoints:
    - port: 80
      protocol: HTTP
      name: backend-server-nginx
    - port: 6379
      protocol: TCP
      name: backend-server-redis

name プロパティの値を設定するために、Migrate to Containers は、ソース VM 名（この例では backend-server）と Service のプログラム名を組み合わせます。生成される名前は、Kubernetes の命名規則と互換性があり、移行計画内で一意です。たとえば、先述の移行計画では、HTTP 経由でポート 80 の Nginx をターゲットとする Service が作成されます。

重複する名前がある場合は、Migrate to Containers によって接尾辞として番号が追加されます。たとえば、Nginx が 2 つのポートに関連付けられている場合、2 番目の定義では -2 接尾辞が name に追加されます。

  endpoints:
    - port: 80
      protocol: HTTP
      name: backend-server-nginx
    - port: 8080
      protocol: HTTPS
      name: backend-server-nginx-2
    - port: 6379
      protocol: TCP
      name: backend-server-redis

移行を実行して移行アーティファクトを生成すると、Migrate to Containers によって各エンドポイントの deployment_spec.yaml ファイルに Service 定義が作成されます。

例として、deployment_spec.yaml ファイル内の Service 定義を以下に示します。

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  name: backend-server-nginx
spec:
  ports:
  - port: 80
    protocol: HTTP
    targetPort: 80
  selector:
    app: backend-server
status:
  loadBalancer: {}

NFS マウントをカスタマイズする

Migrate to Containers には、生成された移行計画に NFS マウントが含まれます。この情報は fstab ファイルから収集され、移行計画の nfsMounts 配列に書き込まれます。NFS マウント ポイントの定義を追加または編集して、移行計画をカスタマイズできます。

注: nfsMounts 配列のエントリはデフォルトで無効になっています。Migrate to Containers で NFS マウントごとに deployment_spec.yaml ファイルにエントリを生成する場合は、これらを有効にする必要があります。

移行計画を生成する際は、Migrate to Containers は次のように動作します。

• /sys と /dev の NFS マウントを無視します。
• nfs または nfs4 以外のタイプの NFS マウントを無視します。

移行計画の各 NFS マウントには、次の形式でサーバーの IP アドレスとローカル マウントパスが含まれます。

    nfsMounts:
    - mountPoint: MOUNT_POINT
      exportedDirectory: DIR_NAME
      nfsServer: IP
      mountOptions:
         - OPTION_1
         - OPTION_2
      enabled: false|true

ここで

• MOUNT_POINT には、fstab から取得したマウント ポイントを指定します。
• DIR_NAME には、共有ディレクトリの名前を指定します。
• IP には、マウント ポイントをホストするサーバーの IP アドレスを指定します。
• OPTION_N は、fstab から抽出したマウント ポイントのオプションを指定します。

たとえば、fstab の次のエントリの場合:

<file system>       <mount point>   <type>  <options>   <dump>  <pass>
10.49.232.26:/vol1  /mnt/test       nfs     rw,hard     0       0

Migrate to Containers では、移行計画に次のエントリが生成されます。

    nfsMounts:
    - mountPoint: /mnt/test
      exportedDirectory: /vol1
      nfsServer: 10.49.232.26
      mountOptions:
         - rw
         - hard
      enabled: false

nfsMounts 配列のエントリを処理するように Migrate to Containers を構成するには、mountPoint エントリの enabled を true に設定します。mountPoints エントリの 1 つ、複数、またはすべてを有効にしたり、エントリを編集したり、独自のエントリを追加したりできます。

移行を実行して移行アーティファクトを生成すると、Migrate to Containers が Volumes と volumeMounts の定義と、PersistentVolume と PersistentVolumeClaim の定義を有効な NFS マウントごとに deployment_spec.yaml ファイルに作成します。

注: Migrate to Containers を使用するには、移行したコンテナ ワークロードをホストするデプロイ クラスタから NFS サーバーにアクセスできる必要があります。ただし、Migrate to Containers はその接続を検証しません。接続に問題がある移行済みのコンテナを起動することはできません。この問題を解決するには、deployment_spec.yaml ファイルの編集が必要になることがあります。詳細情報については、Filestore CSI ドライバを使用した Filestore インスタンスへのアクセスをご覧ください。

例として、deployment_spec.yaml ファイル内の volumeMounts 定義を以下に示します。

    spec:
      containers:
          - image: gcr.io/myimage-1/image-name
            name: some-app
            volumeMounts:
                   - mountPath: /sys/fs/cgroup
                     name: cgroups
                   - mountPath: /mnt/test
                     name: nfs-pv

ここで、name の値は、Migrate to Containers によって生成された固有識別子です。

deployment_spec.yaml ファイル内の PersistentVolumeClaim と PersistentVolume の定義の例を以下に示します。

apiVersion: v1
kind: PersistentVolumeClaim
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Mi
  storageClassName: ""
  volumeName: nfs-pv

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  mountOptions:
    - rw
    - hard
  nfs:
    path: /vol1
    server: 10.49.232.26

Cloud Logging に書き込まれるログデータをカスタマイズする

通常、ソース VM は 1 つ以上のログファイルに情報を書き込みます。VM の移行の一環として、移行されるワークロードを構成して、そのログ情報を Cloud Logging に書き込むことができます。

注: Cloud Logging へのロギングの構成で説明しているように、Migrate to Containers の以前のリリースでは、ターゲット ワークロード クラスタで ConfigMap を使用してロギングをカスタマイズできます。このセクションでは、logs.yaml ファイルを使用してロギングを構成する方法について説明します。logs.yaml ファイルが存在する場合、ConfigMap で定義されたロギング設定は無視されます。

移行計画を生成すると、Migrate to Containers は、ソース VM のログの宛先ファイルを自動的に検索します。Migrate to Containers によって、検出されたファイルに関する情報が移行計画の logPaths 領域に書き込まれます。

deployment:
    ...
    logPaths:
    - appName: APP_NAME
      globs:
      - LOG_PATH

次に例を示します。

deployment:
    ...
    logPaths:
    - appName: tomcat
      globs:
      - /var/log/tomcat*/catalina.out

移行アーティファクトを生成すると、Migrate to Containers が移行計画から logs.yaml ファイルを生成するようになりました。このファイルには、ソース VM で検出されたログファイルのリストが含まれます。たとえば、上記の logsPath の定義で、logs.yaml には以下が含まれています。

logs:
  tomcat:
  - /var/log/tomcat*/catalina.out

この例では、移行されたワークロードをデプロイすると、catalina.out に書き込まれたログ情報が自動的に Cloud Logging に書き込まれます。

ログで、エントリは次の形式で 1 行に表示されます。

DATE TIME APP_NAME LOG_OUTPUT

次の例は、Tomcat からのエントリの形式を示しています。

2019-09-22 12:43:08.681193976 +0000 UTC tomcat log-output

ロギングを構成するには、次のいずれかを行います。

• 移行アーティファクトを生成する前に移行計画を編集し、logPaths のエントリを追加、削除、または編集します。移行アーティファクトを生成すると、この編集は logs.yaml ファイルに反映されます。

• 移行アーティファクトを生成した後に logs.yaml を編集して、logs のエントリを追加、削除、または編集します。

移行計画を編集する利点は、アーティファクトを生成するたびに編集内容が logs.yaml に反映されることです。なんらかの理由で logs.yaml を直接編集してからアーティファクトを再生成する場合は、編集内容を logs.yaml に再度適用する必要があります。

Linux v2kServiceManager の正常性プローブを設定する

マネージド コンテナのダウンタイムと準備完了ステータスは、Tomcat ウェブサーバーの移行計画でプローブを指定することによりモニタリングできます。正常性プローブのモニタリングは、移行されたコンテナのダウンタイムを減らし、モニタリングを改善する効果があります。

不明なヘルス状態は、可用性の低下、可用性モニタリングの誤判定、およびデータ損失を引き起こす可能性があります。正常性プローブがなければ、kubelet は、コンテナの健全性を想定することしかできず、準備ができていないコンテナ インスタンスにトラフィックを送信する可能性があります。これにより、トラフィックが失われる場合があります。kubelet は、フリーズされたコンテナを検出することもできず、コンテナは再起動されません。

正常性プローブは、コンテナの起動時に小さなスクリプト ステートメントを実行します。このスクリプトは、成功したプローブの種類をチェックします。これは、使用されるプローブのタイプによって定義されます。期間は移行計画の periodSeconds フィールドで定義されます。これらのスクリプトは、手動で実行または定義できます。

kubelet のプローブの詳細については、Kubernetes ドキュメントの livenessProbe、readinessProbe、startupProbe の構成をご覧ください。

構成可能なプローブには 2 つのタイプがありますが、どちらのプローブも probe-v1-core リファレンスで定義された Probe-v1-core で、container-v1-core の対応フィールドと同じ機能を共有します。

• livenessProbe - livenessProbe は、コンテナを再起動するタイミングを把握するために使用します。
  注: コンテナ内のプロセスに問題が発生した場合や、プロセスが異常な状態になった場合は、livenessProbe を必ずしも使う必要はありません。正しいアクションは、kubelet が Pod の restartPolicy に従って自動的に実行します。
• readinessProbe - readinessProbe は、コンテナがトラフィックの受信を開始する準備が整うタイミングを認識するために使用します。プローブが成功した場合にのみ Pod へのトラフィックの送信を開始するには、readinessProbe を指定します。readinessProbe は livenessProbe と同様に機能する場合もありますが、仕様の readinessProbe は、Pod がトラフィックを受信せずに起動し、プローブが成功した後にのみトラフィックの受信を開始することを示します。

調査後、プローブ構成が移行計画に追加されます。プローブは、次のようにデフォルト構成で使用できます。プローブを無効にするには、yaml から probes セクションを削除します。

deployment:
  probes:
    livenessProbe:
      exec:
        command:
        - /ko-app/service-manager-runtime
        - /probe

    readinessProbe:
      exec:
        command:
        - gamma
        - /probe
      initialDelaySeconds: 60
      periodSeconds: 5

image:
  # Disable system services that do not need to be executed at the migrated workload containers.
  # Enable the 'probed' property to include system services in the container health checks.
  systemServices:
  - enabled: true
    name: apache2
    probed: true
  - enabled: true
    name: atd
    probed: false 

デフォルトでは、すべてのサービス プローブは無効になっています。モニタリングするサービスのサブセットを定義する必要があります。

注: すべてのサービスがプローブをサポートしているわけではなく、コンテナの起動に失敗する可能性があります。

プローブを使用してコンテナを確認するには、事前定義された 4 つの方法があります。各プローブでは、次の 4 つのメカニズムのいずれか 1 つのみを定義する必要があります。

• exec - コンテナ内で指定されたコマンドを実行します。終了ステータス コードが 0 の場合、正常に実行されたとみなされます。
• grpc - gRPC を使用してリモート プロシージャ コールを実行します。gRPC プローブはアルファ版の機能です。
• httpGet - 指定されたポートとパスにある Pod の IP アドレスに対して HTTP GET リクエストを実行します。ステータス コードが 200 以上 400 未満の場合、リクエストが正常に終了したとみなされます。
• tcpSocket - 指定されたポートにある Pod の IP アドレスに対して TCP チェックを実行します。ポートが開いている場合、チェックが正常に終了したとみなされます。

デフォルトでは、移行計画によって exec プローブ方式が有効になります。移行計画に手動構成を使用して、別の方法を有効にします。

デフォルトの readinessProbe を使用しながら、readinessProbe に外部依存関係を追加するには、exec readinessProbe と、ロジックを実装するスクリプトを定義します。

次のステップ

• 移行の実行方法を学ぶ。