Resolver problemas do Config Connector

Nesta página, descrevemos técnicas de solução de problemas que você pode usar para resolver problemas do Config Connector e problemas comuns que podem ocorrer 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 faça uma referência cruzada com as notas da versão para verificar se a versão em execução é compatível com os 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

Normalmente, é 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 é especialmente útil para determinar se o Config Connector não reconciliou 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, confira 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 o Config Connector estiver instalado no namespaced-mode, você 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 o Config Connector estiver instalado no namespaced-mode, o comando anterior vai mostrar os registros de todos os pods do controlador combinados. Verifique os registros do pod do controlador para um namespace específico executando:

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.

Leia mais sobre 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, você precisa 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 YAML.
  5. Aplique a configuração YAML atualizada para adquirir o recurso abandonado.

Problemas comuns

O recurso é atualizado a cada 5 a 15 minutos.

Se o recurso do Config Connector ficar alternando entre um status UpToDate e um status 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 o Config Connector atualize constantemente o recurso.

Primeiro, confirme que não há sistemas externos modificando constantemente o Config Connector ou o recurso Google Cloud (por exemplo, pipelines de CI/CD, controladores personalizados, jobs do 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, Google Cloud muda a formatação (por exemplo, o uso de maiúsculas) dos valores de campo, o que leva a uma diferença entre o estado desejado e o estado real do recurso.

Receba o estado do recurso Google Cloud usando a API REST (por exemplo, para ContainerCluster) ou a Google Cloud CLI. Em seguida, compare esse estado com o recurso do Config Connector. Procure campos com valores diferentes e atualize o recurso do Config Connector para corresponder. Em particular, procure valores que foram reformatados por Google Cloud. Por exemplo, consulte os problemas do GitHub #578 e #294.

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

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

Exclusões de namespaces travados em "Encerramento"

As exclusões de namespaces podem ficar presas em Terminating se o Config Connector estiver 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. 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 subjacentes depois.

Para evitar esse problema no futuro, exclua o ConfigConnectorContext somente depois que todos os recursos do Config Connector no namespace forem excluídos do Kubernetes. Evite excluir namespaces inteiros antes que todos os recursos do Config Connector nesse namespace sejam excluídos, já que o ConfigConnectorContext pode ser excluído primeiro.

Saiba também como a exclusão de um namespace que contém um projeto e seus filhos ou uma pasta e seus filhos pode ficar travada.

Exclusões de recursos presos em "DeleteFailed" após a exclusão do projeto

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

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

Para evitar esse problema no futuro, exclua apenas os projetos Google Cloud 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 Config Connector tiver um status UpdateFailed com uma mensagem informando que os metadados do Compute Engine não estão definidos, isso provavelmente significa que a conta de serviço do IAM usada pelo Config Connector 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 evitar esse problema no futuro, siga as instruções de instalação do Config Connector.

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

Se o recurso do Config Connector tiver um status UpdateFailed com uma mensagem indicando um erro 403 devido a escopos de autenticação insuficientes, isso 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ê vir 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 para o GKE ativada.

Se o mesmo erro ainda aparecer em um cluster do GKE com a federação de identidade da carga de trabalho para GKE ativada, verifique se você não se esqueceu de ativar também 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 atuais. 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 Forbidden: o usuário 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 indicando 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 sua 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 mitigar 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 Config Connector tiver um status UpdateFailed com uma mensagem informando que o autor da chamada não tem uma permissão do IAM, isso provavelmente significa que a conta de serviço do IAM usada pelo Config Connector não tem a permissão do IAM indicada na mensagem 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 o mesmo erro persistir depois de conceder à sua conta de serviço do IAM as permissões adequadas, 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 for compatível com um campo spec.projectRef) e confira 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. Leia mais sobre como configurar o projeto de destino para recursos no escopo do projeto.

Se o mesmo erro persistir, verifique se a federação de identidade da carga de trabalho para GKE está ativada no cluster do GKE.

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

Versão não compatível com 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 recursos .

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 aparece se a federação de identidade da carga de trabalho para GKE ou o GKE Monitoring estiverem desativados. 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 em 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 ferramentas que reaplicam recursos continuamente (por exemplo, GitOps) podem ficar presas 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 realizar essa atualização é excluir e recriar o recurso.

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

Você pode encontrar os seguintes erros no status do recurso do Config Connector logo após criar ou adquirir um recurso do 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 não significa que você atualizou o recurso, mas que a API Google Cloud fez uma mudança em um campo imutável 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 ativo. 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 compatível com o 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.

Confira no repositório do GitHub quais tipos de recursos são compatíveis com quais versões do Config Connector. Por exemplo, estes são 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 rótulos encontrados em metadata.labels para o recursoGoogle Cloud subjacente. No entanto, nem todos os recursos do Google Cloud aceitam rótulos. Consulte a documentação da API REST do recurso (por exemplo, documentação da API para PubSubTopic) para saber se ele é compatível com rótulos.

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

