Os clusters do Anthos no VMware agora são o Google Distributed Cloud (somente software) para VMware. Para mais informações, consulte a visão geral do produto.

Esta página foi traduzida pela API Cloud Translation.

Criar snapshots de diagnóstico quando o cluster avançado estiver ativado

Este documento mostra como usar o comando gkectl diagnose para criar instantâneos de diagnóstico para resolver problemas nos clusters criados usando o Google Distributed Cloud (somente software) para VMware quando o cluster avançado está ativado. O cluster avançado é ativado quando enableAdvancedClusters é definido como true no arquivo de configuração do cluster de administrador e no arquivo de configuração do cluster de usuário. Se o cluster avançado não estiver ativado, consulte Criar snapshots de diagnóstico quando o cluster avançado não estiver ativado.

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.

`gkectl diagnose snapshot`

Esse comando compacta o status, as configurações e os registros de um cluster em um arquivo tar. A configuração padrão do comando gkectl diagnose snapshot 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, Serviços, Endpoints, ConfigMaps, ReplicaSets, CronJobs, Pods e os proprietários desses pods, incluindo implantações, DaemonSets e StatefulSets
Status do plano de controle.
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 contêiner no nó do plano de controle do cluster de administrador quando o servidor da API Kubernetes não está disponível.
Registros do comando gkectl diagnose snapshot
Registros de jobs de simulação.
Registros de contêineres em namespaces com base nos cenários.

As credenciais, inclusive do vSphere e F5, são removidas antes que o arquivo .tar seja criado.

Capturar o estado do cluster de administrador

Para capturar o estado de um cluster de administrador, execute o seguinte comando:

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG

Substitua ADMIN_CLUSTER_KUBECONFIG pelo caminho para o arquivo kubeconfig do cluster de administrador.

A saída inclui uma lista de arquivos e o nome de um arquivo .tar, conforme mostrado neste exemplo de saída:

Using "system" snapshot configuration...
Creating ssh signer for "[ADMIN_CLUSTER_NAME]"...
Taking snapshots in 10 thread(s)...
    gkectlLogs/gkectl-xxx.log
...
    kubectlCommands/[NAMESPACE]/kubectl_get_pods
    kubectlCommands/[NAMESPACE]/kubectl_get_deployments
    kubectlCommands/[NAMESPACE]/kubectl_get_daemonsets
...
    nodes/[ADMIN_CLUSTER_NODE]/commands/journalctl_-u_kubelet
    nodes/[ADMIN_CLUSTER_NODE]/files/var/log/startup.log
...
Snapshot succeeded. Output saved in [FILENAME].tar.gz.

Para extrair o arquivo tar para um diretório, execute o seguinte comando:

tar -zxf TAR_FILE_NAME --directory EXTRACTION_DIRECTORY_NAME

Substitua:

TAR_FILE_NAME: o nome do arquivo .tar.
EXTRACTION_DIRECTORY_NAME: o diretório em que você quer extrair o arquivo .tar.

Para ver a lista de arquivos produzidos pelo snapshot, execute os seguintes comandos:

cd EXTRACTION_DIRECTORY_NAME/EXTRACTED_SNAPSHOT_DIRECTORY
ls kubectlCommands
ls nodes/NODE_NAME/commands
ls nodes/NODE_NAME/files

Substitua NODE_NAME pelo nome do nó que você quer visualizar os arquivos.

Para ver os detalhes de uma operação específica, abra um dos arquivos.

Especificar a chave SSH para o cluster de administrador

Quando você recebe um snapshot do cluster de administrador, o gkectl encontra a chave SSH privada do cluster de administrador automaticamente. Também é possível especificar a chave explicitamente usando o parâmetro --admin-ssh-key-path.

Siga as instruções sobre Como usar o SSH para se conectar a um nó de cluster para fazer o download das chaves SSH.

No comando gkectl diagnose snapshot, defina --admin-ssh-key-path como seu caminho de chave decodificado:

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --admin-ssh-key-path=PATH_TO_DECODED_KEY

Capturar o estado do cluster de usuário

Para capturar o estado de um cluster de usuário, execute o seguinte comando:

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME

O exemplo de saída a seguir inclui uma lista de arquivos e o nome de um arquivo .tar.:

Using "system" snapshot configuration...
Creating ssh signer for "[USER_CLUSTER_NAME]"...
Taking snapshots in 10 thread(s)...
    gkectlLogs/gkectl-xxx.log
...
    kubectlCommands/[NAMESPACE]/kubectl_get_pods
    kubectlCommands/[NAMESPACE]/kubectl_get_deployments
    kubectlCommands/[NAMESPACE]/kubectl_get_daemonsets
...
    nodes/[USER_CLUSTER_NODE_IP_ADDRESS]/commands/journalctl_-u_kubelet
    nodes/[USER_CLUSTER_NODE_IP_ADDRESS]/files/var/log/startup.logn
...
Snapshot succeeded. Output saved in [FILENAME].tar.gz.

