Resolver problemas do Config Connector

---

Esta página descreve técnicas de solução de problemas que podem ser usadas para resolver problemas com o Config Connector e problemas comuns que você pode encontrar ao usar o produto.

Técnicas básicas de solução de problemas

Verificar a versão do Config Connector

Execute o comando a seguir para conferir a versão instalada do Config Connector e consulte as notas da versão para verificar se a versão em execução oferece suporte aos recursos e recursos que você quer usar:

kubectl get ns cnrm-system -o jsonpath='{.metadata.annotations.cnrm\.cloud\.google\.com/version}'

Verificar o status e os eventos do recurso

Geralmente, é possível determinar o problema com os recursos do Config Connector inspecionando o estado deles no Kubernetes. Verificar o status e os eventos de um recurso é particularmente útil para determinar se o Config Connector não conseguiu reconciliar o recurso e por que a reconciliação falhou.

Verificar se o Config Connector está em execução

Para verificar se o Config Connector está em execução, verifique se todos os pods estão READY:

kubectl get pod -n cnrm-system

Exemplo de saída:

NAME                                            READY   STATUS    RESTARTS   AGE
cnrm-controller-manager-0                       1/1     Running   0          1h
cnrm-deletiondefender-0                         1/1     Running   0          1h
cnrm-resource-stats-recorder-77dc8cc4b6-mgpgp   1/1     Running   0          1h
cnrm-webhook-manager-58496b66f9-pqwhz           1/1     Running   0          1h
cnrm-webhook-manager-58496b66f9-wdcn4           1/1     Running   0          1h

Se você tiver o Config Connector instalado no namespaced-mode, terá um pod de controlador (cnrm-controller-manager) para cada namespace responsável por gerenciar os recursos do Config Connector nesse namespace.

Para verificar o status do pod do controlador responsável por um namespace específico, execute:

kubectl get pod -n cnrm-system \
    -l cnrm.cloud.google.com/scoped-namespace=NAMESPACE \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager

Substitua NAMESPACE pelo nome do namespace.

Verificar os registros do controlador

O pod do controlador registra informações e erros relacionados à reconciliação de recursos do Config Connector.

Para verificar os registros do pod do controlador, execute:

kubectl logs -n cnrm-system \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager \
    -c manager

Se você tiver o Config Connector instalado no namespaced-mode, o comando anterior vai mostrar os registros de todos os pods de controlador combinados. Para verificar os registros do pod do controlador de um namespace específico, execute:

kubectl logs -n cnrm-system \
    -l cnrm.cloud.google.com/scoped-namespace=NAMESPACE \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager \
    -c manager

Substitua NAMESPACE pelo nome do namespace.

Saiba como inspecionar e consultar os registros do Config Connector.

Abandonar e adquirir o recurso

Em alguns casos, talvez seja necessário atualizar um campo imutável em um recurso. Como não é possível editar campos imutáveis, é necessário abandonar e adquirir o recurso:

1. Atualize a configuração YAML do recurso do Config Connector e defina a anotação cnrm.cloud.google.com/deletion-policy como abandon.
2. Aplique a configuração YAML atualizada para atualizar a política de exclusão do recurso do Config Connector.
3. Abandone o recurso do Config Connector.
4. Atualize os campos imutáveis que precisam ser alterados na configuração do YAML.
5. Aplique a configuração YAML atualizada para adquirir o recurso abandonado.

Problemas comuns

O recurso continua sendo atualizado a cada 5 a 15 minutos

Se o recurso do Config Connector continuar alternando de um status UpToDate para um Updating a cada 5 a 10 minutos, é provável que o Config Connector esteja detectando diferenças não intencionais entre o estado desejado e o estado real do recurso, fazendo com que ele seja atualizado constantemente.

Primeiro, confirme se você não tem sistemas externos que estão constantemente modificando o Config Connector ou o recurso Google Cloud (por exemplo, pipelines de CI/CD, controladores personalizados, jobs cron etc.).

Se o comportamento não for devido a um sistema externo, verifique se Google Cloud está mudando algum dos valores especificados no recurso do Config Connector. Por exemplo, em alguns casos, o Google Cloud muda a formatação (por exemplo, maiúsculas) dos valores de campo, o que leva a uma diferença entre o estado desejado e o real do recurso.

