Resolver problemas de instalação ou upgrade do cluster

Nesta página, fornecemos informações sobre solução de problemas se você tiver problemas ao instalar ou fazer upgrade do GKE em clusters Bare Metal.

Problemas de cluster de inicialização

Quando o GKE em bare metal cria clusters autogerenciados (administrador, híbrido ou autônomo), ele implanta um cluster do Kubernetes no Docker (tipo) para hospedar temporariamente o Controladores do Kubernetes necessários para criar clusters. Esse cluster transitório é chamado de cluster de inicialização. Os clusters de usuário são criados e atualizados pelo cluster de administrador ou híbrido de gerenciamento sem o uso de um cluster de inicialização.

Se um cluster de tipo já existir na implantação, quando você tentar fazer a instalação, o GDCV para Bare Metal excluirá o cluster de tipo atual. A exclusão só ocorre depois que a instalação ou o upgrade são bem-sucedidos. Para preservar o cluster de tipo atual mesmo após a conclusão, use a sinalização --keep-bootstrap-cluster de bmctl.

O GDCV para Bare Metal cria um arquivo de configuração para o cluster de inicialização em WORKSPACE_DIR/.kindkubeconfig. Só é possível se conectar ao cluster de inicialização durante a criação e o upgrade dele.

O cluster de inicialização precisa acessar um repositório do Docker para extrair imagens. O registro padrão é o Container Registry, a menos que você esteja usando um registro particular. Durante a criação do cluster, bmctl cria os seguintes arquivos:

  • bmctl-workspace/config.json: contém as credenciais da conta de serviço do Google Cloud para o acesso ao registro. As credenciais são recebidas do campo gcrKeyPath no arquivo de configuração do cluster.

  • bmctl-workspace/config.toml: contém a configuração do containerd no cluster de tipo.

Depurar o cluster de bootstrap

Para depurar o cluster de inicialização, siga estas etapas:

  • Conecte-se ao cluster de inicialização durante a criação e o upgrade do cluster.
  • Receba os registros do cluster de inicialização.

É possível encontrar os registros na máquina que você usa para executar bmctl nas seguintes pastas:

  • bmctl-workspace/CLUSTER_NAME/log/create-cluster-TIMESTAMP/bootstrap-cluster/
  • bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP/bootstrap-cluster/

Substitua CLUSTER_NAME e TIMESTAMP pelo nome do cluster e o horário do sistema correspondente.

Para acessar os registros do cluster de inicialização diretamente, execute o seguinte comando durante a criação e o upgrade do cluster:

docker exec -it bmctl-control-plane bash

O comando abre um terminal dentro do contêiner do plano de controle bmctl que é executado no cluster de inicialização.

Para inspecionar os registros kubelet e containerd, use os seguintes comandos e procure erros ou avisos na saída:

journalctl -u kubelet
journalctl -u containerd

Problemas de upgrade de cluster

Ao fazer upgrade do GKE em clusters Bare Metal, é possível monitorar o progresso e verificar o status dos clusters e nós.

As orientações a seguir podem ajudar a determinar se o upgrade continua normalmente ou se há um problema.

Monitorar o progresso do upgrade

Use o comando kubectl describe cluster para ver o status de um cluster durante o processo de upgrade:

kubectl describe cluster CLUSTER_NAME \
    --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Substitua os seguintes valores:

  • CLUSTER_NAME: nome do cluster
  • CLUSTER_NAMESPACE: o namespace do cluster.
  • ADMIN_KUBECONFIG: o arquivo kubeconfig do administrador.
    • Por padrão, os clusters de administrador, híbrido e autônomo usam um upgrade no local. Se você usar a sinalização --use-bootstrap=true com o comando bmctl upgrade, a operação de upgrade usará um cluster de inicialização. Para monitorar o progresso do upgrade quando um cluster de inicialização for usado, especifique o caminho para o arquivo kubeconfig do cluster de inicialização, .kindkubeconfig. Esse arquivo está localizado no diretório do espaço de trabalho.

Observe a seção Status da saída, que mostra uma agregação do status de upgrade do cluster. Se o cluster relatar um erro, use as seções a seguir para solucionar o problema.

Verificar se os nós estão prontos

Use o comando kubectl get nodes para ver o status dos nós em um cluster durante o processo de upgrade:

kubectl get nodes --kubeconfig KUBECONFIG

