チュートリアル: Anthos VM ランタイムを使用して既存の VM を Anthos クラスタにデプロイする

このドキュメントでは、Anthos VM ランタイムを使用して、Anthos clusters on bare metal に仮想マシン（VM）ベースのワークロードをデプロイする手順を説明します。このガイドで使用するワークロードは、サンプルの POS アプリケーションです。このアプリケーションは、小売店のオンプレミスハードウェアで実行される一般的な POS ターミナルを表します。

このドキュメントでは、VM から Anthos clusters on bare metal にこのアプリケーションを移行し、アプリケーションのウェブフロントエンドにアクセスします。既存の VM をクラスタに移行するには、まず、その VM のディスクイメージを作成する必要があります。次に、クラスタがアクセスできるリポジトリにイメージをホストする必要があります。最後に、そのイメージの URL を使用して VM を作成できます。Anthos VM ランタイムは、イメージが qcow2 形式であることを前提としています。別のイメージタイプを指定すると、自動的に qcow2 形式に変換されます。繰り返しの変換を回避して再利用を有効にするには、仮想ディスクイメージを変換して、qcow2 イメージをホストします。

このドキュメントでは、ワークロードが systemd サービスとして実行される Compute Engine VM インスタンスの事前作成されたイメージを使用します。独自のアプリケーションをデプロイするには、同じ手順を実行します。

目標

Anthos VM ランタイムを有効にし、virtctl プラグインをインストールする
VM ベースのワークロードをデプロイする
VM にログインし、アプリケーションのステータスを確認する
VM ベースのワークロードにアクセスする

始める前に

このドキュメントを完了するには、次のリソースが必要です。

手動ロードバランサを使用して Compute Engine VM 上で Anthos clusters on bare metal を実行するのガイドの手順で作成された Anthos clusters on bare metal バージョン 1.12.0 以降のクラスタへのアクセス。このドキュメントでは、ブラウザ経由で VM 内で実行されているワークロードにアクセスできるように、ネットワークリソースを設定します。その動作を必要としない場合は、このドキュメントでは、Anthos clusters on bare metal を使用できます。
次の要件を満たすワークステーション。
- bmctl CLI を使用してクラスタにアクセスできる。
- kubectl CLI を使用してクラスタにアクセスできる。

Anthos VM ランタイムを有効にし、`virtctl` プラグインをインストールする

Anthos VM ランタイムのカスタムリソース定義（CRD）は、バージョン 1.10 以降の Anthos clusters on bare metal のすべてのクラスタの一部です。VMRuntime カスタムリソースのインスタンスは、インストール時にすでに作成されています。ただし、デフォルトでは無効になっています。

Anthos VM ランタイムを有効にする
```
sudo bmctl enable vmruntime --kubeconfig KUBECONFIG_PATH
```
- KUBECONFIG_PATH: Anthos ユーザークラスタの Kubernetes 構成ファイルのパス
VMRuntime が有効になっていることを確認します。
```
kubectl wait --for=jsonpath='{.status.ready}'=true --timeout=300s vmruntime vmruntime
```
VMRuntime を使用できるようになるまで数分かかることがあります。準備ができていない場合は、少し遅れて数回チェックしてください。次の出力例は、VMRuntime の準備ができていることを示しています。
```
vmruntime.vm.cluster.gke.io/vmruntime condition met
```
kubectl 用の virtctl プラグインをインストールします。
```
sudo -E bmctl install virtctl
```
次の出力例は、virtctl プラグインのインストールプロセスが完了したことを示しています。
```
Please check the logs at bmctl-workspace/log/install-virtctl-20220831-182135/install-virtctl.log
[2022-08-31 18:21:35+0000] Install virtctl succeeded
```

virtctl プラグインのインストールを確認します。

kubectl virt

次の出力例は、virtctl プラグインが kubectl で使用できることを示しています。

Available Commands:
  addvolume         add a volume to a running VM
  completion        generate the autocompletion script for the specified shell
  config            Config subcommands.
  console           Connect to a console of a virtual machine instance.
  create            Create subcommands.
  delete            Delete  subcommands.
...

VM ベースのワークロードをデプロイする

Anthos clusters on bare metal に VM をデプロイする場合、Anthos VM ランタイムは VM イメージを想定します。このイメージは、デプロイされた VM のブートディスクとして機能します。

