Verificações de simulação

Version 1.15 

• Mais recente
• Versão 1.16
• Versões anteriores (sem suporte)

As verificações de simulação são uma medida preventiva para ajudar a identificar problemas antes de você iniciar uma operação importante de cluster, como a criação ou o upgrade de clusters. Quando essas verificações são executadas automaticamente antes de uma operação, nenhuma alteração é feita nos clusters, a menos que a simulação seja aprovada. Também é possível executar verificações de simulação sob demanda.

Este documento descreve cada verificação, em que circunstâncias ela é executada automaticamente, como e quando executá-la manualmente e como interpretar os resultados.

No GDCV para Bare Metal, é possível executar verificações de simulação para diferentes situações:

• O GDCV para Bare Metal executa verificações de simulação quando você cria ou faz upgrade de clusters e recursos de pool de nós com bmctl. Se as verificações falharem, nenhuma alteração será feita. Também é possível ignorar essas verificações ou executá-las explicitamente.

• O GDCV para Bare Metal também executa verificações internas de simulação quando um cluster de administrador ou híbrido cria ou atualiza recursos do Kubernetes em clusters de usuário. As verificações são executadas antes que as alterações sejam aplicadas aos clusters de usuário afetados. Se as verificações falharem, nenhuma alteração será feita.

PreflightCheck recursos personalizados

Quando uma verificação de simulação é executada, o GDCV para Bare Metal cria um recurso personalizado PreflightCheck. Os recursos personalizados PreflightCheck são permanentes e fornecem um registro das atividades e dos resultados da verificação de simulação.

Para recuperar recursos personalizados PreflightCheck:

1. Acesse uma lista de verificações de simulação executadas para um determinado cluster:

   kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
   

   Substitua:

   • ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador.
   • CLUSTER_NAMESPACE: o namespace do cluster.

   A resposta lista os recursos por namespace. É possível executar kubectl get preflightchecks em todos os namespaces para ter uma lista abrangente. Para cada recurso, a resposta mostra a idade do recurso e se as verificações de simulação foram aprovadas ou não. O exemplo de resposta a seguir mostra recursos PreflightCheck para o namespace cluster-test-admin001.

   NAMESPACE              NAME                                PASS    AGE
   cluster-test-admin001   test-admin001                      true    52d
   cluster-test-admin001   test-admin001jkm4q                 true    52d
   cluster-test-admin001   test-admin001k79t7                 true    6d20h
   cluster-test-admin001   upgrade-cluster-20231106-222746    true    6d20h
   

