Como trabalhar com cargas de trabalho baseadas em VM

Nesta página, mostramos como implantar VMs em clusters do Anthos em Bare Metal usando o ambiente de execução de VM do Anthos. O ambiente de execução do Anthos VM usa o KubeVirt para orquestrar VMs em clusters, permitindo que você trabalhe com seus aplicativos e cargas de trabalho baseados em VM em um ambiente de desenvolvimento uniforme. Você pode ativar o ambiente de execução do Anthos VM ao criar um novo cluster e em clusters atuais.

Antes de começar

Para seguir estas instruções, é necessário ter um cluster em execução. Se você não fizer isso, siga as instruções no Guia de início rápido do clusters do Anthos em bare metal para configurar rapidamente um cluster na estação de trabalho.

Ativar o ambiente de execução da VM do Anthos

O ambiente de execução da VM do Anthos está desativado por padrão. Para ativar o tempo de execução da VM do Anthos, edite o recurso personalizado VMRuntime no cluster. A partir da versão 1.10.0 dos clusters do Bare Metal, o recurso personalizado VMRuntime é instalado automaticamente nos clusters.

Para ativar o ambiente de execução da VM do Anthos, faça o seguinte:

  1. Atualize o recurso personalizado VMRuntime para definir enabled como true.

    apiVersion: vm.cluster.gke.io/v1
    kind: VMRuntime
    metadata:
      name: vmruntime
    spec:
      enabled: true
      # useEmulation default to false if not set.
      useEmulation: true
      # vmImageFormat default to "qcow2" if not set.
      vmImageFormat: qcow2
    
  2. Se o nó não for compatível com a virtualização de hardware ou se você não tiver certeza, defina useEmulation como true.

    Se disponível, a virtualização de hardware oferece um desempenho melhor do que a emulação de software. O campo useEmulation terá false como padrão se não for especificado.

    apiVersion: vm.cluster.gke.io/v1
    kind: VMRuntime
    metadata:
      name: vmruntime
    spec:
      enabled: true
      # useEmulation default to false if not set.
      useEmulation: true
      # vmImageFormat default to "qcow2" if not set.
      vmImageFormat: qcow2
    
  3. É possível alterar o formato da imagem usado para as VMs criadas definindo o campo vmImageFormat.

    O campo vmImageFormat aceita dois valores de formato de imagem de disco: raw e qcow2. Se você não definir vmImageFormat, o ambiente de execução da VM do Anthos usará o formato de imagem de disco raw para criar VMs. O formato raw pode melhorar o desempenho em relação ao qcow2, uma cópia no formato de gravação, mas pode usar mais disco. Para mais informações sobre os formatos de imagem da VM, consulte Formatos de arquivo de imagem de disco na documentação do QEMU.

    apiVersion: vm.cluster.gke.io/v1
    kind: VMRuntime
    metadata:
      name: vmruntime
    spec:
      enabled: true
      # useEmulation default to false if not set.
      useEmulation: true
      # vmImageFormat default to "qcow2" if not set.
      vmImageFormat: qcow2
    
  4. Salve a configuração e verifique se o recurso personalizado VMRuntime está ativado:

    kubectl describe vmruntime vmruntime
    

    Os detalhes do recurso personalizado VMRuntime incluem uma seção Status. O ambiente de execução da VM do Anthos está ativado e funcionando quando VMRuntime.Status.Ready está definido como true.

Como fazer upgrade de clusters

O recurso personalizado VMRuntime é instalado automaticamente em clusters atualizados para a versão 1.10.0 ou superior. Quando você faz upgrade de um cluster 1.9.x para a versão 1.10.0 e mais recente, o processo de upgrade verifica as configurações do cluster e define o recurso VMRuntime personalizado para corresponder às configurações do ambiente de execução da VM do Anthos no cluster 1.9.x. Se spec.kubevirt estiver presente no recurso do cluster 1.9.x, o processo de upgrade ativará o ambiente de execução de VM do Anthos.

As configurações de recursos personalizados VMRuntime têm precedência sobre as configurações legadas do cluster de ambiente de execução da VM do Anthos, como spec.kubevirt.useEmulation, nos clusters da versão 1.10.0 ou mais recente. Atualize o recurso personalizado VMRuntime para alterar as configurações do ambiente de execução da VM do Anthos para o cluster 1.10.0 ou mais recente.

Instale o virtctl (em inglês)

  1. Instalar a ferramenta CLI virtctl como um plug-in kubectl

    export GOOGLE_APPLICATION_CREDENTIALS="bm-gcr.json"
    sudo -E ./bmctl install virtctl
    
  2. Verifique se o virtctl está instalado:

    kubectl plugin list
    

    Se virtctl estiver listado na resposta, isso significa que ele foi instalado.

Crie uma VM

Depois de ativar o KubeVirt no seu cluster e instalar o plug-in virtctl para kubectl, você pode começar a criar VMs no seu cluster usando o comando kubectl virt create vm. Antes de executar este comando, recomendamos configurar um arquivo cloud-init para garantir que você tenha acesso ao console para a VM depois que ela for criada.

Criar um arquivo cloud-init personalizado para acesso ao console

Há duas maneiras de criar um arquivo cloud-init personalizado. A maneira mais fácil é especificar a sinalização --os=<OPERATING_SYSTEM> ao criar a VM. Esse método configura automaticamente um arquivo cloud-init simples e funciona para os sistemas operacionais a seguir.

  • Ubuntu
  • CentOS
  • Debian
  • Fedora

Depois que a VM for criada, você poderá acessá-la pela primeira vez com as credenciais a seguir e alterar a senha:

user: root
password: changeme

Se sua imagem contém um SO baseado em Linux diferente ou se você precisa de uma configuração mais avançada, crie manualmente um arquivo cloud-init personalizado e especifique o caminho para esse arquivo especificando a sinalização --cloud-init-file=<path/to/file>. Na forma mais básica, o arquivo cloud-init é um arquivo YAML que contém o seguinte:

#cloud-config
user: root
password: changeme
lock_passwd: false
chpasswd: {expire: false}
disable_root: false
ssh_authorized_keys:
- <ssh-key>

Para configurações mais avançadas, consulte Exemplos de configuração do Cloud.

Depois de determinar qual método usar, você está pronto para criar uma VM.

Execute o comando kubectl virt create vm.

É possível criar VMs com base em imagens públicas ou personalizadas.

Imagem pública

Se o cluster tiver uma conexão externa, crie uma VM a partir de uma imagem pública executando:

kubectl virt create vm VM_NAME \
    --boot-disk-access-mode=MODE \
    --boot-disk-size=DISK_SIZE \
    --boot-disk-storage-class="DISK_CLASS" \
    --cloud-init-file=FILE_PATH \
    --cpu=CPU_NUMBER \
    --image=IMAGE_NAME \
    --memory=MEMORY_SIZE

Substitua:

  • VM_NAME pelo nome da VM que você quer criar.
  • MODE pelo modo de acesso do disco de inicialização. Os valores possíveis são ReadWriteOnce (padrão) ou ReadWriteMany.
  • DISK_SIZE pelo tamanho que você quer para o disco de inicialização. O valor padrão é 20Gi.
  • DISK_CLASS pela classe de armazenamento do disco de inicialização. O valor padrão é local-shared. Para ver uma lista de classes de armazenamento disponíveis, execute kubectl get storageclass.
  • FILE_PATH pelo caminho completo do arquivo cloud-init personalizado. Dependendo da imagem, isso pode ser necessário para acessar o console à VM depois que ela é criada. Se você planeja configurar automaticamente o arquivo cloud-init com a sinalização --os, não especifique a sinalização --cloud-init-file. Se você especificar a sinalização --cloud-init-file, a sinalização --os será ignorada. Os valores aceitáveis para --os são ubuntu, centos, debian e fedora.
  • CPU_NUMBER pelo número de CPUs que você quer configurar para a VM. O valor padrão é 1.
  • IMAGE_NAME pela imagem da VM, que pode ser ubuntu20.04 (padrão), centos8 ou um URL da imagem.
  • MEMORY_SIZE pelo tamanho da memória da VM. O valor padrão é 4Gi.