このチュートリアルでは、Compute Engine VM ベースのワークロードを Anthos clusters on bare metal のクラスタに移行します。この Compute Engine VM が作成され、サンプル POS（PoS）アプリケーションも systemd サービスとして実行するように構成されました。Google Cloud で、この VM のディスクイメージと PoS アプリケーションワークロードが作成されました。このイメージは、qcow2 イメージとして Cloud Storage バケットにエクスポートされました。この準備済みの qcow2 イメージを次のステップで使用します。

このドキュメントのソースコードは、anthos-samples GitHub リポジトリで入手できます。このリポジトリのリソースを使用して、以降の手順を行います。

MySQL StatefulSet をデプロイします。POS アプリケーションは、在庫とお支払い情報を格納するために MySQL データベースに接続されることを想定しています。POS リポジトリには、MySQL StatefulSet のデプロイ、関連する ConfigMap、Kubernetes Service の構成を行うサンプルマニフェストがあります。ConfigMap は、MySQL インスタンスの認証情報を定義します。これは、POS アプリケーションに渡されるものと同じ認証情報です。
```
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/point-of-sale/main/k8-manifests/common/mysql-db.yaml
```
準備済みの qcow2 イメージを使用して VM ワークロードをデプロイします。
```
kubectl virt create vm pos-vm \
    --boot-disk-size=80Gi \
    --memory=4Gi \
    --vcpu=2 \
    --image=https://storage.googleapis.com/pos-vm-images/pos-vm.qcow2
```
このコマンドにより、VM（google-virtctl/pos-vm.yaml）の名前が付いた YAML ファイルが作成されます。ファイルを調べると、VirtualMachine と VirtualMachineDisk の定義を確認できます。virtctl プラグインを使用する代わりに、作成した YAML ファイルに記載されている Kubernetes リソースモデル（KRM）定義を使用して VM ワークロードをデプロイすることもできます。

コマンドが正常に実行されると、作成されたさまざまなリソースを説明する次の例のような出力が生成されます。
```
Constructing manifest for vm "pos-vm":
Manifest for vm "pos-vm" is saved to /home/tfadmin/google-virtctl/pos-vm.yaml
Applying manifest for vm "pos-vm"
Created gvm "pos-vm"
```
VM の作成ステータスを確認します。

VirtualMachine リソースは、Anthos VM ランタイムの vm.cluster.gke.io/v1.VirtualMachine リソースで識別されます。短縮形は gvm です。

VM を作成すると、次の 2 つのリソースが作成されます。
- VirtualMachineDisk は、VM イメージのコンテンツをインポートする永続ディスクです。
- VirtualMachine は VM インスタンス自体です。VM を起動する前に、DataVolume が VirtualMachine にマウントされます。
VirtualMachineDisk のステータスを確認します。VirtualMachineDisk は内部で DataVolume リソースを作成します。VM イメージが、VM にマウントされた DataVolume にインポートされます。
```
kubectl get datavolume
```
次の出力例は、イメージのインポートの開始を示しています。
```
NAME              PHASE             PROGRESS   RESTARTS   AGE
pos-vm-boot-dv    ImportScheduled   N/A                   8s
```
VirtualMachine のステータスを確認します。DataVolume が完全にインポートされるまで、VirtualMachine は Provisioning 状態になります。
```
kubectl get gvm
```
次の出力例は、プロビジョニングされている VirtualMachine を示しています。
```
NAME      STATUS         AGE     IP
pos-vm    Provisioning   1m
```
VM イメージが DataVolume に完全にインポートされるまで待ちます。画像のインポート中に進行状況を確認します。
```
kubectl get datavolume -w
```
次の出力例は、インポートされるディスクイメージを示しています。
```
NAME              PHASE              PROGRESS   RESTARTS   AGE
pos-vm-boot-dv   ImportInProgress   0.00%                 14s
...
...
pos-vm-boot-dv   ImportInProgress   0.00%                 31s
pos-vm-boot-dv   ImportInProgress   1.02%                 33s
pos-vm-boot-dv   ImportInProgress   1.02%                 35s
...
```
インポートが完了し、DataVolume が作成された場合、次の出力例は Succeeded の PHASE を示しています。
```
kubectl get datavolume
```
```
NAME              PHASE             PROGRESS   RESTARTS   AGE
pos-vm-boot-dv    Succeeded         100.0%                14m18s
```
注: インポート時間は、使用する VM イメージのサイズによって異なります。このドキュメントの Compute Engine VM イメージは約 5 GB で、インポートには最大 15 分かかります。
VirtualMachine が正常に作成されたことを確認します。
```
kubectl get gvm
```
作成が成功すると、次の例に示すように STATUS に RUNNING と VM の IP アドレスが表示されます。
```
NAME      STATUS    AGE     IP
pos-vm    Running   40m     192.168.3.250
```

