Solucionar problemas do Config Sync

Nesta página, mostramos como resolver problemas com o Config Sync.

Nós nos esforçamos para que a experiência do Config Sync funcione sempre para você, mas há situações em que você pode precisar da solução de problemas na sua configuração. Este guia apresenta orientações sobre alguns mecanismos comuns que podem ajudar a resolver problemas.

Práticas recomendadas gerais

Ver o status do Config Sync

O comando nomos status exibe dados agregados e erros para ajudar você a entender o que está acontecendo com a instalação do Config Sync. As informações a seguir estão disponíveis com nomos status:

Status da instalação por cluster
Erros de sincronização (na leitura do Git e na reconciliação das alterações)

Para usar nomos status, instale o comando nomos.

Também é possível usar o comando gcloud alpha anthos config sync repo ou o painel do Config Sync para visualizar o status do Config Sync por repositório.

Usar indicadores de nível de serviço (SLIs)

Para receber notificações quando o Config Sync não estiver funcionando conforme o esperado, configure as regras de alerta do Prometheus com base nos SLIs do Config Sync. Para saber mais, consulte Usar SLIs do Config Sync.

Usar o kubectl para examinar recursos

O Config Sync é composto de vários recursos personalizados que podem ser consultados usando comandos kubectl. Esses comandos ajudam você a entender o status de cada um dos objetos do Config Sync.

Você precisa conhecer as seguintes informações sobre os recursos do Kubernetes que o Config Sync gerencia:

config-management-system é o namespace que usamos para executar todos os principais componentes do sistema do Config Sync
configmanagement.gke.io/v1 e configsync.gke.io são os prefixos de versão que usamos para todos os recursos personalizados.

Veja uma lista completa dos recursos personalizados executando o seguinte comando:

kubectl api-resources | grep -E "configmanagement.gke.io|configsync.gke.io"

Recursos personalizados individuais podem ser consumidos ao executar: kubectl get RESOURCE -o yaml.

Por exemplo, a saída do comando a seguir permite verificar o status de um objeto RootSync:

kubectl get rootsync -n config-management-system -o yaml

Também é possível usar o comando gcloud alpha anthos config sync resources ou o painel do Config Sync para visualizar os recursos que ele gerencia.

Ver os objetos RootSync e RepoSync

Ao instalar o Config Sync usando kubectl, você cria um objeto RootSync que contém detalhes sobre a configuração do seu repositório raiz. Ao instalar o Config Sync usando o Console do Google Cloud ou a Google Cloud CLI, o Config Sync cria automaticamente um objeto RootSync para você. Ao configurar a sincronização de vários repositórios, você cria objetos RepoSync que contêm informações de configuração sobre os repositórios de namespace.

A análise desses objetos pode revelar informações valiosas sobre o estado do Config Sync. Para saber mais, consulte Monitorar objetos RootSync e RepoSync.

Usar registros de auditoria

Os registros de auditoria podem ser uma ferramenta útil para depuração.

Se você instalou o Config Sync usando o console do Google Cloud ou a Google Cloud CLI, conclua as etapas a seguir para usar os registros de auditoria para investigar o Config Sync.

Console

Ative os registros de auditoria das APIs Connect/Hub do GKE.
1. No console do Google Cloud, acesse a página Registros de auditoria do IAM.
  
  Acessar a página "Registros de auditoria"
2. Na tabela, marque a caixa de seleção APIs Connect/Hub do GKE.
3. Marque as seguintes caixas de seleção:
  - Leitura de administradores
  - Leitura de dados
  - Gravação de dados
4. Clique em Salvar.
Acesse a página Explorador de registros.

Acessar a página Explorador de registros

Na caixa de texto Criador de consultas, adicione os seguintes filtros:

resource.type="audited_resource" resource.labels.service="gkehub.googleapis.com"

Clique em Run.
Na seção Resultados da consulta, selecione entradas para saber mais sobre os eventos.

Resolver problemas gerais

Evento com FailedScheduling

A saída de kubectl get events pode incluir um evento com o tipo FailedScheduling. O evento é semelhante ao seguinte exemplo:

LAST SEEN   TYPE      REASON              OBJECT                                       MESSAGE
9s          Warning   FailedScheduling    pod/config-management-operator-74594dc8f6    0/1 nodes are available: 1 Insufficient cpu.

Esse evento pode acontecer porque os pods não podem ser programados nos nós, o que geralmente significa que não há CPU ou memória suficiente nos nós. Para corrigir esse erro, escolha uma das seguintes opções:

adicionar um nó a um pool de nós do GKE atual.
criar um pool com nós maiores.

Objeto ConfigManagement válido, mas incorreto

Se você instalar o Config Sync usando comandos kubectl e a instalação falhar devido a um problema com o objeto ConfigManagement que não seja devido a um erro de sintaxe YAML ou JSON, o objeto poderá ser instanciado em cluster, mas talvez não funcione corretamente. Nessa situação, use o comando nomos status para verificar se há erros no objeto.

Uma instalação válida sem problemas tem o status PENDING ou SYNCED.

Uma instalação inválida tem o status NOT CONFIGURED e lista um dos seguintes erros:

missing git-creds Secret
missing required syncRepo field
git-creds Secret is missing the key specified by secretType

Para resolver o problema, corrija o erro de configuração. Dependendo do tipo de erro, talvez seja necessário reaplicar o manifesto ConfigManagement ao cluster.

Se o problema for que você esqueceu de criar o Secret git-creds, o Config Sync detectará o Secret assim que ele for criado e você não precisará reaplicar a configuração.

Os campos de ResourceGroup continuam mudando

Para cada repositório Git sincronizado com o cluster, o status de reconciliação de todos os recursos é agregado a um recurso denominado ResourceGroup. Para cada objeto RootSync ou RepoSync, um ResourceGroup é gerado para capturar o conjunto de recursos aplicados ao cluster e agregar os status deles.

Finalmente, seu ResourceGroup pode entrar em um loop que continua atualizando o spec do ResourceGroup. Se isso acontecer, você poderá notar os seguintes problemas:

O metadata.generation de um ResourceGroup continua aumentando em um curto período.
O ResourceGroup spec está sempre mudando.
O ResourceGroup spec não inclui o status.resourceStatuses dos recursos que estão sendo sincronizados com o cluster.

Se você observar esses problemas, significa que alguns dos recursos nos repositórios do Git não foram aplicados ao cluster. A causa desses problemas é a falta de permissões necessárias para aplicar esses recursos.

Você pode verificar se as permissões estão ausentes recebendo o status do recurso RepoSync:

kubectl get reposync repo-sync -n NAMESPACE -o yaml

Substitua NAMESPACE pelo namespace em que você criou seu repositório de namespace.

Você também pode usar o nomos status.

Se as mensagens a seguir aparecerem no status, significa que o reconciliação em NAMESPACE não tem a permissão necessária para aplicar o recurso:

errors:
  - code: "2009"
    errorMessage: |-
      KNV2009: deployments.apps "nginx-deployment" is forbidden: User "system:serviceaccount:config-management-system:ns-reconciler-     default" cannot get resource "deployments" in API group "apps" in the namespace "default"

      For more information, see https://g.co/cloud/acm-errors#knv2009

Para corrigir esse problema, é preciso declarar uma configuração RoleBinding que concede à conta de serviço ns-reconciler-NAMESPACE permissão para gerenciar o recurso com falha nesse namespace. Os detalhes sobre como adicionar um RoleBinding estão incluídos em Configurar a sincronização de vários repositórios.

Grande número de recursos no repositório Git

Quando o repositório Git é sincronizado com um cluster por um objeto RepoSync ou RootSync contém configuração para mais de alguns milhares de recursos, ele pode fazer com que ResourceGroup exceda o limite de tamanho do objeto etcd. Quando isso acontece, não é possível visualizar o status agregado dos recursos no seu repositório Git. Embora não seja possível visualizar o status agregado, seu repositório ainda está sincronizado.

Se você vir o seguinte erro do objeto RootSync, RepoSync ou dos registros de reconciliação, isso significa que o recurso ResourceGroup excede o limite de tamanho do objeto etcd.

KNV2009: etcdserver: request is too large

Para resolver esse problema, recomendamos dividir seu repositório Git em vários menores. Para saber mais, consulte Dividir um repositório em vários menores.

Se não for possível dividir o repositório Git, no Config Sync v1.11.0 e posterior, é possível mitigar o problema desativando a exibição dos dados de status. Para isso, defina o campo .spec.override.statusMode do objeto RootSync ou RepoSync como disabled. Ao fazer isso, o Config Sync interromperá a atualização do status dos recursos gerenciados no objeto ResourceGroup. Isso reduz o tamanho do objeto ResourceGroup. No entanto, não será mais possível conferir o status dos recursos gerenciados de nomos status ou gcloud alpha anthos config sync.