Imagem personalizada

Ao criar uma VM a partir de uma imagem personalizada, é possível especificar uma imagem de um servidor de imagens HTTP ou de uma imagem armazenada localmente.

Servidor de imagem HTTP

É possível configurar um servidor HTTP usando Apache ou nginx e fazer upload da imagem personalizada para a pasta exposta. Em seguida, crie uma VM a partir da imagem personalizada executando:

kubectl virt create vm VM_NAME \
    --boot-disk-access-mode=DISK_ACCESS_MODE \
    --boot-disk-size=DISK_SIZE \
    --boot-disk-storage-class=DISK_CLASS \
    --cloud-init-file=FILE_PATH \
    --cpu=CPU_NUMBER \
    --image=http://SERVER_IP/IMAGE_NAME \
    --memory=MEMORY_SIZE

Substitua:

  • VM_NAME pelo nome da VM que você quer criar.
  • DISK_ACCESS_MODE pelo modo de acesso do disco de inicialização. Os valores possíveis são ReadWriteOnce (padrão) ou ReadWriteMany.
  • DISK_SIZE pelo tamanho que você quer para o disco de inicialização. O valor padrão é 20Gi.
  • DISK_CLASS pela classe de armazenamento do disco de inicialização. O valor padrão é local-shared. Para ver uma lista de classes de armazenamento disponíveis, execute kubectl get storageclass.
  • FILE_PATH pelo caminho completo do arquivo cloud-init personalizado. Dependendo da imagem, isso pode ser necessário para acessar o console à VM depois que ela é criada. Se você planeja configurar automaticamente o arquivo cloud-init com a sinalização --os, não especifique a sinalização --cloud-init-file. Se você especificar a sinalização --cloud-init-file, a sinalização --os será ignorada. Os valores acessíveis para --os são ubuntu, centos, debian e fedora.
  • CPU_NUMBER pelo número de CPUs que você quer configurar para a VM. O valor padrão é 1.
  • SERVER_IP pelo endereço IP do servidor que hospeda a imagem.
  • IMAGE_NAME pelo nome do arquivo da imagem personalizada.
  • MEMORY_SIZE pelo tamanho da memória da VM. O valor padrão é 4Gi.

Imagem armazenada localmente

Para armazenar a imagem personalizada localmente e criar uma VM a partir dela, execute:

kubectl virt create vm VM_NAME \
    --boot-disk-access-mode=DISK_ACCESS_MODE \
    --boot-disk-size=DISK_SIZE \
    --boot-disk-storage-class=DISK_CLASS \
    --cloud-init-file=FILE_PATH \
    --cpu=CPU_NUMBER \
    --image=IMAGE_PATH \
    --memory=MEMORY_SIZE \

Substitua:

  • VM_NAME pelo nome da VM que você quer criar.
  • DISK_ACCESS_MODE pelo modo de acesso do disco de inicialização. Os valores possíveis são ReadWriteOnce (padrão) ou ReadWriteMany.
  • DISK_SIZE pelo tamanho que você quer para o disco de inicialização. O valor padrão é 20Gi.
  • DISK_CLASS pela classe de armazenamento do disco de inicialização. O valor padrão é local-shared.
  • FILE_PATH pelo caminho completo do arquivo cloud-init personalizado. Dependendo da imagem, isso pode ser necessário para acessar o console à VM depois que ela é criada. Se você planeja configurar automaticamente o arquivo cloud-init com a sinalização --os, não especifique a sinalização --cloud-init-file. Se você especificar a sinalização --cloud-init-file, a sinalização --os será ignorada. Os valores acessíveis para --os são ubuntu, centos, debian e fedora.
  • CPU_NUMBER pelo número de CPUs que você quer configurar para a VM. O valor padrão é 1.
  • IMAGE_PATH pelo caminho do arquivo local para a imagem personalizada.
  • MEMORY_SIZE pelo tamanho da memória da VM. O valor padrão é 4Gi.

É possível alterar os valores padrão de sinalizações

O comando kubectl virt create vm usa valores padrão para preencher automaticamente sinalizações não especificadas quando o comando é executado. É possível alterar esses valores padrão executando:

kubectl virt config default FLAG

Substitua FLAG pela sinalização do parâmetro cujo valor padrão você quer alterar.

Exemplo: o comando a seguir altera a configuração padrão da CPU do padrão inicial de 1 para 2:

kubectl virt config default --cpu=2

Para ver uma lista de sinalizações compatíveis e os valores padrão atuais, execute:

kubectl virt config default -h

As configurações padrão são armazenadas no lado do cliente como um arquivo local chamado ~/.virtctl.default. Também é possível alterar as configurações padrão editando esse arquivo.

Acessar sua VM

Use estes métodos para acessar as VMs:

Acesso ao console

Para acessar uma VM no console, execute:

kubectl virt console VM_NAME

Substitua VM_NAME pelo nome da VM que você quer acessar.

Acesso ao VNC

Para acessar uma VM usando o VNC, execute:

# This requires remote-viewer from the virt-viewer package and a graphical desktop from where you run virtctl
kubectl virt vnc VM_NAME

Substitua VM_NAME pelo nome da VM que você quer acessar.

Acesso interno

Os endereços IP das VMs do cluster podem ser acessados diretamente por todos os outros pods no cluster. Para encontrar o endereço IP de uma VM, execute:

kubectl get vmi VM_NAME

Substitua VM_NAME pelo nome da VM que você quer acessar.

O comando retorna algo como:

NAME     AGE   PHASE     IP              NODENAME
vm1      13m   Running   192.168.1.194   upgi-bm002

Acesso externo

As VMs criadas no cluster têm endereços de rede de pods que só podem ser acessados de dentro do cluster. Para acessar VMs de cluster externamente:

  1. Exponha a VM como um serviço de balanceador de carga:

    kubectl virt expose vm VM_NAME \
        --port=LB_PORT \
        --target-port=VM_PORT \
        --type=LoadBalancer \
        --name=SERVICE_NAME
    

    Substitua:

    • VM_NAME pelo nome da VM que você quer acessar.
    • LB_PORT pela porta do serviço de balanceador de carga exposto.
    • VM_PORT pela porta da VM que você quer acessar por meio do serviço de balanceador de carga.
    • SERVICE_NAME pelo nome que você quer dar a esse serviço de balanceador de carga.
  2. Consiga o endereço IP externo do serviço do balanceador de carga:

    kubectl get svc SERVICE_NAME
    

    Substitua SERVICE_NAME pelo nome do serviço do balanceador de carga que expõe a VM.

    É possível acessar a porta de destino da VM por meio do endereço IP listado no campo EXTERNAL-IP da resposta.

Exemplo

Se você tiver uma VM chamada galaxy que quer acessar fora do cluster usando SSH, execute:

kubectl virt expose vm galaxy \
   --port=25022 \
   --target-port=22 \
   --type=LoadBalancer \
   --name=galaxy-ssh

Busque o endereço IP do balanceador de carga:

kubectl get svc galaxy-ssh

O comando retorna algo como:

NAME        TYPE          CLUSTER-IP     EXTERNAL-IP   PORT(S)           AGE
galaxy-ssh  LoadBalancer  10.96.250.76   21.1.38.202   25000:30499/TCP   4m40s

