Neste documento, fornecemos um guia explicativo para implantar uma carga de trabalho baseada em máquina virtual (VM) no GKE em Bare Metal usando o ambiente de execução de VMs no Google Distributed Cloud. A carga de trabalho usada neste guia é a amostra do aplicativo de ponto de venda. Este aplicativo representa um terminal de ponto de venda típico que é executado em hardware local em uma loja de varejo.
Neste documento, você migra esse aplicativo de uma VM para um GKE em Bare Metal
e acessa o front-end da Web do aplicativo. Para migrar uma VM
para o cluster, primeiro é necessário criar uma imagem de disco dessa VM. Em seguida, a imagem
precisa ser hospedada em um repositório que o cluster possa acessar. Por fim, o URL
dessa imagem pode ser usado para criar a VM. O ambiente de execução de VMs no Google Distributed Cloud espera que as imagens estejam no formato qcow2
. Se você fornecer um tipo de imagem diferente, ele
será automaticamente convertido para o formato qcow2
. Para evitar conversões repetitivas
e permitir a reutilização, é possível converter uma imagem de disco virtual
e hospedar a imagem qcow2
.
Neste documento, usamos uma imagem pré-preparada de uma instância de VM do Compute Engine em que a carga de trabalho é executada como um serviço systemd. Siga as mesmas etapas para implantar seu próprio aplicativo.
Objetivos
Antes de começar
Para preencher este documento, você precisa dos recursos a seguir:
- Acesso a um cluster do GKE em Bare Metal versão 1.12.0 ou mais recente criado seguindo o guia Como executar o GKE em Bare Metal em VMs do Compute Engine com balanceador de carga manual. de dois minutos. Nesse documento, você vai ver a configuração de recursos de rede para que seja possível acessar a carga de trabalho executada na VM por um navegador. Se você não precisar desse comportamento, siga este documento usando qualquer Cluster do GKE em Bare Metal.
- Uma estação de trabalho que atenda aos requisitos a seguir:
Ative o ambiente de execução de VMs no Google Distributed Cloud e instale o plug-in virtctl
O ambiente de execução de VMs na definição de recursos personalizados (CRD, na sigla em inglês) do Google Distributed Cloud faz parte de todos os clusters do GKE em Bare Metal desde a versão 1.10. Uma instância do recurso personalizado VMRuntime
é criada após a instalação. Porém, ela fica desativada por padrão.
Ative o ambiente de execução de VMs no Google Distributed Cloud:
sudo bmctl enable vmruntime --kubeconfig KUBECONFIG_PATH
- KUBECONFIG_PATH: caminho para o arquivo de configuração do Kubernetes do cluster de usuário do GKE Enterprise
Verifique se
VMRuntime
está ativado:kubectl wait --for=jsonpath='{.status.ready}'=true vmruntime vmruntime
Pode demorar alguns minutos para que
VMRuntime
fique pronto. Se não ficar, verifique algumas vezes com pequenos intervalos de tempo. O exemplo de saída a seguir mostra queVMRuntime
está pronto:vmruntime.vm.cluster.gke.io/vmruntime condition met
Instale o plug-in virtctl para
kubectl
:sudo -E bmctl install virtctl
A saída de exemplo a seguir mostra que o processo de instalação do plug-in
virtctl
foi concluído:Please check the logs at bmctl-workspace/log/install-virtctl-20220831-182135/install-virtctl.log [2022-08-31 18:21:35+0000] Install virtctl succeeded
Verifique a instalação do plug-in
virtctl
:kubectl virt
O exemplo de saída a seguir mostra que o plug-in
virtctl
está disponível para uso comkubectl
:Available Commands: addvolume add a volume to a running VM completion generate the autocompletion script for the specified shell config Config subcommands. console Connect to a console of a virtual machine instance. create Create subcommands. delete Delete subcommands. ...
Implantar a carga de trabalho baseada em VM
Quando você implanta uma VM no GKE em Bare Metal, o ambiente de execução de VMs no Google Distributed Cloud espera uma imagem de VM. Essa imagem serve como disco de inicialização para a VM implantada.
Neste tutorial, você vai migrar uma carga de trabalho baseada em VM do Compute Engine para um
cluster do GKE em Bare Metal. Essa VM do Compute Engine foi criada, e o aplicativo
de ponto de venda (PoS) de amostra foi configurado para ser executado como um serviço sistema. Uma
imagem de disco dessa VM com a carga de trabalho do aplicativo de PoS foi criada
no Google Cloud. Essa imagem foi
exportada para um bucket do Cloud Storage como uma imagem qcow2
.
Você usa essa imagem qcow2
pré-preparada nas etapas a seguir.
O código-fonte deste documento está disponível no repositório anthos-samples (em inglês) do GitHub. Use recursos desse repositório para concluir as etapas a seguir.
Implante um
StatefulSet
do MySQL. O aplicativo de ponto de venda espera se conectar a um banco de dados MySQL para armazenar inventário e informações de pagamento. O repositório de ponto de venda tem um manifesto de amostra que implanta umStatefulSet
do MySQL, configura umConfigMap
associado e umService
do Kubernetes. OConfigMap
define as credenciais da instância do MySQL, que são as mesmas credenciais transmitidas para o aplicativo de ponto de venda.kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/point-of-sale/main/k8-manifests/common/mysql-db.yaml
Implante a carga de trabalho da VM usando a imagem
qcow2
pré-preparada:kubectl virt create vm pos-vm \ --boot-disk-size=80Gi \ --memory=4Gi \ --vcpu=2 \ --image=https://storage.googleapis.com/pos-vm-images/pos-vm.qcow2
Esse comando cria um arquivo YAML com o nome da VM (
google-virtctl/pos-vm.yaml
). É possível inspecionar o arquivo para ver a definição deVirtualMachine
eVirtualMachineDisk
. Em vez de usar o plug-invirtctl
, é possível implantar a carga de trabalho da VM usando definições do Kubernetes Resource Model (KRM), como visto no arquivo YAML criado.Quando o comando é executado com êxito, ele produz um resultado como o exemplo a seguir, que explica os diferentes recursos criados:
Constructing manifest for vm "pos-vm": Manifest for vm "pos-vm" is saved to /home/tfadmin/google-virtctl/pos-vm.yaml Applying manifest for vm "pos-vm" Created gvm "pos-vm"
Verifique o status de criação da VM.
O recurso
VirtualMachine
é identificado pelo recursovm.cluster.gke.io/v1.VirtualMachine
no ambiente de execução de VMs no Google Distributed Cloud. A forma curta égvm
.Durante a criação de uma VM, são criados os dois recursos a seguir:
- O VirtualMachineDisk é o disco permanente para onde o conteúdo da imagem da VM é importado.
- Uma VirtualMachine é a própria instância de VM. O DataVolume é ativado na VirtualMachine antes de uma VM ser inicializada.
Verifique o status do VirtualMachineDisk. O VirtualMachineDisk cria internamente um recurso
DataVolume
. A imagem da VM é importada para o DataVolume, que é montado na VM:kubectl get datavolume
Este exemplo de saída mostra o início da importação da imagem:
NAME PHASE PROGRESS RESTARTS AGE pos-vm-boot-dv ImportScheduled N/A 8s
Verifique o status de
VirtualMachine
. AVirtualMachine
fica no estadoProvisioning
até que oDataVolume
seja importado completamente:kubectl get gvm
O exemplo de saída a seguir mostra a
VirtualMachine
sendo provisionada:NAME STATUS AGE IP pos-vm Provisioning 1m
Aguarde até que a imagem da VM seja totalmente importada para o
DataVolume
. Continue acompanhando o progresso enquanto a imagem é importada:kubectl get datavolume -w
A saída de exemplo a seguir mostra a imagem do disco que está sendo importada:
NAME PHASE PROGRESS RESTARTS AGE pos-vm-boot-dv ImportInProgress 0.00% 14s ... ... pos-vm-boot-dv ImportInProgress 0.00% 31s pos-vm-boot-dv ImportInProgress 1.02% 33s pos-vm-boot-dv ImportInProgress 1.02% 35s ...
Quando a importação for concluída e
DataVolume
for criado, o exemplo de saída a seguir vai mostrar oPHASE
deSucceeded
:kubectl get datavolume
NAME PHASE PROGRESS RESTARTS AGE pos-vm-boot-dv Succeeded 100.0% 14m18s
Confirme se
VirtualMachine
foi criado:kubectl get gvm
Se a criação for bem-sucedida,
STATUS
vai mostrarRUNNING
, como mostrado no exemplo a seguir, junto com o endereço IP da VM:NAME STATUS AGE IP pos-vm Running 40m 192.168.3.250
Conectar-se à VM e verificar o status do aplicativo
A imagem usada para a VM inclui o aplicativo de amostra de ponto de venda. O aplicativo está configurado para iniciar automaticamente na inicialização como um serviço systemd. Veja os arquivos de configuração dos serviços systemd no diretório pos-systemd-services.
Conecte-se ao console da VM. Execute o comando a seguir e pressione Enter⏎ depois de ver a mensagem
Successfully connected to pos-vm…
:kubectl virt console pos-vm
Este comando produz o exemplo de saída a seguir, que solicita que você insira os detalhes de login:
Successfully connected to pos-vm console. The escape sequence is ^] pos-from-public-image login:
Use a conta de usuário e a senha a seguir. Essa conta foi configurada dentro da VM original em que a imagem do ambiente de execução da VM no Google Distributed Cloud VirtualMachine foi criada.
- Nome de usuário do login:
abmuser
- Senha:
abmworks
- Nome de usuário do login:
Verifique o status dos serviços de aplicativos do ponto de venda. O aplicativo de ponto de venda inclui três serviços: API, inventário e pagamentos. Esses serviços são executados como serviços do sistema.
Os três serviços se conectam pelo localhost. Porém, o aplicativo se conecta ao banco de dados MySQL usando um serviço do mysql-db Kubernetes criado na etapa anterior. Esse comportamento significa que a VM é conectada automaticamente à mesma rede que
Pods
eServices
, permitindo a comunicação contínua entre as cargas de trabalho da VM e outros aplicativos conteinerizados. Você não precisa fazer mais nada para tornar oServices
do Kubernetes acessível pelas VMs implantadas usando o ambiente de execução da VM do Anthos.sudo systemctl status pos*
A saída de exemplo a seguir mostra o status dos três serviços e do serviço do sistema raiz,
pos.service
:● pos_payments.service - Payments service of the Point of Sale Application Loaded: loaded (/etc/systemd/system/pos_payments.service; enabled; vendor > Active: active (running) since Tue 2022-06-21 18:55:30 UTC; 1h 10min ago Main PID: 750 (payments.sh) Tasks: 27 (limit: 4664) Memory: 295.1M CGroup: /system.slice/pos_payments.service ├─750 /bin/sh /pos/scripts/payments.sh └─760 java -jar /pos/jars/payments.jar --server.port=8083 ● pos_inventory.service - Inventory service of the Point of Sale Application Loaded: loaded (/etc/systemd/system/pos_inventory.service; enabled; vendor> Active: active (running) since Tue 2022-06-21 18:55:30 UTC; 1h 10min ago Main PID: 749 (inventory.sh) Tasks: 27 (limit: 4664) Memory: 272.6M CGroup: /system.slice/pos_inventory.service ├─749 /bin/sh /pos/scripts/inventory.sh └─759 java -jar /pos/jars/inventory.jar --server.port=8082 ● pos.service - Point of Sale Application Loaded: loaded (/etc/systemd/system/pos.service; enabled; vendor preset: e> Active: active (exited) since Tue 2022-06-21 18:55:30 UTC; 1h 10min ago Main PID: 743 (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 4664) Memory: 0B CGroup: /system.slice/pos.service Jun 21 18:55:30 pos-vm systemd[1]: Starting Point of Sale Application... Jun 21 18:55:30 pos-vm systemd[1]: Finished Point of Sale Application. ● pos_apiserver.service - API Server of the Point of Sale Application Loaded: loaded (/etc/systemd/system/pos_apiserver.service; enabled; vendor> Active: active (running) since Tue 2022-06-21 18:55:31 UTC; 1h 10min ago Main PID: 751 (api-server.sh) Tasks: 26 (limit: 4664) Memory: 203.1M CGroup: /system.slice/pos_apiserver.service ├─751 /bin/sh /pos/scripts/api-server.sh └─755 java -jar /pos/jars/api-server.jar --server.port=8081
Saia da VM. Para sair da conexão de console, use a sequência de escape
^]
pressionandoCtrl + ]
.
Acessar a carga de trabalho baseada em VM
Se o cluster foi configurado seguindo o guia
Como executar o GKE em Bare Metal nas VMs do Compute Engine com o balanceador de carga manual,
ele tem umIngress
recurso chamado pos-ingress
já criado. Esse
recurso encaminha o tráfego do endereço IP público do balanceador de carga da Entrada
para o serviço de servidor da API do aplicativo de amostra de ponto de venda.
Se o cluster não tiver esse recurso
Ingress
, crie-o aplicando o manifesto a seguir:kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-bm-gcp-terraform/resources/manifests/pos-ingress.yaml
Crie um
Service
do Kubernetes que encaminhe o tráfego para a VM. O recursoIngress
encaminha o tráfego para esteService
:kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-vmruntime/pos-service.yaml
O exemplo de saída abaixo confirma a criação de um Serviço:
service/api-server-svc created
Encontre o endereço IP público do balanceador de carga
Ingress
. O LoadbalancerIngress
encaminha o tráfego com base nas regras de recursoIngress
. Você já tem uma regrapos-ingress
para encaminhar solicitações para o servidorService
da API. EsteService
encaminha as solicitações para a VM:INGRESS_IP=$(kubectl get ingress/pos-ingress -o jsonpath='{.status.loadBalancer.ingress[0].ip}') echo $INGRESS_IP
A saída de exemplo a seguir mostra o endereço IP do balanceador de carga
Ingress
:172.29.249.159 # you might have a different IP address
Acesse o aplicativo usando o endereço IP do recurso Loadbalancer do Ingress em um navegador. As capturas de tela de exemplo a seguir mostram o quiosque de ponto de venda simples com dois itens. Clique nos itens mais de uma vez para pedir vários deles e faça o pedido com o botão Pagar. Esta experiência mostra que você implantou com sucesso uma carga de trabalho tradicional baseada em VM em um cluster do Anthos usando o ambiente de execução de VM no Google Distributed Cloud.
Limpar
É possível excluir todos os recursos criados neste tutorial ou apenas a VM e manter os recursos reutilizáveis. O artigo Excluir uma VM no GKE em Bare Metal explica em detalhes as opções disponíveis.
Excluir tudo
Exclua o ambiente de execução da VM na nuvem distribuída do Google
VirtualMachine
com todos os recursos:kubectl virt delete vm pos-vm --all
O exemplo de saída a seguir confirma a exclusão:
vm "pos-vm" used the following resources: gvm: pos-vm VirtualMachineDisk: pos-vm-boot-dv Start deleting the resources: Deleted gvm "pos-vm". Deleted VirtualMachineDisk "pos-vm-boot-dv".
Excluir apenas a VM
A exclusão apenas da VM preserva o
VirtualMachineDisk
criado. Isso permite a reutilização dessa imagem de VM e economiza o tempo gasto na importação da imagem ao criar uma nova VM.kubectl virt delete vm pos-vm
O exemplo de saída a seguir confirma a exclusão:
vm "pos-vm" used the following resources: gvm: pos-vm VirtualMachineDisk: pos-vm-boot-dv Start deleting the resources: Deleted gvm "pos-vm".
A seguir
- A VM original usada neste guia é uma instância do Compute Engine que executa o Ubuntu 20.04 LTS. A imagem dessa VM é acessível publicamente pelo bucket do Cloud Storage pos-vm-images. Para mais informações sobre como a VM foi configurada e a respectiva imagem criada, consulte as instruções no repositório do ponto de venda.
- Ao criar uma VM em um cluster do Anthos usando o comando
kubectl virt create vm pos-vm
, um arquivo YAML com o nome da VM (google-virtctl/pos-vm.yaml
) é criado. É possível inspecionar o arquivo para ver a definição deVirtualMachine
eVirtualMachineDisk
. Em vez de usar o plug-invirtctl
, é possível implantar uma VM usando definições de KRM, como visto no arquivo YAML criado.