Se você encontrar um erro semelhante ao exemplo a seguir, talvez esteja enfrentando 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

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

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 que você excluir esses recursos, o certificado correto será regenerado.

Para mais informações sobre esse erro, consulte o problema no GitHub (em inglês).

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 a seguir, é provável que o metadata.name do recurso tenha 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 seguinte recurso SQLUser contém um caractere inválido em metadata.name:

apiVersion: sql.cnrm.cloud.google.com/v1beta1
kind: SQLUser
metadata:
  name: test.example@example-project.iam
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 "test.example@example-project.iam" is invalid: metadata.name: Invalid value: "test.example@example-project.iam": 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 no Kubernetes, mas 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: test.example@example-project.iam

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

Não foi possível remover campos da especificação de recurso

Remover um campo da especificação de um recurso do Config Connector (atualizando o arquivo .yaml do recurso e reaplicando ou usando kubectl edit para editar a especificação do recurso) não remove esse campo da especificação do recurso do Config Connector nem do recurso Google Cloud subjacente. Em vez disso, remover um campo da especificação apenas o torna gerenciado externamente.

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

  • Para um campo 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: "foo-bar@foo-project.iam.gserviceaccount.com"
    - external: "bar@foo-project.iam.gserviceaccount.com"

    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: ""

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

KNV2005: o sincronizador está atualizando o recurso em excesso

Se você estiver usando o Config Sync e receber erros KNV2005 para recursos do Config Connector, é provável que o Config Sync e o Config Connector estejam disputando o 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.

Dizemos que o Config Sync e o Config Connector estão "disputando" um recurso se eles continuarem atualizando os mesmos campos com valores diferentes. Uma atualização 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.

Lutar 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 não especificados no Config Sync e definidos como padrão 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 objeto, 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, a definição de valores padrão para subcampos é considerada uma mudança no valor da lista inteira.

Portanto, o Config Sync e o Config Connector vão acabar entrando em conflito se o Config Sync definir um campo de lista e o Config Connector usar os valores padrão de quaisquer subcampos nessa lista.

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

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

    Uma maneira de fazer isso é parar temporariamente a sincronização de configurações, esperar que o Config Connector termine de reconciliar o 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 no recurso no servidor da API Kubernetes definindo a anotação client.lifecycle.config.k8s.io/mutation como ignore. Leia mais sobre como fazer o Config Sync ignorar mutações de objetos.

  3. Para impedir que o Config Connector atualize totalmente a especificação do recurso, defina 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 verificar se o recurso é compatível com a anotação, consulte a página de referência de recursos correspondente. Leia mais sobre a anotação.

failed calling webhook

É possível que o Config Connector esteja em um estado em que não seja possível desinstalá-lo. Isso geralmente acontece ao usar o complemento do 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 o processo de 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 confira 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 Google Cloud documentação do IAM sobre como excluir uma conta de serviço.

Para evitar esse problema, sempre limpe os recursos IAMPolicy, IAMPartialPolicy e IAMPolicyMember do Config Connector 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.

Uma confusão 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 relação a determinados recursos de mensagens de registro de contêiner ou registros de auditoria do cluster do Kubernetes. Essas solicitações de exclusão são resultado de gatilhos externos, e o Config Connector está tentando reconciliar as solicitações de exclusão.

Para determinar por que um recurso foi excluído, analise a primeira solicitação de exclusão enviada a ele. 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 os 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"

Com essa consulta, você procuraria a primeira solicitação de exclusão e verificaria authenticationInfo.principalEmail dessa 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 do controlador do Config Connector, isso indica que um contêiner ou todo o pod 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, analisar os 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á resolvendo.

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

PodSecurityPolicy impede upgrades

Depois de mudar do complemento 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 se as PodSecurityPolicies estão impedindo o upgrade, verifique os eventos do config-connector-operator e procure um erro semelhante a este:

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, especifique a anotação na 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 na exclusão e você quiser se livrar deles do cluster do Kubernetes, force a exclusão excluindo os finalizadores.

É possível excluir os finalizadores de um recurso editando-o com kubectl edit, excluindo o campo metadata.finalizers e salvando o arquivo para preservar as mudanças 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 recursoGoogle Cloud subjacente. Isso significa que talvez seja necessário excluir manualmente seus recursos do 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 estiver usando o GKE, você poderá usar o Cloud Logging para consultar registros de um recurso específico com a seguinte consulta:

# 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 com o nome do cluster do GKE que executa o Config Connector
  • GKE_CLUSTER_LOCATION com o local do cluster do GKE que executa o Config Connector. Por exemplo, us-central1.
  • RESOURCE_KIND com o tipo do 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 suporte doGoogle Cloud .