Resolver problemas de observabilidade do GDCV em bare metal

Este documento ajuda a resolver problemas de observabilidade no Google Distributed Cloud Virtual for Bare Metal. Se você tiver algum desses problemas, analise as sugestões de correções e soluções alternativas.

Se precisar de mais ajuda, entre em contato com o Suporte do Google.

Os registros de auditoria do Cloud não são coletados

Os registros de auditoria do Cloud são ativados por padrão, a menos que haja uma sinalização disableCloudAuditLogging definida na seção clusterOperations da configuração do cluster.

Se os registros de auditoria do Cloud estiverem ativados, as permissões serão o motivo mais comum de não serem coletados. Nesse cenário, as mensagens de erro de permissão negada são exibidas no contêiner do proxy de registros de auditoria do Cloud.

O contêiner de proxy dos Registros de auditoria do Cloud é executado como um DaemonSet em todos os clusters do Google Distributed Cloud Virtual para Bare Metal.

Se você encontrar erros de permissão, siga as etapas para resolver problemas de permissão.

Métricas kube-state-metrics não são coletadas

O kube-state-metrics (KSM) é executado como uma única implantação de réplica no cluster e gera métricas em quase todos os recursos no cluster. Quando o KSM e o gke-metrics-agent são executados no mesmo nó, há um risco maior de interrupção entre os agentes de métricas em todos os nós.

As métricas do KSM têm nomes que seguem o padrão de kube_<ResourceKind>, como kube_pod_container_info. As métricas que começam com kube_onpremusercluster_ são do controlador de cluster local, não do KSM.

Se as métricas do KSM estiverem ausentes, revise as seguintes etapas de solução de problemas:

  • No Cloud Monitoring, verifique a contagem de CPU, memória e reinicialização do KSM usando as métricas da API de resumo, como kubernetes.io/anthos/container/.... Esse é um pipeline separado com o KSM. Confirme se o pod KSM não está limitado por recursos insuficientes.
    • Se essas métricas de API de resumo não estiverem disponíveis para KSM, gke-metrics-agent no mesmo nó provavelmente também terá o mesmo problema.
  • No cluster, verifique o status e os registros do pod KSM e o pod gke-metrics-agent no mesmo nó com o KSM.

Repetição de falhas de kube-state-metrics

Sintoma

Nenhuma métrica de kube-state-metrics (KSM) está disponível no Cloud Monitoring.

Causa

É mais provável que esse cenário ocorra em clusters grandes ou clusters com grandes quantidades de recursos. O KSM é executado como uma única implantação de réplica e lista quase todos os recursos no cluster, como pods, implantações, DaemonSets, ConfigMaps, Secrets e PersistentVolumes. As métricas são geradas em cada um desses objetos de recurso. Se algum dos recursos tiver muitos objetos, como um cluster com mais de 10.000 pods, o KSM poderá ficar sem memória.

Versões afetadas

Esse problema pode ocorrer em qualquer versão do Google Distributed Cloud Virtual para Bare Metal.

O limite padrão de CPU e memória aumentou nas últimas versões do Google Distributed Cloud Virtual para Bare Metal. Portanto, esses problemas de recursos são menos comuns.

Correção e solução alternativa

Para verificar se o problema é causado por problemas de memória, consulte as seguintes etapas:

  • Use kubectl describe pod ou kubectl get pod -o yaml e verifique a mensagem de status de erro.
  • Verifique a métrica de consumo e utilização de memória para KSM e confirme se ela está atingindo o limite antes de ser reiniciada.

