Com executar verificações de simulação

Nesta página, explicamos como executar verificações de simulação nos clusters do Anthos no arquivo de configuração do VMware (GKE ON-Prem).

Visão geral

Durante a instalação, execute gkectl create-config para gerar clusters do Anthos no arquivo de configuração da VMware. O arquivo de configuração impulsiona a instalação: você fornece informações sobre o ambiente vSphere, a aparência dos clusters, a rede e o balanceador de carga. É possível gerar um arquivo de configuração antes ou depois de criar uma estação de trabalho de administrador. Para que determinadas verificações sejam aprovadas, elas precisam ser executadas na estação de trabalho de administrador.

Depois de modificar o arquivo para atender às necessidades do ambiente e dos clusters, use o arquivo para criar os clusters no ambiente local.

Antes de criar clusters, execute gkectl check-config para validar o arquivo de configuração com várias verificações de simulação. Se o comando retornar mensagens FAILURE, corrija os problemas e valide o arquivo novamente. Se uma determinada validação de recurso retornar qualquer mensagem WARNING, você precisará corrigir os problemas subjacentes antes de usar esse recurso.

Modos de verificação de simulação e como pular validações

gkectl check-config tem um modo padrão e um modo rápido:

  • No modo padrão, o comando valida cada campo de forma abrangente. Além disso, o modo padrão cria máquinas virtuais (VMs) temporárias do vSphere como parte das validações, o que pode levar mais tempo.

  • No modo rápido, o comando pula as verificações que criam VMs de teste e executa apenas as verificações rápidas. Ative o modo rápido transmitindo a sinalização --fast.

É possível pular validações específicas transmitindo outras sinalizações, que são descritas em gkectl check-config --help.

Tráfego entre a estação de trabalho de administrador e as VMs de teste

No modo padrão, a verificação de simulação cria VMs de teste para o cluster. Cada VM de teste executa um servidor HTTP que detecta na porta 443 e nas portas de nó especificadas no arquivo de configuração.

Vários endereços IP são atribuídos às VMs de teste. Se o arquivo de configuração indicar que os nós do cluster receberão os endereços IP de um servidor DHCP, a verificação de simulação usará um servidor DHCP para atribuir endereços IP às VMs de teste. Se o arquivo de configuração indicar que os nós do cluster receberão endereços IP estáticos, a verificação de simulação atribuirá os endereços IP estáticos especificados nos arquivos IP block às VMs de teste.

A verificação de simulação, em execução na estação de trabalho de administrador, envia solicitações HTTP para as VMs de teste usando os vários endereços IP atribuídos às VMs. As solicitações são enviadas para a porta 443 e para as portas de nó que você especificou no arquivo de configuração.

Quando devo executar verificações de simulação?

É uma prática recomendada executar verificações de simulação antecipadamente e antes de tentar criar clusters. A execução antecipada de verificações de simulação ajuda a confirmar se você configurou o ambiente vSphere e a rede corretamente.

Se você estiver usando clusters do Anthos na versão 1.2.0-gke.6 do VMware, execute gkectl check-config duas vezes:

  1. Execute gkectl check-config --fast.

  2. Execute gkectl prepare.

  3. Execute gkectl check-config novamente, sem a sinalização --fast.

A razão para executar duas vezes é que gkectl prepare faz o upload do modelo de VM da imagem do SO do nó do cluster para o ambiente vSphere. Esse modelo de VM precisa estar em vigor antes de você executar o conjunto completo de validações.

Nos clusters do Anthos na versão 1.2.1 e mais recentes no VMware, o comando check-config faz o upload do modelo de VM para que você execute o conjunto completo de validações antes de executar gkectl prepare:

  1. Execute gkectl check-config, sem a sinalização --fast.

  2. Execute gkectl prepare.

As verificações de simulação validam os valores fornecidos para o arquivo. Não é preciso preencher todos os campos do arquivo de configuração para executar verificações de simulação no arquivo. Em vez disso, é possível validar o arquivo iterativamente ao preencher os campos. Por exemplo, se você quiser apenas validar a configuração do vCenter, preencha apenas os campos vcenter e execute verificações nesses campos.

Lembre-se que os clusters do Anthos na configuração do VMware se tornam imutáveis após a criação deles. A execução de verificações de simulação ajuda você a descobrir e resolver problemas na configuração antes de criar os clusters.

Como preservar a VM de teste para depuração

Começando com os clusters do Anthos na versão 1.2.1 do VMware, o comando gkectl check-config tem uma sinalização --cleanup.

