21 Edge Virtualization #

Esta seção descreve como usar o Edge Virtualization para executar máquinas virtuais em nós de borda. O Edge Virtualization foi projetado para casos de uso de virtualização leve, em que se espera o uso de um fluxo de trabalho comum para implantação e gerenciamento de aplicativos tanto virtualizados quanto conteinerizados.

O SUSE Edge Virtualization oferece suporte a dois métodos de execução de máquinas virtuais:

Implantação manual de máquinas virtuais pelo libvirt+qemu-kvm no nível do host (não há envolvimento do Kubernetes)
Implantação do operador KubeVirt para gerenciamento de máquinas virtuais com base no Kubernetes

As duas opções são válidas, mas apenas a segunda está descrita abaixo. Para usar os mecanismos de virtualização padrão e prontos para uso incluídos no SUSE Linux Micro, há um guia completo aqui e, apesar de ter sido escrito inicialmente para o SUSE Linux Enterprise Server, os conceitos são quase idênticos.

A princípio, este guia explica como implantar os componentes de virtualização adicionais em um sistema que já foi pré-implantado, mas acompanha uma seção que descreve como incorporar essa configuração à implantação inicial usando o Edge Image Builder. Se você não quer ler os conceitos básicos e definir as configurações manualmente, pule direto para essa seção.

21.1 Visão geral do KubeVirt #

O KubeVirt permite o gerenciamento de máquinas virtuais com o Kubernetes junto ao restante de suas cargas de trabalho conteinerizadas. Para fazer isso, ele executa a parte referente ao espaço do usuário da pilha de virtualização do Linux em um contêiner. Isso minimiza os requisitos no sistema host, o que facilita a configuração e o gerenciamento.

Os detalhes sobre a arquitetura do KubeVirt estão disponíveis na documentação upstream.

21.2 Pré-requisitos #

Se você está seguindo este guia, já deve ter os seguintes itens disponíveis:

No mínimo, um host físico com o SUSE Linux Micro 6.1 instalado e com as extensões de virtualização habilitadas no BIOS (consulte aqui para obter detalhes).
Em todos os nós, um cluster Kubernetes do K3s/RKE2 já implantado com um kubeconfig apropriado que permite o acesso de superusuário ao cluster.
Acesso ao usuário root. Nestas instruções, consideramos você como usuário root, sem escalar seus privilégios por meio do sudo.
Você tem o Helm disponível localmente com uma conexão de rede adequada para poder enviar as configurações ao cluster Kubernetes e fazer download das imagens necessárias.

21.3 Instalação manual do Edge Virtualization #

Este guia não orientará na implantação do Kubernetes, mas ele considera que você já instalou a versão apropriada ao SUSE Edge do K3s ou do RKE2 e configurou o kubeconfig de acordo para que os comandos kubectl padrão sejam executados como superusuário. Pressupomos que seu nó constitua um cluster de nó único, apesar de não haver diferenças significativas esperadas nas implantações de vários nós.

O SUSE Edge Virtualization é implantado por meio de três gráficos Helm separados, especificamente:

KubeVirt: os componentes de virtualização principais, ou seja, as CRDs do Kubernetes, os operadores e outros componentes necessários para que o Kubernetes possa implantar e gerenciar máquinas virtuais.
Extensão de dashboard KubeVirt: uma extensão de IU opcional do Rancher que permite o gerenciamento básico de máquinas virtuais, por exemplo, iniciar/parar máquinas virtuais e acessar o console.
Containerized Data Importer (CDI): um componente adicional que permite a integração de armazenamento persistente para KubeVirt, oferecendo recursos para as máquinas virtuais usarem os back ends de armazenamento do Kubernetes existentes para dados, mas também permitindo que os usuários importem ou clonem volumes de dados em máquinas virtuais.

Cada um desses gráficos Helm é versionado de acordo com a versão do SUSE Edge que você usa. Para uso em produção/com suporte, aplique os artefatos disponíveis no SUSE Registry.

Primeiro, garanta que o acesso ao kubectl esteja funcionando:

$ kubectl get nodes

Esse comando deve retornar algo semelhante ao seguinte:

NAME                   STATUS   ROLES                       AGE     VERSION
node1.edge.rdo.wales   Ready    control-plane,etcd,master   4h20m   v1.30.5+rke2r1
node2.edge.rdo.wales   Ready    control-plane,etcd,master   4h15m   v1.30.5+rke2r1
node3.edge.rdo.wales   Ready    control-plane,etcd,master   4h15m   v1.30.5+rke2r1