Receba o estado do recurso Google Cloud usando a API REST (por exemplo, para ContainerCluster) ou a CLI do Google Cloud. Em seguida, compare esse estado com o recurso do Config Connector. Procure campos com valores que não correspondem e atualize o recurso do Config Connector para que eles correspondam. Procure valores que foram reformulados por Google Cloud. Por exemplo, consulte os problemas do GitHub #578 e #294.

Esse não é um método perfeito, já que o Config Connector e os modelos de recursoGoogle Cloud são diferentes, mas ele pode detectar a maioria dos casos de diferenças não intencionais.

Se não conseguir resolver o problema, consulte Ajuda adicional.

Exclusão de namespaces travados em "Encerrando"

As exclusões de namespaces podem ficar presas em Terminating se você tiver o Config Connector instalado no modo com namespace e se o ConfigConnectorContext do namespace tiver sido excluído antes de todos os recursos do Config Connector nesse namespace serem excluídos. Quando o ConfigConnectorContext de um namespace é excluído, o Config Connector é desativado para esse namespace, o que impede que os recursos restantes do Config Connector nesse namespace sejam excluídos.

Para corrigir esse problema, faça uma limpeza forçada e exclua manualmente os recursos Google Cloud .

Para atenuar esse problema no futuro, exclua o ConfigConnectorContext somente depois que todos os recursos do Config Connector no namespace tiverem sido excluídos do Kubernetes. Evite excluir namespaces inteiros antes que todos os recursos do Config Connector naquele namespace tenham sido excluídos, porque o ConfigConnectorContext pode ser excluído primeiro.

Confira também como a exclusão de um namespace que contém um projeto e seus elementos filhos ou uma pasta e seus elementos filhos pode travar.

As exclusões de recursos ficam "DeleteFailed" após a exclusão do projeto.

As exclusões de recursos do Config Connector podem ficar presas em DeleteFailed se o projeto Google Cloud tiver sido excluído anteriormente.

Para corrigir esse problema, restaure o projeto no Google Cloud para permitir que o Config Connector exclua os recursos filhos restantes do Kubernetes. Como alternativa, faça uma limpeza forçada.

Para atenuar esse problema no futuro, exclua os projetos Google Cloud somente depois que todos os recursos filhos do Config Connector forem excluídos do Kubernetes. Evite excluir namespaces inteiros que possam conter um recurso Project e os recursos filhos do Config Connector, já que o recurso Project pode ser excluído primeiro.

Metadados do Compute Engine não definidos

Se o recurso do conector de configuração tiver um status UpdateFailed com uma mensagem afirmando que os metadados do Compute Engine não estão definidos, provavelmente significa que a conta de serviço do IAM usada pelo conector de configuração não existe.

Exemplo de mensagem UpdateFailed:

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner- instance": Get
"https://spanner.googleapis.com/v1/projects/my-project/instances/my-spanner-instance?alt=json":
metadata: Compute Engine metadata "instance/service-accounts/default/token?
scopes=https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)compute%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSIN
G)auth%!F(MISSING)cloud-platform%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)cloud-identity%!C(MISSING)https%!A(MISSING)%!F(MISS
ING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)ndev.clouddns.readwrite%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSIN
G)devstorage.full_control%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)userinfo.email%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F
(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)drive.readonly" not
defined, detail:

Para corrigir o problema, verifique se a conta de serviço do IAM usada pelo Config Connector existe.

Para atenuar esse problema no futuro, siga as instruções de instalação do Config Connector.

Erro 403: a solicitação não tem escopos de autenticação suficientes

Se o recurso do Config Connector tiver um status UpdateFailed com uma mensagem que indica um erro 403 devido a escopos de autenticação insuficientes, provavelmente significa que a Identidade da carga de trabalho não está ativada no cluster do GKE.

Exemplo de mensagem UpdateFailed:

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner-instance": googleapi: Error 403: Request had
insufficient authentication scopes.

Para investigar, conclua as seguintes etapas:

1. Salve a seguinte configuração de pod como wi-test.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: workload-identity-test
     namespace: cnrm-system
   spec:
     containers:
     - image: google/cloud-sdk:slim
       name: workload-identity-test
       command: ["sleep","infinity"]
     serviceAccountName: cnrm-controller-manager
   

   Se você instalou o Config Connector usando o modo com namespace, serviceAccountName precisa ser cnrm-controller-manager-NAMESPACE. Substitua NAMESPACE pelo namespace usado durante a instalação.