Quando gkectl check-config executa um conjunto completo de validações, ele cria uma VM de teste e uma chave SSH associada. Se você quiser preservar a VM de teste e a chave SSH para fins de depuração, defina --cleanup como falso.

O valor padrão de --cleanup é verdadeiro.

Lista de verificações de simulação

As verificações de simulação validam cada campo no arquivo de configuração. Veja as verificações atuais:

Categoria Descrição
Arquivo de configuração

Geralmente, valida se cada campo e especificação tem o formato e os valores esperados.

Pulado com a sinalização --skip-validation-config.

Pule a validação do campo proxy com a sinalização --skip-validation-proxy.

Internet

Valida o acesso à Internet para domínios obrigatórios. Valida a configuração do proxy com base no local em que você está executando o gkectl.

Pulado com a sinalização --skip-validation-internet.

Imagem do SO

Valida se as imagens do SO existem.

Ignorado com a sinalização --skip-validation-os-images.

Versão do SO Windows

Valida a versão do SO Windows.

Valida a compatibilidade da versão do Windows ao criar estações de trabalho de administrador com a ferramenta de linha de comando gkeadm. Embora a ferramenta gkeadm esteja disponível para Windows 10, Windows Server 2019 e Linux, não há uma verificação de simulação para Linux. Essa validação começa na versão 1.4.1.

Versão do cluster

Valida se a versão do cluster de administrador, a versão do cluster de usuário e a versão gkectl são correspondentes para criação e upgrade.

Pulado com a sinalização --skip-validation-cluster-version.

Integridade do cluster

Valida se o cluster de administrador ou usuário está íntegro antes do upgrade:

  • Cluster administrador: a verificação inclui o serviço do Kubernetes, o status do componente, o DaemonSets, as implantações, as máquinas e os pods.
  • Cluster do usuário: a verificação inclui o serviço do Kubernetes, os endpoints da API do cluster, StatefulSets, implantações, implantações de máquina, máquinas e pods.

Pulado com a sinalização --skip-validation-cluster-health.

Entrada

Verifica se o cluster de usuário tem um objeto de gateway do Istio antes do upgrade. Consulte Migração de entrada.

IP reservado

Valida se há endereços IP suficientes disponíveis para criação e atualização.

Pulado com a sinalização --skip-validation-reserved-ips.

Google Cloud
Project ID
[*].projectid
Valida os IDs do projeto fornecidos para vários campos na configuração. Se o ID do projeto estiver ausente, a validação será pulada.
Registrar conta de serviço
registerserviceaccountkeypath
Valida se a conta de serviço tem os papéis do IAM necessários. Valida se as APIs necessárias estão ativadas.
Conectar conta de serviço
agentserviceaccountkeypath
Valida se a conta de serviço tem os papéis do IAM necessários. Valida se as APIs necessárias estão ativadas.
Conta de serviço do pacote de operações do Google Cloud
stackdriver.serviceaccountkeypath
Valida se a conta de serviço tem os papéis do IAM necessários. Valida se as APIs necessárias estão ativadas.
Pulado com a sinalização --skip-validation-gcp.
Acesso ao acesso gcr.io/gke-on-prem-release Valida o acesso aos clusters do Anthos no registro de imagem de contêiner da VMware hospedado no Container Registry.

Pulado pela sinalização --skip-validation-docker.

Registro do Docker
privateregistryconfig
Se configurado, inclui o acesso ao registro do Docker.

Pulado com a sinalização --skip-validation-docker.

vCenter Verifica se todos os campos vcenter estão presentes e verifica o seguinte:
Credenciais
vcenter.credentials.[*]
Valida a autenticação para o servidor vCenter usando as credenciais de usuário fornecidas.
Versão do vSphere Valida se o vSphere está na versão correta.
Data center
vcenter.datacenter
Valida se o data center do vSphere existe.
Datastore
vcenter.datastore
Valida se o armazenamento de dados do vSphere existe.
Disco de dados
vcenter.datadisk
Valida se o disco de máquina virtual (VMDK, na sigla em inglês) do vSphere ainda não existe.
Pool de recursos
vcenter.resourcepool
Valida se o pool de recursos do vSphere existe.
Rede
vcenter.network
Valida se a rede do vSphere existe.
Driver CSI do vSphere Valida os pré-requisitos do driver CSI do vSphere.

Pulado com a sinalização --skip-validation-infra.

Hosts para grupos antiafinidade

Valida se o número de hosts físicos do vCenter é pelo menos três se antiAffinityGroups estiver ativado.