Se você instalou o Config Sync usando o console do Google Cloud ou a Google Cloud CLI, crie um objeto RootSync editável para definir spec.override.statusMode. Para saber mais, confira Configurar o Config Sync com comandos kubectl.

Se nenhum erro do objeto RootSync ou RepoSync é exibido, isso significa que seu repositório Git está sincronizado com o cluster. Para verificar se o recurso ResourceGroup excede o limite de tamanho do objeto etcd, verifique o status do recurso ResourceGroup e o registro do controlador ResourceGroup:

Verifique o status do ResourceGroup:
- Para verificar o status do RootSync, execute o comando a seguir:
```
 kubectl get resourcegroup.kpt.dev root-sync -n config-management-system
```
- Para verificar o status do RootSync, execute o comando a seguir:
```
kubectl get resourcegroup.kpt.dev repo-sync -n NAMESPACE
```
A resposta será semelhante a:
```
NAME        RECONCILING   STALLED   AGE
root-sync   True          False     35m
```
Se o valor da coluna RECONCILING for True, significa que o recurso ResourceGroup ainda está fazendo a reconciliação.
Verifique os registros do controlador ResourceGroup:
```
kubectl logs deployment/resource-group-controller-manager -c manager -n resource-group-system
```
Se você vir o seguinte erro na saída, o recurso ResourceGroup é muito grande e excede o limite de tamanho de objeto etcd:
```
"error":"etcdserver: request is too large"
```

Para evitar que o ResourceGroup seja muito grande, reduza o número de recursos no seu repositório Git. Siga as instruções para dividir um repositório raiz em vários repositórios raiz.

Fora de sincronia do repositório Git

Se novas confirmações forem enviadas para seu repositório do Git, mas o status do Config Sync do cluster ainda for Synced para uma confirmação antiga por muito tempo (mais que spec.git.period), você precisará verificar os registros do contêiner git-sync:

# check git-sync logs for a root reconciler
kubectl logs -n config-management-system deployment/root-reconciler -c git-sync

# check git-sync logs for a namespace reconciler
kubectl logs -n config-management-system deployment/ns-reconciler-NAMESPACE -c git-sync

É provável que git-sync não sincronize do repositório do Git, mas o reconciliador continuará a sincronização da confirmação realizada anteriormente. O exemplo de saída a seguir indica que você está com um problema de git-sync:

