Verificações de simulação

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

Neste documento, descrevemos cada verificação, em quais circunstâncias ela é executada automaticamente, como e quando ela é executada manualmente e como interpretar os resultados.

No Google Distributed Cloud, é possível executar verificações de simulação para diferentes situações:

• O Google Distributed Cloud executa verificações de simulação quando você cria ou atualiza clusters e recursos do 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 de maneira explícita.

• O Google Distributed Cloud também executa verificações de simulação interna 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.

Recursos personalizados PreflightCheck

Quando uma verificação de simulação é executada, o Google Distributed Cloud 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. Confira 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 e se as verificações de simulação deram certo 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. Extraia 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.

   O exemplo de resposta de comando a seguir mostra um recurso PreflightCheck para uma verificação de simulação executada como parte da criação de um 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.16.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.16.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 as 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ó (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 Google) para máquinas com endereços IP 192.0.2.53 e 192.0.2.54.
     • Gcp: as verificações de conectividade do Google Cloud para o cluster.
     • Node - Network: verificações de rede (conectividade, operação etcd, acesso a VIP e vinculação de porta) para o cluster.
     • Pod - Cidr: o endereço IP do pod verifica endereços sobrepostos para o 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 de forma coletiva.

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 Google Distributed Cloud cria arquivos de registro. Confira o que é gerado e onde:

• Os registros de verificação de simulação são gerados em um diretório com um nome que segue o padrão 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 são compostos pelos seguintes arquivos:

  • Arquivos de registro para verificações de máquinas de nós, um para cada nó do cluster. Os nomes desses arquivos de registro usam o endereço IP do nó. Por exemplo, um nome de arquivo pode ser 192.0.2.53.

  • Arquivos de registro para verificações de acesso do Google Cloud, um para cada nó do cluster. Os nomes desses arquivos de registro usam o endereço IP do nó. Por exemplo, um nome de arquivo pode ser 192.0.2.53-gcp.

  • Arquivo de registro para verificações de acesso ao Google Cloud do cluster, chamado gcp.

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

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

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

Ao criar clusters, o Google Distributed Cloud automaticamente executa verificações de simulação antes que qualquer alteração seja feita.

O que é verificado?

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

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

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

  • A versão do SO é compatível.

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

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

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

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

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

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

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

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

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

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

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

  • 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 de forma correta. Se o cluster estiver configurado para ser executado por trás de um proxy, essa verificação será ignorada.

  • Os CIDRs de pods 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, esse espelho pode ser acessado.

• Verificações do Google Cloud para cada nó e para o cluster:

  • O Container Registry, gcr.io, está acessível. Se o cluster estiver configurado para usar um espelho de registro, essa verificação será ignorada.

  • As APIs do Google são acessíveis.

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

  • O VIP para o 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 foi provisionada e os requisitos de porta foram atendidos.

Quando todas as verificações forem aprovadas, o Google Distributed Cloud vai criar o cluster. Para mais informações sobre os requisitos para a criação de clusters, consulte Visão geral dos pré-requisitos de instalação.

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

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

Observação: as verificações de simulação são atualizadas à medida que os problemas conhecidos são identificados. Para direcionar bmctl a executar as verificações da imagem de patch mais recente da versão secundária instalada, use a flag de opção --check-image-version latest. Para mais informações, consulte Executar as verificações de simulação mais recentes.

Clusters autogerenciados

• 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
  

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

• Esse 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
  

O bmctl é compatível com o uso de --kubeconfig como um alias para a flag --admin-kubeconfig.

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

Ao fazer upgrade de clusters, o Google Distributed Cloud automaticamente executa 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 incluem:

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

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

  • A versão do SO é compatível.

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

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

  • As máquinas de nó 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ó atendem aos requisitos mínimos de memória.

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

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

  • 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 de forma correta. Se o cluster estiver configurado para ser executado por trás de um proxy, essa verificação será ignorada.

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

  * Nenhum nó do plano de controle ou do balanceador de carga está no modo de manutenção.

• Verificações do Google Cloud para cada nó e para o cluster:

  • O Container Registry, gcr.io, está acessível. Se o cluster estiver configurado para usar um espelho de registro, essa verificação será ignorada.

  • As APIs do Google são acessíveis.

• Verificações da máquina:

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

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

  • O status do endpoint de integridade da interface de rede de contêiner (CNI) está íntegro.

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

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

  • O VIP para o 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 foi provisionada e os requisitos de porta foram atendidos.

Observação: em máquinas de nó 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 vai falhar. É possível remover o Docker ou ativar o serviço do Docker.

Quando todas as verificações forem aprovadas, o Google Distributed Cloud vai fazer upgrade do cluster. Para mais informações sobre como fazer upgrade de clusters, consulte Práticas recomendadas para upgrades de cluster do Google Distributed Cloud e Ciclo de vida e estágios dos upgrades do 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. Verifique se os clusters estão prontos para um upgrade executando o seguinte comando de verificação de simulação antes de iniciar o upgrade:

Observação: as verificações de simulação são atualizadas à medida que os problemas conhecidos são identificados. Para direcionar bmctl a executar as verificações da imagem de patch mais recente da versão secundária instalada, use a flag de opção --check-image-version latest. Para mais informações, consulte Executar as verificações de simulação mais recentes.

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

2. Use o comando a seguir para verificar 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 de cluster, um recurso personalizado PreflightCheck é criado no cluster de administrador.

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

O Google Distributed Cloud executa verificações de simulação interna automaticamente quando você aplica recursos do Kubernetes a um cluster. Se alguma verificação falhar, o Google Distributed Cloud não vai mudar nenhum dos nós relacionados, a não ser que você ignore as verificações explicitamente.

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

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

Aqui está 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.30.100-gke.96
...

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

As verificações de simulação e de integridade são atualizadas à medida que os problemas conhecidos são identificados. Para direcionar bmctl a executar as verificações da imagem de patch mais recente da versão secundária instalada, use a flag de opção --check-image-version latest:

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

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

Isso pode ajudar a detectar problemas conhecidos identificados recentemente sem precisar criar ou fazer upgrade do cluster.

Também é possível realizar as verificações de integridade mais recentes de um cluster ativo para determinar se ele está funcionando de forma correta. Para mais informações, consulte Executar as verificações de integridade mais recentes.

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

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

A seguir

• Verificações de integridade

• Detector de problemas de nós

• Verificar a conectividade do cluster com nettest

• Criar snapshots para ajudar a diagnosticar problemas de cluster