このドキュメントは、GDC 上の VM ランタイムを使用して、ベアメタル上の Google Distributed Cloud（ソフトウェアのみ）で作成されたクラスタで仮想マシン（VM）を実行するアプリケーション オーナーを対象としています。このドキュメントでは、ベアメタル クラスタで実行されている VM を編集する方法について説明します。たとえば、CPU やメモリなどのリソース割り当ての編集や、VM の接続先ネットワークの変更を行うことができます。
VirtualMachine リソースの spec セクションに存在する任意のフィールドを変更できます。VM のラベルを編集することもできます。VM 名（metadata.name）など他のフィールドは編集できません。デフォルトでは、リソースを編集する前に VM が Stopped 状態になっている必要があります。ただし、Google Distributed Cloud バージョン 1.13.0 以降では、構成を変更するたびに自動的に再起動するように VirtualMachine リソースを構成できます。
VirtualMachine リソースへの編集の保存時にエラーが含まれる場合、変更は拒否され、通知が表示されます。エラーを修正して、もう一度 VirtualMachine リソースを保存してみてください。変更後に VM が起動しない場合は、kubectl describe gvm VM_NAME コマンドを使用してトラブルシューティング情報を表示し、エラーを修正します。
始める前に
このドキュメントの内容を実施するには、次のリソースへのアクセス権が必要です。
- クラスタのいずれかで動作する VM。必要に応じて、ベアメタル クラスタに VM を作成します。
kubectlのプラグインとしてインストールされたvirtctlクライアント ツール。必要に応じて、virtctl クライアント ツールをインストールします。
コンピューティング リソースを編集
コンピューティング ワークロードの変更が必要な場合は、VM に割り当てる仮想 CPU の数と仮想メモリの量を更新できます。コンピューティング ワークロードを編集するには、次の手順を行います。
編集する VM を停止します。
kubectl virt stop VM_NAMEVM_NAMEは、停止する VM の名前に置き換えます。kubectlを使用して VM を編集します。kubectl edit gvm VM_NAMEVM_NAMEは、編集する VM の名前に置き換えます。エディタで、変更するコンピューティング リソースの値を更新します。
たとえば、次の
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 ...VM マニフェストを保存して閉じます。
編集した VM を起動します。
kubectl virt start VM_NAMEVM_NAMEは、編集した VM の名前に置き換えます。VM の
STATUSを確認します。kubectl get gvm VM_NAMEVM が
Running状態であることを確認します。VM がホストが提供できるよりも多くのコンピューティング リソースをリクエストすると、VM は起動できません。VM がRunning状態でない場合は、VirtualMachineリソース マニフェストとホストのコンピューティング リソースの使用可否を確認します。次の出力例では、
Running状態の VM を示します。NAME STATUS AGE IP vm1 Running 1m 192.168.2.72kubectl describe gvmを使用して、VM の詳細情報を表示します。kubectl describe gvm VM_NAMEVM_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 にアタッチされているディスクを編集するには、次の手順を行います。
編集する VM を停止します。
kubectl virt stop VM_NAMEVM_NAMEは、停止する VM の名前に置き換えます。kubectlを使用して VM を編集します。kubectl edit gvm VM_NAMEVM_NAMEは、編集する VM の名前に置き換えます。エディタで、
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は、アタッチするディスクの名前に置き換えます。VM マニフェストを保存して閉じます。
編集した VM を起動します。
kubectl virt start VM_NAMEVM_NAMEは、編集した VM の名前に置き換えます。VM の
STATUSを確認します。kubectl get gvm VM_NAMEVM が
Running状態であることを確認します。VM がホストが提供できないStorageClassやディスクの割り当てをリクエストすると、VM は起動できません。VM がRunning状態でない場合は、VirtualMachineとVirtualMachineDiskのリソース マニフェストとホスト ストレージのサポートを確認します。kubectl describe gvmを使用して、VM の詳細情報を表示します。kubectl describe gvm VM_NAMEVM_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 のネットワーク構成を編集するには、次の手順を行います。
編集する VM を停止します。
kubectl virt stop VM_NAMEVM_NAMEは、停止する VM の名前に置き換えます。kubectlを使用して VM を編集します。kubectl edit gvm VM_NAMEVM_NAMEは、編集する VM の名前に置き換えます。エディタで、変更するネットワーク構成の設定を更新します。
たとえば、次の
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を指定します。VM マニフェストを保存して閉じます。
編集した VM を起動します。
kubectl virt start VM_NAMEVM_NAMEは、編集した VM の名前に置き換えます。VM の
STATUSを確認します。kubectl get gvm VM_NAMEVM が
Running状態であることを確認します。VM がホストが提供できないネットワーク接続をリクエストした場合、VM は起動できません。VM がRunning状態でない場合は、VirtualMachineリソース マニフェストとホスト ネットワークのサポートを確認します。kubectl describe gvmを使用して、VM の詳細情報を表示します。kubectl describe gvm VM_NAMEVM_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 を停止して再起動する必要があります。バージョン 1.13.0 以降のクラスタで実行されている VM は、構成を変更するたびに自動的に再起動するように構成できます。この機能を使用するように VM を構成する場合、カスタム リソースを編集する際に VM を停止して再起動する必要はありません。GDC 上の VM ランタイムが VM をモニタリングし、構成の変更を検出すると、VM を自動的に再起動して変更を同期します。
Config Sync を使用して YAML 構成ファイルを管理する場合、この機能は特に便利です。この機能を使用しない場合は、VirtualMachine カスタム リソースを変更する前に VM を手動で停止し、変更が完了したら VM を手動で起動する必要があります。
自動再起動を有効にするには:
kubectlを使用して VM を編集します。kubectl edit gvm VM_NAMEエディタで、
autoRestartOnConfigurationChangeフィールドを追加してtrueに設定します。vcpusの値を更新するなど、VM に追加の変更を加えることができます。computeの設定を編集した場合は、変更を保存するときに GDC 上の 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 ...VM マニフェストを保存して閉じます。
対応する VM インスタンスと同期する必要がある VM にその他の変更を加えた場合、GDC 上の VM ランタイムが VM を再起動します。自動再起動を有効にするように変更しただけの場合は、VM の再起動は必要ありません。
VM の
statusを確認します。kubectl get gvm VM_NAMEVM の取得速度によっては、VM を再起動すると
state: Startingが表示される場合があります。VM が正常に再起動されると、state: Runningが表示されます。後続の構成をVirtualMachineカスタム リソースに変更しても、VM を手動で停止して起動する必要はありません。その後のカスタム リソースの変更は、VM インスタンスに一貫して反映されます。
次の機能の動作に注意してください。
VirtualMachineカスタム リソースを編集する前に VM を手動で停止した場合、構成の変更によって再起動はトリガーされません。構成変更が行われる前の VM の停止状態。自動再起動機能を有効にする前に、VM のラベルやスケジュールの変更を行った場合は、他の変更を行わずにすぐに
autoRestartOnConfigurationChangeを追加しても再起動はトリガーされません。この機能によって VM インスタンスと VM 構成の整合性が維持されるのが理想的です。ただし、GDC 上の VM ランタイムは、以前の不整合を検出できません。