VM に接続し、アプリケーションのステータスを確認する

VM に使用されるイメージには、POS サンプルアプリケーションが含まれています。アプリケーションは、systemd サービスとして起動時に自動的に開始するように構成されています。systemd サービスの構成ファイルは、pos-systemd-services ディレクトリにあります。

VM コンソールに接続します。次のコマンドを実行し、Successfully connected to pos-vm… メッセージが表示されたら Enter キーを押します。
```
kubectl virt console pos-vm
```
このコマンドを実行すると、ログインの詳細の入力を求める次の出力例が生成されます。
```
Successfully connected to pos-vm console. The escape sequence is ^]

pos-from-public-image login:
```
次のユーザーアカウントとパスワードを使用します。このアカウントは、Anthos VM ランタイム VirtualMachine のイメージが作成された元の VM 内で設定されます。
- ログインユーザー名: abmuser
- パスワード: abmworks

POS アプリケーションサービスのステータスを確認します。POS アプリケーションには、API、Inventory、Payments の 3 つのサービスが含まれます。これらのサービスはすべてシステムサービスとして実行されます。

3 つのサービスはすべて、ローカルホストを介して相互に接続します。ただし、アプリケーションは前のステップで作成した mysql-db Kubernetes Service を使用して MySQL データベースに接続します。この動作は、VM が Pods と Services と同じネットワークに自動的に接続されることを意味します。これにより、VM ワークロードと他のコンテナ化されたアプリケーションの間のシームレスな通信が可能になります。Anthos VM ランタイムを使用してデプロイされた VM から Kubernetes Services に到達できるようにするための追加作業は必要ありません。

sudo systemctl status pos*

次の出力例は、3 つのサービスとルートシステムサービス pos.service のステータスを示しています。