"msg"="unexpected error syncing repo, will retry" "error"="Run(git fetch -f
--tags --depth 1 origin develop): exit status 128: { stdout: "", stderr: "fatal:
couldn't find remote ref develop\n" }"

O webhook nega a solicitação de atualização/exclusão de um recurso gerenciado por um RootSync/RepoSync excluído

A exclusão de um objeto RootSync ou RepoSync não limpa as anotações e rótulos do Config Sync, e o webhook de admissão do Config Sync nega solicitações tentando modificar ou excluir esses recursos se o Config Sync ainda estiver ativado no cluster.

Se você quiser manter esses recursos gerenciados, primeiro é possível remover o gerenciamento desses recursos definindo a anotação configmanagement.gke.io/managed como disabled em cada recurso gerenciado declarado no repositório Git. Isso removeria as anotações e os rótulos do Config Sync dos recursos gerenciados, mas não excluiria esses recursos. Quando a sincronização for concluída, é possível remover o objeto RootSync ou RepoSync.

Se você quiser excluir esses recursos gerenciados, primeiro exclua os recursos gerenciados modificando o objeto RootSync ou RepoSync para sincronizar de um diretório Git vazio. Quando a sincronização for concluída, é possível remover o objeto RootSync ou RepoSync.

Se o objeto RootSync ou RepoSync foi excluído antes de remover o gerenciamento ou de excluir os recursos gerenciados, é possível adicionar o objeto RootSync ou RepoSync novamente, remover o gerenciamento ou excluir recursos gerenciados e, em seguida, excluir o objeto RootSync ou RepoSync novamente.

O escalonamento automático horizontal de pods não está funcionando

O Config Sync gerencia todos os campos especificados nos manifestos no repositório Git. Pode haver conflitos de recursos quando dois controladores tentam controlar o mesmo campo. Eles acontecem quando você tenta usar o escalonamento automático horizontal de pods com o Config Sync.

Se você quiser usar o escalonamento automático horizontal de pods, deixe o escalonador automático horizontal de pods gerenciar spec.replicas removendo esse campo de todos os manifestos no repositório Git. Caso contrário, o Config Sync tentará reverter todas as alterações no que é especificado no repositório.

PersistentVolumeClaim está com status perdido

Ao fazer upgrade de um cluster do Kubernetes para a versão 1.22 e posteriores, talvez o PersistentVolumeClaims gerenciado possa resultar em um status Lost. Isso ocorre quando a vinculação de PersistentVolumes e PersistentVolumeClaims é definida usando o campo claimRef em um recurso PersistentVolume. As alterações upstream do Kubernetes tornaram o campo claimRef atômico, o que faz com que esse bug ocorra, porque impede diferentes proprietários de campo para os diferentes subcampos claimRef ao usar aplicação do lado do servidor.

Até que esse problema seja resolvido no Kubernetes upstream (rastreador de problemas do GitHub, PR de correção de bugs), recomendamos atualizar seus recursos de PersistentVolume e PersistentVolumeClaim. para usar um método alternativo de vinculação. A vinculação pode ser definida no spec.volumeName do recurso PersistentVolumeClaim. Isso pode ser feito nas versões 1.21 e anteriores do Kubernetes para evitar interrupções ao fazer upgrade para a versão 1.22.

Veja a seguir um exemplo mínimo de vinculação de staging-pvc a staging-pv:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: staging-pvc
  namespace: staging
spec:
  volumeName: staging-pv
  ...

---

apiVersion: v1
kind: PersistentVolume
metadata:
  name: staging-pv
spec:
  ...

Usar volumeName em vez de claimRef para vinculação não garante privilégios de vinculação para o PersistentVolume.

Resolver problemas de mensagens de erro

KNV1045: configurações com status especificado não são permitidas

Se você especificar qualquer campo status no repositório de origem, encontrará KNV1045: configurações com "status" especificado não são permitidas. Não é permitido usar o Config Sync para sincronizar o campo status. Outro controlador precisa gerenciar e atualizar o campo status no cluster dinamicamente. Se o Config Sync tentar controlar o status pretendido do campo status, ele vai entrar em conflito com o controlador responsável por gerenciar o campo status.

Para corrigir esse erro, remova o campo status do repositório de origem. Para configurações de terceiros que não pertencem a você, use patches kustomize para remover campos status especificados nos manifestos em massa.

KNV2004: não é possível sincronizar o erro de repositório no contêiner git-sync

O Config Sync cria um clone superficial do seu repositório Git. Em casos raros, o Config Sync talvez não consiga encontrar a confirmação no clone superficial. Quando isso acontece, o Config Sync aumenta o número de confirmações do Git a serem buscadas.

Para definir o número de confirmações do Git a serem buscadas, defina o campo spec.override.gitSyncDepth em um objeto RootSync ou RepoSync:

Se esse campo não for fornecido, o Config Sync o configurará automaticamente.
O Config Sync faria um clone completo se esse campo fosse 0, e um clone superficial se ele fosse maior que 0.
Não é permitido definir esse campo como um valor negativo.

Se você instalou o Config Sync usando o console do Google Cloud ou a Google Cloud CLI, crie um objeto RootSync editável para definir spec.override.gitSyncDepth. Para saber mais, confira Configurar o Config Sync com comandos kubectl.

Veja um exemplo de configuração do número de confirmações do Git a serem buscadas em 88:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  override:
    gitSyncDepth: 88
  git:
    ...

Execute o seguinte comando para verificar se a alteração entra em vigor (GIT_SYNC_DEPTH precisa ser definido como 88 no campo data do ConfigMap root-reconciler-git-sync):

kubectl get cm root-reconciler-git-sync -n config-management-system -o yaml

É possível substituir o número de confirmações do Git para buscar em um reconciliador de namespace da mesma forma.

Erro: permissão recusada

Se você receber um erro semelhante ao exemplo abaixo quando tentar configurar o Config Sync, talvez não tenha o papel de Administrador do GKE Hub:

Permission 'gkehub.features.create' denied on 'projects/PROJECT_ID/locations/global/features/configmanagement'

Para garantir que você tenha as permissões necessárias, verifique se concedeu os papéis do IAM necessários.

Erro: o webhook de admissão negou uma solicitação

Se você receber o seguinte erro ao tentar aplicar uma alteração a um campo que o Config Sync gerencia, é possível que tenha feito uma alteração conflitante:

error: OBJECT could not be patched: admission webhook "v1.admission-webhook.configsync.gke.io"
denied the request: fields managed by Config Sync can not be modified

Quando você declara um campo em uma configuração e seu repositório é sincronizado com um cluster, o Config Sync gerencia esse campo. Qualquer alteração que você tentar fazer nesse campo será uma alteração conflitante.

Por exemplo, se você tiver uma configuração de implantação no seu repositório com um rótulo environment:prod e tentar alterar esse rótulo para environment:dev no seu cluster, haverá um conflito e a mensagem de erro anterior. No entanto, se você adicionar um novo rótulo (por exemplo, tier:frontend) à implantação, não haverá conflito.

Para que o Config Sync ignore qualquer alteração em um objeto, adicione a anotação descrita em Como ignorar mutações de objetos.

Erro: tempo limite de E/S da solicitação de webhook de admissão

Se você receber o seguinte erro quando o reconciliador tentar aplicar uma configuração ao cluster, a porta do webhook de admissão 8676 poderá ser bloqueada pelo firewall para a rede do plano de controle:

KNV2009: Internal error occurred: failed calling webhook "v1.admission-webhook.configsync.gke.io": Post https://admission-webhook.config-management-system.svc:8676/admission-webhook?timeout=3s: dial tcp 10.1.1.186:8676: i/o timeout

Para resolver esse problema, adicione uma regra de firewall para autorizar a porta 8676, que o webhook de admissão do Config Sync usa para a prevenção de deslocamento.

Erro: conexão do webhook de admissão recusada

Se você receber o seguinte erro quando o reconciliador tentar aplicar uma configuração ao cluster, o webhook de admissão ainda não estará pronto:

KNV2009: Internal error occurred: failed calling webhook "v1.admission-webhook.configsync.gke.io": Post "https://admission-webhook.config-management-system.svc:8676/admission-webhook?timeout=3s": dial tcp 10.92.2.14:8676: connect: connection refused

É um erro temporário que talvez você veja ao inicializar o Config Sync. Se o problema persistir, consulte a implantação do webhook de admissão para ver se os pods podem ser programados e estão íntegros.

kubectl describe deploy admission-webhook -n config-management-system

kubectl get pods -n config-management-system -l app=admission-webhook

Erro: não é possível montar o Git Secret

Se você receber o seguinte erro quando o contêiner git-sync tentar sincronizar um repositório com um secret, ele não será ativado no contêiner git-sync:

KNV2004: unable to sync repo Error in the git-sync container: ERROR: can't configure SSH: can't access SSH key: stat /etc/git-secret/ssh: no such file or directory: lstat /repo/root/rev: no such file or directory

Esse erro pode ser causado pela mudança do tipo de autenticação do repositório Git de none, gcenode ou gcpserviceaccount para outros tipos que precisam de um secret.

Para resolver esse problema, execute os seguintes comandos para reiniciar o Reconciler Manager e o Reconcilers:

# Stop the reconciler-manager Pod. The reconciler-manager Deployment will spin
# up a new Pod which can pick up the latest `spec.git.auth`.
kubectl delete po -l app=reconciler-manager -n config-management-system

# Delete the reconciler Deployments. The reconciler-manager will recreate the
# reconciler Deployments with correct volume mount.
kubectl delete deployment -l app=reconciler -n config-management-system

Erro: não é possível extrair bases remotas de repositórios públicos

Se você receber o seguinte erro durante o processo de renderização, o processo de renderização não será concluído com sucesso ao tentar extrair bases remotas de repositórios públicos:

KNV1068: failed to run kustomize build in /repo/source/0a7fd88d6c66362584131f9dfd024024352916af/remote-base, stdout:...
no 'git' program on path: exec: "git": executable file not found in $PATH

For more information, see https://g.co/cloud/acm-errors#knv1068

Para resolver esse problema, defina spec.override.enableShellInRendering como true na versão 1.12.0 e mais recentes do Anthos Config Management.

Os contêineres `reconciler`, `hydration-controller` e/ou `git-sync` são OOMKilled

É possível substituir as solicitações e os limites de CPU e/ou memória de um repositório raiz ou de namespace. Para substituir esses valores, use o campo spec.override.resources de um objeto RootSync ou RepoSync. Se você instalou o Config Sync usando o console do Google Cloud ou a Google Cloud CLI, crie um objeto RootSync editável para definir spec.override.resources. Para saber mais, confira Configurar o Config Sync com comandos kubectl.

O exemplo a seguir mostra como modificar os limites de CPU e memória do contêiner reconciler e a solicitação de CPU e o limite de memória do contêiner git-sync de um reconciliador raiz. Ele só pode substituir os contêineres git-sync e reconciler. A substituição parcial é permitida: quando um valor de modificação para uma solicitação ou limite de recurso não é fornecido, o valor do recurso padrão é usado para a solicitação ou o limite.

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceFormat: "unstructured"
  override:
    resources:
    - containerName: "reconciler"
      cpuLimit: "800m"
      memoryLimit: "500Mi"
    - containerName: "git-sync"
      cpuRequest: "100m"
      memoryLimit: "400Mi"
  git:
     ...

Execute o seguinte comando para verificar se os novos limites de recursos entram em vigor:

kubectl get deployment.apps/root-reconciler -n config-management-system -o yaml

É possível substituir os limites de recursos de um reconciliador de namespace da mesma forma.

Erro: um namespace fica preso na fase `Terminating`

Um namespace travado na fase Terminating precisa ter a seguinte condição:

    message: 'Failed to delete all resource types, 1 remaining: admission webhook
      "v1.admission-webhook.configsync.gke.io" denied the request: system:serviceaccount:kube-system:namespace-controller
      is not authorized to delete managed resource "_configmap_bookstore_cm1"'
    reason: ContentDeletionFailed
    status: "True"
    type: NamespaceDeletionContentFailure

Esse erro acontece quando você tenta excluir um namespace de um repositório raiz, mas alguns objetos no namespace ainda são gerenciados ativamente por um reconciliador de namespace. Quando um namespace é excluído, o controlador de namespace, que tem a conta de serviço system:serviceaccount:kube-system:namespace-controller, tenta excluir todos os objetos nesse namespace. No entanto, o webhook de admissão do Config Sync só permite que o reconciliador de raiz ou de namespace exclua esses objetos e nega o controlador de namespaces para excluí-los.

A solução é excluir o webhook de admissão do Config Sync:

kubectl delete deployment.apps/admission-webhook -n config-management-system

O Config Management Operator recria o webhook de admissão do Config Sync.

Se essa solução alternativa não funcionar, talvez seja necessário reinstalar o Config Sync.

Para evitar que o erro se repita, remova o repositório de namespace antes de remover o namespace.

Erro: o campo `webhooks` não foi encontrado na configuração do webhook de validação

Se você encontrar os seguintes erros nos registros de webhook de admissão do Config Sync ao executar kubectl logs -n config-management-system -l app=admission-webhook:

cert-rotation "msg"="Unable to inject cert to webhook." "error"="`webhooks` field not found in ValidatingWebhookConfiguration" "gvk"={"Group":"admissionregistration.k8s.io","Version":"v1","Kind":"ValidatingWebhookConfiguration"} "name"="admission-webhook.configsync.gke.io"
controller-runtime/manager/controller/cert-rotator "msg"="Reconciler error" "error"="`webhooks` field not found in ValidatingWebhookConfiguration" "name"="admission-webhook-cert" "namespace"="config-management-system"

Isso significa que o root-reconciler não sincroniza nenhum recurso com o cluster. Pode ser que root-reconciler ainda não esteja pronta ou não haja nada a ser sincronizado do repositório Git (por exemplo, o diretório de sincronização está vazio). Se o problema persistir, verifique a integridade do root-reconciler:

kubectl get pods -n config-management-system -l configsync.gke.io/reconciler=root-reconciler

Se o root-reconciler estiver em um loop de falhas ou com OOMKill, aumente os limites de recursos.

Erro: não foi possível criar o exportador do Stackdriver/GoogleCloud

Quando um componente no Open Telemetry Collector não pode acessar a conta de serviço padrão no mesmo namespace, você pode observar que o pod otel-collector em config-management-monitoring está no status CrashLoopBackoff ou Você poderá ver uma mensagem de erro semelhante a esta:

Error: cannot build exporters: error creating stackdriver exporter: cannot configure Google Cloud metric exporter: stackdriver: google: could not find default credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information.

Esse problema geralmente acontece quando a Identidade da carga de trabalho está ativada no cluster.

Para resolver esse problema, siga as instruções em Como monitorar o Config Sync para conceder permissão de gravação de métrica à conta de serviço padrão.

Se o erro persistir, configure o pod otel-collector para que as alterações entrem em vigor.