Resolver problemas de instalação ou upgrade do cluster

Nesta página, você encontrará informações sobre solução de problemas se você tiver problemas ao instalar ou atualizar o GKE em Bare Metal.

Problemas de cluster de inicialização

Quando o GKE em Bare Metal cria ou atualiza clusters, ele implanta um cluster do Kubernetes no Docker (tipo) para hospedar temporariamente os controladores do Kubernetes necessários para criar ou fazer upgrade de clusters. Esse cluster transitório é chamado de cluster de inicialização.

Se um cluster de tipo já existir em sua implantação ao tentar instalar, o GKE em Bare Metal excluirá o cluster de tipo existente. 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 o sucesso, use a sinalização --keep-bootstrap-cluster de bmctl.

O GKE em 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 é o padrão para 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 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, um cluster de inicialização é usado para upgrades de cluster de administrador, híbrido e autônomo. 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 ver a versão do Kubernetes de um determinado GKE em versão Bare Metal, confira a tabela na Política de suporte de versão.

Se o nó mostrar NOT READY, tente o conectar e verificar 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á fazendo upgrade

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 abaixo mostra que o nó que está sendo atualizado no momento 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 no momento

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 de 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 que estão travados ou lentos para drenagem. O upgrade prossegue, mesmo com pods travados, quando o processo de drenagem em um nó leva mais de 20 minutos.