Criar snapshots para ajudar a diagnosticar problemas de cluster

Se você tiver um problema com um dos clusters, poderá receber ajuda do Cloud Customer Care O Customer Care pode solicitar que você faça um "snapshot" do cluster, que pode usar para diagnosticar o problema. Um snapshot captura arquivos de configuração de cluster e de nó, além de empacotar essas informações em um único arquivo .tar.

Neste documento, você verá como criar snapshots padrão ou mais personalizados de um cluster. Você também explica como criar snapshots quando um cluster está passando por erros específicos.

Instantâneos padrão

As seções a seguir descrevem o que está em um snapshot padrão e como criar um. Para informações sobre snapshots personalizados, consulte a seção Snapshots personalizados.

Quais informações contêm um snapshot padrão?

O snapshot de um cluster é um arquivo .tar de arquivos de configuração e registros sobre o cluster. Especificamente, a configuração padrão do comando captura as seguintes informações sobre o cluster:

  • Versão do Kubernetes

  • Status dos recursos do Kubernetes nos namespaces kube-system e gke-system: cluster, machine, nós, Services, Endpoints, ConfigMaps, replicaSets, CronJobs, Pods e os proprietários desses pods, incluindo implantações, DaemonSets e StatefulSets

  • Detalhes sobre cada configuração de nó, incluindo endereços IP, regras de iptables, pontos de montagem, sistemas de arquivos, conexões de rede e processos em execução

  • Registros do comando bmctl check cluster --snapshot

As informações de credencial de um cluster não estão incluídas no snapshot padrão. Se o Cloud Customer Care solicitar essas informações, consulte Como recuperar informações de cluster.

Para uma lista abrangente de informações coletadas ao executar o comando de snapshot, consulte o arquivo de configuração mostrado na seção Detalhes do arquivo de configuração. Este arquivo de configuração mostra quais comandos são executados ao capturar um snapshot padrão.

Como criar um snapshot padrão

O comando bmctl check cluster tira um snapshot de um cluster. É possível usar este comando para executar uma das seguintes ações: * criar um snapshot e fazer o upload automático desse snapshot para um bucket do Cloud Storage * criar um snapshot de um cluster e salvar o snapshot na máquina local em que você está executando o comando.

Método 1: crie um snapshot padrão e faça o upload automático para o bucket do Cloud Storage

Para criar e fazer upload de um snapshot em um bucket do Cloud Storage, faça o seguinte:

  1. Configure a API e a conta de serviço:

    1. Ative a API Cloud Storage no projeto do Google Cloud.
    2. Conceda um papel storage.admin à conta de serviço para que ela possa fazer upload de dados no Cloud Storage.
    3. Faça o download da chave JSON da conta de serviço.

    Consulte os detalhes em Como ativar contas de serviço e serviços do Google.

  2. Execute o comando bmctl a seguir para criar e fazer o upload automático de um snapshot para um bucket do Cloud Storage: 

    bmctl check cluster --snapshot --cluster=CLUSTER_NAME
--kubeconfig=KUBECONFIG_PATH
--upload-to BUCKET_NAME
[--service-account-key-file SERVICE_ACCOUNT_KEY_FILE]

    No comando, substitua as seguintes entradas por informações específicas ao ambiente do cluster:

    • CLUSTER_NAME: o nome do cluster de que você quer gerar um snapshot.
    • KUBECONFIG_PATH especifica o caminho até o arquivo kubeconfig do cluster de administrador; O caminho para o arquivo kubeconfig geralmente é bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig. No entanto, se você tiver especificado seu espaço de trabalho com a sinalização WORKSPACE_DIR, o caminho será WORKSPACE_DIR/CLUSTER_NAME/CLUSTER_NAME-kubeconfig.
    • BUCKET_NAME: o nome de um bucket do Cloud Storage que é seu.
    • SERVICE_ACCOUNT_KEY_FILE_PATH: se você não fornecer a sinalização --service-account-key-file, bmctl tentará buscar o caminho para o arquivo de chave da conta de serviço da variável de ambiente GOOGLE_APPLICATION_CREDENTIALS de dados.

  3. Conceda ao Cloud Customer Care acesso de leitura ao bucket que contém o snapshot:

    gsutil iam ch \