● pos_payments.service - Payments service of the Point of Sale Application
    Loaded: loaded (/etc/systemd/system/pos_payments.service; enabled; vendor >
    Active: active (running) since Tue 2022-06-21 18:55:30 UTC; 1h 10min ago
  Main PID: 750 (payments.sh)
      Tasks: 27 (limit: 4664)
    Memory: 295.1M
    CGroup: /system.slice/pos_payments.service
            ├─750 /bin/sh /pos/scripts/payments.sh
            └─760 java -jar /pos/jars/payments.jar --server.port=8083

● pos_inventory.service - Inventory service of the Point of Sale Application
    Loaded: loaded (/etc/systemd/system/pos_inventory.service; enabled; vendor>
    Active: active (running) since Tue 2022-06-21 18:55:30 UTC; 1h 10min ago
  Main PID: 749 (inventory.sh)
      Tasks: 27 (limit: 4664)
    Memory: 272.6M
    CGroup: /system.slice/pos_inventory.service
            ├─749 /bin/sh /pos/scripts/inventory.sh
            └─759 java -jar /pos/jars/inventory.jar --server.port=8082

● pos.service - Point of Sale Application
    Loaded: loaded (/etc/systemd/system/pos.service; enabled; vendor preset: e>
    Active: active (exited) since Tue 2022-06-21 18:55:30 UTC; 1h 10min ago
  Main PID: 743 (code=exited, status=0/SUCCESS)
      Tasks: 0 (limit: 4664)
    Memory: 0B
    CGroup: /system.slice/pos.service

Jun 21 18:55:30 pos-vm systemd[1]: Starting Point of Sale Application...
Jun 21 18:55:30 pos-vm systemd[1]: Finished Point of Sale Application.

● pos_apiserver.service - API Server of the Point of Sale Application
    Loaded: loaded (/etc/systemd/system/pos_apiserver.service; enabled; vendor>
    Active: active (running) since Tue 2022-06-21 18:55:31 UTC; 1h 10min ago
  Main PID: 751 (api-server.sh)
      Tasks: 26 (limit: 4664)
    Memory: 203.1M
    CGroup: /system.slice/pos_apiserver.service
            ├─751 /bin/sh /pos/scripts/api-server.sh
            └─755 java -jar /pos/jars/api-server.jar --server.port=8081

VM を終了します。コンソール接続を終了するには、Ctrl + ] を押してエスケープシーケンス ^] を使用します。

VM ベースのワークロードにアクセスする

手動ロードバランサを使用して Compute Engine VM 上で Anthos clusters on bare metal を実行するのガイドの手順に従ってクラスタを設定した場合、pos-ingress という名前の Ingress リソースが作成済みです。このリソースは、Ingress ロードバランサのパブリック IP アドレスから、POS サンプルアプリケーションの API サーバーサービスにトラフィックをルーティングします。

クラスタにこの Ingress リソースがない場合は、次のマニフェストを適用して作成します。

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-bm-gcp-terraform/resources/manifests/pos-ingress.yaml

anthos-bm-gcp-terraform/resources/manifests/pos-ingress.yaml

GitHub で表示

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: pos-ingress
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-server-svc
            port:
              number: 8080

VM にトラフィックをルーティングする Kubernetes Service を作成します。Ingress リソースは、この Service にトラフィックをルーティングします。

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-vmruntime/pos-service.yaml

次の出力例では、Service が作成されたことを確認します。

service/api-server-svc created

anthos-vmruntime/pos-service.yaml

GitHub で表示

apiVersion: v1
kind: Service
metadata:
  name: api-server-svc
spec:
  selector:
    kubevirt/vm: pos-vm
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 8081

Ingress ロードバランサのパブリック IP アドレスを取得します。Ingress ロードバランサは、Ingress リソースルールに基づいてトラフィックをルーティングします。API サーバー Service にリクエストを転送するための pos-ingress ルールがすでにあります。この Service はリクエストを VM に転送します。
```
INGRESS_IP=$(kubectl get ingress/pos-ingress -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
echo $INGRESS_IP
```
次の出力例は、Ingress ロードバランサの IP アドレスを示しています。
```
172.29.249.159 # you might have a different IP address
```
ブラウザで Ingress ロードバランサ IP アドレスを使用してアプリケーションにアクセスします。次のスクリーンショットの例は、2 つの商品を含むシンプルな POS キオスクを示しています。アイテムを複数注文する場合は、アイテムを複数回クリックし、[支払う] ボタンで注文を実行します。このエクスペリエンスは、Anthos VM ランタイムを使用して、従来の VM ベースのワークロードを Anthos クラスタに正常にデプロイしていることを示しています。

クリーンアップ

このチュートリアルで作成したすべてのリソースを削除するか、VM のみを削除して再利用可能なリソースを保持できます。Anthos clusters on bare metal の VM を削除するで、使用可能なオプションについて詳しく説明します。

すべて削除

Anthos VM ランタイム VirtualMachine とすべてのリソースを削除します。

kubectl virt delete vm pos-vm --all

次の出力例で、削除が確認されます。

vm "pos-vm" used the following resources:
    gvm: pos-vm
    VirtualMachineDisk: pos-vm-boot-dv
Start deleting the resources:
    Deleted gvm "pos-vm".
    Deleted VirtualMachineDisk "pos-vm-boot-dv".

VM のみの削除

VM のみを削除すると、作成された VirtualMachineDisk が保持されます。これにより、この VM イメージを再利用でき、新しい VM の作成時にイメージをインポートする時間を短縮できます。
```
kubectl virt delete vm pos-vm
```
次の出力例で、削除が確認されます。
```
vm "pos-vm" used the following resources:
    gvm: pos-vm
    VirtualMachineDisk: pos-vm-boot-dv
Start deleting the resources:
    Deleted gvm "pos-vm".
```

次のステップ

このガイドで使用されている元の VM は、Ubuntu 20.04 LTS を実行する Compute Engine インスタンスです。この VM のイメージは、pos-vm-images Cloud Storage バケットを介して一般公開されます。VM の構成とイメージの作成方法について詳しくは、POS リポジトリの手順をご覧ください。
kubectl virt create vm pos-vm コマンドを使用して Anthos クラスタに VM を作成すると、VM（google-virtctl/pos-vm.yaml）の名前が付いた YAML ファイルが作成されます。ファイルを調べると、VirtualMachine と VirtualMachineDisk の定義を確認できます。virtctl プラグインを使用する代わりに、作成した YAML ファイルに記載されている KRM 定義を使用して VM をデプロイできます。