Google Distributed Cloud 上の VM ランタイムで VM 構成を編集する

このドキュメントは、Google Distributed Cloud 上の VM ランタイムを使用して、ベアメタル版 GKE で仮想マシン(VM)を実行するアプリケーション オーナーを対象としています。このドキュメントでは、GKE クラスタで実行されている VM を編集する方法について説明します。たとえば、CPU やメモリなどのリソース割り当ての編集や、VM の接続先ネットワークの変更を行うことができます。

VirtualMachine リソースの spec セクションに存在する任意のフィールドを変更できます。VM のラベルを編集することもできます。VM 名(metadata.name)など他のフィールドは編集できません。デフォルトでは、リソースを編集する前に VM が Stopped 状態になっている必要があります。GKE on bare metal バージョン 1.13.0 では、構成を変更するたびに自動的に再起動するように VirtualMachine リソースを構成できます。

VirtualMachine リソースへの編集の保存時にエラーが含まれる場合、変更は拒否され、通知が表示されます。エラーを修正して、もう一度 VirtualMachine リソースを保存してみてください。変更後に VM が起動しない場合は、kubectl describe gvm VM_NAME コマンドを使用してトラブルシューティング情報を表示し、エラーを修正します。

始める前に

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

コンピューティング リソースを編集

コンピューティング ワークロードの変更が必要な場合は、VM に割り当てる仮想 CPU の数と仮想メモリの量を更新できます。コンピューティング ワークロードを編集するには、次の手順を行います。

  1. 編集する VM を停止します。

    kubectl virt stop VM_NAME
    

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

  2. kubectl を使用して VM を編集します。

    kubectl edit gvm VM_NAME
    

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

  3. エディタで、変更するコンピューティング リソースの値を更新します。

    たとえば、次の VirtualMachine マニフェストの例は、VM リソースに 2 個の vCPU が割り当てられていることを示しています。

    apiVersion: vm.cluster.gke.io/v1
    kind: VirtualMachine
    metadata:
      name: vm1
    spec:
      ...
      compute:
        cpu:
          vcpus: 2
    ...
    

    割り当てられている vCPU の数を更新する場合は、次の例に示すように、エディタでその値を変更します。

    apiVersion: vm.cluster.gke.io/v1
    kind: VirtualMachine
    metadata:
      name: vm1
    spec:
      ...
      compute:
        cpu:
          vcpus: 4
    ...
    
  4. VM マニフェストを保存して閉じます。

  5. 編集した VM を起動します。

    kubectl virt start VM_NAME
    

    VM_NAME は、編集した VM の名前に置き換えます。

  6. VM の STATUS を確認します。

    kubectl get gvm VM_NAME
    

    VM が Running 状態であることを確認します。VM がホストが提供できるよりも多くのコンピューティング リソースをリクエストすると、VM は起動できません。VM が Running 状態でない場合は、VirtualMachine リソース マニフェストとホストのコンピューティング リソースの使用可否を確認します。

    次の出力例では、Running 状態の VM を示します。

    NAME   STATUS    AGE   IP
    vm1    Running   1m    192.168.2.72
    
  7. kubectl describe gvm を使用して、VM の詳細情報を表示します。

    kubectl describe gvm VM_NAME
    

    VM_NAME は、編集した VM の名前に置き換えます。

    次の出力例では、vCPU の数が正常に変更された VM の要約情報を示します。

    Name:         vm1
    Namespace:    default
    Labels:       <none>
    Annotations:  <none>
    API Version:  vm.cluster.gke.io/v1
    Kind:         VirtualMachine
    ...
    Spec:
      Compute:
        Cpu:
          Vcpus:  4
    ...
    

詳細については、特定の vCPU とメモリ コンピューティング構成を持つ VM を作成するをご覧ください。

ディスク リソースを編集

