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 grande operação 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 verifique todas as aprovações. Também é possível executar verificações de simulação sob demanda.

Neste documento, descrevemos cada verificação, em que circunstâncias ela é executada automaticamente, como e quando executá-la 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 faz upgrade de 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 explicitamente.

  • O Google Distributed Cloud também executa verificações de simulação internas quando um administrador ou um cluster 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 recurso personalizado

Quando uma verificação de simulação é executada, o Google Distributed Cloud cria um recurso personalizado PreflightCheck. Os recursos personalizados PreflightCheck são persistentes e fornecem um registro das atividades e dos resultados de verificação de simulação.

Para recuperar PreflightCheck recursos personalizados:

  1. Receba uma lista de verificações de simulação executadas em 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 do comando de exemplo a seguir mostra um recurso PreflightCheck para uma verificação de simulação bem-sucedida que foi 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.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 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 do Google) para máquinas com endereços IP 192.0.2.53 e 192.0.2.54.
      • Gcp: verificações de conectividade do Google Cloud para o cluster.
      • Node - Network: verificações de rede (conectividade, operação etcd, acesso VIP e vinculação de portas) do cluster.
      • Pod - Cidr: o endereço IP do pod verifica se há 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 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 Google Distributed Cloud cria arquivos de registros. Confira 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 para o 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 para 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 registro 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 ao cluster do Google Cloud, chamado gcp.

    • Arquivo de registros 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 a identificar e solucionar o problema.

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

Quando você cria clusters, o Google Distributed Cloud 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 da máquina do nó:

    • As máquinas do cluster usam um sistema operacional (SO) compatível.

    • 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 pode ser operacional e os pacotes necessários estão disponíveis.

    • Para o Red Hat Enterprise Linux, o gerenciador de pacotes dnf pode ser operado, 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ós atendem aos requisitos mínimos de CPU.

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

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

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

    • 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 em 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, esse espelho pode ser acessado.

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

    • 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 são acessíveis.

  • Verificações de rede de nós (varia com base na configuração de 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 são aprovadas, o Google Distributed Cloud cria 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 forma 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 grande operação de cluster pode ajudar na programação.

Clusters autogerenciados

  • O comando a seguir valida o arquivo de configuração de 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.

  • 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

bmctl é compatível com o 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 Google Distributed Cloud 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 da máquina do nó:

    • As máquinas do cluster usam um sistema operacional (SO) compatível.

    • 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ós atendem aos requisitos mínimos de CPU.

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

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

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

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

    • A rota padrão para rotear pacotes para o gateway padrão está presente em 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, esse espelho pode ser acessado.

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

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

    • 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 são acessíveis.

  • 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êiner (CNI, na sigla em inglês) está í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 (varia com base na configuração de 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 Google Distributed Cloud fará o 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 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. É possível verificar se os clusters estão prontos para um upgrade executando 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 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 internas automaticamente quando você aplica recursos do Kubernetes a um cluster atual. Se alguma verificação falhar, o Google Distributed Cloud não vai alterar nenhum dos nós relacionados, a menos que você consiga 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.

Veja a seguir parte de um arquivo de configuração de 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.29.100-gke.251
...

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

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

  • Para usar a lista mais recente de verificações e determinar se as máquinas e a rede estão prontas para a criação do cluster, siga estas etapas:

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

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

Também é possível executar as últimas verificações de integridade de um cluster ativo para determinar se ele está íntegro.

  • Para executar 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, poderá ignorar as verificações de simulação automatizadas. Para ignorar verificações de simulação automatizadas, use a sinalização opcional --force ao executar bmctl create cluster ou bmctl upgrade cluster.

A seguir