Verificações prévias

As verificações pré-voo são uma medida preventiva para ajudar a identificar problemas antes de iniciar uma operação de cluster importante, como a criação ou a atualização de clusters. Quando estas verificações são executadas automaticamente antes de uma operação, não são feitas alterações aos seus clusters, a menos que todas as verificações prévias sejam aprovadas. Também pode executar verificações pré-voo a pedido.

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

No Google Distributed Cloud, pode executar verificações prévias para diferentes situações:

  • O Google Distributed Cloud executa verificações prévias quando cria ou atualiza clusters e recursos do conjunto de nós com bmctl. Se as verificações falharem, não são feitas alterações. Também pode ignorar estas verificações ou executá-las explicitamente.

  • O Google Distributed Cloud também executa verificações prévias internas quando um administrador ou um cluster híbrido cria ou atualiza recursos do Kubernetes em clusters de utilizadores. As verificações são executadas antes de as alterações serem aplicadas aos clusters de utilizadores afetados. Se as verificações falharem, não são feitas alterações.

PreflightCheck recursos personalizados

Quando é executada uma verificação prévia, o Google Distributed Cloud cria um recurso personalizado.PreflightCheck Os recursos personalizados PreflightChecksão persistentes e fornecem um registo das atividades e dos resultados da verificação prévia.

