Conectar a VMs que usam o ambiente de execução de VMs no Google Distributed Cloud

Este documento é destinado aos proprietários de aplicativos que executam o GKE em bare metal. Neste documento, mostramos como se conectar a máquinas virtuais (VMs) que usam o ambiente de execução de VMs no Google Distributed Cloud. É possível se conectar a VMs diretamente por um endereço IP ou usando ferramentas integradas para acesso SSH ou console.

Antes de começar

Para concluir este documento, você precisa de acesso aos seguintes recursos:

Uma VM executada em um dos clusters. Se necessário, crie uma VM no GKE em Bare Metal.
A ferramenta do cliente virtctl instalada como um plug-in para o kubectl. Se necessário, instale a ferramenta de cliente virtctl.

Configurar o acesso SSH sem senhas para VMs

O acesso SSH direto e sem senha à sua VM é facilitado por um agente convidado instalado pelo ambiente de execução da VM no Google Distributed Cloud. Entre outras funções, o agente convidado instala e expira as chaves SSH. Esse recurso ativa um túnel SSH para acessar sua VM de clientes fora da rede do cluster.

Ativar o agente convidado

Para ativar o agente convidado:

Verifique seu recurso personalizado VirtualMachine para confirmar se ele está configurado para ativar o agente convidado:
```
kubectl get gvm VM_NAME -o yaml --kubeconfig KUBECONFIG
```
O campo spec.osType precisa ser definido como o sistema operacional da VM, Linux ou Windows. A seção spec.guestEnvironment não pode ser configurada explicitamente como vazia. Se a seção estiver configurada como vazia (guestEnvironment: {}), será possível removê-la totalmente para ativar o agente convidado.

O recurso personalizado VirtualMachine da VM que você quer acessar precisa ser assim:
```
apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  name: sample-vm
spec:
  compute:
    cpu:
      vcpus: 2
    memory:
      capacity: 4Gi
...
  osType: Linux
...
```
Se necessário, use kubectl edit para atualizar o recurso personalizado VirtualMachine.

Para verificar se o agente convidado está funcionando, confira o status no recurso personalizado da VM:

kubectl get gvm VM_NAME --kubeconfig KUBECONFIG

Quando o agente convidado estiver funcionando, você verá status: "True" para as condições GuestEnvironmentEnabled e GuestEnvironmentDataSynced.

apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  ...
  name: vm-sample-01
  ...
status:
  conditions:
  - lastTransitionTime: "2022-10-05T22:40:26Z"
    message: ""
    observedGeneration: 1
    reason: UserConfiguration
    status: "True"
    type: GuestEnvironmentEnabled
  - lastTransitionTime: "2022-10-06T21:55:57Z"
    message: ""
    observedGeneration: 1
    reason: GuestEnvironmentDataSynced
    status: "True"
    type: GuestEnvironmentSynced
  ...

Ativar o acesso SSH sem senha

Para ativar o acesso SSH sem senha para sua VM:

Crie um arquivo de manifesto de VirtualMachineAccessRequest, como vm-access-request.yaml, no editor de sua escolha:
```
apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineAccessRequest
metadata:
  name: VMAR_NAME
  namespace: VM_NAMESPACE
spec:
  vm: VM_NAME
  user: USERNAME
  ssh:
    key: PUBLIC_SSH_KEY
    ttl: EXPIRATION_TIME
```
Substitua:
- VMAR_NAME: o nome do recurso da solicitação de acesso.
- VM_NAMESPACE: o namespace da VM que você quer acessar.
- VM_NAME: o nome da VM que você quer acessar.
- USERNAME: o nome de usuário do usuário que está acessando a VM.
- PUBLIC_SSH_KEY: a chave pública para acesso ao SSH. Normalmente, é o conteúdo do arquivo id_rsa.pub.
- EXPIRATION_TIME: o campo ttl (time to live) especifica o tempo de validade da chave SSH.
  
  Por exemplo, se você especificar 30m, a chave SSH expirará após 30 minutos.
  
  Essa sinalização usa as seguintes unidades:
  - s para segundos
  - m para minutos
  - h para horas
  - d para dias
Use kubectl apply para criar o VirtualMachineAccessRequest usando o arquivo de manifesto. Por exemplo, se você nomeou seu arquivo de manifesto como vm-access-request.yaml,
```
kubectl apply -f MANIFEST --kubeconfig KUBECONFIG
```
Substitua:
- MANIFEST: o nome do arquivo de manifesto da solicitação de acesso. Por exemplo, vm-access-request.yaml.
- KUBECONFIG: o caminho para o arquivo kubeconfig do cluster que hospeda a VM que você está acessando.