2. Crie o pod no cluster do GKE:

   kubectl apply -f wi-test.yaml
   

3. Abra uma sessão interativa no pod:

   kubectl exec -it workload-identity-test \
       --namespace cnrm-system \
       -- /bin/bash
   

4. Liste sua identidade:

   gcloud auth list
   

5. Verifique se a identidade listada corresponde à conta de serviço do Google vinculada aos recursos.

   Se você encontrar a conta de serviço padrão do Compute Engine, quer dizer que a federação de identidade da carga de trabalho para GKE não está ativada no cluster do GKE e/ou no pool de nós.

6. Saia da sessão interativa e exclua o pod do cluster do GKE:

   kubectl delete pod workload-identity-test \
       --namespace cnrm-system
   

Para corrigir esse problema, use um cluster do GKE com a federação de identidade da carga de trabalho do GKE ativada.

Se você ainda estiver recebendo o mesmo erro em um cluster do GKE com a federação de identidade da carga de trabalho para GKE ativada, verifique se você não esqueceu de ativar a federação de identidade da carga de trabalho para GKE nos pools de nós do cluster. Leia mais sobre como ativar a Federação de identidade da carga de trabalho para o GKE em pools de nós existentes. Recomendamos ativar a federação de identidade da carga de trabalho para o GKE em todos os pools de nós do cluster, já que o Config Connector pode ser executado em qualquer um deles.

403 Proibido: o autor da chamada não tem permissão. Consulte a documentação da Federação de Identidade da Carga de Trabalho para GKE.

Se o recurso do Config Connector tiver um status UpdateFailed com uma mensagem que indica um erro 403 devido à Federação de Identidade da Carga de Trabalho para GKE, isso provavelmente significa que a conta de serviço do Kubernetes do Config Connector não tem as permissões do IAM adequadas para representar a conta de serviço do IAM como um usuário da Federação de Identidade da Carga de Trabalho para GKE.

