Solução de problemas: diagnosticar e redefinir clusters

É possível diagnosticar ou verificar clusters para depurar problemas e capturar um snapshot do estado dele. Além disso, se você tiver parcialmente concluído uma instalação, mas o cluster retornar erros ou não estiver funcionando corretamente, tente redefini-lo.

Como diagnosticar clusters com bmctl check cluster

É possível capturar o estado dos clusters criados com o comando bmctl check cluster. As sinalizações do comando permitem que você escolha o escopo de diagnóstico do comando para que seja possível conseguir informações focalizadas.

As informações de diagnóstico podem ajudar você a descobrir problemas e depurar suas implantações com mais eficiência. O comando captura todos os arquivos de configuração de cluster e nó relevantes para o escopo definido e empacota as informações em um único arquivo tar.

bmctl check cluster --snapshot --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

Substitua:

  • CLUSTER_NAME: o nome do cluster de destino.

  • ADMIN_KUBECONFIG_PATH especifica o caminho até o arquivo kubeconfig do cluster de administrador;

Esse comando gera um arquivo tar com informações de depuração relevantes de todos os componentes e máquinas do sistema no cluster especificado.

É possível alterar o escopo das informações de diagnóstico coletadas com as seguintes sinalizações de comando:

  • A sinalização --snapshot-scenario all aumenta o escopo do snapshot de diagnóstico para incluir todos os pods no cluster especificado:
bmctl check cluster --snapshot --snapshot-scenario all --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH
  • A sinalização --snapshot-dry-run funciona em conjunto com a sinalização --snapshot-config string. Use a sinalização --snapshot-dry-run para gerar um arquivo de configuração que pode ser modificado para definir um escopo de diagnóstico personalizado. O escopo pode incluir pods, namespaces ou comandos de nós específicos.

Depois de modificar o arquivo de saída criado com a sinalização --snapshot-dry-run, é possível usá-lo como entrada para diagnosticar o escopo específico com a sinalização --snapshot-config string, descrita abaixo. Se você omitir essa sinalização, uma configuração padrão será aplicada.

bmctl check cluster --snapshot --snapshot-dry-run --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH
  • A sinalização --snapshot-config instrui o comando bmctl a usar as opções de escopo especificadas em um arquivo de configuração do snapshot. Geralmente, você cria o arquivo de configuração do snapshot com a sinalização --snapshot-dry-run.
bmctl check cluster --snapshot --snapshot-config SNAPSHOT_CONFIG_FILE --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

Como diagnosticar clusters quando o cluster de administrador está inacessível

Quando o cluster de administrador estiver inativo ou inacessível, use um arquivo de configuração de snapshot para tirar um snapshot do cluster. Um arquivo de configuração de snapshot está no formato YAML. O arquivo de configuração inclui os seguintes campos para especificar como as informações são capturadas para o cluster:

  • numOfParallelThreads: a rotina de snapshot geralmente executa vários comandos. Várias linhas de execução paralelas ajudam a executar a rotina mais rapidamente. Recomendamos que você defina numOfParallelThreads como 10, conforme mostrado no exemplo a seguir. Se os snapshots levarem muito tempo, aumente esse valor.

  • excludeWords: o snapshot contém uma grande quantidade de dados para os nós do cluster. Use excludeWords para reduzir os riscos de segurança ao compartilhar seu snapshot. Por exemplo, exclua password para que as strings de senha correspondentes não possam ser identificadas.

  • nodeCommands: esta seção especifica as seguintes informações:

    • nodes: uma lista de endereços IP para os nós do cluster de onde você quer coletar informações. Para criar um snapshot quando o cluster de administrador não estiver acessível, especifique pelo menos um endereço IP do nó.

    • commands: uma lista de comandos e argumentos a serem executados em cada nó. A saída de cada comando é incluída no snapshot.

  • nodeFiles: esta seção especifica as seguintes informações:

    • nodes: uma lista de endereços IP para os nós do cluster de onde você quer coletar arquivos. Para criar um snapshot quando o cluster de administrador não estiver acessível, especifique pelo menos um endereço IP do nó .

    • files: uma lista de arquivos a serem recuperados de cada nó. Quando os arquivos especificados são encontrados em um nó, eles são incluídos no snapshot.

  • nodeSSHKey: caminho para o arquivo de chave SSH dos nós. Esse campo é obrigatório para criar um snapshot quando o cluster de administrador não está acessível.

Use o comando a seguir para criar um snapshot usando um arquivo de configuração de snapshot:

bmctl check cluster --snapshot --snapshot-config SNAPSHOT_CONFIG

Substitua SNAPSHOT_CONFIG pelo caminho para o arquivo de configuração do snapshot.

O arquivo de configuração de snapshot a seguir mostra os comandos padrão e os arquivos usados para criar um snapshot. Você pode adicionar mais comandos e arquivos quando precisar de mais informações de diagnóstico.