Para obter PreflightCheck recursos personalizados:

  1. Obtenha uma lista de verificações prévias que foram executadas para um determinado cluster:

    kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE

    Substitua o seguinte:

    • ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.
    • CLUSTER_NAMESPACE: o espaço de nomes do cluster.

    A resposta apresenta os recursos por espaço de nomes. Pode executar kubectl get preflightchecks em todos os espaços de nomes para obter uma lista abrangente. Para cada recurso, a resposta mostra a idade do recurso e se as verificações prévias foram aprovadas ou não. A seguinte resposta de exemplo mostra os recursos PreflightCheck para o espaço de nomes 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 PreflightCheck recurso personalizado específico:

    kubectl describe preflightchecks --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE

    Substitua o seguinte:

    • ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.
    • CLUSTER_NAMESPACE: o espaço de nomes do cluster.

    A seguinte resposta de comando de exemplo mostra um recurso PreflightCheck para uma verificação prévia 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.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 secção Status contém as seguintes informações:

    • A secção Checks apresenta verificações pré-publicação individuais que foram executadas e se foram aprovadas ou não. Neste exemplo, foram executadas as seguintes verificações:
      • 192.0.2.53 e 192.0.2.54: verificações de nós (configuração do SO, recursos e definiçõ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: Google Cloud verificações de conetividade (Artifact Registry e acesso à API Google) para máquinas com endereços IP 192.0.2.53 e 192.0.2.54.
      • Gcp: Google Cloud verificações de conetividade para o cluster.
      • Node - Network: verificações de rede (conetividade, funcionamento etcd, acesso VIP e vinculação de portas) para o cluster.
      • Pod - Cidr: o endereço IP do pod verifica se existem endereços sobrepostos para o cluster.
    • A secção Cluster Spec mostra a configuração do cluster.
    • O campo Pass mostra true, o que indica que as verificações pré-voo foram aprovadas coletivamente.

Registos de verificação prévia

Quando as verificações de pré-voo são executadas como resultado de um comando bmctl, como bmctl check preflight, o Google Distributed Cloud cria ficheiros de registo. Veja o que é gerado e onde:

  • Os registos da verificação prévia são gerados num diretório com o seguinte padrão de nomenclatura: preflight-TIMESTAMP.

  • Este diretório de pré-teste é criado no diretório log para o cluster no espaço de trabalho bmctl. Por predefinição, o caminho do diretório log é bmctl-workspace/CLUSTER_NAME/log.

  • Os registos de pré-publicação consistem nos seguintes ficheiros:

    • Ficheiros de registo para verificações de máquinas de nós, um para cada nó do cluster. O nome destes ficheiros de registo é o endereço IP do nó. Por exemplo, um nome de ficheiro pode ser 192.0.2.53.

    • Ficheiros de registo para Google Cloud verificações de acesso, um para cada nó do cluster. O nome destes ficheiros de registo é o endereço IP do nó. Por exemplo, o nome de um ficheiro pode ser 192.0.2.53-gcp.

    • Ficheiro de registo para verificações de acesso ao cluster Google Cloud , denominado gcp.

    • Ficheiro de registo para verificações de rede de nós, denominado node-network.

Se uma verificação prévia falhar, estes ficheiros de registo podem ajudar a identificar e resolver o problema.

Verificações prévias para a criação de clusters

Quando cria clusters, o Google Distributed Cloud executa automaticamente verificações prévias antes de serem feitas alterações.

O que é verificado?

As verificações prévias de instalação verificam o seguinte:

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

    • As máquinas do cluster estão a usar um sistema operativo (SO) compatível.

    • A versão do SO é suportada.

    • O SO está a usar uma versão do kernel suportada.

    • Para o Ubuntu, a firewall não complicada (UFW) está desativada.

    • Para o Ubuntu, o gestor de pacotes apt está operacional e os pacotes necessários estão disponíveis.

    • Para o Red Hat Enterprise Linux, o gestor de pacotes dnf está operacional e os pacotes necessários estão disponíveis.

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

    • As máquinas de nós cumprem os requisitos mínimos de CPU.

    • As máquinas de nós cumprem os requisitos mínimos de memória.

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

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

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

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

    • A rota predefinida para encaminhar pacotes para o gateway predefinido está presente nos nós.

    • O Sistema de Nomes de Domínio (DNS) está a funcionar corretamente. Se o cluster estiver configurado para ser executado através de um proxy, esta verificação é ignorada.

    • Os CIDRs de pods não se sobrepõem aos endereços IP das máquinas dos nós.

    • Se o cluster estiver configurado para usar um espelho do registo, o espelho do registo está acessível.

  • Google Cloud verifica cada nó e o cluster:

    • O alcance do Artifact Registry, gcr.io, é verificado. Se o cluster estiver configurado para usar uma imagem espelhada do registo, esta verificação é ignorada.

    • As APIs Google são acessíveis.

  • Verificações de rede de nós (variam consoante a configuração do equilíbrio de carga):

    • O IP virtual para o servidor da API Kubernetes está acessível.

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

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

    • A instância de eventos etcd é aprovisionada e os requisitos de portas são cumpridos.

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 vista geral dos pré-requisitos de instalação.

Execute verificações prévias a pedido para a criação de clusters

Também pode executar verificações pré-publicação de forma independente, antes de criar um cluster. Isto pode ser benéfico, uma vez que as principais operações de cluster, como a criação de clusters, demoram muito tempo. A identificação e a resolução de problemas em separado antes de iniciar uma operação de cluster importante podem ajudar na programação.

Clusters autogeridos

  • O comando seguinte valida o ficheiro 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 ficheiro de configuração que está a verificar.

  • Este comando verifica se os computadores e a rede estão prontos para a criação do cluster:

    bmctl check preflight --cluster CLUSTER_NAME

    Substitua CLUSTER_NAME pelo nome do cluster que está a verificar.

Clusters de utilizadores

  • O comando seguinte valida o ficheiro 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 o seguinte:

    • CLUSTER_NAME: o nome do cluster de utilizadores que está a verificar.
    • ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador associado.

  • O comando seguinte 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 suporta a utilização de --kubeconfig como um alias para a flag --admin-kubeconfig.

Verificações prévias para atualizações de clusters

Quando atualiza clusters, o Google Distributed Cloud executa automaticamente verificações de pré-implementação antes de serem feitas alterações.

O que é verificado?

As verificações prévias para atualizações de clusters verificam o seguinte:

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

    • As máquinas do cluster estão a usar um sistema operativo (SO) compatível.

    • A versão do SO é suportada.

    • O SO está a usar uma versão do kernel suportada.

    • Para o Ubuntu, a firewall não complicada (UFW) está desativada.

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

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

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

    • A rota predefinida para encaminhar pacotes para o gateway predefinido está presente nos nós.

    • O Sistema de Nomes de Domínio (DNS) está a funcionar corretamente. Se o cluster estiver configurado para ser executado através de um proxy, esta verificação é ignorada.

    • Se o cluster estiver configurado para usar um espelho do registo, o espelho do registo está acessível.

    • Nenhum nó do plano de controlo ou nó do equilibrador de carga está no modo de manutenção.

  • Google Cloud verifica cada nó e o cluster:

    • O alcance do Artifact Registry, gcr.io, é verificado. Se o cluster estiver configurado para usar uma imagem espelhada do registo, esta verificação é ignorada.

    • As APIs Google são acessíveis.

  • Verificações de máquinas:

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

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

    • O estado do ponto final de verificação do estado da interface de rede do contentor (CNI) é bom.

    • Os CIDRs de pods não se sobrepõem aos endereços IP das máquinas dos nós.

    • Os certificados kubeadm não expiraram.

  • Verificações de rede de nós (variam consoante a configuração do equilíbrio de carga):

    • O IP virtual para o servidor da API Kubernetes está acessível.

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

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

    • A instância de eventos etcd é aprovisionada e os requisitos de portas são cumpridos.

Quando todas as verificações são aprovadas, o Google Distributed Cloud atualiza o cluster. Para mais informações sobre a atualização de clusters, consulte os artigos Práticas recomendadas para atualizações de clusters do Google Distributed Cloud e Ciclo de vida e fases das atualizações de clusters.

Execute verificações prévias a pedido para atualizações de clusters

O comando bmctl check preflight permite-lhe executar uma verificação prévia antes de atualizar o cluster. Pode verificar se os clusters estão prontos para uma atualização executando o seguinte comando de verificação prévia antes de iniciar a atualização:

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

  2. Use o seguinte comando para verificar se os clusters estão prontos para uma atualização e executar uma verificação prévia:

    bmctl check preflight --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    Substitua o seguinte:

    • CLUSTER_NAME: o nome do cluster a atualizar.
    • ADMIN_KUBECONFIG: o caminho para o ficheiro kubeconfig do cluster de administrador.

    Quando cria a verificação prévia com este comando para testar uma atualização do cluster, é criado um recurso personalizado PreflightCheck no cluster de administrador.

Verificações prévias internas em clusters existentes

O Google Distributed Cloud realiza verificações prévias internas automaticamente quando aplica recursos do Kubernetes a um cluster existente. Se alguma verificação falhar, o Google Distributed Cloud não altera nenhum dos nós relacionados, a menos que ignore as verificações explicitamente.

Ignore as verificações prévias ao aplicar recursos do Kubernetes

Para ignorar as verificações prévias internas quando aplica recursos a clusters existentes, tem de definir o campo BypassPreflightCheck como true no ficheiro de configuração do cluster.

Segue-se parte de um ficheiro 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.33.100-gke.89
...

Execute as verificações de pré-publicação mais recentes

As verificações prévias (e as verificações de funcionamento) são atualizadas à medida que são identificados problemas conhecidos. Para direcionar o bmctl para executar as verificações a partir da imagem de patch mais recente da versão secundária instalada, use a opção --check-image-version latest:

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

Substitua CLUSTER_NAME pelo nome do cluster que está a verificar.

Isto pode ajudar a detetar problemas conhecidos identificados recentemente sem ter de criar ou atualizar primeiro o cluster.

Também pode executar as verificações de estado mais recentes de um cluster ativo para determinar se está a funcionar corretamente. Para mais informações, consulte o artigo Execute as verificações de funcionamento mais recentes.

Ignore os resultados das verificações prévias automáticas

Se executar verificações prévias a pedido antes de criar ou atualizar clusters, pode ignorar as verificações prévias automáticas. Para ignorar as verificações prévias automáticas, use a flag --force opcional quando executar bmctl create cluster ou bmctl upgrade cluster.

O que se segue?