Exemplo de mensagem UpdateFailed:

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner- instance": Get
"https://spanner.googleapis.com/v1/projects/my-project/instances/my-spanner-instance?alt=json":
compute: Received 403 `Unable to generate access token; IAM returned 403
Forbidden: The caller does not have permission
This error could be caused by a missing IAM policy binding on the target IAM
service account.
For more information, refer to the Workload Identity Federation for GKE documentation:
  https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#creating_a_relationship_between_ksas_and_gsas

Para corrigir e atenuar o problema no futuro, consulte as instruções de instalação do Config Connector.

Erro 403: o autor da chamada não tem permissão do IAM

Se o recurso do Configurar conector tiver um status UpdateFailed com uma mensagem afirmando que o autor da chamada não tem uma permissão do IAM, provavelmente significa que a conta de serviço do IAM usada pelo Configurar conector não tem a permissão do IAM declarada na mensagem que é necessária para gerenciar o recurso Google Cloud .

Exemplo de mensagem UpdateFailed:

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner- instance": googleapi: Error 403: Caller is missing IAM
permission spanner.instances.get on resource
projects/my-project/instances/my-spanner-instance., detail:

Se você ainda estiver recebendo o mesmo erro depois de conceder as permissões apropriadas do IAM à sua conta de serviço do IAM, verifique se o recurso está sendo criado no projeto correto. Verifique o campo spec.projectRef do recurso do Config Connector ou a anotação cnrm.cloud.google.com/project-id, se o recurso não tiver suporte a um campo spec.projectRef, e verifique se o recurso está referenciando o projeto correto. O Config Connector usa o nome do namespace como o ID do projeto se nem o recurso nem o namespace especificarem um projeto de destino. Saiba como configurar o projeto de destino para recursos no escopo do projeto.

Se o mesmo erro ainda aparecer, verifique se a Federação de Identidade da Carga de Trabalho para GKE está ativada no cluster do GKE.

Para atenuar esse problema no futuro, siga as instruções de instalação do Config Connector.

Versão sem suporte em instalações de complementos do Config Connector

Se não for possível ativar o complemento Config Connector, a seguinte mensagem de erro será exibida: Node version 1.15.x-gke.x s unsupported. Para resolver esse erro, verifique se a versão do cluster do GKE atende aos requisitos de versão e recurso.

Para ver todas as versões válidas para os clusters, execute o comando a seguir.

gcloud container get-server-config --format "yaml(validMasterVersions)" \
    --zone ZONE

Substitua ZONE pela zona do Compute Engine.

Escolha na lista uma versão que atenda aos requisitos.

A mensagem de erro também será exibida se a Federação de identidade da carga de trabalho para GKE ou o GKE Monitoring estiver desativado. Verifique se esses recursos estão ativados para corrigir o erro.

Não é possível fazer mudanças em campos imutáveis

O Config Connector rejeita atualizações de campos imutáveis na admissão.

Por exemplo, atualizar um campo imutável com kubectl apply faz com que o comando falhe imediatamente.

Isso significa que as ferramentas que reaplicam recursos continuamente (por exemplo, GitOps) podem ficar bloqueadas ao atualizar um recurso se não processarem erros de admissão.

Como o Config Connector não permite atualizações em campos imutáveis, a única maneira de fazer isso é excluir e recriar o recurso.

Erro ao atualizar os campos imutáveis quando não há atualização

Talvez você encontre os seguintes erros no status do recurso do Config Connector logo após criar ou adquirir um recurso Google Cloud usando o Config Connector:

• Update call failed: error applying desired state: infeasible update: ({true \<nil\>}) would require recreation (exemplo)

• Update call failed: cannot make changes to immutable field(s) (exemplo)

Isso pode não significar que você realmente atualizou o recurso, mas pode ser que a API Google Cloud fez uma mudança em um campo imutável que foi gerenciado por você no recurso do Config Connector. Isso causou a incompatibilidade entre o estado desejado e o estado ativo dos campos imutáveis.

Para resolver o problema, atualize os valores desses campos imutáveis no recurso do Config Connector para corresponder ao estado em tempo real. Para isso, siga estas etapas:

1. Atualize a configuração YAML do recurso do Config Connector e defina a anotação cnrm.cloud.google.com/deletion-policy como abandon.
2. Aplique a configuração YAML atualizada para atualizar a política de exclusão do recurso do Config Connector.
3. Abandone o recurso do Config Connector.
4. Imprima o estado ativo do recurso Google Cloud correspondente usando a CLI gcloud.
5. Encontre a incompatibilidade entre a saída da CLI gcloud e a configuração YAML do recurso do Config Connector e atualize esses campos na configuração YAML.
6. Aplique a configuração YAML atualizada para adquirir o recurso abandonado.

O recurso não tem status

Se os recursos não tiverem um campo status, é provável que o Config Connector não esteja sendo executado corretamente. Verifique se o Config Connector está em execução.

Nenhuma correspondência para o tipo "Foo"

Quando esse erro é encontrado, significa que o cluster do Kubernetes não tem o CRD para o tipo de recurso Foo instalado.

Verifique se o tipo é um tipo de recurso aceito pelo Config Connector.

Se o tipo for compatível, isso significa que a instalação do Config Connector está desatualizada ou inválida.

Se você instalou o Config Connector usando o complemento do GKE, a instalação será atualizada automaticamente. Se você instalou o Config Connector manualmente, faça um upgrade manual.

Verifique o repositório do GitHub para determinar quais tipos de recursos são compatíveis com quais versões do Config Connector. Por exemplo, confira os tipos compatíveis com o Config Connector v1.44.0.

Os rótulos não são propagados para o recurso Google Cloud

O Config Connector propaga os identificadores encontrados em metadata.labels para o recurso Google Cloud subjacente. No entanto, nem todos os recursos Google Cloud são compatíveis com rótulos. Confira a documentação da API REST do recurso (por exemplo, confira a documentação da API para PubSubTopic) para saber se ele oferece suporte a identificadores.

Falha ao chamar o webhook x509: o certificado depende do campo "Nome comum" legado.

Se você encontrar um erro semelhante ao exemplo abaixo, talvez haja um problema com certificados:

Error from server (InternalError): error when creating "/mnt/set-weaver-dns-record.yml": Internal error occurred: failed calling webhook "annotation-defaulter.cnrm.cloud.google.com": Post "https://cnrm-validating-webhook.cnrm-system.svc:443/annotation-defaulter?timeout=30s": x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0

Observação: esse problema ocorre apenas com as versões 1.19 ou mais recentes do Kubernetes e as versões 1.43 ou mais recentes do Config Connector oferecem suporte à geração automática do certificado, o que deve impedir que você encontre esse problema.

Para contornar esse problema, exclua os certificados e os pods relevantes:

kubectl delete -n cnrm-system secrets cnrm-webhook-cert-abandon-on-uninstall
kubectl delete -n cnrm-system secrets cnrm-webhook-cert-cnrm-validating-webhook
kubectl delete -n cnrm-system pods -l "cnrm.cloud.google.com/component=cnrm-webhook-manager"

Depois de excluir esses recursos, o certificado correto será regenerado.

Para mais informações sobre esse erro, consulte o problema do GitHub.

Erro devido a caracteres especiais no nome do recurso

Caracteres especiais não são válidos no campo metadata.name do Kubernetes. Se você encontrar um erro semelhante ao exemplo abaixo, o metadata.name do recurso provavelmente tem um valor com caracteres especiais:

a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

Por exemplo, o recurso SQLUser abaixo contém um caractere inválido em metadata.name:

apiVersion: sql.cnrm.cloud.google.com/v1beta1
kind: SQLUser
metadata:
  name: [e-mail]
spec:
  instanceRef:
    name: test-cloudsql-db
  type: "CLOUD_IAM_USER"

Se você tentar criar esse recurso, vai receber o seguinte erro:

Error from server (Invalid): error when creating "sqlusercrd.yaml": SQLUser.sql.cnrm.cloud.google.com "[e-mail]" is invalid: metadata.name: Invalid value: "[e-mail]": a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

Se você quiser dar ao recurso um nome que não seja válido para o Kubernetes, mas que seja um nome de recurso Google Cloud válido, use o campo resourceID, conforme mostrado no exemplo a seguir:

apiVersion: sql.cnrm.cloud.google.com/v1beta1
kind: SQLUser
metadata:
  name: 'test'
spec:
  instanceRef:
    name: sqlinstance-sample-postgresql
  host: "%"
  type: CLOUD_IAM_USER
  resourceID: [e-mail]

Essa configuração faz com que o Config Connector use resourceID em vez de metadata.name como o nome do recurso.

Não é possível remover campos da especificação de recursos

A remoção de um campo da especificação de um recurso do Config Connector (atualizando o arquivo .yaml do recurso e aplicando novamente ou usando kubectl edit para editar a especificação do recurso) não remove esse campo da especificação do recurso do Config Connector ou do recurso Google Cloud subjacente. Em vez disso, a remoção de um campo da especificação faz com que ele seja gerenciado externamente.

Observação: há uma exceção: campos em listas. As listas são atômicas, o que significa que o Config Connector vai tentar definir a lista no Google Cloud subjacente para que seja equivalente à especificada.

Se você quiser mudar o valor de um campo para vazio ou padrão no recurso Google Cloud , será necessário zerar o campo na especificação de recursos do Config Connector:

• Para campos do tipo lista, defina o campo como uma lista vazia usando [].

  O exemplo a seguir mostra o campo targetServiceAccounts que queremos remover:

  spec:
    targetServiceAccounts:
      - external: "[e-mail]"
      - external: "[e-mail]"
  

  Para remover esse campo, defina o valor como vazio:

  spec:
    targetServiceAccounts: []
  

• Para um campo de tipo primitivo, defina o campo como vazio usando uma das seguintes opções:

  Tipo	Valor vazio
  string	""
  bool	"false"
  integer	0

  O exemplo a seguir mostra o campo identityNamespace que queremos remover:

  spec:
    workloadIdentityConfig:
      identityNamespace: "foo-project.svc.id.goog"
  

  Para remover esse campo, defina o valor como vazio:

  spec:
    workloadIdentityConfig:
      identityNamespace: ""
  

• Para campos de tipo de objeto, atualmente no Config Connector, não há uma maneira fácil de definir um campo de tipo de objeto inteiro como "NULL". Tente definir os subcampos do tipo de objeto como vazios ou padrão seguindo as orientações acima e verifique se funciona.

KNV2005: o recurso de sincronização está atualizando excessivamente

Se você estiver usando o Config Sync e tiver erros KNV2005 nos recursos do Config Connector, é provável que o Config Sync e o Config Connector estejam competindo pelo recurso.

Exemplo de mensagem de registro:

KNV2005: detected excessive object updates, approximately 6 times per
minute. This may indicate Config Sync is fighting with another controller over
the object.

O Config Sync e o Config Connector "brigam" por um recurso se continuarem atualizando os mesmos campos com valores diferentes. A atualização de um aciona a outra para agir e atualizar o recurso, o que faz com que a outra aja e atualize o recurso, e assim por diante.

A luta não é um problema para a maioria dos campos. Os campos especificados no Config Sync não são alterados pelo Config Connector, enquanto os campos que não são especificados no Config Sync e têm o valor padrão definido pelo Config Connector são ignorados pelo Config Sync. Portanto, para a maioria dos campos, o Config Sync e o Config Connector nunca devem atualizar o mesmo campo para valores diferentes.

Há uma exceção: campos de lista. Assim como o Config Connector pode definir subcampos padrão em campos de objetos, ele também pode definir subcampos padrão em objetos dentro de listas. No entanto, como os campos de lista nos recursos do Config Connector são atômicos, o padrão de subcampos é considerado como uma mudança completa do valor da lista.

Portanto, o Config Sync e o Config Connector vão entrar em conflito se o Config Sync definir um campo de lista e o Config Connector definir como padrão todos os subcampos dentro dessa lista.

Para contornar esse problema, você tem as seguintes opções:

1. Atualize o manifesto do recurso no repositório do Config Sync para que corresponda ao que o Config Connector está tentando definir.

   Uma maneira de fazer isso é interromper temporariamente a sincronização de configurações, aguardar que o Config Connector termine a reconciliação do recurso e, em seguida, atualizar o manifesto do recurso para corresponder ao recurso no servidor da API Kubernetes.

2. Impeça que o Config Sync reaja a atualizações do recurso no servidor da API Kubernetes definindo a anotação client.lifecycle.config.k8s.io/mutation como ignore. Saiba como fazer com que o Config Sync ignore mutações de objetos.

3. Impeça que o Config Connector atualize completamente a especificação do recurso definindo a anotação cnrm.cloud.google.com/state-into-spec como absent no recurso. Essa anotação não é compatível com todos os recursos. Para saber se o recurso é compatível com a anotação, verifique a página de referência do recurso correspondente. Leia mais sobre a anotação.

failed calling webhook

O Config Connector pode estar em um estado em que não é possível desinstalá-lo. Isso geralmente acontece ao usar o complemento Config Connector e desativar o Config Connector antes de remover as CRDs do Config Connector. Ao tentar desinstalar, você recebe um erro semelhante a este:

error during reconciliation: error building deployment objects: error finalizing the deletion of Config Connector system components deployed by ConfigConnector controller: error waiting for CRDs to be deleted: error deleting CRD accesscontextmanageraccesslevels.accesscontextmanager.cnrm.cloud.google.com: Internal error occurred: failed calling webhook "abandon-on-uninstall.cnrm.cloud.google.com": failed to call webhook: Post "https://abandon-on-uninstall.cnrm-system.svc:443/abandon-on-uninstall?timeout=3s": service "abandon-on-uninstall" not found

Para resolver esse erro, primeiro exclua os webhooks manualmente:

kubectl delete validatingwebhookconfiguration abandon-on-uninstall.cnrm.cloud.google.com --ignore-not-found --wait=true
kubectl delete validatingwebhookconfiguration validating-webhook.cnrm.cloud.google.com --ignore-not-found --wait=true
kubectl delete mutatingwebhookconfiguration mutating-webhook.cnrm.cloud.google.com --ignore-not-found --wait=true

Depois, você pode desinstalar o Config Connector.

Erro de atualização com IAMPolicy, IAMPartialPolicy e IAMPolicyMember

Se você excluir um recurso do Config Connector IAMServiceAccount antes de limpar os recursos IAMPolicy, IAMPartialPolicy e IAMPolicyMember que dependem dessa conta de serviço, o Config Connector não poderá localizar a conta de serviço referenciada nesses recursos do IAM durante a reconciliação. Isso resulta em um status UpdateFailed com uma mensagem de erro como esta:

Update call failed: error setting policy member: error applying changes: summary: Request `Create IAM Members roles/[MYROLE] serviceAccount:[NAME]@[PROJECT_ID].iam.gserviceaccount.com for project \"projects/[PROJECT_ID]\"` returned error: Error applying IAM policy for project \"projects/[PROJECT_ID]\": Error setting IAM policy for project \"projects/[PROJECT_ID]\": googleapi: Error 400: Service account [NAME]@[PROJECT_ID].iam.gserviceaccount.com does not exist., badRequest

