18 Edge Virtualization #
このセクションでは、Edge Virtualizationを使用してエッジノードで仮想マシンを実行する方法について説明します。Edge Virtualizationは包括的なソリューションではなく、機能も限られていることを指摘しておくことが重要です。Edge Virtualizationは、基本的な仮想マシン機能が要求される軽量な仮想化の要件を解決しようとするものです。より包括的な仮想化(およびハイパーコンバージドインフラストラクチャ)ソリューションは、Harvesterで提供されています。
SUSE Edge Virtualizationでは、仮想マシンの実行方法として次の2つをサポートしています。
libvirt+qemu-kvmを使用してホストレベルで手動で仮想マシンをデプロイする
KubeVirtオペレータをデプロイし、Kubernetesベースで仮想マシンを管理する
どちらのオプションも有効ですが、以下では2番目のオプションのみを説明しています。SLE Microで提供されている、すぐに使用できる標準の仮想化メカニズムを使用する場合は、こちらで包括的なガイドを参照してください。このガイドは主にSUSE Linux Enterprise Server用に記載されていますが、概念はほぼ同じです。
このガイドではまず、事前にデプロイ済みのシステムに追加の仮想化コンポーネントをデプロイする方法について説明しますが、その後に続くセクションでは、Edge Image Builderを使用してこの設定を最初のデプロイメントに組み込む方法を説明しています。基本手順を実行して環境を手動で設定する必要がない場合は、そちらのセクションに進んでください。
18.1 KubeVirtの概要 #
KubeVirtでは、仮想マシンと他のコンテナ化ワークロードを併せてKubernetesで管理できます。これを実現するために、Linux仮想化スタックのユーザスペース部分をコンテナ内で実行します。これにより、ホストシステムの要件が最小限に抑えられ、セットアップと管理が容易になります。
KubeVirtのアーキテクチャの詳細については、アップストリームドキュメントを参照してください。
18.2 前提条件 #
このガイドに従って操作を進める場合、以下がすでに用意されていることを想定しています。
SLE Micro 5.5+がインストールされ、BIOSで仮想化拡張機能が有効になっている物理ホスト1台以上(詳細については、こちらを参照)。
ノード全体で、K3s/RKE2 Kubernetesクラスタがすでにデプロイされており、クラスタへのスーパーユーザアクセスを可能にする適切な
kubeconfigが設定されている。ルートユーザへのアクセス — 以下の説明では、自身がルートユーザであり、
sudoを使用して特権を昇格して「いない」ことを想定しています。Helmがローカルで利用可能で、適切なネットワーク接続を備えていて、Kubernetesクラスタに設定をプッシュし、必要なイメージをダウンロードできる。
18.3 Edge Virtualizationの手動インストール #
このガイドでは、Kubernetesのデプロイメント手順については説明しませんが、SUSE Edgeに適したバージョンのK3sまたはRKE2がインストールされていること、およびkubeconfigが適切に設定されていて標準のkubectlコマンドをスーパーユーザとして実行できることを想定しています。また、シングルノードクラスタを形成することを想定していますが、マルチノードのデプロイメントでも大きな違いはないと考えられます。
SUSE Edge Virtualizationは、3つの別個のHelmチャートを使用してデプロイします。具体的には次のとおりです。
KubeVirt: 中心的な仮想化コンポーネント。つまり、Kubernetesが仮想マシンをデプロイおよび管理できるようにするために必要なKubernetes CRD、オペレータ、およびその他のコンポーネント。
KubeVirtダッシュボード拡張機能: 仮想マシンの起動/停止やコンソールへのアクセスなど、基本的な仮想マシン管理を実行できるオプションのRancher UI拡張機能。
Containerized Data Importer (CDI): KubeVirtの永続ストレージの統合を可能にする追加コンポーネント。仮想マシンが既存のKubernetesストレージバックエンドをデータ用に使用する機能を提供するだけでなく、ユーザが仮想マシンのデータボリュームのインポートまたはクローンの作成を行うことも可能にします。
これらの各Helmチャートは、現在使用しているSUSE Edgeのリリースに従ってバージョン管理されています。運用での使用/サポートされる使用のためには、SUSEレジストリにあるアーティファクトを使用してください。
まず、 kubectlのアクセスが機能していることを確認します。
$ kubectl get nodes
次のような画面が表示されます。
NAME STATUS ROLES AGE VERSION node1.edge.rdo.wales Ready control-plane,etcd,master 4h20m v1.28.9+rke2r1 node2.edge.rdo.wales Ready control-plane,etcd,master 4h15m v1.28.9+rke2r1 node3.edge.rdo.wales Ready control-plane,etcd,master 4h15m v1.28.9+rke2r1
これで、KubeVirtおよびContainerized Data Importer (CDI)のHelmチャートのインストールに進むことができます。
$ helm install kubevirt oci://registry.suse.com/edge/kubevirt-chart --namespace kubevirt-system --create-namespace $ helm install cdi oci://registry.suse.com/edge/cdi-chart --namespace cdi-system --create-namespace
数分ですべてのKubeVirtおよびCDIコンポーネントがデプロイされるはずです。これを検証するには、kubevirt-systemおよびcdi-systemのネームスペース内にデプロイされたすべてのリソースを確認します。
KubeVirtリソースを確認します。
$ kubectl get all -n kubevirt-system
次のような画面が表示されます。
NAME READY STATUS RESTARTS AGE pod/virt-operator-5fbcf48d58-p7xpm 1/1 Running 0 2m24s pod/virt-operator-5fbcf48d58-wnf6s 1/1 Running 0 2m24s pod/virt-handler-t594x 1/1 Running 0 93s pod/virt-controller-5f84c69884-cwjvd 1/1 Running 1 (64s ago) 93s pod/virt-controller-5f84c69884-xxw6q 1/1 Running 1 (64s ago) 93s pod/virt-api-7dfc54cf95-v8kcl 1/1 Running 1 (59s ago) 118s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubevirt-prometheus-metrics ClusterIP None <none> 443/TCP 2m1s service/virt-api ClusterIP 10.43.56.140 <none> 443/TCP 2m1s service/kubevirt-operator-webhook ClusterIP 10.43.201.121 <none> 443/TCP 2m1s service/virt-exportproxy ClusterIP 10.43.83.23 <none> 443/TCP 2m1s NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/virt-handler 1 1 1 1 1 kubernetes.io/os=linux 93s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/virt-operator 2/2 2 2 2m24s deployment.apps/virt-controller 2/2 2 2 93s deployment.apps/virt-api 1/1 1 1 118s NAME DESIRED CURRENT READY AGE replicaset.apps/virt-operator-5fbcf48d58 2 2 2 2m24s replicaset.apps/virt-controller-5f84c69884 2 2 2 93s replicaset.apps/virt-api-7dfc54cf95 1 1 1 118s NAME AGE PHASE kubevirt.kubevirt.io/kubevirt 2m24s Deployed
CDIリソースを確認します。
$ kubectl get all -n cdi-system
次のような画面が表示されます。
NAME READY STATUS RESTARTS AGE pod/cdi-operator-55c74f4b86-692xb 1/1 Running 0 2m24s pod/cdi-apiserver-db465b888-62lvr 1/1 Running 0 2m21s pod/cdi-deployment-56c7d74995-mgkfn 1/1 Running 0 2m21s pod/cdi-uploadproxy-7d7b94b968-6kxc2 1/1 Running 0 2m22s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/cdi-uploadproxy ClusterIP 10.43.117.7 <none> 443/TCP 2m22s service/cdi-api ClusterIP 10.43.20.101 <none> 443/TCP 2m22s service/cdi-prometheus-metrics ClusterIP 10.43.39.153 <none> 8080/TCP 2m21s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/cdi-operator 1/1 1 1 2m24s deployment.apps/cdi-apiserver 1/1 1 1 2m22s deployment.apps/cdi-deployment 1/1 1 1 2m21s deployment.apps/cdi-uploadproxy 1/1 1 1 2m22s NAME DESIRED CURRENT READY AGE replicaset.apps/cdi-operator-55c74f4b86 1 1 1 2m24s replicaset.apps/cdi-apiserver-db465b888 1 1 1 2m21s replicaset.apps/cdi-deployment-56c7d74995 1 1 1 2m21s replicaset.apps/cdi-uploadproxy-7d7b94b968 1 1 1 2m22s
VirtualMachineカスタムリソース定義(CRD)がデプロイされていることを確認するには、次のコマンドで検証できます。
$ kubectl explain virtualmachine
VirtualMachineオブジェクトの定義が出力され、次のような画面が表示されます。
GROUP: kubevirt.io
KIND: VirtualMachine
VERSION: v1
DESCRIPTION:
VirtualMachine handles the VirtualMachines that are not running or are in a
stopped state The VirtualMachine contains the template to create the
VirtualMachineInstance. It also mirrors the running state of the created
VirtualMachineInstance in its status.
(snip)18.4 仮想マシンのデプロイ #
KubeVirtとCDIがデプロイされたので、openSUSE Tumbleweedに基づくシンプルな仮想マシンを定義してみましょう。この仮想マシンは最もシンプルな設定であり、標準の「Podネットワーキング」を使用して、他のPodと同じネットワーキング設定を行います。また、非永続ストレージを使用するため、PVCを持たないコンテナと同様に、ストレージは一時的なものになります。
$ kubectl apply -f - <<EOF
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
name: tumbleweed
namespace: default
spec:
runStrategy: Always
template:
spec:
domain:
devices: {}
machine:
type: q35
memory:
guest: 2Gi
resources: {}
volumes:
- containerDisk:
image: registry.opensuse.org/home/roxenham/tumbleweed-container-disk/containerfile/cloud-image:latest
name: tumbleweed-containerdisk-0
- cloudInitNoCloud:
userDataBase64: I2Nsb3VkLWNvbmZpZwpkaXNhYmxlX3Jvb3Q6IGZhbHNlCnNzaF9wd2F1dGg6IFRydWUKdXNlcnM6CiAgLSBkZWZhdWx0CiAgLSBuYW1lOiBzdXNlCiAgICBncm91cHM6IHN1ZG8KICAgIHNoZWxsOiAvYmluL2Jhc2gKICAgIHN1ZG86ICBBTEw9KEFMTCkgTk9QQVNTV0Q6QUxMCiAgICBsb2NrX3Bhc3N3ZDogRmFsc2UKICAgIHBsYWluX3RleHRfcGFzc3dkOiAnc3VzZScK
name: cloudinitdisk
EOFこれにより、VirtualMachineが作成されたことを示すメッセージが出力されます。
virtualmachine.kubevirt.io/tumbleweed created
このVirtualMachine定義は最小限であり、設定はほとんど指定されていません。この定義は単に、この仮想マシンが、一時的なcontainerDiskに基づくディスクイメージ(つまり、リモートイメージリポジトリからのコンテナイメージに保存されるディスクイメージ)を使用する、2GBのメモリを備えたマシンタイプ「q35」であることを示しています。また、base64でエンコードされたcloudInitディスクを指定しており、このディスクはブート時にユーザを作成してパスワードを適用する目的にのみ使用します(デコードにはbase64
-dを使用します)。
注記この仮想マシンイメージはテスト専用です。このイメージは公式にサポートされておらず、ドキュメントの例としてのみ使用されています。
このマシンは、openSUSE Tumbleweedのディスクイメージをダウンロードする必要があるためブートに数分かかりますが、ブートが完了したら、次のコマンドで仮想マシンの情報をチェックして、仮想マシンの詳細を確認できます。
$ kubectl get vmi
これにより、仮想マシンが起動されたノードと、仮想マシンのIPアドレスが出力されます。Podネットワーキングを使用しているため、報告されるIPアドレスは他のPodと同様であり、ルーティング可能であることに注意してください。
NAME AGE PHASE IP NODENAME READY tumbleweed 4m24s Running 10.42.2.98 node3.edge.rdo.wales True
これらのコマンドをKubernetesクラスタノード自体で実行する場合は、トラフィックをPodに直接ルーティングするCNI
(Ciliumなど)を使用して、マシン自体に直接sshで接続できるはずです。次のIPアドレスを、仮想マシンに割り当てられているIPアドレスに置き換えます。
$ ssh suse@10.42.2.98 (password is "suse")
この仮想マシンに接続すると、さまざまな操作を試すことができますが、リソースの点で制限があり、ディスク容量は1GBしかないことに注意してください。終了したら、Ctrl-DまたはexitでSSHセッションを切断します。
仮想マシンプロセスは、依然として標準のKubernetes
Podでラップされています。VirtualMachine
CRDは目的の仮想マシンを表していますが、仮想マシンが実際に起動されるプロセスは、他のアプリケーションと同様に、標準のKubernetes
Podであるvirt-launcher
Podを介して行われます。起動されたすべての仮想マシンに対して、virt-launcher
Podが存在することがわかります。
$ kubectl get pods
次に、定義したTumbleweedマシンの1つのvirt-launcher Podが表示されます。
NAME READY STATUS RESTARTS AGE virt-launcher-tumbleweed-8gcn4 3/3 Running 0 10m
このvirt-launcher
Podを調べてみると、libvirtプロセスとqemu-kvmプロセスを実行していることがわかります。このPod自体を起動して詳細を確認できます。次のコマンドは、使用しているPodの名前に合わせて調整する必要があることに注意してください。
$ kubectl exec -it virt-launcher-tumbleweed-8gcn4 -- bash
Podが起動したら、virshコマンドを実行するのと併せて、プロセスを確認してみます。qemu-system-x86_64バイナリに加え、仮想マシンを監視するための特定のプロセスも実行されていることがわかります。
また、ディスクイメージの場所と、ネットワーキングが(タップデバイスとして)どのように接続されているかもわかります。
qemu@tumbleweed:/> ps ax
PID TTY STAT TIME COMMAND
1 ? Ssl 0:00 /usr/bin/virt-launcher-monitor --qemu-timeout 269s --name tumbleweed --uid b9655c11-38f7-4fa8-8f5d-bfe987dab42c --namespace default --kubevirt-share-dir /var/run/kubevirt --ephemeral-disk-dir /var/run/kubevirt-ephemeral-disks --container-disk-dir /var/run/kube
12 ? Sl 0:01 /usr/bin/virt-launcher --qemu-timeout 269s --name tumbleweed --uid b9655c11-38f7-4fa8-8f5d-bfe987dab42c --namespace default --kubevirt-share-dir /var/run/kubevirt --ephemeral-disk-dir /var/run/kubevirt-ephemeral-disks --container-disk-dir /var/run/kubevirt/con
24 ? Sl 0:00 /usr/sbin/virtlogd -f /etc/libvirt/virtlogd.conf
25 ? Sl 0:01 /usr/sbin/virtqemud -f /var/run/libvirt/virtqemud.conf
83 ? Sl 0:31 /usr/bin/qemu-system-x86_64 -name guest=default_tumbleweed,debug-threads=on -S -object {"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/run/kubevirt-private/libvirt/qemu/lib/domain-1-default_tumbleweed/master-key.aes"} -machine pc-q35-7.1,usb
286 pts/0 Ss 0:00 bash
320 pts/0 R+ 0:00 ps ax
qemu@tumbleweed:/> virsh list --all
Id Name State
------------------------------------
1 default_tumbleweed running
qemu@tumbleweed:/> virsh domblklist 1
Target Source
---------------------------------------------------------------------------------------------
sda /var/run/kubevirt-ephemeral-disks/disk-data/tumbleweed-containerdisk-0/disk.qcow2
sdb /var/run/kubevirt-ephemeral-disks/cloud-init-data/default/tumbleweed/noCloud.iso
qemu@tumbleweed:/> virsh domiflist 1
Interface Type Source Model MAC
------------------------------------------------------------------------------
tap0 ethernet - virtio-non-transitional e6:e9:1a:05:c0:92
qemu@tumbleweed:/> exit
exit最後に、この仮称マシンを削除して、クリーンアップしましょう。
$ kubectl delete vm/tumbleweed virtualmachine.kubevirt.io "tumbleweed" deleted
18.5 virtctlの使用 #
KubeVirtには、標準のKubernetes
CLIツールであるkubectlとともに、仮想化の世界とKubernetesが設計された世界との間のギャップを埋める方法でクラスタとのインタフェースを可能にするCLIユーティリティが付属しています。たとえば、
virtctlツールは、APIやCRDを直接使用することなく、仮想マシンのライフサイクル(起動、停止、再起動など)の管理、仮想コンソールへのアクセスの提供、仮想マシンイメージのアップロード、サービスなどのKubernetesコンストラクトとのインタフェースを行う機能を提供します。
virtctlツールの最新の安定バージョンをダウンロードしましょう。
$ export VERSION=v1.1.0
$ wget https://github.com/kubevirt/kubevirt/releases/download/${VERSION}/virtctl-${VERSION}-linux-amd64別のアーキテクチャまたはLinux以外のマシンを使用している場合は、他のリリースをこちらで見つけることができます。続行する前に、この実行可能ファイルを作成する必要があります。また、実行可能ファイルを$PATH内の特定の場所に移動すると便利な場合があります。
$ mv virtctl-${VERSION}-linux-amd64 /usr/local/bin/virtctl
$ chmod a+x /usr/local/bin/virtctlその後、virtctlコマンドラインツールを使用して、仮想マシンを作成できます。出力をkubectl
applyに直接パイプしていることに注意して、前の仮想マシンを複製してみましょう。
$ virtctl create vm --name virtctl-example --memory=1Gi \
--volume-containerdisk=src:registry.opensuse.org/home/roxenham/tumbleweed-container-disk/containerfile/cloud-image:latest \
--cloud-init-user-data "I2Nsb3VkLWNvbmZpZwpkaXNhYmxlX3Jvb3Q6IGZhbHNlCnNzaF9wd2F1dGg6IFRydWUKdXNlcnM6CiAgLSBkZWZhdWx0CiAgLSBuYW1lOiBzdXNlCiAgICBncm91cHM6IHN1ZG8KICAgIHNoZWxsOiAvYmluL2Jhc2gKICAgIHN1ZG86ICBBTEw9KEFMTCkgTk9QQVNTV0Q6QUxMCiAgICBsb2NrX3Bhc3N3ZDogRmFsc2UKICAgIHBsYWluX3RleHRfcGFzc3dkOiAnc3VzZScK" | kubectl apply -f -これで、仮想マシンが実行されているのがわかります(コンテナイメージがキャッシュされるため、今回はかなり早く起動するはずです)。
$ kubectl get vmi NAME AGE PHASE IP NODENAME READY virtctl-example 52s Running 10.42.2.29 node3.edge.rdo.wales True
これで、 virtctlを使用して仮想マシンに直接接続できるようになりました。
$ virtctl ssh suse@virtctl-example (password is "suse" - Ctrl-D to exit)
virtctlで使用可能なコマンドはほかにも多数あります。たとえば、 virtctl
consoleを使用すると、ネットワーキングが機能していない場合にシリアルコンソールにアクセスでき、virtctl
guestosinfoを使用すると、ゲストにqemu-guest-agentがインストールされていて実行されていれば、包括的なOS情報を取得できます。
最後に、仮想マシンを一時停止し、再開してみましょう。
$ virtctl pause vm virtctl-example VMI virtctl-example was scheduled to pause
VirtualMachineオブジェクトが「Paused」と表示され、VirtualMachineInstanceオブジェクトは「Running」ですが「READY=False」と表示されているのがわかります。
$ kubectl get vm NAME AGE STATUS READY virtctl-example 8m14s Paused False $ kubectl get vmi NAME AGE PHASE IP NODENAME READY virtctl-example 8m15s Running 10.42.2.29 node3.edge.rdo.wales False
また、仮想マシンに接続できなくなっていることもわかります。
$ virtctl ssh suse@virtctl-example can't access VMI virtctl-example: Operation cannot be fulfilled on virtualmachineinstance.kubevirt.io "virtctl-example": VMI is paused
仮想マシンを再開して、もう一度試してみましょう。
$ virtctl unpause vm virtctl-example VMI virtctl-example was scheduled to unpause
これで、接続を再確立できるはずです。
$ virtctl ssh suse@virtctl-example suse@vmi/virtctl-example.default's password: suse@virtctl-example:~> exit logout
最後に、仮想マシンを削除しましょう。
$ kubectl delete vm/virtctl-example virtualmachine.kubevirt.io "virtctl-example" deleted
18.6 シンプルなIngressネットワーキング #
このセクションでは、仮想マシンを標準のKubernetesサービスとして公開し、NGINXとRKE2、TraefikとK3sなどのKubernetes Ingressサービスを介して利用可能にする方法を示します。このドキュメントでは、これらのコンポーネントがすでに適切に設定されていること、およびKubernetesサーバノードまたはIngress仮想IPを指す適切なDNSポインタが設定されていて(ワイルドカードを使用するなど)、Ingressを適切に解決できることを前提としています。
注記SUSE Edge 3.0以降では、K3sをマルチサーバノード設定で使用している場合、MetalLBベースのVIPをIngress用に設定しなければならなかった可能性があります。これはRKE2では必要ありません。
この例の環境では、別のopenSUSE
Tumbleweed仮想マシンをデプロイし、cloud-initを使用して、ブート時にNGINXをシンプルなWebサーバとしてインストールしています。また、呼び出しの実行時に期待どおりに動作することを確認するためにシンプルなメッセージを返すように設定しています。この処理を確認するには、以下の出力のcloud-initのセクションに対してbase64
-dを実行するだけです。
では、この仮想マシンを作成してみましょう。
$ kubectl apply -f - <<EOF
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
name: ingress-example
namespace: default
spec:
runStrategy: Always
template:
metadata:
labels:
app: nginx
spec:
domain:
devices: {}
machine:
type: q35
memory:
guest: 2Gi
resources: {}
volumes:
- containerDisk:
image: registry.opensuse.org/home/roxenham/tumbleweed-container-disk/containerfile/cloud-image:latest
name: tumbleweed-containerdisk-0
- cloudInitNoCloud:
userDataBase64: I2Nsb3VkLWNvbmZpZwpkaXNhYmxlX3Jvb3Q6IGZhbHNlCnNzaF9wd2F1dGg6IFRydWUKdXNlcnM6CiAgLSBkZWZhdWx0CiAgLSBuYW1lOiBzdXNlCiAgICBncm91cHM6IHN1ZG8KICAgIHNoZWxsOiAvYmluL2Jhc2gKICAgIHN1ZG86ICBBTEw9KEFMTCkgTk9QQVNTV0Q6QUxMCiAgICBsb2NrX3Bhc3N3ZDogRmFsc2UKICAgIHBsYWluX3RleHRfcGFzc3dkOiAnc3VzZScKcnVuY21kOgogIC0genlwcGVyIGluIC15IG5naW54CiAgLSBzeXN0ZW1jdGwgZW5hYmxlIC0tbm93IG5naW54CiAgLSBlY2hvICJJdCB3b3JrcyEiID4gL3Nydi93d3cvaHRkb2NzL2luZGV4Lmh0bQo=
name: cloudinitdisk
EOFこの仮想マシンが正常に起動したら、virtctlコマンドを使用して、外部ポート8080とターゲットポート80
(NGINXがデフォルトでリスンするポート)でVirtualMachineInstanceを公開できます。virtctlコマンドは、仮想マシンオブジェクトとPodのマッピングを理解しているため、ここではこのコマンドを使用します。これにより、新しいサービスが作成されます。
$ virtctl expose vmi ingress-example --port=8080 --target-port=80 --name=ingress-example Service ingress-example successfully exposed for vmi ingress-example
これで、適切なサービスが自動的に作成されます。
$ kubectl get svc/ingress-example NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ingress-example ClusterIP 10.43.217.19 <none> 8080/TCP 9s
次に、kubectl create
ingressを使用すると、このサービスを指すIngressオブジェクトを作成できます。ここでURL (ingressオブジェクトの「ホスト」として知られている)をDNS設定に合わせて調整し、ポート8080を指すようにします。
$ kubectl create ingress ingress-example --rule=ingress-example.suse.local/=ingress-example:8080
DNSが正しく設定されたら、URLに対してすぐにcurlを実行できます。
$ curl ingress-example.suse.local It works!
この仮想マシンとそのサービス、およびIngressリソースを削除して、クリーンアップしましょう。
$ kubectl delete vm/ingress-example svc/ingress-example ingress/ingress-example virtualmachine.kubevirt.io "ingress-example" deleted service "ingress-example" deleted ingress.networking.k8s.io "ingress-example" deleted
18.7 Rancher UI拡張機能の使用 #
SUSE Edge VirtualizationはRancher Manager用のUI拡張機能を提供しており、Rancher Dashboard UIを使用して基本的な仮想マシン管理を行うことができます。
18.7.1 インストール #
インストールのガイダンスについては、Rancher Dashboard拡張機能に関するセクションを参照してください。
18.7.2 KubeVirt Rancher Dashboard拡張機能の使用 #
この拡張機能により、Cluster Explorerに新たに［KubeVirt］セクションが導入されます。このセクションは、KubeVirtがインストールされている管理対象クラスタに追加されます。
この拡張機能を使用すると、次の2つのKubeVirtリソースを直接操作できます。
Virtual Machine Instances— 実行中の1つの仮想マシンインスタンスを表すリソース。Virtual Machines— 仮想マシンのライフサイクルを管理するために使用されるリソース。
18.7.2.1 仮想マシンの作成 #
左側のナビゲーションでKubeVirtが有効な管理対象クラスタをクリックして、［Cluster Explorer］に移動します。
［KubeVirt ］ > ［Virtual Machines (仮想マシン)］ページで、画面の右上にある［
Create from YAML (YAMLから作成)］をクリックします。仮想マシンの定義を入力するか貼り付けて、［
Create (作成)］を押します。「仮想マシンのデプロイ 」セクションの仮想マシンの定義を参考にしてください。
18.7.2.2 仮想マシンの起動と停止 #
仮想マシンを起動および停止するには、各仮想マシンの右側にある⋮ドロップダウンリストからアクセスできるアクションメニューを使用するか、アクションを実行する仮想マシンを選択してリストの上部にあるグループアクションを使用します。
spec.runningプロパティが定義されている仮想マシンに対してのみ、起動および停止アクションを実行できます。spec.runStrategyが使用されている場合、そのようなマシンは直接起動および停止できません。詳細については、KubeVirtのドキュメントを参照してください。
18.7.2.3 仮想マシンコンソールへのアクセス #
［Virtual Machines (仮想マシン)］リストには［Console
(コンソール)］ドロップダウンリストがあり、ここからVNCまたはシリアルコンソールを使用してマシンに接続できます。このアクションは、実行中のマシンでのみ使用できます。
新しく起動した仮想マシンでは、コンソールにアクセスできるようになるまでにしばらく時間がかかることがあります。
18.8 Edge Image Builderを使用したインストール #
SUSE Edgeは、ベースとなるSLE Micro OSイメージをカスタマイズするために第9章 「Edge Image Builder」を使用しています。EIBによってプロビジョニングされたKubernetesクラスタ上にKubeVirtとCDIの両方をエアギャップインストールするには、21.9項 「KubeVirtとCDIのインストール」に従ってください。