Se você confirmar que há problemas de falta de memória, use uma das soluções abaixo:

  • Aumentar a solicitação de memória e o limite para KSM.

    Para ajustar a CPU e a memória do KSM, use o resourceOverride do recurso personalizado do Stackdriver para kube-state-metrics.

  • Reduza o número de métricas do KSM.

    No Google Distributed Cloud Virtual for Bare Metal 1.13, o KSM expõe apenas um número menor de métricas, chamadas de métricas principais, por padrão. Esse comportamento significa que o uso de recursos é menor que as versões anteriores, mas o mesmo procedimento pode ser seguido para reduzir ainda mais o número de métricas do KSM.

    Para as versões do Google Distributed Cloud Virtual para Bare Metal anteriores à 1.13, o KSM usa as sinalizações padrão. Essa configuração expõe um grande número de métricas.

Repetição de falhas de gke-metrics-agent

Se gke-metrics-agent só tiver problemas de falta de memória no nó em que kube-state-metrics existe, a causa é um grande número de métricas kube-state-metrics. Para atenuar esse problema, reduza stackdriver-operator e modifique o KSM para expor um pequeno conjunto de métricas necessárias, conforme detalhado na seção anterior. Lembre-se de escalonar o stackdriver-operator novamente após o upgrade do cluster para o Google Distributed Cloud Virtual for Bare Metal 1.13, em que o KSM, por padrão, expõe um número menor de métricas principais.

Para problemas que não estão relacionados a eventos de falta de memória, verifique os registros de pods de gke-metric-agent. É possível ajustar a CPU e a memória de todos os pods gke-metrics-agent adicionando o campo resourceAttrOverride ao recurso personalizado do Stackdriver.

Repetição de falhas de stackdriver-metadata-agent

Sintoma

Nenhum rótulo de metadados do sistema está disponível ao filtrar métricas no Cloud Monitoring.

Causa

O caso mais comum de repetição de falha stackdriver-metadata-agent é devido a eventos de memória insuficiente. Este evento é semelhante a kube-state-metrics. Embora stackdriver-metadata-agent não esteja listando todos os recursos, ele ainda lista todos os objetos dos tipos de recursos relevantes, como pods, implantações e NetworkPolicy. O agente é executado como uma única implantação de réplica, o que aumenta o risco de eventos de memória insuficiente se o número de objetos for muito grande.

Versão afetada

Esse problema pode ocorrer em qualquer versão do Google Distributed Cloud Virtual para Bare Metal.

O limite padrão de CPU e memória foi aumentado nas últimas versões do Google Distributed Cloud Virtual para Bare Metal. Portanto, esses problemas de recursos são menos comuns.

Correção e solução alternativa

Para verificar se o problema é causado por problemas de memória, consulte as seguintes etapas:

  • Use kubectl describe pod ou kubectl get pod -o yaml e verifique a mensagem de status do erro.
  • Verifique a métrica de consumo e utilização de memória para stackdriver-metadata-agent e confirme se ela está atingindo o limite antes de ser reiniciada.
Se você confirmar que problemas de falta de memória estão criando obstáculos, aumente o limite de memória no campo resourceAttrOverride do recurso personalizado do Stackdriver.

Repetição de falhas de metrics-server

Sintoma

O escalonador automático horizontal de pods e o kubectl top não funcionam no cluster.

Causa e versões afetadas

Esse problema não é muito comum, mas é causado por erros de falta de memória em clusters grandes ou em clusters com alta densidade de pods.

Esse problema pode ocorrer em qualquer versão do Google Distributed Cloud Virtual para Bare Metal.

Correção e solução alternativa

Aumentar os limites de recursos do servidor de métricas. No Google Distributed Cloud Virtual for Bare Metal versão 1.13 e mais recentes, o namespace de metrics-server e a configuração dele foram movidos de kube-system para gke-managed-metrics-server.

No Google Distributed Cloud Virtual for Bare Metal, a edição da configuração do assistente seria revertida em um evento de atualização ou upgrade do cluster. Você precisará reaplicar as alterações de configuração. Para contornar essa limitação, reduza a escala vertical de metrics-server-operator e mude manualmente o pod metrics-server.

A seguir

Se precisar de mais ajuda, entre em contato com o Suporte do Google.