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

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

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

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

目標

Google Distributed Cloud 上の 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 を使用してクラスタにアクセスできる。

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

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

Google Distributed Cloud 上の VM ランタイムを有効にする
```
sudo bmctl enable vmruntime --kubeconfig KUBECONFIG_PATH
```
- KUBECONFIG_PATH: GKE Enterprise ユーザークラスタの 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 をデプロイする場合、Google Distributed Cloud 上の VM ランタイムは VM イメージを想定します。このイメージは、デプロイされた VM のブートディスクとして機能します。

このチュートリアルでは、Compute Engine VM ベースのワークロードを GKE 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 リソースは、Google Distributed Cloud 上の 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:
```
次のユーザーアカウントとパスワードを使用します。このアカウントは、Google Distributed Cloud 上の VM ランタイム VirtualMachine のイメージが作成された元の VM 内で設定されます。
- ログインユーザー名: abmuser
- パスワード: abmworks

POS アプリケーションサービスのステータスを確認します。POS アプリケーションには、API、インベントリ、お支払いの 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 上で 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

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

クリーンアップ

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

すべてを削除

Google Distributed Cloud 上の 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 の構成とイメージの作成方法の詳細については、point-of-sale リポジトリの手順をご覧ください。
kubectl virt create vm pos-vm コマンドを使用して Anthos クラスタに VM を作成すると、VM（google-virtctl/pos-vm.yaml）の名前が付いた YAML ファイルが作成されます。ファイルを調べると、VirtualMachine と VirtualMachineDisk の定義を確認できます。virtctl プラグインを使用する代わりに、作成した YAML ファイルに記載されている KRM 定義を使用して VM をデプロイできます。