ストレージ要件が変わった場合は、VM の仮想ディスクを追加または削除できます。VM にアタッチされているディスクを編集するには、次の手順を行います。

  1. 編集する VM を停止します。

    kubectl virt stop VM_NAME
    

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

  2. kubectl を使用して VM を編集します。

    kubectl edit gvm VM_NAME
    

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

  3. エディタで、spec.disks セクションを更新してディスクのアタッチや切断を行います。

    たとえば、次の VirtualMachine マニフェストの例は、ブートディスクのみが VM にアタッチされていることを示しています。

    apiVersion: vm.cluster.gke.io/v1
    kind: VirtualMachine
    metadata:
      name: vm1
    spec:
      ...
      disks:
        - boot: true
          virtualMachineDiskName: vm1-boot-dv
      ...
    

    既存の空のディスクを追加する場合は、次の例に示すように、エディタでディスク構成を更新します。

    apiVersion: vm.cluster.gke.io/v1
    kind: VirtualMachine
    metadata:
      name: vm1
    spec:
      ...
      disks:
        - boot: true
          virtualMachineDiskName: vm1-boot-dv
        - virtualMachineDiskName: DISK_NAME
      ...
    

    DISK_NAME は、アタッチするディスクの名前に置き換えます。

  4. VM マニフェストを保存して閉じます。

  5. 編集した VM を起動します。

    kubectl virt start VM_NAME
    

    VM_NAME は、編集した VM の名前に置き換えます。

  6. VM の STATUS を確認します。

    kubectl get gvm VM_NAME
    

    VM が Running 状態であることを確認します。VM がホストが提供できない StorageClass やディスクの割り当てをリクエストすると、VM は起動できません。VM が Running 状態でない場合は、VirtualMachineVirtualMachineDisk のリソース マニフェストとホスト ストレージのサポートを確認します。

  7. kubectl describe gvm を使用して、VM の詳細情報を表示します。

    kubectl describe gvm VM_NAME
    

    VM_NAME は、編集した VM の名前に置き換えます。

    次の出力例では、アタッチされたディスクの変更が正常に適用された、VM の情報を抜粋して示します。

    Name:         vm1
    Namespace:    default
    Labels:       <none>
    Annotations:  <none>
    API Version:  vm.cluster.gke.io/v1
    Kind:         VirtualMachine
    ...
    Spec:
      Disks:
        Name:  vm1-boot-dv
        Name:  data-disk-01
    ...
    

詳細については、ディスクの作成と管理をご覧ください。

ネットワーク リソースの編集

インフラストラクチャが変更されると、必要に応じて VM のネットワーク構成を変更できます。たとえば、VM を別の仮想ネットワークに接続できます。または、IP アドレスを手動で割り当てることもできます。VM のネットワーク構成を編集するには、次の手順を行います。

  1. 編集する VM を停止します。

    kubectl virt stop VM_NAME
    

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

  2. kubectl を使用して VM を編集します。

    kubectl edit gvm VM_NAME
    

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

  3. エディタで、変更するネットワーク構成の設定を更新します。

    たとえば、次の VirtualMachine マニフェストの例では、IP アドレスが定義されていないため、VM が backend-vlan100 という名前のネットワークに接続して DHCP を使用することを示します。

    apiVersion: vm.cluster.gke.io/v1
    kind: VirtualMachine
    metadata:
      name: vm1
    spec:
      ...
      interfaces:
        - name: eth0
          networkName: backend-vlan100
          default: true
    ...
    

    VM が接続するネットワークを変更する場合や、手動の IP アドレスを割り当てる場合は、次の例に示すように、エディタでネットワーク構成を更新します。

    apiVersion: vm.cluster.gke.io/v1
    kind: VirtualMachine
    metadata:
      name: vm1
    spec:
      ...
      interfaces:
        - name: eth0
          networkName: NETWORK_NAME
            ipAddresses:
              - IP_ADDRESS
          default: true
    ...
    

    NETWORK_NAME は、接続するネットワークの名前に置き換えます。あるいは、ipAddresses セクションを追加して、VM に使用する IP_ADDRESS を指定します。

  4. VM マニフェストを保存して閉じます。

  5. 編集した VM を起動します。

    kubectl virt start VM_NAME
    

    VM_NAME は、編集した VM の名前に置き換えます。

  6. VM の STATUS を確認します。

    kubectl get gvm VM_NAME
    

    VM が Running 状態であることを確認します。VM がホストが提供できないネットワーク接続をリクエストした場合、VM は起動できません。VM が Running 状態でない場合は、VirtualMachine リソース マニフェストとホスト ネットワークのサポートを確認します。

  7. kubectl describe gvm を使用して、VM の詳細情報を表示します。

    kubectl describe gvm VM_NAME
    

    VM_NAME は、編集した VM の名前に置き換えます。

    次の出力例では、ネットワークと IP アドレスの構成に対する変更内容が正常に適用された VM の情報を抜粋して示します。

    Name:         vm1
    Namespace:    default
    Labels:       <none>
    Annotations:  <none>
    API Version:  vm.cluster.gke.io/v1
    Kind:         VirtualMachine
    ...
    Spec:
      Compute:
      Interfaces:
        Name:          eth0
        Network Name:  backend-vlan200
    ...
    Status:
      ...
      Interfaces:
        Dns Config:
          Nameservers:
            8.8.8.8
        gateway4:  10.200.0.9
        Ip Addresses:
          10.200.0.22/24
        Mac Address:    22:b4:e3:d2:ef:fb
        Name:           eth0
        Resource Name:  vm1-eth0-f2468
    ...
    

