VM ベースのワークロードでの操作

このページでは、Anthos VM ランタイムを使用して、ベアメタル版 Anthos クラスタに VM をデプロイする方法について説明します。Anthos VM ランタイムは、KubeVirt を使用してクラスタ上の VM をオーケストレートし、VM ベースのアプリとワークロードを均一な開発環境で使用できるようにします。Anthos VM ランタイムは、新しいクラスタの作成時、および既存のクラスタに対して有効にできます。

始める前に

以下の手順は、クラスタが稼働していることを前提としています。稼働していない場合は、ベアメタル版 Anthos クラスタクイックスタートの手順に沿って、ワークステーション上のクラスタをすばやく設定できます。

Anthos VM ランタイムを有効にする

Anthos VM ランタイムはデフォルトで無効になっています。Anthos VM ランタイムを有効にするには、クラスタ内の VMRuntime カスタムリソースを編集します。Anthos clusters on bare metal 1.10.0 から、VMRuntime カスタムリソースが自動的にクラスタにインストールされます。

Anthos VM ランタイムを有効にするには:

VMRuntime カスタムリソースを更新して、enabled を true に設定します。

apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  enabled: true
  # useEmulation default to false if not set.
  useEmulation: true
  # vmImageFormat default to "qcow2" if not set.
  vmImageFormat: qcow2

ノードがハードウェア仮想化をサポートしていない場合や、それが不明な場合は、useEmulation を true に設定します。

使用可能な場合、ハードウェア仮想化は、ソフトウェアエミュレーションよりもパフォーマンスが優れています。指定しない場合、useEmulation フィールドはデフォルトで false になります。
```
apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  enabled: true
  # useEmulation default to false if not set.
  useEmulation: true
  # vmImageFormat default to "qcow2" if not set.
  vmImageFormat: qcow2
```
作成した VM に使用するイメージ形式は、vmImageFormat フィールドを設定することによって変更できます。

vmImageFormat フィールドは、raw と qcow2 の 2 つのディスクイメージ形式値をサポートしています。vmImageFormat を設定しない場合、Anthos VM ランタイムは raw ディスクイメージ形式を使用して VM を作成します。raw 形式によって、書き込み形式のコピーである qcow2 よりもパフォーマンスが向上しますが、より多くのディスクを使用する場合があります。VM のイメージ形式の詳細については、QEMU ドキュメントのディスクイメージファイル形式をご覧ください。
```
apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  enabled: true
  # useEmulation default to false if not set.
  useEmulation: true
  # vmImageFormat default to "qcow2" if not set.
  vmImageFormat: qcow2
```
構成を保存し、VMRuntime カスタムリソースが有効であることを確認します。
```
kubectl describe vmruntime vmruntime
```
VMRuntime カスタムリソースの詳細には、Status セクションが含まれています。VMRuntime.Status.Ready が true に設定されていれば、Anthos VM ランタイムは有効で、機能しています。

クラスタのアップグレード

バージョン 1.10.0 以降にアップグレードされたクラスタには、VMRuntime カスタムリソースが自動的にインストールされます。1.9.x クラスタをバージョン 1.10.0 以降にアップグレードすると、アップグレードプロセスによってクラスタの設定が確認され、1.9.x クラスタの Anthos VM ランタイムの設定に合わせて VMRuntime カスタムリソースが構成されます。spec.kubevirt が 1.9.x クラスタリソースに存在する場合、アップグレードプロセスによって Anthos VM ランタイムが有効化されます。

バージョン 1.10.0 以降のクラスタでは、VMRuntime カスタムリソース設定は、以前の Anthos VM ランタイムクラスタ設定（spec.kubevirt.useEmulation など）よりも優先されます。VMRuntime カスタムリソースを更新して、1.10.0 以降のクラスタの Anthos VM ランタイムの設定を変更します。

`virtctl` をインストールします。

virtctl CLI ツールを kubectl プラグインとしてインストールします。