Para resolver esse problema, verifique suas contas de serviço e veja se a conta de serviço necessária para esses recursos do IAM foi excluída. Se a conta de serviço for excluída, limpe também os recursos relacionados do Config Connector do IAM. Para IAMPolicyMember, exclua todo o recurso. Para IAMPolicy e IAMParitialPolicy, remova apenas as vinculações que envolvem a conta de serviço excluída. No entanto, essa limpeza não remove as vinculações de papéis Google Cloud imediatamente. As vinculações de papel Google Cloud são mantidas por 60 dias devido à retenção na conta de serviço excluída. Para mais informações, consulte a documentação do Google Cloud IAM sobre Excluir uma conta de serviço.

Observação: se você tiver problemas durante a exclusão, talvez seja necessário fazer uma limpeza forçada. Se você quiser excluir as vinculações do IAM Google Cloud imediatamente, exclua manualmente os recursos Google Cloud subjacentes usando gcloud.

Para evitar esse problema, sempre limpe os recursos do Config Connector IAMPolicy, IAMPartialPolicy e IAMPolicyMember antes de excluir o IAMServiceAccount referenciado.

Recurso excluído pelo Config Connector

O Config Connector nunca exclui seus recursos sem uma causa externa. Por exemplo, executar kubectl delete, usar ferramentas de gerenciamento de configuração, como Argo CD, ou usar um cliente de API personalizado pode causar a exclusão de recursos.