2. Recupere os detalhes de um recurso personalizado PreflightCheck específico:

   kubectl describe preflightchecks --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
   

   Substitua:

   • ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador.
   • CLUSTER_NAMESPACE: o namespace do cluster.

   A resposta de comando de amostra a seguir mostra um recurso PreflightCheck para uma verificação de simulação bem-sucedida, executada como parte da criação do cluster:

   Name:         create-cluster-20230922-175006
   Namespace:    cluster-test-user001
   Labels:       <none>
   Annotations:  <none>
   API Version:  baremetal.cluster.gke.io/v1
   Kind:         PreflightCheck
   Metadata:
     Creation Timestamp:  2023-09-22T17:50:11Z
     Generation:          1
     Resource Version:    6502800
     UID:                 917daf64-963d-44b4-a1f9-c54972a39191
   Spec:
     Check Image Version:  latest
     Config YAML:          ---
   apiVersion: v1
   kind: Namespace
   metadata:
     name: cluster-test-user
   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: test-user001
     namespace: cluster-test-user001
   spec:
     type: user
     profile: default
     anthosBareMetalVersion: 1.15.0
     gkeConnect:
       projectID: clusters-project
     controlPlane:
       nodePoolSpec:
         nodes:
         - address: 192.0.2.53
     ...
   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: NodePool
   metadata:
     name: node-pool-1
     namespace: cluster-test-user001
   spec:
     clusterName: test-user001
     nodes:
     - address: 192.0.2.54
     ...
   Status:
     Checks:
       192.0.2.53:
         Job UID:  d0b5dc1f-9d39-4cc8-b3d2-0841212f7f8c
         Message:
         Pass:     true
       192.0.2.53-gcp:
         Job UID:  b4d96ce5-0d4e-4e3c-97db-6317e0c15fc8
         Message:
         Pass:     true
       192.0.2.54:
         Job UID:  b67cf195-3951-46ad-b91c-0d79025cfc0a
         Message:
         Pass:     true
       192.0.2.54-gcp:
         Job UID:  aed509e2-4bf7-44c4-bfa0-8147ef8ea74e
         Message:
         Pass:     true
       Gcp:
         Job UID:  ac479ac4-e1c4-4681-9f2b-5773069bf6ae
         Message:
         Pass:     true
       Node - Network:
         Job UID:  8a57c4ee-ad17-4560-8809-b117c871ad5d
         Message:
         Pass:     true
       Pod - Cidr:
         Message:
         Pass:     true
     Cluster Spec:
       Anthos Bare Metal Version:  1.15.0
       Bypass Preflight Check:     false
       Cluster Network:
         Bundled Ingress:  true
         Pods:
           Cidr Blocks:
             10.0.0.0/16
         Services:
           Cidr Blocks:
             10.96.0.0/20
     ...
     Completion Time:                 2023-09-22T17:51:22Z
     Conditions:
       Last Transition Time:  2023-10-02T23:59:06Z
       Observed Generation:   1
       Reason:                Reconciling
       Status:                True
       Type:                  Reconciling
     Node Pool Specs:
       node-pool-1:
         Cluster Name:  test-user001
         Nodes:
           Address:         192.0.2.54
       ...
     Pass:                  true
     Start Time:            2023-09-22T17:50:32Z
   Events:                  <none>
   

   No recurso personalizado PreflightCheck anterior, a seção Status contém as seguintes informações:

   • A seção Checks lista verificações de simulação individuais que foram executadas e se elas foram aprovadas ou não. Neste exemplo, as seguintes verificações foram executadas:
     • 192.0.2.53 e 192.0.2.54: verificações de nós (configuração do SO, recursos e configurações de software) para máquinas com endereços IP 192.0.2.53 e 192.0.2.54.
     • 192.0.2.53-gpc e 192.0.2.54-gcp: verificações de conectividade do Google Cloud (acesso ao Container Registry e à API do Google) para máquinas com endereços IP 192.0.2.53 e 192.0.2.54.
     • Gcp: a conectividade do Google Cloud verifica o cluster.
     • Node - Network: verificações de rede (conectividade, operação etcd, acesso VIP e vinculação de porta) para o cluster.
     • Pod - Cidr: o endereço IP do pod verifica se há endereços sobrepostos no cluster.
   • A seção Cluster Spec mostra a configuração do cluster.
   • O campo Pass mostra true, indicando que as verificações de simulação foram aprovadas coletivamente.

Registros de verificação de simulação

Quando as verificações de simulação são executadas como resultado de um comando bmctl, como bmctl check preflight, o GDCV para Bare Metal cria arquivos de registros. Veja o que é gerado e onde:

• Os registros de verificação de simulação são gerados em um diretório com o seguinte padrão de nomenclatura preflight-TIMESTAMP.

• Esse diretório de simulação é criado no diretório log do cluster no espaço de trabalho bmctl. Por padrão, o caminho do diretório log é bmctl-workspace/CLUSTER_NAME/log.

• Os registros de simulação consistem nos seguintes arquivos:

  • Arquivos de registros das verificações da máquina do nó, um para cada nó do cluster. Esses arquivos de registro são nomeados usando o endereço IP do nó. Por exemplo, um nome de arquivo pode ser 192.0.2.53.

  • Arquivos de registros das verificações de acesso do Google Cloud, um para cada nó do cluster. Esses arquivos de registro são nomeados usando o endereço IP do nó. Por exemplo, um nome de arquivo pode ser 192.0.2.53-gcp.

  • Arquivo de registros das verificações de acesso do cluster do Google Cloud, denominado gcp.

  • Arquivo de registro para verificações de rede de nós, chamado node-network.

Se uma verificação de simulação falhar, esses arquivos de registro poderão ajudar você a identificar e resolver o problema.

Verificações de simulação para criação de clusters

Quando você cria clusters, a GDCV para Bare Metal executa automaticamente verificações de simulação antes que qualquer alteração seja feita.

O que é verificado?

As verificações de simulação para instalação verificam o seguinte:

• Verificações de máquina do nó:

  • As máquinas de cluster estão usando um sistema operacional (SO) com suporte.

  • A versão do SO é suportada.

  • O SO está usando uma versão do kernel com suporte.

  • No Ubuntu, o Uncomplicated Firewall (UFW) está desativado.

  • Para o Ubuntu, o gerenciador de pacotes apt é operável e os pacotes necessários estão disponíveis.

  • Para o Red Hat Enterprise Linux, o gerenciador de pacotes dnf é operável e os pacotes necessários estão disponíveis.

  • Para o Red Hat Enterprise Linux, o Podman não está instalado.

  • Máquinas de nós atendem aos requisitos mínimos de CPU.

  • As máquinas de nós atendem aos requisitos mínimos de memória.

  • Máquinas de nós atendem aos requisitos mínimos de armazenamento em disco.

  • A sincronização de tempo é configurada nas máquinas de nós.

  • kubelet está ativo e em execução nas máquinas de nós.

  • containerd está ativo e em execução nas máquinas de nós.

  • A rota padrão para rotear pacotes para o gateway padrão está presente nos nós.

  • O Sistema de Nomes de Domínio (DNS) está funcionando corretamente. Se o cluster estiver configurado para ser executado atrás de um proxy, essa verificação será ignorada.

  • Os CIDRs do pod não se sobrepõem aos endereços IP da máquina do nó.

  • Se o cluster estiver configurado para usar um espelho de registro, o espelho de registro poderá ser acessado.

