Etapa 1: Obter o estado do nó do trabalhador

Se o seu cluster está em um estado Crítico, Exclusão com falha ou Aviso ou está preso no estado Pendente por muito tempo, revise o estado de seus nós do trabalhador.

ibmcloud oc worker ls --cluster CLUSTER_NAME_OR_ID

Etapa 2: Revisar o estado do nó do trabalhador

Revise os campos State e Status para cada nó do trabalhador em sua saída da CLI.

Para obter mais informações, consulte Estados do nó do trabalhador.

Etapa 3: Obter os detalhes para cada nó do trabalhador

Obtenha os detalhes para o nó do trabalhador. Se os detalhes incluem uma mensagem de erro, revise a lista de mensagens de erro comum para nós do trabalhador para saber como resolver o problema.

ibmcloud oc worker get --cluster CLUSTER_NAME_OR_ID --worker WORKER_NODE_ID

Etapa 4: Revisar o provedor de infraestrutura para o nó do trabalhador

Revise o ambiente de infraestrutura para verificar outros motivos que podem causar os problemas do nó do trabalhador.

1. Verifique com sua equipe de rede para garantir que nenhuma manutenção recente, como atualizações de firewall ou de sub-rede, possa afetar as conexões do nó do trabalhador.
2. Resenha IBM Cloud para Red Hat OpenShift on IBM Cloud e o provedor de infraestrutura subjacente, como Virtual Servers para componentes clássicos relacionados à VPC, ou Satellite.
3. Se você tiver acesso à infraestrutura subjacente, como Virtual Servers clássicos, revise os detalhes das máquinas correspondentes para os nós do trabalhador.

Etapa 5: Reúna os registros e outros detalhes sobre seus nós de trabalho

Executando o comando must-gather

O comando da CLI oc adm must-gather coleta as informações do cluster para depuração de problemas. A ferramenta obrigatória coleta definições de recursos, registros de serviços e muito mais. Observe que os registros de auditoria não são coletados como parte do conjunto padrão de informações para reduzir o tamanho dos arquivos.

Quando você executa oc adm must-gather, um novo pod com um nome aleatório é criado em um novo projeto no cluster. Os dados são coletados nesse pod e salvos em um novo diretório que começa com must-gather.local.

Analise os exemplos de comandos a seguir.

oc adm must-gather

Exemplo de comando para coletar dados relacionados a um ou mais recursos específicos, use o argumento --image com uma imagem específica.

oc adm must-gather \
--image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.17.5

Exemplo de comando para coletar logs de auditoria.

oc adm must-gather -- /usr/bin/gather_audit_logs

Exemplo de comando para executar o must-gather em um namespace específico.

oc adm must-gather --run-namespace NAMESPACE \
--image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.17.5

Exemplo de comandos para coletar os logs de um determinado momento.

oc adm must-gather --since=24h

oc adm must-gather --since-time=$(date -d '-24 hours' +%Y-%m-%dT%T.%9N%:z )

Exemplo de comando para coletar registros de rede.

oc adm must-gather -- gather_network_logs

Para obter mais exemplos e argumentos, execute o seguinte comando

oc adm must-gather -h

Exemplo de comando para criar um arquivo compactado a partir do diretório must-gather.

tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/

Anexe o arquivo compactado ao seu caso de suporte.

Coleta de um relatório SOS

sosreport é uma ferramenta que coleta detalhes de configuração, informações do sistema e dados de diagnóstico dos sistemas Red Hat Enterprise Linux (RHEL) e Red Hat Enterprise Linux CoreOS (RHCOS). Ele fornece uma maneira padronizada de coletar informações de diagnóstico relacionadas a um nó, que podem ser fornecidas ao suporte para o diagnóstico de problemas.

Em algumas interações de suporte, o suporte pode solicitar que você colete um arquivo sosreport para um nó OpenShift Container Platform específico. Por exemplo, pode ser necessário analisar os registros do sistema ou outros dados específicos do nó que não estão incluídos na saída do site oc adm must-gather.

O método para coletar um sosreport varia de acordo com o sistema operacional do nó de trabalho. Os nós do RHCOS utilizam o comando toolbox . Os nós RHEL 8 e RHEL 9 não oferecem suporte ao comando toolbox``; use, em vez disso, o script sosreport do Red Hat.

A maneira recomendada de gerar um sosreport para um nó de cluster OpenShift Container Platform é por meio de um pod de depuração.

Acesse o seu Red Hat OpenShift cluster.

1. Liste seus nós de trabalho para identificar o nó de destino e seu sistema operacional.

   oc get nodes -o wide
   

   Anote o nome do nó de trabalho do qual você deseja coletar o arquivo sosreport . A coluna OS-IMAGE indica se o nó executa o RHCOS ou o RHEL.

2. Inicie uma sessão de depuração no nó de destino.

   oc debug node/node_name
   

   Para entrar em uma sessão de depuração no nó de destino que está contaminado com o efeito NoExecute, adicione uma tolerância a um namespace temporário e inicie o pod de depuração no namespace temporário.

   oc new-project temp oc patch namespace temp --type=merge -p '{"metadata": {"annotations": { "scheduler.alpha.kubernetes.io/defaultTolerations": "[{\"operator\": \"Exists\"}]"}}}'
   

   oc debug node/my-cluster-node
   

3. Defina /host como o diretório raiz no shell de depuração. O pod de depuração monta o sistema de arquivos raiz do host em /host dentro do pod. Ao alterar o diretório raiz para /host, você pode executar os binários contidos nos caminhos de executáveis do host.

   chroot /host
   

   OpenShift Container Platform Os nós do cluster que executam o Red Hat Enterprise Linux CoreOS (RHCOS) são imutáveis e dependem dos Operadores para aplicar alterações no cluster. O acesso aos nós do cluster usando SSH não é recomendado. No entanto, se a API OpenShift Container Platform não estiver disponível ou se o kubelet não estiver funcionando corretamente no nó de destino, as operações oc podem ser afetadas. Em tais situações, é possível acessar os nós usando ssh core@NODE.CLUSTER_NAME.BASE_DOMAIN.

4. Recupere o arquivo sosreport utilizando o método compatível com o sistema operacional do nó de trabalho.

   • Nós do RHCOS : Use o comando toolbox .

     1. Inicie um contêiner de caixa de ferramentas, que inclui os binários e plug-ins necessários para executar o sosreport. O comando toolbox é compatível apenas com nós do RHCOS.

        toolbox
        

        Se um pod da caixa de ferramentas existente já estiver em execução, o comando da caixa de ferramentas produzirá 'toolbox-' already exists. Trying to start….. Remova o contêiner da caixa de ferramentas em execução com podman rm toolbox- e inicie um novo contêiner da caixa de ferramentas.

     2. Execute o comando sos report e siga os prompts para coletar dados de solução de problemas.

        sos report -k crio.all=on -k crio.logs=on -k podman.all=on -k podman.logs=on
        

        Exemplo de comando para incluir informações sobre configurações de rede OVN- Kubernetes de um nó em seu relatório.

        sos report --all-logs
        

        A saída do comando sosreport fornece a localização do arquivo e a soma de verificação. O exemplo de saída a seguir faz referência ao ID do caso de suporte 01234567. O caminho do arquivo está fora do ambiente chroot porque o contêiner da caixa de ferramentas monta o diretório raiz do host em /host.

        Your sosreport has been generated and saved in:
        /host/var/tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz
        The checksum is: 382ffc167510fd71b4f12a4f40b97a4e
        

   • Nós RHEL 8 e RHEL 9 : O comando toolbox não é compatível com nós RHEL. Em vez disso, use o script de coleta de relatórios SOS “ Red Hat ”.

     1. Baixe e execute o script sosreport do Red Hat seguindo as instruções contidas no artigo da base de conhecimento Red Hat.

     2. Siga as instruções do script para coletar os dados de solução de problemas. Anote o local do arquivo compactado gerado a partir da saída do script.

5. Envie o endereço sosreport para um arquivo.

   O contêiner de depuração monta o diretório raiz do host em /host. Ao especificar os arquivos de destino para concatenação, utilize o caminho absoluto a partir do diretório raiz do contêiner de depuração, incluindo /host.

   oc debug node/my-cluster-node -- bash -c 'cat /host/var/tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz' > /tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz
   

   OpenShift Container Platform Os nós do cluster que executam o Red Hat Enterprise Linux CoreOS (RHCOS) são imutáveis e dependem dos Operadores para aplicar alterações no cluster. A transferência de um arquivo sosreport de um nó de cluster usando scp não é recomendada. No entanto, se a API OpenShift Container Platform não estiver disponível ou se o kubelet não estiver funcionando corretamente no nó de destino, oc as operações podem ser afetadas. Em tais situações, é possível copiar um arquivo sosreport de um nó executando scp core@<node>.<cluster_name>.<base_domain>:<file_path> <local_path>.

6. Carregue o arquivo em seu caso de suporte.