Um equívoco comum é que o Config Connector iniciou e excluiu alguns dos recursos no cluster. Por exemplo, se você estiver usando o Config Connector, poderá notar solicitações de exclusão do gerenciador de controladores do Config Connector em determinados recursos de mensagens de registro de contêineres ou de auditoria do cluster do Kubernetes. Essas solicitações de exclusão são resultado de acionadores externos, e o Config Connector está tentando reconciliar as solicitações de exclusão.

Para determinar por que um recurso foi excluído, é necessário analisar a primeira solicitação de exclusão enviada para o recurso correspondente. A melhor maneira de analisar isso é examinando os registros de auditoria do cluster do Kubernetes.

Por exemplo, se você estiver usando o GKE, poderá usar o Cloud Logging para consultar registros de auditoria do cluster do GKE. Por exemplo, se você quiser procurar as solicitações de exclusão iniciais de um recurso BigQueryDataset chamado foo no namespace bar, execute uma consulta como esta:

resource.type="k8s_cluster"
resource.labels.project_id="my-project-id"
resource.labels.cluster_name="my-cluster-name"
protoPayload.methodName="com.google.cloud.cnrm.bigquery.v1beta1.bigquerydatasets.delete"
protoPayload.resourceName="bigquery.cnrm.cloud.google.com/v1beta1/namespaces/bar/bigquerydatasets/foo"