• O Google Cloud verifica o cluster e cada nó:

  • Container Registry, gcr.io, a acessibilidade está verificada. Se o cluster estiver configurado para usar um espelho de registro, essa verificação será ignorada.

  • As APIs do Google podem ser acessadas.

• Verificações de rede de nós (variam com base na configuração do balanceamento de carga):

  • O VIP do servidor da API Kubernetes está acessível.

  • Os VIPs do balanceador de carga são acessíveis.

  • Os nós podem se comunicar nas portas necessárias.

  • A instância de eventos etcd é provisionada e os requisitos de porta são atendidos.

Quando todas as verificações forem aprovadas, o GDCV para Bare Metal criará o cluster. Para mais informações sobre os requisitos para criar clusters, consulte a Visão geral dos pré-requisitos de instalação.

Executar verificações de simulação sob demanda para criação de clusters

Também é possível executar verificações de simulação de maneira independente, antes de criar um cluster. Isso pode ser benéfico porque as principais operações de cluster, como a criação de cluster, são demoradas. Identificar e resolver problemas separadamente antes de iniciar uma operação de cluster importante pode ajudar na programação.

Clusters autogerenciados

• O comando a seguir valida o arquivo de configuração do cluster especificado, mas não tenta criar o cluster em si:

  bmctl check config --cluster CLUSTER_NAME
  

  Substitua CLUSTER_NAME pelo nome do cluster associado ao arquivo de configuração que você está verificando.

• Este comando verifica se as máquinas e a rede estão prontas para a criação do cluster:

  bmctl check preflight --cluster CLUSTER_NAME
  

  Substitua CLUSTER_NAME pelo nome do cluster que você está verificando.

Clusters de usuários

• O comando a seguir valida o arquivo de configuração do cluster especificado, mas não tenta criar o próprio cluster:

  bmctl check config --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG
  

  Substitua:

  • CLUSTER_NAME: o nome do cluster de usuário que você está verificando.
  • ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador associado.

• O comando a seguir verifica se as máquinas e a rede estão prontas para a criação do cluster:

  bmctl check preflight --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG
  

bmctl oferece suporte ao uso de --kubeconfig como um alias para a sinalização --admin-kubeconfig.

Verificações de simulação para upgrades de cluster

Quando você faz upgrade de clusters, o GDCV para Bare Metal executa automaticamente verificações de simulação antes que qualquer alteração seja feita.

O que é verificado?

As verificações de simulação para upgrades de cluster verificam o seguinte:

• Verificações de máquina do nó:

  • As máquinas de cluster estão usando um sistema operacional (SO) com suporte.

  • A versão do SO é suportada.

  • O SO está usando uma versão do kernel com suporte.

  • No Ubuntu, o Uncomplicated Firewall (UFW) está desativado.

  • Máquinas de nós atendem aos requisitos mínimos de CPU.

  • As máquinas de nó têm mais de 20% dos recursos de CPU disponíveis.

  • As máquinas de nós atendem aos requisitos mínimos de memória.

  • Máquinas de nós atendem aos requisitos mínimos de armazenamento em disco.

  • A sincronização de tempo é configurada nas máquinas de nós.

  • A rota padrão para rotear pacotes para o gateway padrão está presente nos nós.

  • O Sistema de Nomes de Domínio (DNS) está funcionando corretamente. Se o cluster estiver configurado para ser executado atrás de um proxy, essa verificação será ignorada.

  • Se o cluster estiver configurado para usar um espelho de registro, o espelho de registro poderá ser acessado.

  * Nenhum nó do plano de controle ou do balanceador de carga está no modo de manutenção. Adicionado na GDCV para a versão 1.15.2 do Bare Metal.

• O Google Cloud verifica o cluster e cada nó:

  • Container Registry, gcr.io, a acessibilidade está verificada. Se o cluster estiver configurado para usar um espelho de registro, essa verificação será ignorada.

  • As APIs do Google podem ser acessadas.