export GOOGLE_APPLICATION_CREDENTIALS="bm-gcr.json"
sudo -E ./bmctl install virtctl

virtctl がインストールされていることを確認します。
```
kubectl plugin list
```
レスポンスに virtctl が表示されていれば、正常にインストールされています。

VM を作成する

クラスタで KubeVirt を有効にして、kubectl 用の virtctl プラグインをインストールすると、kubectl virt create vm コマンドを使用してクラスタで VM の作成を開始できます。次のコマンドを実行する前に、cloud-init ファイルを構成して、作成された VM にコンソールからアクセスできるようにすることをおすすめします。

コンソールアクセス用にカスタム cloud-init ファイルを作成する

カスタム cloud-init ファイルを作成する方法は 2 つあります。最も簡単な方法は、VM の作成時に --os=<OPERATING_SYSTEM> フラグを指定することです。この方法は、次のオペレーティングシステムで動作する簡単な cloud-init ファイルを自動的に構成します。

Ubuntu
CentOS
Debian
Fedora

VM が作成されたら、初回は認証情報を使用してアクセスし、パスワードを変更します。

user: root
password: changeme

イメージに別の Linux ベースの OS が含まれている場合や、より高度な構成が必要な場合は、カスタム cloud-init ファイルを手動で作成し、--cloud-init-file=<path/to/file> フラグでそのファイルへのパスを指定できます。最も基本的な形式では、cloud-init ファイルは次の内容を含む YAML ファイルです。

#cloud-config
user: root
password: changeme
lock_passwd: false
chpasswd: {expire: false}
disable_root: false
ssh_authorized_keys:
- <ssh-key>

より高度な構成については、Cloud 構成の例をご覧ください。

どちらの方法を使用するかを決定したら、VM を作成する準備が整います。

`kubectl virt create vm` コマンドを実行する

VM は、公開イメージか、カスタムイメージから作成できます。

公開イメージ

クラスタに外部接続がある場合は、次のコマンドを実行して公開イメージから VM を作成できます。

kubectl virt create vm VM_NAME \
    --boot-disk-access-mode=MODE \
    --boot-disk-size=DISK_SIZE \
    --boot-disk-storage-class="DISK_CLASS" \
    --cloud-init-file=FILE_PATH \
    --cpu=CPU_NUMBER \
    --image=IMAGE_NAME \
    --memory=MEMORY_SIZE

以下を置き換えます。

VM_NAME は、作成する VM の名前に置き換えます。
MODE は、ブートディスクのアクセスモードに置き換えます。有効な値は ReadWriteOnce（デフォルト）または ReadWriteMany です。
DISK_SIZE は、ブートディスクのサイズに置き換えます。デフォルト値は 20Gi です。
DISK_CLASS は、ブートディスクのストレージクラスに置き換えます。デフォルト値は local-shared です。使用可能なストレージクラスのリストを表示するには、kubectl get storageclass を実行します。
FILE_PATH は、カスタマイズした cloud-init ファイルのフルパスに置き換えます。これは、イメージによっては、作成後にその VM にコンソールアクセスするのに必要な場合があります。--os フラグを指定して cloud-init ファイルを自動的に構成する場合は、--cloud-init-file フラグを指定しないでください。--cloud-init-file フラグを指定している場合、--os フラグは無視されます。--os の許容値は ubuntu、centos、debian、fedora です。
CPU_NUMBER は、VM に構成する CPU の数に置き換えます。デフォルト値は 1 です。
IMAGE_NAME は、VM イメージに置き換えます。VM イメージには ubuntu20.04（デフォルト）、centos8、またはイメージの URL を使用できます。
MEMORY_SIZE は、VM のメモリサイズに置き換えます。デフォルト値は 4Gi です。

カスタムイメージ

カスタムイメージから VM を作成する場合、HTTP イメージサーバーからのイメージ、またはローカルに保存されているイメージを指定できます。

HTTP イメージサーバー

Apache や nginx を使用して HTTP サーバーをセットアップし、公開フォルダにカスタムイメージをアップロードできます。その後、次のコマンドを実行して、カスタムイメージから VM を作成します。

