Resolva problemas do Config Connector
Esta página descreve as técnicas de resolução de problemas que pode usar para resolver problemas do Config Connector e problemas comuns que pode encontrar quando usa o produto.
Técnicas básicas de resolução de problemas
Verifique a versão do Config Connector
Execute o seguinte comando para obter a versão do Config Connector instalada e consulte as notas de lançamento para verificar se a versão em execução suporta as funcionalidades e os recursos que quer usar:
kubectl get ns cnrm-system -o jsonpath='{.metadata.annotations.cnrm\.cloud\.google\.com/version}'
Verifique o estado e os eventos do recurso
Normalmente, pode determinar o problema com os recursos do Config Connector inspecionando o estado dos seus recursos no Kubernetes. Verificar o estado e os eventos de um recurso é particularmente útil para determinar se o Config Connector não conseguiu reconciliar o recurso e por que motivo a reconciliação falhou.
Verifique se o Config Connector está em execução
Para verificar se o Config Connector está em execução, confirme se todos os respetivos pods estão
READY:
kubectl get pod -n cnrm-system
Exemplo de resultado:
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 tiver o Config Connector instalado no modo com espaço de nomes, terá um pod de controlador (cnrm-controller-manager) para cada espaço de nomes responsável pela gestão dos recursos do Config Connector nesse espaço de nomes.
Pode verificar o estado do pod do controlador responsável por um espaço de nomes específico executando o seguinte comando:
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 espaço de nomes.
Verifique os registos do comando
O pod do controlador regista informações e erros relacionados com a conciliação dos recursos do Config Connector.
Pode verificar os registos do pod do controlador executando o seguinte comando:
kubectl logs -n cnrm-system \
-l cnrm.cloud.google.com/component=cnrm-controller-manager \
-c manager
Se tiver o Config Connector instalado no modo com espaço de nomes, o comando anterior mostra os registos de todos os pods do controlador combinados. Pode verificar os registos do pod do controlador para um espaço de nomes específico executando o seguinte comando:
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 espaço de nomes.
Leia mais sobre como inspecionar e consultar os registos do Config Connector.
Abandone e adquira o recurso
Em alguns casos, pode ter de atualizar um campo imutável num recurso. Uma vez que não pode editar campos imutáveis, tem de abandonar e, em seguida, adquirir o recurso:
- Atualize a configuração YAML do recurso Config Connector e defina a anotação
cnrm.cloud.google.com/deletion-policycomoabandon. - Aplique a configuração YAML atualizada para atualizar a política de eliminação do recurso do Config Connector.
- Abandonar o recurso do Config Connector.
- Atualize os campos imutáveis que têm de ser alterados na configuração YAML.
- Aplique a configuração YAML atualizada para adquirir o recurso abandonado.
Problemas comuns
O recurso continua a ser atualizado a cada 5 a 15 minutos
Se o seu recurso do Config Connector continuar a alternar entre um estado UpToDate e um estado Updating a cada 5 a 10 minutos, é provável que o Config Connector esteja a detetar diferenças não intencionais entre o estado pretendido e o estado real do recurso, o que faz com que o Config Connector atualize constantemente o recurso.
Primeiro, confirme que não tem sistemas externos que estejam constantemente a modificar o Config Connector ou o recurso Google Cloud (por exemplo, pipelines de CI/CD, controladores personalizados, tarefas cron, etc.).
Se o comportamento não se dever a um sistema externo, verifique se Google Cloud está a alterar algum dos valores especificados no seu recurso do Config Connector. Por exemplo, em alguns casos, Google Cloud altera a formatação (por exemplo, a utilização de maiúsculas) dos valores dos campos, o que gera uma diferença entre o estado pretendido e o estado real do recurso.
Obtenha o estado do recurso Google Cloud através da API REST (por exemplo, para ContainerCluster) ou da Google Cloud CLI. Em seguida, compare esse estado com o recurso do Config Connector. Procure campos cujos valores não correspondam e, em seguida, atualize o recurso do Config Connector para corresponder. Em particular, procure valores que tenham sido formatados novamente por Google Cloud. Por exemplo, consulte os problemas do GitHub #578 e #294.
Tenha em atenção que este não é um método perfeito, uma vez que o Config Connector e osGoogle Cloud modelos de recursossão diferentes, mas deve permitir-lhe detetar a maioria dos casos de diferenças não intencionais.
Se não conseguir resolver o seu problema, consulte a secção Ajuda adicional.
As eliminações de espaços de nomes ficam bloqueadas no estado "A terminar"
As eliminações de espaços de nomes podem ficar bloqueadas em Terminating se tiver o Config Connector instalado no modo com espaço de nomes e se o ConfigConnectorContext do espaço de nomes tiver sido eliminado antes de todos os recursos do Config Connector nesse espaço de nomes serem eliminados. Quando o ConfigConnectorContext de um espaço de nomes é eliminado, o Config Connector é desativado para esse espaço de nomes, o que impede a eliminação de quaisquer recursos do Config Connector restantes nesse espaço de nomes.
Para corrigir este problema, tem de fazer uma limpeza forçada e, em seguida, eliminar manualmente os recursos subjacentes. Google Cloud
Para mitigar este problema no futuro, elimine apenas o ConfigConnectorContext
depois de todos os recursos do Config Connector no respetivo espaço de nomes terem sido eliminados do
Kubernetes. Evite eliminar espaços de nomes inteiros antes de todos os recursos do Config Connector nesse espaço de nomes terem sido eliminados, uma vez que o ConfigConnectorContext pode ser eliminado primeiro.
Veja também como a eliminação de um espaço de nomes que contenha um projeto e os respetivos elementos subordinados ou uma pasta e os respetivos elementos subordinados pode ficar bloqueada.
Eliminações de recursos bloqueadas em "DeleteFailed" após a eliminação do projeto
As eliminações de recursos do Config Connector podem ficar bloqueadas em DeleteFailed se o projeto Google Cloud tiver sido eliminado previamente.
Para corrigir este problema, restaure o projeto em Google Cloud para permitir que o Config Connector elimine os recursos subordinados restantes do Kubernetes. Em alternativa, pode fazer uma limpeza forçada.
Para mitigar este problema no futuro, elimine apenas os Google Cloud projetos
depois de todos os respetivos recursos do Config Connector filho terem sido eliminados do
Kubernetes. Evite eliminar espaços de nomes inteiros que possam conter um recurso Project e os respetivos recursos do Config Connector, uma vez que o recurso Project pode ser eliminado primeiro.
Metadados do Compute Engine não definidos
Se o seu recurso do Config Connector tiver um estado UpdateFailed com uma mensagem a indicar que os metadados do Compute Engine não estão definidos, é provável que a conta de serviço do IAM usada pelo Config Connector não exista.
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, certifique-se de que a conta de serviço da IAM usada pelo Config Connector existe.
Para mitigar este problema no futuro, certifique-se de que segue as instruções de instalação do Config Connector.
Erro 403: o pedido tinha âmbitos de autenticação insuficientes
Se o seu recurso do Config Connector tiver um estado UpdateFailed com uma mensagem
a indicar um erro 403 devido a âmbitos de autenticação insuficientes, é provável que o Workload
Identity não esteja ativado no
seu 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 os seguintes passos:
Guarde a seguinte configuração do 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-managerSe instalou o Config Connector usando o modo com espaço de nomes,
serviceAccountNamedeve sercnrm-controller-manager-NAMESPACE. SubstituaNAMESPACEpelo espaço de nomes que usou durante a instalação.Crie o pod no seu cluster do GKE:
kubectl apply -f wi-test.yamlAbra uma sessão interativa no pod:
kubectl exec -it workload-identity-test \ --namespace cnrm-system \ -- /bin/bashIndique a sua identidade:
gcloud auth listConfirme se a identidade indicada corresponde à conta do serviço Google associada aos seus recursos.
Se vir a conta de serviço predefinida do Compute Engine, significa que a federação de identidades da carga de trabalho para o GKE não está ativada no cluster e/ou no conjunto de nós do GKE.
Saia da sessão interativa e, em seguida, elimine o pod do cluster do GKE:
kubectl delete pod workload-identity-test \ --namespace cnrm-system
Para corrigir este problema, use um cluster do GKE com a Workload Identity Federation para o GKE ativada.
Se continuar a ver o mesmo erro num cluster do GKE com a federação de identidades de cargas de trabalho para o GKE ativada, certifique-se de que também ativou a federação de identidades de cargas de trabalho para o GKE nos conjuntos de nós do cluster. Leia mais sobre como ativar a Workload Identity Federation para o GKE em pools de nós existentes. Recomendamos que ative a Workload Identity Federation para o GKE em todos os conjuntos de nós do cluster, uma vez que o Config Connector pode ser executado em qualquer um deles.
403 Forbidden: o autor da chamada não tem autorização; consulte a documentação da Workload Identity Federation para o GKE
Se o seu recurso do Config Connector tiver um estado UpdateFailed com uma mensagem
que indica um erro 403 devido à Workload Identity Federation para o GKE, é provável que
a conta de serviço do Kubernetes do Config Connector não tenha as
autorizações do IAM adequadas para se fazer passar pela sua conta de serviço do IAM
como utilizador da Workload Identity Federation para o 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 autorização de IAM
Se o seu recurso do Config Connector tiver um estado UpdateFailed com uma mensagem a indicar que o autor da chamada não tem uma autorização do IAM, é provável que a conta de serviço do IAM usada pelo Config Connector não tenha a autorização do IAM indicada na mensagem necessária para gerir 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 continuar a ver o mesmo erro depois de conceder à conta de serviço do IAM as autorizações do IAM adequadas, verifique se o recurso está a ser criado no projeto correto. Verifique o campo spec.projectRef do recurso do Config Connector (ou a respetiva anotação cnrm.cloud.google.com/project-id se o recurso não suportar um campo spec.projectRef) e confirme se o recurso está a fazer referência ao projeto correto. Tenha em atenção que o Config Connector usa o nome do espaço de nomes como o ID do projeto se nem o recurso nem o espaço de nomes especificarem um projeto de destino.
Leia mais sobre como configurar o projeto de destino para recursos
com âmbito do projeto.
Se continuar a ver o mesmo erro, verifique se a Workload Identity Federation para o GKE está ativada no seu cluster do GKE.
Para mitigar este problema no futuro, certifique-se de que segue as instruções de instalação do Config Connector.
Versão não suportada em instalações de suplementos do Config Connector
Se não conseguir ativar o suplemento Config Connector com êxito, é apresentada a seguinte mensagem de erro: Node version 1.15.x-gke.x s unsupported. Para resolver este erro, verifique se a versão do cluster do GKE cumpre os requisitos de versão e funcionalidades.
Para obter todas as versões válidas para os seus clusters, execute o seguinte comando:
gcloud container get-server-config --format "yaml(validMasterVersions)" \
--zone ZONE
Substitua ZONE pela zona do Compute Engine.
Escolha uma versão da lista que cumpra os requisitos.
A mensagem de erro também é apresentada se a Workload Identity Federation para o GKE ou o GKE Monitoring estiverem desativados. Certifique-se de que estas funcionalidades estão ativadas para corrigir o erro.
Não é possível fazer alterações a campos imutáveis
O Config Connector rejeita atualizações de campos imutáveis na admissão.
Por exemplo, a atualização de um campo imutável com kubectl apply faz com que o comando falhe imediatamente.
Isto significa que as ferramentas que reaplicam continuamente recursos (por exemplo, o GitOps) podem ficar bloqueadas ao atualizar um recurso se não processarem erros de admissão.
Uma vez que o Config Connector não permite atualizações de campos imutáveis, a única forma de fazer essa atualização é eliminar e recriar o recurso.
Erro ao atualizar os campos imutáveis quando não existe nenhuma atualização
Pode ver os seguintes erros no estado do recurso do Config Connector pouco depois de 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)
Isto pode não significar que atualizou efetivamente o recurso, mas o motivo pode ser que a Google Cloud API tenha feito uma alteração a um campo imutável Google Cloud que foi gerido por si no recurso do Config Connector. Isto causou a incompatibilidade entre o estado pretendido e o estado em direto dos campos imutáveis.
Pode resolver o problema atualizando os valores desses campos imutáveis no recurso do Config Connector para corresponderem ao estado em direto. Para o conseguir, deve concluir os seguintes passos:
- Atualize a configuração YAML do recurso Config Connector e defina a anotação
cnrm.cloud.google.com/deletion-policycomoabandon. - Aplique a configuração YAML atualizada para atualizar a política de eliminação do recurso do Config Connector.
- Abandone o recurso do Config Connector.
- Imprima o estado publicado do Google Cloud recurso correspondente através da CLI gcloud.
- Encontre a incompatibilidade entre o resultado da CLI gcloud e a configuração YAML do recurso do Config Connector e atualize esses campos na configuração YAML.
- Aplique a configuração YAML atualizada para adquirir o recurso abandonado.
O recurso não tem estado
Se os seus recursos não tiverem um campo status, é provável que o Config Connector não esteja a ser executado corretamente. Verifique se o Config Connector está em execução.
Nenhuma correspondência para o tipo "Foo"
Quando ocorre este erro, significa que o cluster do Kubernetes não tem o tipo de recurso Foo instalado.
Verifique se o tipo é um tipo de recurso suportado pelo Config Connector.
Se o tipo for suportado, significa que a instalação do Config Connector está desatualizada ou é inválida.
Se instalou o Config Connector através do suplemento do GKE, a instalação deve ser atualizada automaticamente. Se instalou manualmente o Config Connector, tem de fazer uma atualização manual.
Verifique o repositório do GitHub para determinar que tipos de recursos são suportados por que versões do Config Connector (por exemplo, aqui estão os tipos suportados pelo Config Connector v1.44.0).
As etiquetas não são propagadas para o recurso Google Cloud
O Config Connector propaga as etiquetas encontradas em metadata.labels para o recursoGoogle Cloud subjacente. No entanto, tenha em atenção que nem todos os Google Cloud
recursos suportam etiquetas. Consulte a documentação da API REST do recurso (por exemplo, aqui encontra a documentação da API para PubSubTopic) para ver se suportam etiquetas.
Falha ao chamar o webhook x509: o certificado baseia-se no campo de nome comum antigo
Se vir um erro semelhante ao seguinte exemplo, pode estar a ter um problema com os 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 este problema, elimine 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 de eliminar estes recursos, o certificado correto é regenerado.
Para mais informações sobre este erro, consulte o problema do GitHub.
Erro devido a carateres especiais no nome do recurso
Os carateres especiais não são válidos no campo metadata.name do Kubernetes.
Se vir um erro semelhante ao exemplo seguinte, é provável que o recurso metadata.name tenha um valor com carateres 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 seguinte contém um caráter 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 tentar criar este recurso, recebe 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 quiser dar ao seu recurso um nome que não seja um nome Kubernetes válido, mas que seja um nome de recurso Google Cloud válido, pode usar o campo resourceID, conforme mostrado no exemplo seguinte:
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
Esta 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 (através da atualização do ficheiro .yaml do recurso e da reaplicação ou através da utilização de kubectl edit para editar a especificação do recurso) não remove efetivamente esse campo da especificação do recurso do Config Connector nem do recurso Google Cloud subjacente.
Em alternativa, a remoção de um campo da especificação apenas torna esse campo gerido externamente.
Se quiser alterar o valor de um campo para vazio ou predefinido no recurso Google Cloud subjacente, tem de definir o campo como zero na especificação do recurso do Config Connector:
Para o campo do tipo de lista, defina o campo como uma lista vazia usando
[].O exemplo seguinte mostra o campo
targetServiceAccountsque queremos remover:spec: targetServiceAccounts: - external: "foo-bar@foo-project.iam.gserviceaccount.com" - external: "bar@foo-project.iam.gserviceaccount.com"Para remover este campo, defina o valor como vazio:
spec: targetServiceAccounts: []Para um campo de tipo primitivo, defina o campo como vazio através de uma das seguintes opções:
Tipo Valor vazio de string "" booleano "false" número inteiro 0 O exemplo seguinte mostra o campo
identityNamespaceque queremos remover:spec: workloadIdentityConfig: identityNamespace: "foo-project.svc.id.goog"Para remover este campo, defina o valor como vazio:
spec: workloadIdentityConfig: identityNamespace: ""Para campos do tipo de objeto, atualmente, no Config Connector, não existe uma forma fácil de definir um campo do tipo de objeto completo como "NULL". Pode tentar definir os subcampos do tipo de objeto como vazios ou predefinidos seguindo as orientações acima e verificar se funciona.
KNV2005: o sincronizador está a atualizar o recurso em excesso
Se estiver a usar a Sincronização de configuração e estiver a ver erros KNV2005 para recursos do Config Connector, é provável que a Sincronização de configuração e o Config Connector estejam a competir pelo recurso.
Exemplo de mensagem de registo:
KNV2005: detected excessive object updates, approximately 6 times per minute. This may indicate Config Sync is fighting with another controller over the object.
Diz-se que o Config Sync e o Config Connector estão a "lutar" por um recurso se atualizarem continuamente os mesmos campos para valores diferentes. A atualização de um faz com que o outro atue e atualize o recurso, o que faz com que o outro atue e atualize o recurso, e assim sucessivamente.
As lutas não sã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 predefinição pelo Config Connector são ignorados pelo Config Sync. Por conseguinte, para a maioria dos campos, a sincronização de configuração e o Config Connector nunca devem acabar por atualizar o mesmo campo para valores diferentes.
Existe uma exceção: os campos de listas. Tal como o Config Connector pode definir subcampos predefinidos em campos de objetos, o Config Connector também pode definir subcampos predefinidos em objetos dentro de listas. No entanto, uma vez que os campos de lista nos recursos do Config Connector são atómicos, a definição predefinida dos subcampos é considerada uma alteração do valor da lista na totalidade.
Por conseguinte, o Config Sync e o Config Connector acabam por entrar em conflito se o Config Sync definir um campo de lista e o Config Connector definir por predefinição quaisquer subcampos nessa lista.
Para contornar este problema, tem as seguintes opções:
Atualize o manifesto de recursos no repositório do Config Sync para corresponder ao que o Config Connector está a tentar definir para o recurso.
Uma forma de o fazer é parar temporariamente a sincronização das configurações, aguardar que o Config Connector termine a conciliação do recurso e, em seguida, atualizar o manifesto do recurso para corresponder ao recurso no servidor da API Kubernetes.
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/mutationcomoignore. Leia mais sobre como fazer com que o Config Sync ignore as mutações de objetos.Impeça o Config Connector de atualizar totalmente a especificação do recurso definindo a anotação
cnrm.cloud.google.com/state-into-speccomoabsentno recurso. Esta anotação não é suportada para todos os recursos. Para ver se o seu recurso suporta a anotação, consulte a página de referência do recurso correspondente. Leia mais acerca da anotação.
failed calling webhook
É possível que o Config Connector esteja num estado em que não o pode desinstalar. Isto acontece normalmente quando usa o suplemento Config Connector e desativa o Config Connector antes de remover os CRDs do Config Connector. Quando tenta desinstalar, recebe um erro semelhante ao seguinte:
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 este erro, tem de eliminar manualmente os webhooks:
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
Em seguida, pode proceder à desinstalação do Config Connector.
Erro de atualização com IAMPolicy, IAMPartialPolicy e IAMPolicyMember
Se eliminar um recurso do IAMServiceAccountConfig Connector antes de limpar os recursos IAMPolicyIAMPartialPolicy e IAMPolicyMember que dependem dessa conta de serviço, o Config Connector não consegue localizar a conta de serviço referenciada nesses recursos do IAM durante a conciliação. Isto resulta num estado UpdateFailed com uma mensagem de erro semelhante à seguinte:
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 este problema, verifique as suas contas de serviço e veja se a conta de serviço necessária para esses recursos do IAM foi eliminada.
Se a conta de serviço for eliminada, limpe também os recursos do IAM Config Connector relacionados. Para IAMPolicyMember, elimine o recurso completo. Para o IAMPolicy e o IAMParitialPolicy, remova apenas as associações que envolvam a conta de serviço eliminada.
No entanto, esta limpeza não remove imediatamente as associações de funções Google Cloud . As Google Cloud vinculações de funções são retidas durante 60 dias devido à retenção na conta de serviço eliminada.
Para mais informações, consulte a Google Cloud documentação do IAM sobre como eliminar uma conta de serviço.
Para evitar este problema, deve sempre limpar os recursos do Config Connector IAMPolicy, IAMPartialPolicy e IAMPolicyMember antes de eliminar o IAMServiceAccount referenciado.
Recurso eliminado pelo Config Connector
O Config Connector nunca elimina os seus recursos sem uma causa externa.
Por exemplo, a execução de kubectl delete, a utilização de ferramentas de gestão de configuração como o Argo CD ou a utilização de um cliente API personalizado podem causar a eliminação de recursos.
Uma ideia errada comum é que o Config Connector iniciou e eliminou alguns dos recursos no seu cluster. Por exemplo, se estiver a usar o Config Connector, pode reparar em pedidos de eliminação do gestor do controlador do Config Connector em relação a determinados recursos a partir de mensagens de registo de contentores ou registos de auditoria do cluster Kubernetes. Estas solicitações de eliminação são o resultado de acionadores externos e o Config Connector está a tentar conciliar as solicitações de eliminação.
Para determinar o motivo pelo qual um recurso foi eliminado, tem de analisar o primeiro pedido de eliminação que foi enviado para o recurso correspondente. A melhor forma de investigar isto é examinar os registos de auditoria do cluster do Kubernetes.
Por exemplo, se estiver a usar o GKE, pode usar o Cloud Logging para consultar os registos de auditoria do cluster do GKE. Por exemplo, se quiser procurar as solicitações de eliminação iniciais de um recurso BigQueryDataset denominado foo no espaço de nomes bar, executaria uma consulta como a seguinte:
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 esta consulta, procura o primeiro pedido de eliminação e, em seguida, verifica o elemento
authenticationInfo.principalEmail dessa mensagem do registo de eliminação para determinar a
causa da eliminação.
Controller Pod OOMKilled
Se vir um erro OOMKilled num pod do controlador do Config Connector, indica que um contentor ou todo o pod foi terminado porque usou mais memória do que o permitido.
Pode verificar isto executando o comando kubectl describe. O estado do Pod pode aparecer como OOMKilled ou Terminating.
Além disso, a análise detalhada dos registos de eventos do pod pode revelar ocorrências de eventos relacionados com OOM.
kubectl describe pod POD_NAME -n cnrm-system
Substitua POD_NAME pelo Pod para o qual está a resolver problemas.
Para resolver este problema, pode usar o recurso personalizado ControllerResource para aumentar o pedido de memória e o limite de memória para o pod.
PodSecurityPolicy impede atualizações
Depois de mudar do suplemento Config Connector para uma instalação manual e atualizar o Config Connector para uma nova versão, a utilização de PodSecurityPolicies pode impedir a atualização dos cnrm pods.
Para confirmar que as PodSecurityPolicies estão a impedir a atualização,
verifique 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 este problema, tem de
especificar 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 seus recursos do Config Connector estiverem bloqueados na eliminação e quiser simplesmente livrar-se deles do seu cluster do Kubernetes, pode forçar a respetiva eliminação eliminando os respetivos finalizadores.
Pode eliminar os finalizadores de um recurso editando o recurso através de kubectl
edit, eliminando o campo metadata.finalizers e, em seguida, guardando o ficheiro para preservar as alterações ao servidor da API Kubernetes.
Uma vez que a eliminação dos finalizadores de um recurso permite que o recurso seja eliminado imediatamente do cluster do Kubernetes, o Config Connector pode (mas não necessariamente) não ter a oportunidade de concluir a eliminação do recursoGoogle Cloud subjacente. Isto significa que pode querer eliminar manualmente os seus recursos Google Cloud posteriormente.
Monitorização
Métrica
Pode usar o Prometheus para recolher e mostrar métricas do Config Connector.
Registo
Todos os pods do Config Connector produzem registos estruturados no formato JSON.
Os registos dos pods do controlador são particularmente úteis para depurar problemas com a conciliação de recursos.
Pode consultar registos de recursos específicos filtrando os seguintes campos nas mensagens de registo:
logger: contém o tipo do recurso em letras minúsculas. Por exemplo, os recursosPubSubTopictêm umloggerdepubsubtopic-controller.resource.namespace: contém o espaço de nomes do recurso.resource.name: contém o nome do recurso.
Usar o Cloud Logging para consultas de registos avançadas
Se estiver a usar o GKE, pode usar o Cloud Logging para consultar os registos 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 o seguinte:
GKE_CLUSTER_NAMEcom o nome do cluster do GKE que executa o Config ConnectorGKE_CLUSTER_LOCATIONcom a localização do cluster do GKE que executa o Config Connector. Por exemplo,us-central1.RESOURCE_KINDcom o tipo de recurso em letras minúsculas. Por exemplo,pubsubtopic.RESOURCE_NAMESPACEcom o espaço de nomes do recurso.RESOURCE_NAMEcom o nome do recurso.
Ajuda adicional
Para obter ajuda adicional, pode apresentar um problema no GitHub ou contactar o Google Cloud apoio técnico.