Para desativar antiAffinityGroups para um cluster, consulte antiAffinityGroups.enabled e esta nota de versão.

Pulado com a sinalização --skip-validation-infra.

Balanceador de carga

Valida a configuração de balanceamento de carga:

  • Se o modo de balanceamento de carga estiver integrado (lbmode: Integrated), valida se todos os campos bigip estão presentes nas especificações admincluster e usercluster.
  • Se o modo de balanceamento de carga for manual (lbmode: Manual), valida se todos os campos manuallbspec estão presentes nas especificações admincluster e usercluster.
Balanceamento de carga integrado
bigip.credentials.[*] Valida as credenciais F5 BIG-IP.
bigip.partition Valida se a partição fornecida existe.
Papel de usuário F5 BIG-IP Valida se o usuário F5 BIG-IP fornecido tem o papel de administrador ou administrador de recursos.
bigip.vips.[*] Valida os VIPs fornecidos.

Pulado com as sinalizações --fast ou --skip-validation-load-balancer.

Balanceamento de carga manual
Configurações de rede Valida VIPs, IPs de nó etc.

Pulado com as sinalizações --fast ou --skip-validation-load-balancer.

[*].manuallbspec.[*] Valida as portas de nó fornecidas.
Pulado com a sinalização --skip-validation-load-balancer.
Rede

Valida se os intervalos CIDR, VIPs e IPs estáticos fornecidos (se configurados) estão disponíveis. Verifica se os endereços IP não se sobrepõem.

Pulado com a sinalização --skip-validation-net-config.

DNS

Valida se o servidor DNS fornecido está disponível.

Pulado com a sinalização --skip-validation-dns.

NTP

Valida se o servidor de Network Time Protocol (NTP) fornecido está disponível.

Pulado com a sinalização --skip-validation-tod.

VIPs

Faz o ping dos VIPs fornecidos. Essa verificação será bem-sucedida se o ping falhar, indicando que o VIP ainda não foi realizado.

Pulado com a sinalização --skip-validation-vips.

IPs de nós

Faz o ping dos endereços IP de nós fornecidos. Essa verificação será bem-sucedida se o ping falhar, indicando que o IP do nó esperado ainda não foi usado.

Pulado com a sinalização --skip-validation-node-ips.

Resultados da verificação de simulação

As verificações de simulação retornam os seguintes resultados:

SUCCESS
O campo e o valor dele passaram na verificação.
FAILURE
O campo e/ou o valor dele não passaram na verificação. Se uma verificação retornar uma mensagem FAILURE, corrija os problemas e valide o arquivo novamente.
SKIPPED

A verificação foi pulada, provavelmente, porque não é relevante para a configuração. Por exemplo, se você estiver usando um servidor DHCP, as verificações de DNS e IPs de nó, relevantes apenas para uma configuração de IP estático, serão puladas.

Se você passar uma sinalização que pule uma validação, a verificação pulada não retornará um resultado SKIPPED. Em vez disso, a validação não é executada e não aparece na resposta ao comando.

UNKNOWN

A ação de pular retornou um código diferente de zero. É possível considerar os resultados UNKNOWN como verificações que falharam. UNKNOWN geralmente indica que a verificação falhou ao executar algum pacote do sistema, como o nslookup ou o gcloud.

Em breve

As seguintes verificações de simulação serão adicionadas em uma versão futura:

  • Servidor NTP

Com executar verificações de simulação

Para executar as verificações de simulação, execute o seguinte comando:

gkectl check-config --config [CONFIG]

em que [CONFIG] é o caminho para os clusters do Anthos no arquivo de configuração da VMware.

Como executar no modo rápido

Se preferir, execute verificações de simulação no "modo rápido", que pula as validações que criam VMs de teste temporárias, como as balanceamentos de carga de VIP e IP do nó. Para fazer isso, passe --fast:

gkectl check-config --config [CONFIG] --fast

Como pular validações específicas

É possível passar sinalizações para pular de maneira granular as validações específicas, como DNS, proxy e rede. Cada sinalização de pular é prefixada com --skip-[VALIDATION].

Para saber mais sobre as sinalizações de pular disponíveis, execute o comando a seguir. Como opção, consulte a referência do gkectl check-config:

gkectl check-config --help

Por exemplo, para pular as validações do balanceador de carga:

gkectl check-config --config my-config.yaml --skip-validation-load-balancer 

Como cancelar verificações de simulação

Se você começou a executar verificações de simulação e quer cancelar, pressione CTRL + C duas vezes. Se uma verificação de simulação tiver criado uma VM de teste, o cancelamento também limpará a VM automaticamente.