• Verificações de máquina:

  • kubelet está ativo e em execução nas máquinas de nós.

  • containerd está ativo e em execução nas máquinas de nós.

  • O status do endpoint de integridade da interface de rede de contêineres (CNI, na sigla em inglês) é íntegro.

  • Os CIDRs do pod não se sobrepõem aos endereços IP da máquina do nó.

• Verificações de rede de nós (variam com base na configuração do balanceamento de carga):

  • O VIP do servidor da API Kubernetes está acessível.

  • Os VIPs do balanceador de carga estão acessíveis.

  • Os nós podem se comunicar nas portas necessárias.

  • A instância de eventos etcd é provisionada e os requisitos de porta são atendidos.

Observação: nas máquinas de nós de cluster, se o executável do Docker estiver presente na variável de ambiente PATH, mas o serviço do Docker não estiver ativo, a verificação de simulação falhará. É possível remover o Docker ou ativar o serviço dele.

Quando todas as verificações forem aprovadas, o GDCV para Bare Metal fará o upgrade do cluster. Para mais informações sobre como fazer upgrade de clusters, consulte Práticas recomendadas de GDCV para upgrades de cluster Bare Metal e Ciclo de vida e estágios dos upgrades de cluster.

Executar verificações de simulação sob demanda para upgrades de cluster

O comando bmctl check preflight permite executar uma verificação de simulação antes de fazer upgrade do cluster. Para verificar se os clusters estão prontos para um upgrade, execute o seguinte comando de verificação de simulação antes de iniciar o upgrade:

1. Atualize a versão do cluster (anthosBareMetalVersion) no arquivo de configuração do cluster.

2. Use o comando a seguir para conferir se os clusters estão prontos para um upgrade e execute uma verificação de simulação:

   bmctl check preflight --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
   

   Substitua:

   • CLUSTER_NAME: o nome do cluster a se fazer upgrade.
   • ADMIN_KUBECONFIG: o caminho até o arquivo kubeconfig do cluster de administrador.

   Quando você cria a verificação de simulação com esse comando para testar um upgrade do cluster, um recurso personalizado PreflightCheck é criado no cluster de administrador.

Verificações de simulação interna em clusters atuais

O GDCV para Bare Metal executa verificações internas de simulação automaticamente quando você aplica recursos do Kubernetes a um cluster atual. Se alguma verificação falhar, a GDCV para Bare Metal não vai mudar nenhum dos nós relacionados, a menos que você ignore as verificações explicitamente.

Ignorar verificações de simulação ao aplicar recursos do Kubernetes

Para ignorar as verificações internas de simulação ao aplicar recursos a clusters atuais, defina o campo BypassPreflightCheck como true no arquivo de configuração do cluster.

Esta é parte de um arquivo de configuração do cluster que mostra o campo bypassPreflightCheck definido como true:

apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user1
  namespace: cluster-user1
spec:
  type: user
  bypassPreflightCheck: true
  # Anthos cluster version.
  anthosBareMetalVersion: 1.15.11
...

Executar as verificações de simulação e de integridade mais recentes

Visualização

Este produto ou recurso está sujeito aos "Termos das ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos do serviço. Os produtos e recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Ao usar bmctl para executar verificações de integridade ou de simulação, é possível adicionar a flag --check-image-version latest ao comando para realizar as verificações da versão mais recente do patch Bare Metal do GDCV para os testes. Isso pode ajudar você a identificar problemas conhecidos sem criar ou fazer upgrade do cluster antes.

• Para usar a lista de verificações mais recente a fim de determinar se as máquinas e a rede estão prontas para a criação de clusters:

  bmctl check preflight --cluster CLUSTER_NAME --check-image-version latest
  

  Substitua CLUSTER_NAME pelo nome do cluster que você está verificando.

Você também pode executar as verificações de integridade mais recentes de um cluster ativo para determinar se ele está íntegro.

• Para realizar as verificações de integridade mais atualizadas em um cluster ativo:

  bmctl check cluster --cluster CLUSTER_NAME --check-image-version latest
  

  Substitua CLUSTER_NAME pelo nome do cluster que você está verificando.

Ignorar os resultados das verificações automáticas de simulação

Se você executar verificações de simulação sob demanda antes de criar ou fazer upgrade de clusters, será possível ignorar as verificações de simulação automatizadas. Para ignorar as verificações de simulação automatizadas, use a sinalização opcional --force ao executar bmctl create cluster ou bmctl upgrade cluster.

A seguir

• Verificações de integridade

• Detector de problemas do nó

• Verificar a conectividade do cluster com o nettest

• Criar snapshots para ajudar a diagnosticar problemas de cluster