kubectl virt create vm VM_NAME \
    --boot-disk-access-mode=DISK_ACCESS_MODE \
    --boot-disk-size=DISK_SIZE \
    --boot-disk-storage-class=DISK_CLASS \
    --cloud-init-file=FILE_PATH \
    --cpu=CPU_NUMBER \
    --image=http://SERVER_IP/IMAGE_NAME \
    --memory=MEMORY_SIZE

以下を置き換えます。

VM_NAME は、作成する VM の名前に置き換えます。
DISK_ACCESS_MODE は、ブートディスクのアクセスモードに置き換えます。有効な値は ReadWriteOnce（デフォルト）または ReadWriteMany です。
DISK_SIZE は、ブートディスクのサイズに置き換えます。デフォルト値は 20Gi です。
DISK_CLASS は、ブートディスクのストレージクラスに置き換えます。デフォルト値は local-shared です。使用可能なストレージクラスのリストを表示するには、kubectl get storageclass を実行します。
FILE_PATH は、カスタマイズした cloud-init ファイルのフルパスに置き換えます。これは、イメージによっては、作成後にその VM にコンソールアクセスするのに必要な場合があります。--os フラグを指定して cloud-init ファイルを自動的に構成する場合は、--cloud-init-file フラグを指定しないでください。--cloud-init-file フラグを指定している場合、--os フラグは無視されます。--os の有効な値は ubuntu、centos、debian、fedora です。
CPU_NUMBER は、VM に構成する CPU の数に置き換えます。デフォルト値は 1 です。
SERVER_IP は、イメージをホストするサーバーの IP アドレスに置き換えます。
IMAGE_NAME は、カスタムイメージのファイル名に置き換えます。
MEMORY_SIZE は、VM のメモリサイズに置き換えます。デフォルト値は 4Gi です。

ローカルに保存されているイメージ

次のコマンドを実行して、カスタムイメージをローカルに保存して、VM を作成できます。

kubectl virt create vm VM_NAME \
    --boot-disk-access-mode=DISK_ACCESS_MODE \
    --boot-disk-size=DISK_SIZE \
    --boot-disk-storage-class=DISK_CLASS \
    --cloud-init-file=FILE_PATH \
    --cpu=CPU_NUMBER \
    --image=IMAGE_PATH \
    --memory=MEMORY_SIZE \

以下を置き換えます。

VM_NAME は、作成する VM の名前に置き換えます。
DISK_ACCESS_MODE は、ブートディスクのアクセスモードに置き換えます。有効な値は ReadWriteOnce（デフォルト）または ReadWriteMany です。
DISK_SIZE は、ブートディスクのサイズに置き換えます。デフォルト値は 20Gi です。
DISK_CLASS は、ブートディスクのストレージクラスに置き換えます。デフォルト値は local-shared です。
FILE_PATH は、カスタマイズした cloud-init ファイルのフルパスに置き換えます。これは、イメージによっては、作成後にその VM にコンソールアクセスするのに必要な場合があります。--os フラグを指定して cloud-init ファイルを自動的に構成する場合は、--cloud-init-file フラグを指定しないでください。--cloud-init-file フラグを指定している場合、--os フラグは無視されます。--os の有効な値は ubuntu、centos、debian、fedora です。
CPU_NUMBER は、VM に構成する CPU の数に置き換えます。デフォルト値は 1 です。
IMAGE_PATH は、カスタムイメージへのローカルファイルパスに置き換えます。
MEMORY_SIZE は、VM のメモリサイズに置き換えます。デフォルト値は 4Gi です。

フラグのデフォルト値の変更

kubectl virt create vm コマンドでは、実行時、未指定のフラグへの自動入力にデフォルト値が使用されます。このデフォルト値は、次のコマンドを実行して変更できます。

kubectl virt config default FLAG

FLAG は、デフォルト値を変更するパラメータのフラグに置き換えます。

例: 次のコマンドは、デフォルトの CPU 構成を最初のデフォルトの 1 から 2 に変更します。

kubectl virt config default --cpu=2

サポートされているフラグと、そのフラグの現在のデフォルト値のリストを表示するには、次のコマンドを実行します。

kubectl virt config default -h

デフォルトの構成は、~/.virtctl.default というローカルファイルとしてクライアントサイドに保存されます。このファイルを編集することでも、デフォルトの構成が変更できます。

VM にアクセスする

次の方法で VM にアクセスできます。

コンソールアクセス

コンソールから VM にアクセスするには、次のコマンドを実行します。

kubectl virt console VM_NAME

VM_NAME は、アクセスする VM の名前に置き換えます。

VNC アクセス

VNC を使用して VM にアクセスするには、次のコマンドを実行します。

# This requires remote-viewer from the virt-viewer package and a graphical desktop from where you run virtctl
kubectl virt vnc VM_NAME

VM_NAME は、アクセスする VM の名前に置き換えます。

内部アクセス

クラスタ VM の IP アドレスには、クラスタ内の他のすべての Pod から直接アクセスできます。VM の IP アドレスを確認するには、次のコマンドを実行します。

kubectl get vmi VM_NAME

VM_NAME は、アクセスする VM の名前に置き換えます。

このコマンドは次のような出力を返します。

NAME     AGE   PHASE     IP              NODENAME
vm1      13m   Running   192.168.1.194   upgi-bm002

外部アクセス

クラスタに作成された VM には、クラスタ内からのみアクセスできる Pod ネットワークアドレスがあります。クラスタ VM に外部からアクセスするには、次のコマンドを実行します。

VM をロードバランササービスとして公開します。
```
kubectl virt expose vm VM_NAME \
    --port=LB_PORT \
    --target-port=VM_PORT \
    --type=LoadBalancer \
    --name=SERVICE_NAME
```
以下を置き換えます。
- VM_NAME は、アクセスする VM の名前に置き換えます。
- LB_PORT は、公開するロードバランササービスのポートに置き換えます。
- VM_PORT は、ロードバランササービスを介してアクセスする VM のポートに置き換えます。
- SERVICE_NAME は、このロードバランササービスに付ける名前に置き換えます。
ロードバランササービスの外部 IP アドレスを取得します。
```
kubectl get svc SERVICE_NAME
```
SERVICE_NAME は、VM を公開するロードバランササービスの名前に置き換えます。

VM のターゲットポートには、レスポンスの EXTERNAL-IP フィールドに列挙されている IP アドレスを使用してアクセスできます。

例

galaxy という名前の VM があり、SSH を使用してクラスタの外部からアクセスしたい場合は、次のコマンドを実行します。

kubectl virt expose vm galaxy \
   --port=25022 \
   --target-port=22 \
   --type=LoadBalancer \
   --name=galaxy-ssh

次に、ロードバランサの IP アドレスを取得します。

kubectl get svc galaxy-ssh

このコマンドは次のような出力を返します。

NAME        TYPE          CLUSTER-IP     EXTERNAL-IP   PORT(S)           AGE
galaxy-ssh  LoadBalancer  10.96.250.76   21.1.38.202   25000:30499/TCP   4m40s

これで、クラスタの外部から 21.1.38.202:25022（VIP: ポート）を介し、SSH を使用して VM にアクセスできるようになりました。

ssh root@21.1.38.202:22 -p 25022

VM テレメトリーとコンソールログの検査

VM テレメトリーとコンソールログは Google Cloud コンソールに統合されました。テレメトリー情報とログデータは、VM のステータスのモニタリングとクラスタ VM に関する問題のトラブルシューティングに不可欠です。

VM テレメトリー

[Anthos クラスタ VM ステータス] ダッシュボードには、クラスタ VM のライブテレメトリーデータが表示されます。

クラスタ VM のテレメトリー情報を表示します。

Google Cloud コンソールで [Monitoring] を選択するか、次のボタンをクリックします。

