Resolva problemas de observabilidade do Google Distributed Cloud

Este documento ajuda a resolver problemas de observabilidade no Google Distributed Cloud. Se tiver algum destes problemas, reveja as correções e as soluções alternativas sugeridas.

Se precisar de assistência adicional, contacte o apoio ao cliente do Google Cloud. Também pode consultar o artigo Receber apoio técnico para mais informações sobre recursos de apoio técnico, incluindo o seguinte:

  • Requisitos para abrir um registo de apoio ao cliente.
  • Ferramentas para ajudar a resolver problemas, como a configuração do ambiente, os registos e as métricas.
  • Componentes suportados.

Os registos de auditoria do Google Cloud não são recolhidos

Os registos de auditoria do Google Cloud estão ativados por predefinição, a menos que exista uma flag disableCloudAuditLogging definida na secção clusterOperations da configuração do cluster.

Se os registos de auditoria da nuvem estiverem ativados, as autorizações são o motivo mais comum para os registos não serem recolhidos. Neste cenário, as mensagens de erro de autorização recusada são apresentadas no contentor do proxy dos registos de auditoria do Cloud.

O contentor proxy dos registos de auditoria do Google Cloud é executado como um DaemonSet em todos os clusters do Google Distributed Cloud.

Se vir erros de autorização, siga os passos para resolver problemas de autorização.

Outra causa possível é o seu projeto ter atingido o limite de contas de serviço suportado. Consulte o artigo Conta de serviço dos registos de auditoria da nuvem divulgada.

kube-state-metrics métricas não são recolhidas

kube-state-metrics (KSM) é executado como uma implementação de réplica única 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ó, existe um maior risco de indisponibilidade entre os agentes de métricas em todos os nós.

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

Se as métricas de KSM estiverem em falta, reveja os seguintes passos de resolução de problemas:

  • No Cloud Monitoring, verifique a CPU, a memória e a contagem de reinícios do KSM através das métricas da API de resumo, como kubernetes.io/anthos/container/... . Esta é uma pipeline separada com o KSM. Confirme que o KSM Pod não está limitado por não ter recursos suficientes.
    • Se estas métricas da API de resumo não estiverem disponíveis para o KSM, gke-metrics-agent no mesmo nó, provavelmente, também tem o mesmo problema.
  • No cluster, verifique o estado e os registos do pod KSM e do pod gke-metrics-agent no mesmo nó com o KSM.

kube-state-metrics loop de falhas

Sintoma

Não estão disponíveis métricas de kube-state-metrics (KSM) no Cloud Monitoring.

Causa

Este cenário é mais provável em clusters grandes ou clusters com grandes quantidades de recursos. O KSM é executado como uma implementação de réplica única e lista quase todos os recursos no cluster, como pods, implementações, DaemonSets, ConfigMaps, segredos e volumes persistentes. As métricas são geradas em cada um destes objetos de recursos. Se algum dos recursos tiver muitos objetos, como um cluster com mais de 10 000 pods, o KSM pode ficar sem memória.

Versões afetadas

Este problema pode ocorrer em qualquer versão do Google Distributed Cloud.

O limite de CPU e memória predefinido foi aumentado nas últimas versões do Google Distributed Cloud, pelo que estes problemas de recursos devem ser menos comuns.

Correção e solução alternativa

Para verificar se o seu problema se deve a problemas de falta de memória, reveja os seguintes passos:

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

Se confirmar que os problemas de falta de memória são o problema, use uma das seguintes soluções:

  • Aumente o pedido e o limite de memória para o KSM.

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

    Para o Google Distributed Cloud 1.13, o KSM expõe apenas um número mais pequeno de métricas denominado Métricas principais por predefinição. Este comportamento significa que a utilização de recursos é inferior à das versões anteriores, mas pode seguir o mesmo procedimento para reduzir ainda mais o número de métricas do KSM.

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

gke-metrics-agent loop de falhas

Se gke-metrics-agent só tiver problemas de falta de memória no nó onde kube-state-metrics existe, a causa é um grande número de métricas kube-state-metrics. Para mitigar este problema, reduza a escala do stackdriver-operator e modifique o KSM para expor um pequeno conjunto de métricas necessárias, conforme detalhado na secção anterior. Não se esqueça de aumentar novamente a escala stackdriver-operator após a atualização do cluster para o Google Distributed Cloud 1.13, em que o KSM expõe por predefinição um número menor de métricas principais.

Para problemas não relacionados com eventos de falta de memória, verifique os registos dos pods de gke-metric-agent. Pode ajustar a CPU e a memória de todos os gke-metrics-agentPods adicionando o campo resourceAttrOverride ao recurso personalizado do Stackdriver.

stackdriver-metadata-agent loop de falhas

Sintoma

Não está disponível nenhuma etiqueta de metadados do sistema quando filtra métricas no Cloud Monitoring.

Causa

O caso mais comum de stackdriver-metadata-agent reinícios constantes deve-se a eventos de falta de memória. Este evento é semelhante a kube-state-metrics. Embora o comando stackdriver-metadata-agent não liste todos os recursos, continua a listar todos os objetos para os tipos de recursos relevantes, como Pods, Deployments e NetworkPolicy. O agente é executado como uma implementação de réplica única, o que aumenta o risco de eventos sem memória se o número de objetos for demasiado elevado.