Cenários de snapshots

Os cenários de snapshot permitem controlar as informações incluídas em um snapshot. Para especificar um cenário, utilize a sinalização --scenario. A lista a seguir mostra os valores possíveis:

system (padrão): coletar snapshots com registros em namespaces do sistema compatíveis.
all: coletar snapshots com registros em todos os namespaces, incluindo aqueles definidos pelo usuário.

Para criar um snapshot do cluster de administrador, não é preciso especificar um cenário:

gkectl diagnose snapshot \
    --kubeconfig=ADMIN_CLUSTER_KUBECONFIG

Para criar um snapshot de um cluster de usuário usando o cenário system:

gkectl diagnose snapshot \
    --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME \
    --scenario=system

Para criar um snapshot de um cluster de usuário usando o cenário all:

gkectl diagnose snapshot \
    --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME \
    --scenario=all

Usar `--log-since` para limitar um snapshot

É possível usar a sinalização --log-since para limitar a coleta de registros a um período recente. Por exemplo, é possível coletar apenas os registros dos últimos dois dias ou das últimas três horas. Por padrão, diagnose snapshot coleta todos os registros.

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=CLUSTER_NAME \
    --scenario=system \
    --log-since=DURATION

Substitua <var>DURATION</var> por um valor de tempo como 120m ou 48h.

As seguintes considerações se aplicam:

A sinalização --log-since é compatível apenas com os registros kubectl e journalctl.
Sinalizações de comando como --log-since não são permitidas na configuração do snapshot personalizado.

Executar uma simulação para um snapshot

É possível usar a sinalização --dry-run para mostrar as ações a serem realizadas e a configuração do snapshot.

Para executar uma simulação no cluster de administrador, insira o seguinte comando:

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=ADMIN_CLUSTER_NAME \
    --dry-run

Para executar uma simulação em um cluster de usuário, insira o seguinte comando:

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME \
    --dry-run

Usar uma configuração de snapshot

Se esses dois cenários (--scenario system ou all) não atenderem às suas necessidades, crie um snapshot personalizado transmitindo um arquivo de configuração de snapshot usando a sinalização --snapshot-config:

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME \
    --snapshot-config=SNAPSHOT_CONFIG_FILE

Gerar uma configuração de snapshot

É possível gerar uma configuração de snapshot para um determinado cenário transmitindo as sinalizações --scenario e --dry-run. Por exemplo, para ver a configuração de snapshot do cenário padrão (system) de um cluster de usuário, digite o seguinte comando:

gkectl diagnose snapshot \
    --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME \
    --scenario=system
    --dry-run

A resposta será semelhante a:

The snapshot configuration is:
numOfParallelThreads: 10
excludeWords:
- password
kubectlCommands:
- commands:
  - kubectl version
  - kubectl cluster-info
  - kubectl top node
  - kubectl top pod -A --containers
  namespaces: []
- commands:
  - kubectl get -o wide --ignore-not-found
  - kubectl get -o yaml --ignore-not-found
  - kubectl describe
  namespaces:
  - kube-system
...
  expandResources: true
- commands:
  - kubectl logs
  namespaces:
  - kube-system
...
kindNodeCommands: []
nodeCommands:
- nodes: []
  commands:
  - uptime
  - df --all --inodes
  - ip addr
  - ip neigh
  - iptables-save --counters
  - mount
  - ip route list table all
  - top -bn1 || true
  - docker info || true
...
- nodes: []
  commands:
  - dmesg
  - systemctl status -l kubelet
  - journalctl --utc -u kubelet
  - journalctl --utc -u kubelet-monitor.service
...
nodeFiles:
- nodes: []
  files:
  - /proc/sys/fs/file-nr
  - /proc/sys/net/netfilter/nf_conntrack_max
...
- nodes: []
  files:
  - /var/log/apiserver/audit-proxy-buffer/* || true

As seguintes informações são exibidas na saída:

numOfParallelThreads: número de linhas de execução paralelas usadas para tirar snapshots.
excludeWords: lista de palavras a serem excluídas do snapshot (não diferencia maiúsculas de minúsculas). As linhas que contêm essas palavras são removidas dos resultados do snapshot. A "senha" é sempre excluída, independentemente de você especificá-la ou não.
kubectlCommands: lista de comandos kubectl a serem executados. Os resultados são salvos. Os comandos são executados nos namespaces correspondentes. Para comandos kubectl logs, todos os pods e contêineres nos namespaces correspondentes são adicionados automaticamente. As expressões regulares são compatíveis com a especificação de namespaces. Se você não especificar um namespace, default será usado.
nodeCommands: lista de comandos a serem executados nos nós correspondentes. Os resultados são salvos. Quando os nós não são especificados, todos os nós no cluster de destino são considerados.
nodeFiles: lista de arquivos a serem coletados dos nós correspondentes. Os arquivos são salvos. Quando os nós não são especificados, todos os nós no cluster de destino são considerados.

A seguir