Para verificar se um nó concluiu o processo de upgrade, observe as colunas VERSION e AGE na resposta do comando. O VERSION é a versão do Kubernetes do cluster. Para conferir a versão do Kubernetes de uma determinada versão do GDCV para Bare Metal, consulte a tabela na Política de suporte de versões.

Se o nó mostrar NOT READY, tente se conectar a ele e verifique o status do kubelet:

systemctl status kubelet

Você também pode analisar os registros do kubelet:

journalctl -u kubelet

Analise a saída do status do kubelet e os registros das mensagens que indicam por que o nó tem um problema.

Verificar qual nó está sendo atualizado

Para verificar qual nó do cluster está em processo de upgrade, use o comando kubectl get baremetalmachines:

kubectl get baremetalmachines --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Substitua os seguintes valores:

  • CLUSTER_NAMESPACE: o namespace do cluster.
  • ADMIN_KUBECONFIG: o arquivo kubeconfig do administrador.
    • Se um cluster de inicialização for usado para um upgrade híbrido, de administrador ou independente, especifique o arquivo kubeconfig do cluster de inicialização (bmctl-workspace/.kindkubeconfig).

O exemplo de saída a seguir mostra que o nó que está sendo atualizado tem um ABM VERSION diferente de DESIRED ABM VERSION:

NAME         CLUSTER    READY   INSTANCEID               MACHINE      ABM VERSION   DESIRED ABM VERSION
10.200.0.2   cluster1   true    baremetal://10.200.0.2   10.200.0.2   1.13.0        1.14.0
10.200.0.3   cluster1   true    baremetal://10.200.0.3   10.200.0.3   1.13.0        1.13.0

Verificar quais nós estão sendo drenados

Durante o processo de upgrade, os nós são esvaziados dos pods, e a programação fica desativada até que o upgrade do nó seja concluído. Para ver quais nós estão sendo drenados dos pods, use o comando kubectl get nodes:

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG | grep "SchedulingDisabled"

Substitua USER_CLUSTER_KUBECONFIG pelo caminho para o arquivo Kubeconfig do cluster de usuário.

A coluna STATUS é filtrada usando grep para mostrar apenas os nós que informam SchedulingDisabled. Esse status indica que os nós estão sendo drenados.

Também é possível verificar o status do nó do cluster de administrador:

kubectl get baremetalmachines -n CLUSTER_NAMESPACE \
  --kubeconfig ADMIN_KUBECONFIG

Substitua os seguintes valores:

  • CLUSTER_NAMESPACE: o namespace do cluster.
  • ADMIN_KUBECONFIG: o arquivo kubeconfig do administrador.
    • Se um cluster de inicialização for usado para um upgrade híbrido, de administrador ou independente, especifique o arquivo kubeconfig do cluster de inicialização (bmctl-workspace/.kindkubeconfig).

O nó que está sendo drenado mostra o status na coluna MAINTENANCE.

Verifique por que um nó está no status de drenagem há muito tempo

Use um dos métodos na seção anterior para identificar o nó que está sendo drenado usando o comando kubectl get nodes. Use o comando kubectl get pods e filtre o nome desse nó para ver mais detalhes:

kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE_NAME

Substitua NODE_NAME pelo nome do nó que está sendo drenado. A saída retorna uma lista de pods travados ou com drenagem lenta. O upgrade continua, mesmo com pods travados, quando o processo de drenagem em um nó leva mais de 20 minutos.

Verificar por que os pods não estão íntegros

Os upgrades poderão falhar se um pod contiver endereços IP do plano de controle upgrade-first-node ou upgrade-node. Esse comportamento geralmente ocorre porque os pods estáticos não estão íntegros.

  1. Verifique os pods estáticos com o comando crictl ps -a e procure os pods do Kubernetes ou etcd com falha. Se você tiver pods com falha, revise os registros dos pods para ver por que eles estão falhando.

    Veja algumas possibilidades de comportamento de loop de falhas:

    • As permissões ou o proprietário de arquivos montados em pods estáticos não estão corretos.
    • A conectividade com o endereço IP virtual não funciona.
    • Problemas com etcd

  2. Se o comando crictl ps não funcionar ou não retornar nada, verifique o status de kubelet e containerd. Use os comandos systemctl status SERVICE e journalctl -u SERVICE para analisar os registros.