Agora você pode instalar os gráficos Helm KubeVirt e Containerized Data Importer (CDI):

$ helm install kubevirt oci://registry.suse.com/edge/charts/kubevirt --namespace kubevirt-system --create-namespace
$ helm install cdi oci://registry.suse.com/edge/charts/cdi --namespace cdi-system --create-namespace

Em alguns minutos, os componentes KubeVirt e CDI estarão implantados. Para validar isso, verifique todos os recursos implantados no namespace kubevirt-system e cdi-system.

Verifique os recursos do KubeVirt:

$ kubectl get all -n kubevirt-system

Esse comando deve retornar algo semelhante ao seguinte:

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

Verifique os recursos do CDI:

$ kubectl get all -n cdi-system

Esse comando deve retornar algo semelhante ao seguinte:

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

Para verificar se as definições de recursos personalizados (CRDs, Custom Resource Definitions) VirtualMachine foram implantadas, faça a validação com:

$ kubectl explain virtualmachine

Esse comando deve retornar a definição do objeto VirtualMachine, com o seguinte conteúdo:

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)

21.4 Implantando máquinas virtuais #

Agora que KubeVirt e CDI estão implantados, vamos definir uma máquina virtual simples com base no openSUSE Tumbleweed. Essa máquina virtual tem as configurações mais simples, usando a configuração de "rede de pod" padrão idêntica a qualquer outro pod. Ela também utiliza um armazenamento não persistente, o que garante que seja efêmero como em qualquer contêiner que não tenha um 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

A saída deve mostrar que uma VirtualMachine foi criada:

virtualmachine.kubevirt.io/tumbleweed created

Essa definição da VirtualMachine é mínima e especifica pouco da configuração. Ela simplesmente descreve que se trata de uma máquina do tipo "q35" com 2 GB de memória, que usa uma imagem de disco baseada em um containerDisk efêmero (ou seja, uma imagem de disco armazenada na imagem de contêiner de um repositório de imagens remoto), e especifica um disco cloudInit codificado com base64, que usamos apenas para criação de usuários e imposição de senha no momento da inicialização (usamos base64 -d para decodificá-lo).

Nota
Essa imagem da máquina virtual é somente para teste. Ela não tem suporte oficial e serve apenas como exemplo para documentação.

A inicialização da máquina leva alguns minutos porque ela precisa fazer download da imagem de disco do openSUSE Tumbleweed. Depois disso, você poderá consultar as informações para ver mais detalhes sobre a máquina virtual:

$ kubectl get vmi

Esse comando deve mostrar o nó em que a máquina virtual foi iniciada e o endereço IP dela. Como ela usa a rede de pod, lembre-se de que o endereço IP relatado será exatamente igual ao de qualquer outro pod e, dessa forma, roteável:

NAME         AGE     PHASE     IP           NODENAME               READY
tumbleweed   4m24s   Running   10.42.2.98   node3.edge.rdo.wales   True

Ao executar esses comandos nos próprios nós do cluster Kubernetes, com uma CNI para rotear o tráfego diretamente aos pods (por exemplo, Cilium), você pode executar ssh diretamente na máquina. Substitua o seguinte endereço IP pelo que foi atribuído à sua máquina virtual:

$ ssh suse@10.42.2.98
(password is "suse")

Depois que você estiver nessa máquina virtual, poderá explorá-la, mas lembre-se de que ela tem recursos limitados e apenas 1 GB de espaço em disco. Quando concluir, use Ctrl-D ou exit para se desconectar da sessão SSH.

O processo da máquina virtual ainda é agrupado em um pod padrão do Kubernetes. A CRD VirtualMachine é uma representação da máquina virtual desejada, mas o processo em que a máquina virtual foi realmente iniciada é realizado pelo pod virt-launcher, um pod padrão do Kubernetes, assim como com qualquer outro aplicativo. Para cada máquina virtual iniciada, você vê que existe um pod virt-launcher:

$ kubectl get pods

Em seguida, o pod virt-launcher deve aparecer para a máquina Tumbleweed que definimos:

NAME                             READY   STATUS    RESTARTS   AGE
virt-launcher-tumbleweed-8gcn4   3/3     Running   0          10m

Se você observar o pod virt-launcher, verá que ele está executando os processos libvirt e qemu-kvm. É possível entrar e analisar o conteúdo do pod, levando em conta que você precisa adaptar o seguinte comando com o nome do seu pod:

