Resolver problemas de observabilidade do GKE em VMware

Este documento ajuda a resolver problemas de observabilidade no GKE em VMware. 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

Verifique se os registros de auditoria do Cloud estão ativados na seção cloudAuditLogging da configuração do cluster. Verifique se o código do projeto, o local e a chave da conta de serviço estão configurados corretamente. O ID do projeto precisa ser igual ao ID do projeto em gkeConnect.

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 do proxy de registros de auditoria do Cloud é executado como um dos seguintes:

  • Um pod estático no cluster de administrador ou independente.
  • Como um contêiner de arquivo secundário no pod kube-apiserver.

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 GKE em VMware.

O limite padrão de CPU e memória aumentou nas últimas versões do GKE em VMware, então esses problemas de recursos passam a ser menos recorrentes.

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:

    1. Para versões 1.9 e anteriores, 1.10.6 ou anteriores, 1.11.2 ou anteriores e 1.12.1 ou anteriores do GKE em VMware:

      1. Não há uma boa solução a longo prazo: se você editar o recurso relacionado ao KSM, as alterações serão revertidas automaticamente por monitoring-operator.

      2. É possível reduzir a escala vertical de monitoring-operator para zero réplicas e, em seguida, editar a implantação do KSM para ajustar o limite de recursos. No entanto, o cluster não receberá patches de vulnerabilidade entregues por novas versões de patch usando monitoring-operator.

        Lembre-se de escalonar monitoring-operator novamente após o upgrade do cluster para uma versão posterior com correção.

    2. Para versões 1.10.7 ou posteriores, 1.11.3 ou posteriores, 1.12.2 ou posteriores e 1.13 e posteriores do GKE em VMware, crie um ConfigMap chamado kube-state-metrics-resizer-config no namespace kube-system (gke-managed-metrics-server para versão 1.13 ou posterior) com a definição abaixo. Ajuste os números de CPU e memória conforme desejado:

      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

      1. Depois de criar o ConfigMap, reinicie a implantação do KSM excluindo o pod do KSM usando o seguinte comando:

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

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

    Para a versão 1.13 do GKE em VMware, o KSM expõe apenas um número menor de métricas chamadas principais métricas 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 versões do GKE no VMware 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. Não se esqueça de escalonar verticalmente stackdriver-operator depois que o cluster for atualizado para a versão 1.13 do GKE em VMware, 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 GKE em VMware.

O limite padrão de CPU e memória aumentou nas últimas versões do GKE em VMware, então esses problemas de recursos passam a ser menos recorrentes.

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 GKE em VMware.

Correção e solução alternativa

Aumentar os limites de recursos do servidor de métricas. Para as versões 1.13 e posteriores do GKE em VMware, o namespace do metrics-server e a configuração dele passaram de kube-system para gke-managed-metrics-server.

A seguir

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