Revise o status do IBM Cloud

1. Para ver se a IBM Cloud está disponível, verifique a página de status da IBM Cloud.
2. Filtro para o componente Kubernetes Service.
3. Revise a documentação de limitações e de problemas conhecidos.
4. Para problemas em projetos de software livre que são usados pela IBM Cloud, consulte a Política de software livre e de terceiros da IBM. Por exemplo, é possível verificar problemas abertos do Kubernetes.

Obtenha seu estado e status do cluster e revise os problemas comuns

1. Liste o cluster e localize o State dele.

   ibmcloud ks cluster ls
   

2. Revise o State do cluster. Se o cluster estiver em um estado Crítico, Falha de exclusão ou Aviso ou se estiver preso no estado Pendente há muito tempo. Para obter mais informações, consulte estados de cluster.

3. Revise o estado de cada nó do trabalhador. Para obter mais informações, consulte Estados do nó do trabalhador.

   ibmcloud ks worker ls -c CLUSTER
   

4. Analise as informações a seguir para depurar ou solucionar problemas do nó de trabalho.

   • Problemas comuns de nós de trabalho
   • Guia de depuração para problemas de nós de trabalho
   • Solução de problemas de nós de trabalho no estado Critical ou NotReady

Reunir detalhes e documentar o problema

Ao documentar os detalhes sobre o problema, seja o mais específico possível Por exemplo, Our app occasionally gets 502 Gateway errors when trying to retrieve transaction logs não é útil porque ele não é específico Certifique-se de restringir o problema o máximo possível antes de documentá-lo. Ao documentar o problema, tente incluir o seguinte.

Arquitetura do ambiente

Certifique-se de ter documentado a arquitetura do seu ambiente para entender os componentes envolvidos. Para obter mais informações, consulte Documentando sua arquitetura de ambiente..

Mensagens de erro e detalhes do componente..

Forneça a mensagem de erro completa e inclua detalhes sobre qual componente está produzindo o erro.. Por exemplo, "Todos os três pods de aplicativos em clusterID ABCDEF ocasionalmente falham nas chamadas HTTPS para GET /transaction-logs do balanceador de carga global com o erro HTTP 502 Gateway Error: Web server received an invalid response while acting as a gateway or proxy server...".

IP de origem, IP de destino, porta e protocolo da conexão

Por exemplo, " Todos os três pods de app no cluster Kubernetes com clusterID ABCDEF. Ocasionalmente, as chamadas HTTPS falham ao tentar GET /transaction-logs para o GLB com o erro O IP do pod de origem é 172.22.5.10 e o IP de destino é 150.40.40.35 porta 433. O protocolo é HTTPS. Outros pods também usam esse endereço IP como os outros dois IPs do GLB 150.40.40.55 e 150.40.40.75".

Data de início, hora e frequência do problema

Analise os exemplos de mensagens a seguir.

• Esse problema afeta aproximadamente 2% de todas as tentativas de conexão.
• Esse problema ocorre apenas entre 19:00 e 21:00 UTC, e durante esses tempos afeta aproximadamente 5% de todas as tentativas de conexão.
• Esse problema ocorre ao se conectar a partir do ID do pod XYZ. O problema começou em 10/25/2023 aproximadamente às 05:30 UTC.

Ações de resolução de problemas já executadas.

Documente o que foi experimentado até agora e os resultados dessas tentativas para ajudar a reduzir ainda mais o problema.

Executando testes para descartar ou descartar cada componente

1. Tente recriar o problema fora do fluxo completo do aplicativo... Isso pode envolver o seguinte..
   • Usando o curl em um sistema separado ou em um pod de teste em um cluster para se conectar ao terminal de back-end ou serviço para descartar que o cliente pode ser a origem do problema.
   • Tentando se conectar a um terminal conhecido como www.ibm.com do cliente ou de um pod de teste no cluster. Se o terminal conhecido funcionar de forma consistente, mas o terminal de app real não funcionar, isso ajudará a reduzir o problema.
2. Tente recriar o problema em um ambiente de teste usando um cluster de teste..
   • Se não puder recriar o problema em um cluster de teste, será possível focar nas diferenças entre o cluster de teste e o cluster real como as possíveis origens do problema.
   • Se você puder recriá-lo em um cluster de teste, provavelmente não será um problema com o próprio cluster. Além disso, você tem um ambiente no qual é possível testar para limitar ainda mais o problema sem impactar seu ambiente de produção

Reunindo mais dados

Depois de conhecer o fluxo do app, o erro específico que você está vendo, e de onde esse erro está vindo, é possível reunir dados mais detalhados dos componentes envolvidos.. Isso pode incluir os logs a seguir:

• Logs de pod e de processo nos componentes impactadas
• Logs do nó do cluster, como syslog ou /var/log/messages Para IBM Cloud Kubernetes Service, você pode obter syslog e outros registros diretamente dos nós.
  • Acesso do nó do cluster.
• Informações de rastreamento do pacote Execução tcpdump é uma maneira comum de obter informações de rastreamento de pacotes.

Entre em contato com o Slack ou revise os fóruns do usuário para problemas semelhantes

1. Poste no Kubernetes Service Slack.
   • Se você for um usuário externo, poste no canal #general.
2. Revise fóruns, como a ajuda do Kubernetes Service ou o Stack Overflow, para ver se outros usuários tiveram o mesmo problema. Ao usar os fóruns para fazer uma pergunta, identifique-a para que ela possa ser vista pelas equipes de desenvolvimento do IBM Cloud.
   • Se você tiver perguntas técnicas sobre desenvolvimento ou implementação de clusters ou apps com o IBM Cloud Kubernetes Service, poste sua pergunta no Stack Overflow e identifique-a com ibm-cloud e containers.
   • Consulte Obtendo ajuda para obter mais detalhes sobre o uso dos fóruns.

Próximas etapas

Se o problema persistir, entre em contato com o suporte. Abrir um caso de suporte. No caso de detalhes, certifique-se de incluir quaisquer arquivos de log relevantes, mensagens de erros ou saídas de comando...