$ kubectl exec -it virt-launcher-tumbleweed-8gcn4 -- bash

Depois que você estiver no pod, execute os comandos virsh enquanto observa os processos. Você verá o binário qemu-system-x86_64 em execução, junto com alguns processos para monitorar a máquina virtual, e também o local da imagem de disco e como a rede está conectada (como um dispositivo TAP):

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

Por fim, vamos excluir a máquina virtual para limpeza:

$ kubectl delete vm/tumbleweed
virtualmachine.kubevirt.io "tumbleweed" deleted

21.5 Usando o virtctl #

Junto com a ferramenta CLI padrão do Kubernetes, ou seja, kubectl, o KubeVirt integra um utilitário CLI complementar que permite estabelecer interface com seu cluster para suprir algumas lacunas entre o cenário da virtualização e o cenário para o qual o Kubernetes foi projetado. Por exemplo, a ferramenta virtctl permite gerenciar o ciclo de vida das máquinas virtuais (início, parada, reinicialização etc.), concedendo acesso aos consoles virtuais, fazendo upload das imagens de máquina virtual e estabelecendo interface com as estruturas do Kubernetes, como serviços, sem usar diretamente a API ou as CRDs.

Vamos fazer download da versão estável mais recente da ferramenta virtctl:

$ export VERSION=v1.4.0
$ wget https://github.com/kubevirt/kubevirt/releases/download/$VERSION/virtctl-$VERSION-linux-amd64

Se você usa uma arquitetura diferente ou uma máquina não Linux, pode encontrar outras versões aqui. Antes de continuar, você precisa torná-la executável, o que pode ser útil para movê-la até um local em seu $PATH:

$ mv virtctl-$VERSION-linux-amd64 /usr/local/bin/virtctl
$ chmod a+x /usr/local/bin/virtctl

Na sequência, use a ferramenta de linha de comando virtctl para criar máquinas virtuais. Vamos replicar nossa máquina virtual anterior, observando que estamos fazendo pipe da saída diretamente em 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 -

Isso deve mostrar a máquina virtual em execução (desta vez, ela deve ser iniciada de forma bem mais rápida, já que a imagem de contêiner estará armazenada em cache):

$ kubectl get vmi
NAME              AGE   PHASE     IP           NODENAME               READY
virtctl-example   52s   Running   10.42.2.29   node3.edge.rdo.wales   True

Vamos usar virtctl para conexão direta com a máquina virtual:

$ virtctl ssh suse@virtctl-example
(password is "suse" - Ctrl-D to exit)

Há vários outros comandos que o virtctl pode usar. Por exemplo, o virtctl console concede a você acesso ao console serial quando a rede não está funcionando, e você pode usar o virtctl guestosinfo para obter as informações completas do sistema operacional, desde que o convidado tenha o qemu-guest-agent instalado e em execução.

Por fim, vamos pausar e retomar a máquina virtual:

$ virtctl pause vm virtctl-example
VMI virtctl-example was scheduled to pause

Observe que o objeto VirtualMachine aparece como Paused (Pausado), e o objeto VirtualMachineInstance como Running (Em execução), mas READY=False (PRONTO=Falso):

$ 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

Veja também que não é mais possível se conectar à máquina virtual:

$ virtctl ssh suse@virtctl-example
can't access VMI virtctl-example: Operation cannot be fulfilled on virtualmachineinstance.kubevirt.io "virtctl-example": VMI is paused

Vamos retomar a máquina virtual e tentar novamente:

$ virtctl unpause vm virtctl-example
VMI virtctl-example was scheduled to unpause

Agora devemos conseguir reestabelecer a conexão:

$ virtctl ssh suse@virtctl-example
suse@vmi/virtctl-example.default's password:
suse@virtctl-example:~> exit
logout

Por fim, vamos remover a máquina virtual:

$ kubectl delete vm/virtctl-example
virtualmachine.kubevirt.io "virtctl-example" deleted

21.6 Rede de entrada simples #

Nesta seção, mostramos como é possível expor máquinas virtuais como serviços padrão do Kubernetes e disponibilizá-los pelo serviço de entrada do Kubernetes, por exemplo, NGINX com RKE2 ou Traefik com K3s. Este documento pressupõe que esses componentes já foram devidamente configurados e que você tem o ponteiro de DNS, por exemplo, usando um curinga, para apontar para os nós do servidor Kubernetes ou IP virtual de entrada para uma resolução de entrada correta.