serviceAccount:service-PROJECT_ID@anthos-support.iam.gserviceaccount.com:roles/storage.objectViewer \
gs://BUCKET_NAME

Método 2: criar um snapshot padrão na máquina local

É possível capturar o estado dos clusters criados com o comando:

bmctl check cluster --snapshot --cluster=CLUSTER_NAME \
    --kubeconfig=KUBECONFIG_PATH

Substitua:

  • CLUSTER_NAME: o nome do cluster de destino.

  • KUBECONFIG_PATH especifica o caminho até o arquivo kubeconfig do cluster de administrador; O caminho para o arquivo kubeconfig geralmente é bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig. No entanto, se você tiver especificado seu espaço de trabalho com a sinalização WORKSPACE_DIR, o caminho será WORKSPACE_DIR/CLUSTER_NAME/CLUSTER_NAME-kubeconfig.

Esse comando gera um arquivo .tar na máquina local. O nome desse arquivo .tar está no formato snapshot-CLUSTER_NAME-TIMESTAMP.tar.gz, em que TIMESTAMP indica a data e a hora em que o arquivo foi criado. Esse arquivo .tar inclui informações de depuração relevantes sobre os componentes e máquinas do sistema de um cluster.

Quando você executa esse comando, as informações são coletadas sobre pods dos seguintes namespaces: gke-system ,gke-connect ,capi-system ,capi-webhook-system ,cert-manager ecapi-kubeadm-bootstrap-system

No entanto, é possível ampliar o escopo das informações de diagnóstico coletadas usando a sinalização --snapshot-scenario all. Essa sinalização aumenta o escopo do snapshot de diagnóstico para incluir todos os pods em um cluster:

bmctl check cluster --snapshot --snapshot-scenario all \
--cluster=CLUSTER_NAME \
--kubeconfig=KUBECONFIG_PATH

Instantâneos personalizados

É possível criar um snapshot personalizado de um cluster pelos seguintes motivos:

Como criar um snapshot personalizado

A criação de um instantâneo personalizado exige o uso de um arquivo de configuração de instantâneo. As etapas a seguir explicam como criar o arquivo de configuração, modificá-lo e usá-lo para criar um snapshot personalizado de um cluster:

  1. Crie um arquivo de configuração de snapshot executando o seguinte comando no cluster e gravando a saída em um arquivo:

     bmctl check cluster
--snapshot --snapshot-dry-run --cluster CLUSTER_NAME
--kubeconfig KUBECONFIG_PATH

  2. Defina o tipo de informação que você quer que apareça no snapshot personalizado. Para fazer isso, modifique o arquivo de configuração de snapshot que você criou na etapa 1. Por exemplo, se você quiser que o snapshot contenha informações adicionais, como o tempo de execução de um nó específico, adicione o comando Linux uptime à seção relevante do arquivo de configuração. O snippet a seguir de um arquivo de configuração mostra como fazer o comando do snapshot fornecer informações uptime sobre o nó 10.200.0.3. Essas informações não aparecem em um snapshot padrão.

    ...
nodeCommands:
- nodes:
  - 10.200.0.3
  commands:
  - uptime
...

  3. Depois de modificar o arquivo de configuração para definir que tipo de snapshot você quer, crie o snapshot personalizado executando o seguinte comando:

     bmctl check cluster
--snapshot --snapshot-config SNAPSHOT_CONFIG_FILE --cluster
CLUSTER_NAME --kubeconfig KUBECONFIG_PATH

    A sinalização --snapshot-config direciona o comando bmctl para usar o conteúdo do arquivo de configuração de snapshot para definir quais informações aparecem no snapshot.