Como limpar uma VM de teste

Se uma VM de teste sobrar após a conclusão das verificações de simulação, será possível excluir a VM do vCenter. Uma VM de teste tem um nome como este:

check-config-[dhcp|static]-[random number]

Para excluir a VM:

  1. Clique com o botão direito do mouse na VM e clique em Ativação > Desativar

  2. Depois que a VM for desativada, clique com o botão direito na VM novamente e clique em Excluir do disco.

Exemplo

Veja abaixo um exemplo da saída do comando. Neste exemplo, a configuração que está sendo validada usa o modo de balanceamento de carga integrado e IPs estáticos sem um registro externo do Docker:

- Validation Category: Config Check
    - [SUCCESS] Config

- Validation Category: Internet Access
    - [SUCCESS] Internet access to required domains

- Validation Category: GCP
    - [SUCCESS] GCP Service
    - [SUCCESS] GCP Service Account

- Validation Category: Docker Registry
    - [SUCCESS] gcr.io/gke-on-prem-release access

- Validation Category: vCenter
    - [SUCCESS] Credentials
    - [SUCCESS] Version
    - [SUCCESS] Datacenter
    - [SUCCESS] Datastore
    - [SUCCESS] Data Disk
    - [SUCCESS] Resource Pool
    - [SUCCESS] Network
    - [SUCCESS] VSphere CSI Driver

- Validation Category: F5 BIG-IP
    - [SUCCESS] Admin Cluster F5 (credentials, partition and user role)
    - [SUCCESS] User Cluster F5 (credentials, partition and user role)

- Validation Category: Network Configuration
    - [SUCCESS] CIDR, VIP and static IP (availability and overlapping)

- Validation Category: DNS
    - [SUCCESS] DNS (availability)

- Validation Category: VIPs
    - [SUCCESS] ping (availability)

- Validation Category: Node IPs
    - [SUCCESS] ping (availability)

Now running slow validation checks. ...

Reusing VM template "gke-on-prem-osimage-xxx" that already exists in vSphere.
Creating test VMs with admin cluster configuration...  DONE
Waiting to get IP addresses from test VMs...  DONE
Waiting for test VMs to become ready...  DONE

Reusing VM template "gke-on-prem-osimage-xxx" that already exists in vSphere.
Creating test VMs with user cluster configuration...  DONE
Waiting to get IP addresses from test VMs...  DONE
Waiting for test VMs to become ready...  DONE

- Validation Category: F5 BIG-IP
    - [SUCCESS] Admin Cluster VIP and NodeIP
    - [SUCCESS] Admin Cluster F5 Access
    - [SUCCESS] User Cluster VIP and NodeIP
    - [SUCCESS] User Cluster F5 Access

- Validation Category: Internet Access
    - [SUCCESS] Internet access to required domains

- Validation Category: vCenter on test VMs
    - [SUCCESS] Test VM: VCenter Access and Permission

- Validation Category: DNS on test VMs
    - [SUCCESS] Test VM: DNS Availability

- Validation Category: TOD on test VMs
    - [SUCCESS] Test VM: TOD Availability

- Validation Category: Docker Registry
    - [SUCCESS] gcr.io/gke-on-prem-release access

Deleting test VMs with admin cluster configuration...  DONE
Deleting test VMs with user cluster configuration...  DONE

Problemas conhecidos

  • Para a versão 1.3.0-gke.16:

    É necessário executar verificações de validação rápidas, gkectl check-config --fast, para suas verificações de simulação se as duas condições a seguir se aplicarem:

    1. Você configurou clusters do Anthos no VMware para usar um proxy.

    2. Você instalou um dos seguintes pacotes:

      • O pacote /var/lib/gke/bundles/gke-onprem-vsphere-1.3.0-gke.16.tgz na página Downloads.
      • O pacote /var/lib/gke/bundles/gke-onprem-vsphere-1.3.0-gke.16.tgz da estação de trabalho de administrador.

    Só é possível executar o conjunto completo de validação se você instalou o pacote completo. Por exemplo: /var/lib/gke/bundles/gke-onprem-vsphere-1.3.0-gke.16-full.tgz

  • Para a versão 1.2.0-gke.6:

    Se você estiver usando pools de recursos aninhados ou padrão, o gkectl check-config falhará ao tentar fazer um conjunto completo de validações. No entanto, é possível fazer um conjunto menor de validações passando a sinalização --fast.

    gkectl check-config --config [CONFIG] --fast

A seguir