Nota
A partir do SUSE Edge 3.1, se você usa o K3s em uma configuração de nó de vários servidores, talvez tenha que configurar um VIP com base no MetalLB para entrada. Isso não é necessário no RKE2.

No ambiente de exemplo, outra máquina virtual openSUSE Tumbleweed foi implantada, o cloud-init foi usado para instalar o NGINX como servidor web simples no momento da inicialização e uma mensagem simples foi configurada para ser exibida para verificar se ela funciona conforme o esperado quando uma chamada é feita. Para ver como isso é feito, basta executar base64 -d na seção cloud-init na saída a seguir.

Agora vamos criar a máquina virtual:

$ 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

Quando a máquina virtual é iniciada com sucesso, podemos usar o comando virtctl para expor VirtualMachineInstance com a porta externa 8080 e a porta de destino 80 (na qual o NGINX escuta por padrão). Usamos o comando virtctl aqui porque ele reconhece o mapeamento entre o objeto e o pod da máquina virtual. Isso cria um novo serviço:

$ virtctl expose vmi ingress-example --port=8080 --target-port=80 --name=ingress-example
Service ingress-example successfully exposed for vmi ingress-example

Desse modo, o serviço apropriado será criado automaticamente:

$ 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

Se depois você usar kubectl create ingress, poderemos criar a seguir um objeto de entrada que aponte para esse serviço. Adapte o URL aqui (conhecido como "host" no objeto ingress) de acordo com sua configuração do DNS e garanta que ele aponte para a porta 8080:

$ kubectl create ingress ingress-example --rule=ingress-example.suse.local/=ingress-example:8080

Com a configuração correta do DNS, você pode executar curl no URL imediatamente:

$ curl ingress-example.suse.local
It works!

Vamos fazer a limpeza removendo a máquina virtual e os respectivos recursos de entrada e serviço:

$ 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

21.7 Usando a extensão de IU do Rancher #

O SUSE Edge Virtualization oferece uma extensão de IU para o Rancher Manager, que permite o gerenciamento básico de máquinas virtuais usando a interface de usuário do Rancher Dashboard.

21.7.1 Instalação #

Consulte as extensões do Rancher Dashboard (Capítulo 6, Extensões do Rancher Dashboard) para obter orientação de instalação.

21.7.2 Usando a extensão KubeVirt do Rancher Dashboard #

A extensão introduz uma nova seção KubeVirt no explorador de clusters, que é adicionada a qualquer cluster gerenciado que tenha o KubeVirt instalado.

A extensão permite interagir diretamente com os recursos de máquina virtual do KubeVirt para gerenciar o ciclo de vida das máquinas virtuais.

21.7.2.1 Criando uma máquina virtual #

Navegue até o explorador de clustersr clicando no cluster gerenciado habilitado para KubeVirt na navegação esquerda.
Navegue até a página KubeVirt > Virtual Machines (Máquinas virtuais) e clique em Create from YAML (Criar do YAML) na parte superior direita da tela.
Preencha ou cole uma definição da máquina virtual e clique em Create (Criar). Use a definição da máquina virtual da seção Implantando máquinas virtuais como modelo.

21.7.2.2 Ações da máquina virtual #

É possível usar o menu de ações acessado pela lista suspensa ⋮ à direita de cada máquina virtual para executar as ações iniciar, parar, pausar ou fazer reboot suave. Se preferir, use as ações em grupo na parte superior da lista selecionando as máquinas virtuais nas quais executar a ação.

A execução das ações pode afetar a estratégia de execução da máquina virtual. Consulte a tabela na documentação do KubeVirt para obter mais detalhes.

21.7.2.3 Acessando o console da máquina virtual #

A lista de "máquinas virtuais" oferece a lista suspensa Console, que permite conectar-se à máquina usando VNC ou console serial. Essa ação está disponível apenas em máquinas que estão em execução.

Em alguns casos, leva um curto tempo para que o console fique disponível em uma máquina virtual que acabou de ser iniciada.

21.8 Instalando com o Edge Image Builder #

O SUSE Edge usa o Capítulo 11, Edge Image Builder para personalizar as imagens base do sistema operacional SUSE Linux Micro. Siga a Seção 27.9, “Instalação do KubeVirt e CDI” para saber sobre a instalação air-gapped tanto do KubeVirt quanto da CDI em clusters Kubernetes provisionados pelo EIB.