このドキュメントは、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。必要に応じて、ベアメタル版 GKE で VM を作成します。
kubectl
のプラグインとしてインストールされたvirtctl
クライアント ツール。必要に応じて、virtctl クライアント ツールをインストールします。
コンピューティング リソースを編集
コンピューティング ワークロードの変更が必要な場合は、VM に割り当てる仮想 CPU の数と仮想メモリの量を更新できます。コンピューティング ワークロードを編集するには、次の手順を行います。
編集する VM を停止します。
kubectl virt stop VM_NAME
VM_NAME
は、停止する VM の名前に置き換えます。kubectl
を使用して VM を編集します。kubectl edit gvm VM_NAME
VM_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_NAME
VM_NAME
は、編集した VM の名前に置き換えます。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
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 にアタッチされているディスクを編集するには、次の手順を行います。
編集する VM を停止します。
kubectl virt stop VM_NAME
VM_NAME
は、停止する VM の名前に置き換えます。kubectl
を使用して VM を編集します。kubectl edit gvm VM_NAME
VM_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_NAME
VM_NAME
は、編集した VM の名前に置き換えます。VM の
STATUS
を確認します。kubectl get gvm VM_NAME
VM が
Running
状態であることを確認します。VM がホストが提供できないStorageClass
やディスクの割り当てをリクエストすると、VM は起動できません。VM がRunning
状態でない場合は、VirtualMachine
とVirtualMachineDisk
のリソース マニフェストとホスト ストレージのサポートを確認します。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 のネットワーク構成を編集するには、次の手順を行います。
編集する VM を停止します。
kubectl virt stop VM_NAME
VM_NAME
は、停止する VM の名前に置き換えます。kubectl
を使用して VM を編集します。kubectl edit gvm VM_NAME
VM_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_NAME
VM_NAME
は、編集した VM の名前に置き換えます。VM の
STATUS
を確認します。kubectl get gvm VM_NAME
VM が
Running
状態であることを確認します。VM がホストが提供できないネットワーク接続をリクエストした場合、VM は起動できません。VM がRunning
状態でない場合は、VirtualMachine
リソース マニフェストとホスト ネットワークのサポートを確認します。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 を手動で起動する必要があります。
自動再起動を有効にするには:
kubectl
を使用して VM を編集します。kubectl edit gvm VM_NAME
エディタで、
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 ...
VM マニフェストを保存して閉じます。
対応する VM インスタンスと同期する必要がある VM のその他の変更を行った場合、Google Distributed Cloud 上の VM ランタイムが VM を再起動します。自動再起動を有効にするように変更しただけの場合は、VM の再起動は必要ありません。
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 ランタイムでは、以前の不整合を検出できません。