詳細については、仮想ネットワークを作成して管理する方法をご覧ください。

自動再起動用に VM を構成する

compute 設定の変更など、VM 構成の変更の多くは、対応する VM インスタンス(VirtualMachineInstance)と同期するために VM を停止して再起動する必要があります。ベアメタル版 GKE バージョン 1.13.0 以降で実行されている VM は、構成を変更するたびに自動的に再起動するように構成できます。この機能を使用するように VM を構成する場合、カスタム リソースを編集する際に VM を停止して再起動する必要はありません。Google Distributed Cloud 上の VM ランタイムは VM をモニタリングし、構成の変更を検出すると、VM を自動的に再起動して変更を同期します。

Config Management を使用して YAML 構成ファイルを管理する場合、この機能は特に便利です。この機能を使用しない場合は、VirtualMachine カスタム リソースを変更する前に VM を手動で停止し、変更が完了したら VM を手動で起動する必要があります。

自動再起動を有効にするには:

  1. kubectl を使用して VM を編集します。

    kubectl edit gvm VM_NAME
    
  2. エディタで、autoRestartOnConfigurationChange フィールドを追加して true に設定します。

    vcpus の値を更新するなど、VM に追加の変更を加えることができます。compute の設定を編集した場合、変更を保存するときに Google Distributed Cloud 上の VM ランタイムが自動的に VM を再起動します。

    apiVersion: vm.cluster.gke.io/v1
    kind: VirtualMachine
    metadata:
      ...
      name: vm-sample-01
      namespace: default
      resourceVersion: "16711824"
      uid: ed623879-0cfa-52de-ad2c-b63308e6116c
    spec:
      autoRestartOnConfigurationChange: true
      compute:
        cpu:
          vcpus: 2
          ...
    
  3. VM マニフェストを保存して閉じます。

    対応する VM インスタンスと同期する必要がある VM のその他の変更を行った場合、Google Distributed Cloud 上の VM ランタイムが VM を再起動します。自動再起動を有効にするように変更しただけの場合は、VM の再起動は必要ありません。

  4. VM の status を確認します。

    kubectl get gvm VM_NAME
    

    VM の取得速度によっては、VM を再起動すると state: Starting が表示される場合があります。VM が正常に再起動されると、state: Running が表示されます。後続の構成を VirtualMachine カスタム リソースに変更しても、VM を手動で停止して起動する必要はありません。その後のカスタム リソースの変更は、VM インスタンスに一貫して反映されます。

次の機能の動作に注意してください。

  • VirtualMachine カスタム リソースを編集する前に VM を手動で停止した場合、構成の変更によって再起動はトリガーされません。構成変更が行われる前の VM の停止状態。

  • 自動再起動機能を有効にする前に、VM のラベルやスケジュールの変更を行った場合は、他の変更を行わずにすぐに autoRestartOnConfigurationChange を追加しても再起動はトリガーされません。この機能によって VM インスタンスと VM 構成の整合性が維持されるのが理想的です。ただし、Google Distributed Cloud 上の VM ランタイムでは、以前の不整合を検出できません。

次のステップ