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

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

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

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

目標

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

始める前に

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

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

GDC 上の VM ランタイムを有効にして `virtctl` プラグインをインストールする

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

GDC で VM ランタイムを有効にします。
```
sudo bmctl enable vmruntime --kubeconfig KUBECONFIG_PATH
```
- KUBECONFIG_PATH: GKE on Bare Metal ユーザークラスタの Kubernetes 構成ファイルへのパス
VMRuntime が有効であることを確認します。
```
kubectl wait --for=jsonpath='{.status.ready}'=true 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 ベースのワークロードをデプロイする

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

このチュートリアルでは、Compute Engine VM ベースのワークロードを GKE on Bare Metal のクラスタに移行します。この Compute Engine VM は、サンプル POS（PoS）アプリケーションが systemd サービスとして実行されるように作成し構成しています。この VM のディスクイメージと PoS アプリケーションワークロードの作成は、Google Cloud で行われました。その後、このイメージが、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 リソースは、GDC 上の VM ランタイムの vm.cluster.gke.io/v1.VirtualMachine リソースで識別されます。短縮形は gvm です。

VM を作成すると、次の 2 つのリソースが作成されます。
- VirtualMachineDisk は、VM イメージのコンテンツがインポートされる永続ディスクです。
- VirtualMachine は、VM インスタンスそのものです。DataVolume は、VM が起動する前に 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
```
作成が成功した場合、VM の IP アドレスとともに、次の例に示すように、STATUSはRUNNINGを示します。
```
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:
```
次のユーザーアカウントとパスワードを使用します。このアカウントは、GDC 上の VM ランタイム VirtualMachine のイメージが作成された元の VM 内で設定されたものです。
- ログインユーザー名: abmuser
- パスワード: abmworks

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

3 つのサービスはすべてローカルホストを介して相互に接続されます。ただし、アプリケーションは、前の手順で作成した mysql-db Kubernetes Service を使用して MySQL データベースに接続されます。この動作は、VM が Pods や Services と同じネットワークに自動的に接続され、VM ワークロードと他のコンテナ化されたアプリケーション間でシームレスな通信が可能になることを意味します。GDC 上の 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 上で GKE 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

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

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 キオスクを示します。商品を複数注文する場合は、商品を複数回クリックして [支払う] ボタンで注文を実行します。このエクスペリエンスは、GDC 上の VM ランタイムを使用して、VM ベースのワークロードを GKE on Bare Metal クラスタに正常にデプロイしていることを示しています。

クリーンアップ

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

すべてを削除

GDC 上の 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 コマンドを使用して GKE on Bare Metal クラスタに VM を作成すると、VM（google-virtctl/pos-vm.yaml）にちなんで名付けられた YAML ファイルが作成されます。ファイルを調べると、VirtualMachine と VirtualMachineDisk の定義を確認できます。virtctl プラグインを使用する代わりに、作成した YAML ファイルに記載されている KRM 定義を使用して VM をデプロイできます。