[モニタリング] に移動
[ダッシュボード] を選択します。
[すべてのダッシュボード] リストで、Anthos クラスタ VM のステータスをクリックします。

VM コンソールのログ

VM のシリアルコンソールのログは Cloud Logging にストリーミングされ、ログエクスプローラで表示できます。

Anthos クラスタ VM のデータを示すログエクスプローラ

VM とそのリソースを削除する

VM のみを削除する

kubectl virt delete vm VM_NAME

VM_NAME は、削除する VM の名前に置き換えます。

VM ディスクのみを削除する

kubectl virt delete disk DISK_NAME

DISK_NAME は、削除するディスクの名前に置き換えます。VM を削除する前に VM ディスクを削除しようとすると、ディスクは削除マークが付けられ、VM の削除は保留中になります。

VM とリソースを削除する

kubectl virt delete vm VM_NAME --all

VM_NAME は、削除する VM の名前に置き換えます。

削除される VM によって使用されているリソースを確認する場合は、--all とともに --dry-run フラグを指定できます。

Anthos VM ランタイムを無効にする

Anthos VM ランタイムを使用する必要がもうなくなったら、この機能を無効にできます。

bmctl

ランタイムを無効にするには、bmctl ツールを使用します。
```
bmctl disable vmruntime --kubeconfig KUBECONFIG_PATH \
  --timeout TIMEOUT_IN_MINUTES \
  --force true
```
クラスタの kubeconfig ファイルへのパスと次の構成オプションの値を指定します。
- --timeout: 既存の VM リソースが削除されるまで待機するTIMEOUT_IN_MINUTES。デフォルト値は 10 分です。
- --force: true に設定して、既存の VM リソースを削除することを確定します。デフォルト値は false です。

カスタムリソース

VMRuntime カスタムリソースを編集してクラスタの Anthos VM ランタイムを無効にする前に、そのクラスタ内のすべての VM が削除されていることを確認する必要があります。

ランタイムを無効にするには、VMRuntime カスタムリソースを更新します。

クラスタに VM があるかどうかを確認します。
```
kubectl get vm
```
コマンドに、クラスタに VM がまだ残っていることが示されている場合は、続行する前にそれらを削除する必要があります。
VMRuntime カスタムリソースを編集します。
```
kubectl edit vmruntime
```

仕様に enabled:false を設定します。

apiVersion: vm.cluster.gke.io/v1`
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  enabled: false
  useEmulation: true
  vmImageFormat: qcow2

更新したカスタムリソース仕様をエディタに保存します。
VMRuntime カスタムリソースが無効になっていることを確認するには、vm-system 名前空間で実行されている Pod を表示します。
```
kubectl get pods --namespace vm-system
```
vmruntime-controller-manager デプロイメントに属する Pod のみが名前空間で実行されている場合、Anthos VM ランタイムが無効になります。

次のステップ

Anthos VM ランタイムの既知の問題について確認する。
KubeVirt ユーザーガイドを確認する。

VM ベースのワークロードでの操作

始める前に

Anthos VM ランタイムを有効にする

クラスタのアップグレード

virtctl をインストールします。

VM を作成する

コンソール アクセス用にカスタム cloud-init ファイルを作成する

kubectl virt create vm コマンドを実行する

公開イメージ

カスタム イメージ

HTTP イメージ サーバー

ローカルに保存されているイメージ

フラグのデフォルト値の変更

VM にアクセスする

コンソール アクセス

VNC アクセス

内部アクセス

外部アクセス

例

VM テレメトリーとコンソールログの検査

VM テレメトリー

VM コンソールのログ

VM とそのリソースを削除する

VM のみを削除する

VM ディスクのみを削除する

VM とリソースを削除する

Anthos VM ランタイムを無効にする

bmctl

カスタム リソース

次のステップ

`virtctl` をインストールします。

コンソールアクセス用にカスタム cloud-init ファイルを作成する

`kubectl virt create vm` コマンドを実行する

カスタムイメージ

HTTP イメージサーバー

コンソールアクセス

カスタムリソース