Execução de verificações de simulação

Este documento apresenta informações sobre as verificações de simulação que são executadas quando criar ou fazer upgrade de um cluster no Google Distributed Cloud (somente software) VMware.

Revise suas regras de firewall

Na versão 1.29 e mais recentes, as verificações de simulação do lado do servidor são ativadas por padrão ao criar, atualizar e fazer upgrade de clusters. Verificações de simulação do lado do servidor não exigem regras de firewall adicionais. Em Regras de firewall para clusters de administrador, pesquise "Verificações de simulação" e garantir que todas as regras de firewall necessárias sejam configurados.

Como executar gkectl check-config

Se você planeja criar clusters usando gkectl, execute gkectl create-config para gerar um arquivo de configuração. 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 usando gkectl, 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 a versão 1.2.0-gke.6, 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.

Na versão 1.2.1 e mais recentes, o próprio comando check-config faz upload da VM. para que seja possível executar 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 de que sua configuração se torna imutável depois que você cria o clusters. 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

A partir da versão 1.2.1, o comando gkectl check-config tem um --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.
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
ID do projeto
[*].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 de observabilidade 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.
O acesso a gcr.io/gke-on-prem-release Valida o acesso ao registro de imagens de contêiner hospedado em Container Registry.

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

Registro do Docker
privateregistryconfig
Se configurado, valida 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 as versões do vCenter e do ESXi são compatíveis.
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.

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

Armazenamento
Driver CSI do vSphere Valido se o driver CSI do vSphere está ativado se houver PersistentVolumes do inv ou do CSI do vSphere. Ou seja, no arquivo de configuração do cluster de usuário, storage.vSphereCSIDisabled não está definido como true.
Parâmetros StorageClass

Valida se o StorageClass não tem nenhum dos seguintes parâmetros não compatíveis:

  • hostfailurestotolerate
  • forceprovisioning
  • cachereservation
  • diskstripes
  • objectspacereservation
  • iopslimit
  • diskformat

Se o cluster tiver StorageClasses com algum dos parâmetros anteriores, isso poderá significar que é preciso migrar os volumes.

Para mais informações, consulte Considerações para a migração de volumes do vSphere em árvore e a seção de problemas conhecidos sobre upgrades na versão 1.15.

Anotações no PersistentVolume e nas PersistentVolumeClaims do vSphere em árvore estaticamente criadas

Antes do upgrade, verifica as anotações PersistentVolumes na árvore do vSphere e PersistentVolumeClaims do vSphere:

  • Os PersistentVolumes em árvore do vSphere criados estaticamente têm a anotação pv.kubernetes.io/provisioned-by: kubernetes.io/vsphere-volume.
  • Os PersistentVolumesClaims do vSphere criados estaticamente têm a anotação volume.beta.kubernetes.io/storage-provisioner: kubernetes.io/vsphere-volume e volume.kubernetes.io/storage-provisioner: kubernetes.io/vsphere-volume.

Se o cluster tiver PersistentVolumes em árvore do vSphere ou PersistentVolumeClaims do vSphere sem essas anotações, anote os PersistentVolumes e PersistentVolumeClaims antes de continuar, consulte Considerações sobre a migração de volumes do vSphere em árvore.

Carga de trabalho CSI

Valida se o cluster pode executar com sucesso uma carga de trabalho que usa um PersistentVolume provisionado dinamicamente criado por meio do driver CSI do vSphere.

Isso verifica a execução durante o upgrade e somente se houver volumes do vSphere em árvore e nenhum volume do CSI do vSphere.

Essa verificação:

  1. Verifica se não há recursos restantes de execuções anteriores da validação.
  2. Encontra ou cria um StorageClass com o campo do provisionador definido como o campo do provisionador definido como "csi.vsphere.vmware.com".
    1. Em clusters de usuários, ele seleciona o standard-rwo StorageClass CSI.
    2. Em clusters de administrador, ele encontra um StorageClass com o campo do provisionador definido como csi.vsphere.vmware.com. Se não houver esse StorageClass no cluster, o teste criará temporariamente um novo StorageClass CSI e o usará na verificação.
  3. Cria um PersistentVolumeClaim no namespace padrão usando o StorageClass encontrado ou criado na etapa anterior e espera que o PersistentVolume criado dinamicamente esteja na fase Bound.
  4. Cria um job de gravador no namespace padrão que ativa o PersistentVolume criado acima. Um pod de gravação é programado e, na inicialização, ele grava uma string em um arquivo no sistema de arquivos montado.
  5. Desmonta o job do gravador e o pod associado.
  6. Cria um job de leitor no namespace padrão que ativa o PersistentVolume criado acima. Um pod de leitor é programado e, na inicialização, ele lê o arquivo gravado pelo pod de gravação, garantindo que os dados gravados pelo pod de gravação sejam lidos com êxito.
  7. Desmonta o job do leitor e o pod associado.
  8. Elimina o PersistentVolumeClaim. Como resultado, o PersistentVolume também é excluído.
  9. Elimina o StorageClass se ele tiver sido criado durante o teste.

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:

SUCESSO
O campo e o valor dele passaram na verificação.
FALHA
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.

DESCONHECIDO

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

Como 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 o arquivo de configuração

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 o Google Distributed Cloud 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