Para verificar se a configuração da solicitação de acesso foi bem-sucedida, verifique o status do VirtualMachineAccessRequest:

kubectl get vmar VMAR_NAME -o yaml --kubeconfig KUBECONFIG

Quando a configuração for bem-sucedida, a seção status incluirá state: configured:

apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineAccessRequest
metadata:
  ...
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"vm.cluster.gke.io/v1","kind":"VirtualMachineAccessRequest",
      "metadata":{"annotations":{},"name":"vmar-sample","namespace":"default"},
      "spec":{"ssh":{"key":"ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQ...jMLHFc=
          sample-user@sample-host","ttl":"5h"},"user":"sample-user","vm":"vm-sample-01"}}
  creationTimestamp: "2022-10-06T21:55:57Z"
  finalizers:
  - vm.cluster.gke.io/vmar-finalizer
  generation: 2
  name: vmar-sample
  namespace: default
  resourceVersion: "13033921"
  uid: 282d72ad-f48d-4e89-af22-336940ac9f58
spec:
  ssh:
    key: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQ...jMLHFc= sample-user@sample-host
    ttl: 5m0s
  user: sample-user
  vm: vm-sample-01
status:
  processedAt: "2022-10-06T21:55:57Z"
  state: configured

Desativar o agente convidado

Quando você cria uma nova VM e define o campo de osType, o agente convidado é ativado. Enquanto esse recurso estiver na visualização, é possível desativá-lo editando o recurso personalizado VirtualMachine. A desativação do agente convidado desativa o acesso SSH sem senha à VM.

Para desativar o agente convidado:

Use kubectl para interromper a VM antes de fazer mudanças na configuração:
```
kubectl virt stop VM_NAME --kubeconfig KUBECONFIG
```

Edite o recurso da VM:

kubectl edit gvm VM_NAME --kubeconfig KUBECONFIG

Atualize a configuração VirtualMachine para adicionar uma spec.guestEnvironment vazia explicitamente:

apiVersion: vm.cluster.gke.io/v1alpha1
kind: VirtualMachine
metadata:
  name: vm-example
  namespace: default
spec:
  compute:
  ...
  osType: Linux
  guestEnvironment: {}

Salve e feche o manifesto da VM atualizado no editor.

Use kubectl para iniciar a VM:

kubectl virt start VM_NAME --kubeconfig KUBECONFIG

Conectar-se usando um endereço IP

Se a VM tiver um endereço IP acessível e você já tiver as credenciais para acessá-la, será possível se conectar usando um protocolo como SSH, VNC ou RDP.

Conectar pelo endereço IP

Para se conectar diretamente ao endereço IP da VM, use um dos seguintes métodos:

SSH

Consulte os detalhes da VM para ver o endereço IP dela:
```
kubectl get gvm VM_NAME --namespace VM_NAMESPACE --kubeconfig KUBECONFIG
```
Substitua os seguintes valores:
- VM_NAME: o nome da sua VM.
- VM_NAMESPACE: o namespace da sua VM.
O exemplo de saída a seguir mostra as informações da VM e o endereço IP:
```
NAME   STATUS    AGE   IP
vm1    Running   7m    10.200.0.21
```
Conecte-se à VM usando um cliente SSH:
```
ssh USERNAME@IP_ADDRESS -i PATH_TO_KEY
```
Substitua os seguintes valores:
- USERNAME: o nome de usuário de uma conta na sua VM.
- IP_ADDRESS: o endereço IP da VM recebido na etapa anterior.
- PATH_TO_KEY: o caminho para a chave SSH privada.

VNC ou RDP

A computação de rede virtual (VNC, na sigla em inglês) e o protocolo de área de trabalho remota (RDP, na sigla em inglês) permitem usar o console gráfico para acessar a VM. Ao usar um endereço IP, é necessário ativar o VNC ou RDP no SO convidado antes de usar um deles para se conectar à VM. Para informações sobre como ativar e usar o VNC ou o RDP, consulte a documentação do SO convidado.

Também é necessário ter credenciais para fazer login na VM, como aquelas definidas para criar credenciais iniciais de usuário ao criar uma VM.

Consulte os detalhes da VM para ver o endereço IP dela:
```
kubectl get gvm VM_NAME --namespace VM_NAMESPACE --kubeconfig KUBECONFIG
```
Substitua os seguintes valores:
- VM_NAME: o nome da sua VM.
- VM_NAMESPACE: o namespace da sua VM.
O exemplo de saída a seguir mostra as informações da VM e o endereço IP:
```
NAME   STATUS    AGE   IP
vm1    Running   7m    10.200.0.21
```
Conecte-se ao endereço IP da VM recebida na etapa anterior usando uma ferramenta de cliente e a porta apropriada, como a porta VNC 5900 ou RDP 3389.

Conexão por um serviço

Se a VM se conectar ao pod-network padrão e não for possível se comunicar diretamente com o endereço IP da VM, exponha a VM por trás de um balanceador de carga Service.

Crie um manifesto de Service, como my-service-load-balancer.yaml, no editor de sua escolha:
```
nano my-service-load-balancer.yaml
```
Copie e cole o seguinte manifesto YAML:
```
apiVersion: v1
kind: Service
metadata:
  name: VM_NAME-service
spec:
  selector:
    kubevirt/vm: VM_NAME
  ports:
  - name: PORT_NAME
    protocol: PROTOCOL_TYPE
    port: EXTERNAL_PORT
    targetPort: TARGET_PORT
  type: LoadBalancer
```
Nesse tipo de manifesto Service, substitua os seguintes valores:
- VM_NAME: o nome da VM a ser exposta para acesso remoto.
- PORT_NAME: o nome do protocolo, como ssh, vnc ou rdp.
- PROTOCOL_TYPE: o tipo de protocolo, como tcp para SSH e RDP ou udp para VNC.
- EXTERNAL_PORT: o número da porta externa a ser exposta e ao qual você se conecta.
- TARGET_PORT: a porta de destino, como 22 para SSH.
Salve e feche o manifesto Service no seu editor.

Crie Service usando kubectl:

kubectl apply -f my-service-load-balancer.yaml  --kubeconfig KUBECONFIG

Consiga o endereço EXTERNAL-IP do serviço do balanceador de carga:

kubectl get service VM_NAME-service --kubeconfig KUBECONFIG

O endereço IP do balanceador de carga é exibido, conforme mostrado no exemplo de saída a seguir:

NAME          TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
vm1-service   LoadBalancer   172.26.232.167   10.200.0.51   22:31141/TCP   6d20h

Conecte-se ao endereço EXTERNAL-IP do balanceador de carga com um protocolo padrão, como o uso de um cliente SSH:
```
ssh USERNAME@LOAD_BALANCER_IP_ADDRESS  -i PATH_TO_KEY
```
Substitua os seguintes valores:
- USERNAME: o nome de usuário de uma conta na sua VM.
- LOAD_BALANCER_IP_ADDRESS: o endereço IP do balanceador de carga.
- PATH_TO_KEY: o caminho para a chave SSH privada.

Conectar-se diretamente usando SSH

Se o cliente estiver conectado à mesma rede física que o cluster do Anthos em nós bare metal e você não precisar do uso de túneis SSH para se conectar ao cluster, use kubectl virt ssh.

Se quiser usar SSH para conectar uma VM do Linux no console com o complemento virtctl:
```
kubectl virt ssh USERNAME@VM_NAME --namespace VM_NAMESPACE --kubeconfig KUBECONFIG
```
Substitua os seguintes valores:
- USERNAME: o nome de usuário para acessar sua VM. Essa conta será criada se não existir na VM.
- VM_NAME: o nome da VM.
Depois de se conectar usando a VM por SSH e não precisar mais da conexão, saia da sessão SSH:
```
exit
```

Conectar-se diretamente usando o console

Se você não tiver conectividade de rede direta com sua VM Linux para acesso SSH, conecte-se ao console da VM usando o ambiente de execução da VM no console do Google Distributed Cloud. Esse método abre um console serial. Após a conexão, você recebe um prompt de comando, em vez de um console gráfico.

Para acessar uma VM do Linux no console, use o complemento virtctl:
```
kubectl virt console VM_NAME --kubeconfig KUBECONFIG
```
Substitua VM_NAME pelo nome da VM.

Quando solicitado, digite as credenciais de usuário da VM. Essas credenciais precisam existir na VM ou ser aplicadas quando ela for criada. Se necessário, consulte a seção a seguir para criar credenciais iniciais de usuário ao criar uma VM.
Depois de se conectar ao console da VM e não precisar mais da conexão, saia da sessão e do console da VM:
```
Ctrl + ]
```

Conectar-se diretamente com o VNC

É possível usar o comando kubectl virt vnc para abrir o console gráfico de Computação de rede virtual (VNC, na sigla em inglês) para acessar suas VMs. Esse método funciona para VMs que executam um SO convidado do Windows ou do Linux. Ao usar o comando kubectl virt vnc, o ambiente de execução da VM no Google Distributed Cloud abre o VNC. Assim, você não precisa ativar o VNC no SO convidado.