Usando essa consulta, você procuraria a primeira solicitação de exclusão e, em seguida, verificaria authenticationInfo.principalEmail da mensagem de registro de exclusão para determinar a causa da exclusão.

OOMKilled do pod do controlador

Se você encontrar um erro OOMKilled em um pod de controlador do Config Connector, isso indica que um contêiner ou o pod inteiro foi encerrado porque usou mais memória do que o permitido. Para verificar isso, execute o comando kubectl describe. O status do pod pode aparecer como OOMKilled ou Terminating. Além disso, a análise dos registros de eventos do pod pode revelar ocorrências de eventos relacionados a OOM.

kubectl describe pod POD_NAME -n cnrm-system

Substitua POD_NAME pelo pod que você está solucionando.

Para resolver esse problema, use o recurso personalizado ControllerResource para aumentar a solicitação de memória e o limite de memória do pod.

PodSecurityPolicy impede upgrades

Depois de mudar do complemento do Config Connector para uma instalação manual e fazer upgrade do Config Connector para uma nova versão, o uso de PodSecurityPolicies pode impedir a atualização dos pods cnrm.

Para confirmar que as PodSecurityPolicies estão impedindo o upgrade, confira os eventos do config-connector-operator e procure um erro semelhante ao seguinte:

create Pod configconnector-operator-0 in StatefulSet configconnector-operator failed error: pods "configconnector-operator-0" is forbidden: PodSecurityPolicy: unable to admit pod: [pod.metadata.annotations[seccomp.security.alpha.kubernetes.io/pod]: Forbidden: seccomp may not be set pod.metadata.annotations[container.seccomp.security.alpha.kubernetes.io/manager]: Forbidden: seccomp may not be set]