Agora é possível acessar a VM usando SSH por meio de 21.1.38.202:25022 (VIP:port) de fora do cluster:

ssh root@21.1.38.202:22 -p 25022

Inspecionar a telemetria da VM e os registros do console

Os registros de telemetria e console da VM foram integrados ao console do Google Cloud. As informações de telemetria e os dados de registro são essenciais para monitorar o status das VMs e solucionar problemas com as VMs do cluster.

Telemetria da VM

O painel status da VM dos clusters do Anthos fornece dados de telemetria em tempo real para as VMs do cluster.

Para ver informações de telemetria das VMs do cluster:

  1. No console do Google Cloud, selecione Monitoramento ou clique no botão a seguir:

    Acessar Monitoring

  2. Selecione Painéis.

    Painel de status da VM do cluster do Anthos na lista de painéis do Monitoring

  3. Clique em Status da VM dos clusters do Anthos na lista Todos os painéis.

    Detalhes do status da VM do cluster do Anthos

Registros do console da VM

Os registros do console em série da VM são transmitidos por streaming para o Cloud Logging e podem ser vistos no Explorador de registros.

Explorador de registros mostrando dados da VM do cluster Anthos

Excluir VMs e os recursos delas

Como excluir apenas a VM

kubectl virt delete vm VM_NAME

Substitua VM_NAME pelo nome da VM que você quer excluir.

Como excluir apenas discos da VM

kubectl virt delete disk DISK_NAME

Substitua DISK_NAME pelo nome do disco que você quer excluir. Se você tentar excluir um disco da VM antes de excluí-la, o disco será marcado para exclusão após a exclusão da VM.

Como excluir VMs e recursos

kubectl virt delete vm VM_NAME --all

Substitua VM_NAME pelo nome da VM que você quer excluir.

Se você quiser verificar os recursos usados pela VM que serão excluídos, especifique a sinalização --dry-run com --all.

Desativar ambiente de execução de VM do Anthos

Quando não precisar mais usar o Anthos VM Runtime, desative esse recurso.

bmctl

  • Para desativar o ambiente de execução, use a ferramenta bmctl:

    bmctl disable vmruntime --kubeconfig KUBECONFIG_PATH \
      --timeout TIMEOUT_IN_MINUTES \
      --force true
    

    Forneça o caminho para o arquivo kubeconfig do cluster e os valores das seguintes opções de configuração:

    • --timeout: TIMEOUT_IN_MINUTES para aguardar a exclusão dos recursos de VM atuais. O valor padrão é 10 minutos.
    • --force: defina como true para confirmar que você quer excluir os recursos de VM atuais. O valor padrão é false.

Recurso personalizado

Antes de desativar o Anthos VM Runtime em um cluster editando o recurso personalizado VMRuntime, verifique se todas as VMs nesse cluster foram excluídas.

Para desativar o ambiente de execução, atualize o recurso personalizado VMRuntime:

  1. Verifique se há VMs existentes no cluster:

    kubectl get vm
    

    Se o comando mostrar que ainda há VMs no cluster, será necessário excluí-las antes de continuar.

  2. Edite o recurso personalizado VMRuntime:

    kubectl edit vmruntime
    
  3. Defina enabled:false na especificação:

    apiVersion: vm.cluster.gke.io/v1`
    kind: VMRuntime
    metadata:
      name: vmruntime
    spec:
      enabled: false
      useEmulation: true
      vmImageFormat: qcow2
    
  4. Salve a especificação atualizada de recursos personalizados no editor.

  5. Para verificar se o recurso personalizado VMRuntime está desativado, veja os pods executados no namespace vm-system:

    kubectl get pods --namespace vm-system
    

    O ambiente de execução da VM do Anthos é desativado quando apenas os pods que pertencem à implantação de vmruntime-controller-manager estão em execução no namespace.

A seguir