O arquivo de configuração em detalhes

O exemplo de arquivo de configuração de snapshot a seguir mostra os comandos e arquivos padrão usados para criar um snapshot, mas é possível adicionar mais comandos e arquivos quando mais informações de diagnóstico forem necessárias:

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

As seguintes entradas no arquivo de configuração provavelmente são diferentes das que aparecem no arquivo de configuração de amostra acima:

  • Os endereços IP dos nós nas seções nodeCommands e nodeFiles
  • O caminho para o nodeSSHKey do cluster

Campos no arquivo de configuração

Um arquivo de configuração de snapshot está no formato YAML. O arquivo de configuração inclui os seguintes campos:

  • 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 arquivo de configuração de amostra anterior. 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 dos nós de cluster em que 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. Quando o cluster de administrador está inacessível, esse campo é obrigatório.

Como criar snapshots ao enfrentar erros específicos

Como criar um snapshot padrão durante instalações ou upgrades interrompidos

Ao instalar ou fazer upgrade de clusters de administrador, híbridos ou independentes, o bmctl às vezes pode ser interrompido em pontos em que os seguintes resultados podem ser vistos:

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

Se você tiver uma instalação ou um upgrade interrompido, ainda assim poderá tirar um snapshot de um cluster usando o cluster de inicialização. Para isso, execute o seguinte comando:

bmctl check cluster --snapshot --cluster=CLUSTER_NAME \
    --kubeconfig=WORKSPACE_DIR/.kindkubeconfig

Como criar um snapshot personalizado durante instalações ou upgrades interrompidos

As etapas a seguir mostram como criar um snapshot personalizado de um cluster quando uma instalação ou upgrade é interrompido:

  1. Recupere dos seus arquivos um arquivo de configuração de snapshot do cluster.

  2. Modifique o arquivo de configuração de snapshot para que ele contenha as informações que você quer.

  3. Crie o snapshot personalizado executando o seguinte comando:

    bmctl check cluster --snapshot
--snapshot-config=SNAPSHOT_CONFIG_FILE
--cluster=CLUSTER_NAME
--kubeconfig=WORKSPACE_DIR/.kindkubeconfig

Como criar um snapshot personalizado quando o cluster de administrador está inacessível

Se o cluster gerar um erro informando que o cluster de administrador está inacessível, não será possível capturar um snapshot padrão de um cluster. Isso ocorre porque o comando bmctl padrão tenta, entre outras coisas, recuperar informações do cluster de administrador. Quando o comando padrão tenta recuperar informações de um cluster de administrador inacessível, o comando do snapshot falha.

Portanto, quando o cluster de administrador está inacessível, você precisa capturar um snapshot personalizado do cluster, em vez de um snapshot padrão. Dessa forma, é possível criar um snapshot personalizado que não solicite informações de um cluster de administrador com defeito.

As etapas a seguir mostram como criar um snapshot personalizado de um cluster quando o cluster de administrador está inacessível:

  1. Recupere dos seus arquivos um arquivo de configuração de snapshot do cluster.

  2. Na seção de nós, liste os endereços IP dos nós para os quais você quer informações, mas exclua o endereço IP do nó do cluster de administrador.

  3. Crie o snapshot personalizado executando o seguinte comando: 

    bmctl check cluster
--snapshot --snapshot-config=SNAPSHOT_CONFIG_FILE
--cluster=CLUSTER_NAME
--kubeconfig=KUBECONFIG_PATH

Coletar registros de problemas de entrada ou do Anthos Service Mesh

Os snapshots bmctl não contêm informações para solucionar problemas de entrada ou do Anthos Service Mesh. Para instruções sobre como coletar os registros de diagnóstico relevantes, consulte Como coletar registros do Anthos Service Mesh na documentação do Anthos Service Mesh.