Para resolver esse problema, é necessário especificar a anotação no PodSecurityPolicy que corresponde à anotação mencionada no erro. No exemplo anterior, a anotação é seccomp.security.alpha.kubernetes.io.

Limpeza forçada

Se os recursos do Config Connector estiverem presos à exclusão e você quiser excluí-los do cluster do Kubernetes, force a exclusão excluindo os finalizadores.

Aviso: essa operação deve ser feita como último recurso, já que as exclusões de finalizadores estão fora dos limites de uso normal do Config Connector e podem ter consequências não intencionais. Especificamente, não há garantias sobre o que acontece com os recursos Google Cloud subjacentes.

Para excluir os finalizadores de um recurso, edite o recurso usando kubectl edit, exclua o campo metadata.finalizers e salve o arquivo para preservar as alterações no servidor da API Kubernetes.

Como a exclusão dos finalizadores de um recurso permite que ele seja excluído imediatamente do cluster do Kubernetes, o Config Connector pode (mas não necessariamente) não ter a chance de concluir a exclusão do recurso Google Cloud subjacente. Isso significa que você pode excluir manualmente os recursos Google Cloud depois.

Monitoramento

Métricas

É possível usar o Prometheus para coletar e mostrar métricas do Config Connector.

Logging

Todos os pods do Config Connector geram registros estruturados no formato JSON.

Os registros dos pods do controlador são particularmente úteis para depurar problemas com a reconciliação de recursos.

É possível consultar registros de recursos específicos filtrando os seguintes campos nas mensagens de registro:

• logger: contém o tipo do recurso em letras minúsculas. Por exemplo, os recursos PubSubTopic têm um logger de pubsubtopic-controller.
• resource.namespace: contém o namespace do recurso.
• resource.name: contém o nome do recurso.

Como usar o Cloud Logging para consultas avançadas de registros

Se você estiver usando o GKE, poderá usar o Cloud Logging para consultar registros de um recurso específico com a seguinte consulta:

Observação: a sintaxe de consulta não é compatível com comentários. A consulta a seguir usa uma convenção de comentários, # comment, para fornecer um texto explicativo, mas esses comentários não podem ser incluídos em consultas.

# Filter to include only logs coming from the controller Pods
resource.type="k8s_container"
resource.labels.container_name="manager"
resource.labels.namespace_name="cnrm-system"
labels.k8s-pod/cnrm_cloud_google_com/component="cnrm-controller-manager"

# Filter to include only logs coming from a particular GKE cluster
resource.labels.cluster_name="GKE_CLUSTER_NAME"
resource.labels.location="GKE_CLUSTER_LOCATION"

# Filter to include only logs for a particular Config Connector resource
jsonPayload.logger="RESOURCE_KIND-controller"
jsonPayload.resource.namespace="RESOURCE_NAMESPACE"
jsonPayload.resource.name="RESOURCE_NAME"

Substitua:

• GKE_CLUSTER_NAME pelo nome do cluster do GKE que executa o Config Connector
• GKE_CLUSTER_LOCATION pelo local do cluster do GKE que executa o Config Connector. Por exemplo, us-central1.
• RESOURCE_KIND com o tipo de recurso em letras minúsculas. Por exemplo, pubsubtopic.
• RESOURCE_NAMESPACE pelo namespace do recurso.
• RESOURCE_NAME pelo nome do recurso.

Mais ajuda

Para receber mais ajuda, registre um problema no GitHub ou entre em contato com o Google Cloud suporte.