Versão afetada

Este problema pode ocorrer em qualquer versão do Google Distributed Cloud.

O limite predefinido de CPU e memória foi aumentado nas últimas versões do Google Distributed Cloud, pelo que estes problemas de recursos devem ser menos comuns.

Correção e solução alternativa

Para verificar se o seu problema se deve a problemas de falta de memória, reveja os seguintes passos:

  • Use kubectl describe pod ou kubectl get pod -o yaml e verifique a mensagem de estado de erro.
  • Verifique a métrica de consumo e utilização de memória para stackdriver-metadata-agent e confirme se está a atingir o limite antes de o dispositivo ser reiniciado.
Se confirmar que os problemas de falta de memória estão a causar problemas, aumente o limite de memória no campo resourceAttrOverride do recurso personalizado do Stackdriver.

metrics-server loop de falhas

Sintoma

A escala automática horizontal de pods e o kubectl top não funcionam no seu cluster.

Causa e versões afetadas

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

Este problema pode ocorrer em qualquer versão do Google Distributed Cloud.

Correção e solução alternativa

Aumente os limites de recursos do servidor de métricas. Na versão 1.13 e posteriores do Google Distributed Cloud, o espaço de nomes de metrics-server e a respetiva configuração foram movidos de kube-system para gke-managed-metrics-server.

Para o Google Distributed Cloud, a edição da configuração do nanny seria revertida num evento de atualização ou upgrade do cluster. Tem de voltar a aplicar as alterações de configuração. Para contornar esta limitação, reduza a escala metrics-server-operator e altere manualmente o pod metrics-server.

Nem todos os recursos são removidos durante a eliminação da conta de serviço dos registos de auditoria do Google Cloud

Quando elimina uma conta de serviço usada para os registos de auditoria do Cloud, nem todos os Google Cloud recursos são eliminados. Se eliminar e recriar rotineiramente contas de serviço usadas para registos de auditoria do Cloud, o registo de auditoria acaba por falhar.

Sintoma

As mensagens de erro de autorização recusada são apresentadas no contentor de proxy dos registos de auditoria do Cloud.

Para confirmar que a falha do registo de auditoria é causada por este problema, execute o seguinte comando:

curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/global/features/cloudauditlogging

Substitua PROJECT_NUMBER pelo número do seu projeto.

A resposta devolve todas as contas de serviço usadas com os registos de auditoria do Cloud no projeto, incluindo as contas de serviço que foram eliminadas.

Causa e versões afetadas

Nem todos os recursos do Google Cloud são removidos quando elimina uma conta de serviço usada para os registos de auditoria do Cloud e, eventualmente, atinge o limite de 1000 contas de serviço para o projeto.

Este problema pode ocorrer em qualquer versão do Google Distributed Cloud.

Correção e solução alternativa

  1. Crie uma variável de ambiente que contenha uma lista separada por vírgulas de todas as contas de serviço que quer manter. Coloque cada email da conta de serviço entre aspas simples e coloque toda a lista entre aspas duplas. Pode usar o seguinte como ponto de partida:

    SERVICE_ACCOUNT_EMAILS="'SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com'"

    Substitua o seguinte:

    • PROJECT_ID: o ID do seu projeto.
    • SERVICE_ACCOUNT_NAME: o nome da conta de serviço.

    A lista concluída deve ser semelhante ao seguinte exemplo:

    "'sa_name1@example-project-12345.iam.gserviceaccount.com','sa_name2@example-project-12345.iam.gserviceaccount.com','sa_name3@example-project-12345.iam.gserviceaccount.com'"

  2. Execute o seguinte comando para remover a funcionalidade Cloud Audit Logs do projeto:

    curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/FLEET_REGION /features/cloudauditlogging

    Substitua o seguinte:

    • PROJECT_NUMBER: o número do projeto.
    • FLEET_REGION: a localização da subscrição da frota para os seus clusters. Pode ser uma região específica, como us-central1 ou global. Pode executar o comando gcloud container fleet memberships list para obter a localização da subscrição.

    Este comando elimina completamente todas as contas de serviço.

  3. Recrie a funcionalidade de registos de auditoria do Cloud apenas com as contas de serviço que quer manter:

    curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/FLEET_REGION/features?feature_id=cloudauditlogging \
    -d '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":[$SERVICE_ACCOUNT_EMAILS]}}}'

As etiquetas de metadados desaparecem das métricas

Sintoma

As etiquetas de metadados, por exemplo, node_name, não são preenchidas no Cloud Monitoring.

Causa e versões afetadas

Este problema pode ocorrer em qualquer versão do Google Distributed Cloud.

Correção e solução alternativa

Quaisquer alterações ao pod repõem as etiquetas de metadados. Por exemplo, executar comandos como kubectl rollout restart deployment <workload_name>.

O que se segue?

Se precisar de assistência adicional, contacte o apoio ao cliente do Google Cloud. Também pode consultar o artigo Receber apoio técnico para mais informações sobre recursos de apoio técnico, incluindo o seguinte:

  • Requisitos para abrir um registo de apoio ao cliente.
  • Ferramentas para ajudar a resolver problemas, como a configuração do ambiente, os registos e as métricas.
  • Componentes suportados.