numOfParallelThreads: 10
excludeWords:
- password
nodeCommands:
- nodes:
  - 10.200.0.3
  - 10.200.0.4
  commands:
  - uptime
  - df --all --inodes
  - ip addr
  - ip neigh
  - iptables-save --counters
  - mount
  - ip route list table all
  - top -bn1 || true
  - docker info || true
  - docker ps -a || true
  - crictl ps -a || true
  - docker ps -a | grep anthos-baremetal-haproxy | cut -d ' ' -f1 | head -n 1 | xargs
    sudo docker logs || true
  - docker ps -a | grep anthos-baremetal-keepalived | cut -d ' ' -f1 | head -n 1 |
    xargs sudo docker logs || true
  - crictl ps -a | grep anthos-baremetal-haproxy | cut -d ' ' -f1 | head -n 1 | xargs
    sudo crictl logs || true
  - crictl ps -a | grep anthos-baremetal-keepalived | cut -d ' ' -f1 | head -n 1 |
    xargs sudo crictl logs || true
  - ps -edF
  - ps -eo pid,tid,ppid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm,args,cgroup
  - conntrack --count
  - dmesg
  - systemctl status -l docker || true
  - journalctl --utc -u docker
  - journalctl --utc -u docker-monitor.service
  - systemctl status -l kubelet
  - journalctl --utc -u kubelet
  - journalctl --utc -u kubelet-monitor.service
  - journalctl --utc --boot --dmesg
  - journalctl --utc -u node-problem-detector
  - systemctl status -l containerd || true
  - journalctl --utc -u containerd
  - systemctl status -l docker.haproxy || true
  - journalctl --utc -u docker.haproxy
  - systemctl status -l docker.keepalived || true
  - journalctl --utc -u docker.keepalived
  - systemctl status -l container.haproxy || true
  - journalctl --utc -u container.haproxy
  - systemctl status -l container.keepalived || true
  - journalctl --utc -u container.keepalived
nodeFiles:
- nodes:
  - 10.200.0.3
  - 10.200.0.4
  files:
  - /proc/sys/fs/file-nr
  - /proc/sys/net/netfilter/nf_conntrack_max
  - /proc/sys/net/ipv4/conf/all/rp_filter
  - /lib/systemd/system/kubelet.service
  - /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
  - /lib/systemd/system/docker.service || true
  - /etc/systemd/system/containerd.service || true
  - /etc/docker/daemon.json || true
  - /etc/containerd/config.toml || true
  - /etc/systemd/system/container.keepalived.service || true
  - /etc/systemd/system/container.haproxy.service || true
  - /etc/systemd/system/docker.keepalived.service || true
  - /etc/systemd/system/docker.haproxy.service || true
nodeSSHKey: ~/.ssh/id_rsa # path to your ssh key file to each nodes

Criar um snapshot para instalação/upgrade travados do cluster de administrador

Ao instalar clusters de administrador/híbridos/independentes, se o bmctl estiver travado na seguinte saída

  • Como aguardar o preparo do cluster kubeconfig
  • Como aguardar a preparação do cluster
  • Aguardar a conclusão dos pools de nós

ou ao fazer upgrade de clusters de administrador/híbridos/independentes,

  • Aguardando a conclusão do upgrade

Execute o comando a seguir para capturar um snapshot usando o cluster de inicialização.

bmctl check cluster --snapshot --kubeconfig <var>WORKSPACE_DIR</var>/.kindkubeconfig --cluster <var>CLUSTER_NAME</var>

Como redefinir clusters com bmctl reset cluster

Quando a instalação de um cluster falha, é possível retornar os nós para um estado limpo ao redefini-los. Em seguida, reinstale o cluster depois de fazer alterações de configuração.

Como redefinir clusters autogerenciados

Para redefinir um cluster que se gerencia, como um cluster de administrador, emita o seguinte comando:

bmctl reset --cluster CLUSTER_NAME

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

Como redefinir clusters de usuário

Para redefinir um cluster de usuário, emita o seguinte comando:

bmctl reset --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

Substitua CLUSTER_NAME pelo nome do cluster de usuário que você está redefinindo e substitua ADMIN_KUBECONFIG_PATH pelo caminho para o arquivo kubeconfig do cluster de administrador associado. bmctl suporta o uso de --kubeconfig como um alias para a sinalização --admin-kubeconfig.

Redefinir detalhes do cluster

Independentemente do tipo de cluster, o comando de redefinição se aplica a todo o cluster. Não há opção para segmentar um subconjunto de nós em um cluster.

A saída do comando bmctl cluster reset será semelhante a esta amostra:

bmctl reset --cluster cluster1
Creating bootstrap cluster... OK
Deleting GKE Hub member admin in project my-gcp-project...
Successfully deleted GKE Hub member admin in project my-gcp-project
Loading images... OK
Starting reset jobs...
Resetting: 1    Completed: 0    Failed: 0
...
Resetting: 0    Completed: 1    Failed: 0
Flushing logs... OK

Durante a operação de redefinição, bmctl primeiro exclui o registro de associação do GKE Hub e limpa os nós afetados. Durante a redefinição, as ativações de armazenamento e os dados do anthos-system StorageClass também são excluídos.

Para todos os nós, o bmctl executa kubeadm reset, remove as interfaces de túnel usadas para a rede de cluster e exclui os seguintes diretórios:

  • /etc/kubernetes
  • /etc/cni/net.d
  • /root/.kube
  • /var/lib/kubelet

Para os nós do balanceador de carga, bmctl também executa as seguintes ações:

  • Desativa os serviços keepalived e haproxy
  • Exclui os arquivos de configuração de keepalived e haproxy.

A ferramenta de redefinição espera que o arquivo de configuração do cluster esteja no seguinte local no diretório de trabalho atual:

bmctl-workspace/cluster name/cluster name.yaml