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 ランタイムを有効にするには:

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

    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
    
  2. ノードがハードウェア仮想化をサポートしていない場合や、それが不明な場合は、useEmulationtrue に設定します。

    使用可能な場合、ハードウェア仮想化は、ソフトウェア エミュレーションよりもパフォーマンスが優れています。指定しない場合、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
    
  3. 作成した VM に使用するイメージ形式は、vmImageFormat フィールドを設定することによって変更できます。

    vmImageFormat フィールドは、rawqcow2 の 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
    
  4. 構成を保存し、VMRuntime カスタム リソースが有効であることを確認します。

    kubectl describe vmruntime vmruntime
    

    VMRuntime カスタム リソースの詳細には、Status セクションが含まれています。VMRuntime.Status.Readytrue に設定されていれば、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 をインストールします。

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

    export GOOGLE_APPLICATION_CREDENTIALS="bm-gcr.json"
    sudo -E ./bmctl install virtctl
    
  2. 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 の許容値は ubuntucentosdebianfedora です。
  • 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 の有効な値は ubuntucentosdebianfedora です。
  • 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 の有効な値は ubuntucentosdebianfedora です。
  • 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 に外部からアクセスするには、次のコマンドを実行します。

  1. 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 は、このロードバランサ サービスに付ける名前に置き換えます。
  2. ロードバランサ サービスの外部 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 のテレメトリー情報を表示します。

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

    [モニタリング] に移動

  2. [ダッシュボード] を選択します。

    Monitoring ダッシュボード リストにある Anthos クラスタ VM のステータス ダッシュボード

  3. [すべてのダッシュボード] リストで、Anthos クラスタ VM のステータスをクリックします。

    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 カスタム リソースを更新します。

  1. クラスタに VM があるかどうかを確認します。

    kubectl get vm
    

    コマンドに、クラスタに VM がまだ残っていることが示されている場合は、続行する前にそれらを削除する必要があります。

  2. VMRuntime カスタム リソースを編集します。

    kubectl edit vmruntime
    
  3. 仕様に enabled:false を設定します。

    apiVersion: vm.cluster.gke.io/v1`
    kind: VMRuntime
    metadata:
      name: vmruntime
    spec:
      enabled: false
      useEmulation: true
      vmImageFormat: qcow2
    
  4. 更新したカスタム リソース仕様をエディタに保存します。

  5. VMRuntime カスタム リソースが無効になっていることを確認するには、vm-system 名前空間で実行されている Pod を表示します。

    kubectl get pods --namespace vm-system
    

    vmruntime-controller-manager デプロイメントに属する Pod のみが名前空間で実行されている場合、Anthos VM ランタイムが無効になります。

次のステップ