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:

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

Verifique se os registos de auditoria da nuvem estão ativados na secção cloudAuditLogging da configuração do cluster. Confirme se o ID do projeto, a localização e a chave da conta de serviço estão configurados corretamente. O ID do projeto tem de ser igual ao ID do projeto em gkeConnect.

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 de proxy dos registos de auditoria do Google Cloud é executado como uma das seguintes opções:

  • Um agrupamento estático no cluster de administrador ou autónomo.
  • Como um contentor secundário no pod kube-apiserver.

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.

    Para ajustar a CPU e a memória do KSM:

    • Para as versões 1.16.0 ou posteriores do Google Distributed Cloud, o Google Cloud Observability gere o KSM. Para atualizar o KSM, consulte o artigo Substituir os pedidos e os limites predefinidos de CPU e memória para um componente do Stackdriver.

    • Para as versões do Google Distributed Cloud 1.10.7 ou posteriores, 1.11.3 ou posteriores, 1.12.2 ou posteriores e 1.13 e posteriores, mas anteriores a 1.16.0, crie um ConfigMap para ajustar a CPU e a memória:

      1. Crie um ConfigMap denominado kube-state-metrics-resizer-config no espaço de nomes kube-system (gke-managed-metrics-server para a versão 1.13 ou posterior) com a seguinte definição. Ajuste os números de CPU e memória conforme necessário:

          apiVersion: v1
  kind: ConfigMap
  metadata:
    name: kube-state-metrics-resizer-config
    namespace: kube-system
  data:
    NannyConfiguration: |-
      apiVersion: nannyconfig/v1alpha1
      kind: NannyConfiguration
      baseCPU: 200m
      baseMemory: 1Gi
      cpuPerNode: 3m
      memoryPerNode: 20Mi
  ```

      2. Depois de criar o ConfigMap, reinicie a implementação do KSM eliminando o pod do KSM com o seguinte comando:

        kubectl -n kube-system rollout restart deployment kube-state-metrics

    • Para as versões 1.9 e anteriores, 1.10.6 ou anteriores, 1.11.2 ou anteriores e 1.12.1 ou anteriores do Google Distributed Cloud:

      • Não existe uma boa solução a longo prazo. Se editar o recurso relacionado com o KSM, as alterações são automaticamente revertidas por monitoring-operator.
      • Pode reduzir a escala monitoring-operator para 0 réplicas e, em seguida, editar a implementação do KSM para ajustar o respetivo limite de recursos. No entanto, o cluster não recebe patches de vulnerabilidade fornecidos por novas versões de patches através do monitoring-operator. Não se esqueça de aumentar novamente a escala monitoring-operator após a atualização do cluster para uma versão mais recente com a correção.

  • 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, denominadas 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.

Nem todos os recursos são removidos durante a eliminação da conta de serviço dos registos de auditoria do 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 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]}}}'

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: