Realize análises do histórico com o Cloud Logging

Quando um pod falha ou um serviço não funciona como esperado no Google Kubernetes Engine (GKE), é fundamental compreender a sequência de eventos que originaram o problema. A inspeção do estado atual nem sempre é suficiente para encontrar a causa principal, o que torna os dados do histórico de registos inestimáveis.

Use esta página para saber como usar o Cloud Logging para investigar falhas anteriores (por exemplo, por que motivo um pod não foi iniciado ou quem eliminou uma implementação crítica) consultando e analisando os registos do GKE.

Estas informações são importantes para os administradores e os operadores da plataforma que precisam de realizar uma análise da causa principal em problemas ao nível do cluster, auditar alterações e compreender as tendências de comportamento do sistema. Também é essencial para os programadores de aplicações depurarem erros específicos da aplicação, rastrearem caminhos de pedidos e compreenderem o comportamento do respetivo código no ambiente do GKE ao longo do tempo. Para mais informações sobre as funções comuns e exemplos de tarefas que referimos no conteúdo, consulte o artigo Funções e tarefas comuns do utilizador do GKE. Google Cloud

Compreenda os principais tipos de registos para a resolução de problemas

Para ajudar a resolver problemas, o Cloud Logging recolhe e agrega automaticamente vários tipos de registos importantes dos seus clusters do GKE, apps contentorizadas e outrosGoogle Cloud serviços:

  • Registos de nós e de tempo de execução (kubelet, containerd): os registos dos serviços de nós subjacentes. Uma vez que o kubelet gere o ciclo de vida de todos os Pods no nó, os respetivos registos são essenciais para resolver problemas como inícios de contentores, eventos de falta de memória (OOM), falhas de sondagem e erros de montagem de volumes. Estes registos também são essenciais para diagnosticar problemas ao nível do nó, como um nó com o estado NotReady.

    Uma vez que o containerd gere o ciclo de vida dos seus contentores, incluindo a obtenção de imagens, os respetivos registos são cruciais para resolver problemas que ocorrem antes de o kubelet poder iniciar o contentor. Os registos do containerd ajudam a diagnosticar problemas ao nível do nó no GKE, porque documentam as atividades específicas e os potenciais erros do tempo de execução do contentor.

  • Registos da app (stdout, stderr): os fluxos de saída e de erros padrão dos processos em contentores. Estes registos são essenciais para a depuração de problemas específicos da app, como falhas de sistema, erros ou comportamento inesperado.

  • Registos de auditoria: estes registos respondem à pergunta "quem fez o quê, onde e quando?" para o seu cluster. Monitorizam as ações administrativas e as chamadas API feitas ao servidor da API Kubernetes, o que é útil para diagnosticar problemas causados por alterações de configuração ou acesso não autorizado.

Cenários de resolução de problemas comuns

Depois de identificar um problema, pode consultar estes registos para saber o que aconteceu. Para ajudar a começar, a revisão dos registos pode ajudar a resolver os seguintes problemas:

  • Se um nó tiver um estado NotReady, reveja os respetivos registos de nós. Os registos kubelet e containerd revelam frequentemente a causa subjacente, como problemas de rede ou restrições de recursos.
  • Se um novo nó não conseguir o aprovisionamento nem juntar-se ao cluster, reveja os registos da porta série do nó. Estes registos captam a atividade de arranque inicial e de início do kubelet antes de os agentes de registo do nó estarem totalmente ativos.
  • Se um Pod não tiver sido iniciado no passado, reveja os registos da app desse Pod para verificar se existem falhas. Se os registos estiverem vazios ou não for possível agendar o Pod, verifique os registos de auditoria para ver eventos relevantes ou os registos do nó no nó de destino para encontrar pistas sobre a pressão dos recursos ou erros de obtenção de imagens.
  • Se uma implementação crítica foi eliminada e ninguém sabe porquê, consulte os registos de auditoria da atividade de administrador. Estes registos podem ajudar a identificar que utilizador ou conta de serviço emitiu a chamada da API de eliminação, o que oferece um ponto de partida claro para a sua investigação.

Como aceder aos registos

Use o Explorador de registos para consultar, ver e analisar registos do GKE na Google Cloud consola. O Explorador de registos oferece opções de filtragem avançadas que ajudam a isolar o seu problema.

Para aceder e usar o Logs Explorer, conclua os seguintes passos:

  1. Na Google Cloud consola, aceda à página Explorador de registos.

    Aceda ao Explorador de registos

  2. No painel de consultas, introduza uma consulta. Use a linguagem de consulta de registo para escrever consultas segmentadas. Seguem-se alguns filtros comuns para começar:

    Tipo de filtro Descrição Valor de exemplo
    resource.type O tipo de recurso do Kubernetes. k8s_cluster, k8s_node, k8s_pod, k8s_container
    log_id A stream de registos do recurso. stdout, stderr
    resource.labels.RESOURCE_TYPE.name Filtre recursos com um nome específico.
    Substitua RESOURCE_TYPE pelo nome do recurso que quer consultar. Por exemplo, namespace ou pod.    		 example-namespace-name, example-pod-name
    severity O nível de gravidade do registo. DEFAULT, INFO, WARNING, ERROR e CRITICAL
    jsonPayload.message=~ Uma pesquisa de expressão regular para texto na mensagem de registo. scale.down.error.failed.to.delete.node.min.size.reached

    Por exemplo, para resolver problemas de um Pod específico, pode querer isolar os respetivos registos de erros. Para ver apenas registos com uma gravidade ERROR para esse pod, use a seguinte consulta:

    resource.type="k8s_container"
resource.labels.pod_name="POD_NAME"
resource.labels.namespace_name="NAMESPACE_NAME"
severity=ERROR

    Substitua o seguinte:

    • POD_NAME: o nome do agrupamento que está a ter problemas.
    • NAMESPACE_NAME: o espaço de nomes em que o pod se encontra. Se não tiver a certeza do que é o espaço de nomes, reveja a coluna Namespace a partir do resultado do comando kubectl get pods.

    Para ver mais exemplos, consulte o artigo Consultas relacionadas com o Kubernetes na documentação do Google Cloud Observability.

  3. Clique em Executar consulta.

  4. Para ver a mensagem de registo completa, incluindo o payload JSON, os metadados e a data/hora, clique na entrada de registo.

Para mais informações sobre os registos do GKE, consulte o artigo Acerca dos registos do GKE.

O que se segue?