Problemas conhecidos

Nesta página, listamos os problemas conhecidos do Config Connector.

Muitos dos problemas listados aqui foram corrigidos. A coluna Versão corrigida indica a versão em que a correção foi introduzida. Para receber essa correção, faça upgrade para a versão listada ou mais recente.

Se você faz parte do Google Developer Program, salve esta página para receber notificações quando uma nota de lançamento relacionada a ela for publicada. Para saber mais, consulte Páginas salvas.

Para filtrar os problemas conhecidos por uma versão ou categoria do produto, selecione os filtros nos menus suspensos a seguir.

Selecione a versão do Config Connector:

Selecione a categoria do seu problema:

Ou filtre os problemas conhecidos:

Categoria Versão identificada mais antiga Versão corrigida Problema e solução alternativa
Recursos 1.126.0 1.134.1

Ao tentar criar ou aplicar novos recursos do Config Connector, o servidor de API Kubernetes rejeita a solicitação e bloqueia a criação de recursos. Não é possível implantar novos recursos, mas os recursos atuais podem continuar sendo reconciliados normalmente. Esse problema é causado por uma disputa conhecida no componente cnrm-webhook-manager nas versões do Config Connector anteriores à 1.134.1.

Talvez você veja um erro semelhante ao seguinte nas saídas de implantação ou nos registros do servidor de API:

failed calling webhook "container-annotation-handler.cnrm.cloud.google.com": failed to call webhook: Post "https://cnrm-validating-webhook.cnrm-system.svc:443/...": tls: failed to verify certificate: x509: certificate signed by unknown authority

Além disso, os registros do pod cnrm-webhook-manager podem exibir o seguinte:

http: TLS handshake error ... remote error: tls: bad certificate.

Alternativa:

Para desbloquear imediatamente a criação de recursos, force os pods do gerenciador de webhook a sincronizar e extrair os dados corretos do certificado reiniciando a implantação com o seguinte comando:

kubectl rollout restart deployment cnrm-webhook-manager -n cnrm-system
Recursos 1.134 1.134.2

Os recursos SQLInstance afetados podem ficar travados em um estado Updating com uma mensagem de erro sobre a anotação state-into-spec.

invalid value "merge" for "cnrm.cloud.google.com/state-into-spec" annotation

Esse problema ocorre porque uma validação mais rigorosa introduzida na versão 1.134.0 rejeitou incorretamente a estratégia de "mesclagem" para recursos SQLInstance, mesmo quando aplicada como padrão. Isso foi corrigido em versões mais recentes.
Reconciliador direto 1.131 1.134

A versão 1.132.0 do Config Connector apresentou problemas que afetam os recursos que usam o reconciliador direto.

Erro de nome de controlador duplicado

Na versão 1.132.0, recursos como SpannerInstance e SecretManagerSecret podem não ser reconciliados com um erro indicando que já existe um controlador com o mesmo nome:

error registering controller: error adding direct controller for SpannerInstance to a manager: error creating new controller: controller with name spannerinstance-controller already exists.

Erro "last-applied-configuration" do SecretManagerSecret

Se você ativar o reconciliador direto para um SecretManagerSecret (usando a anotação alpha.cnrm.cloud.google.com/reconciler: direct) nas versões 1.131.0 a 1.133, a reconciliação poderá falhar com um erro de API:

[kubectl.kubernetes.io/last-applied-configuration] must follow pattern [a-z0-9A-Z]+([_\.\-]*[a-z0-9A-Z]+)*), be less than 64 characters, and must have a UTF encoding of less than 128 bytes

Isso ocorre porque o Config Connector tenta transmitir incorretamente as anotações internas do Kubernetes como rótulos para a API Secret Manager.
Instalação, rede Kubernetes 1.19 1,43

Se você receber 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

Esse problema ocorre com as versões 1.19 e mais recentes do Kubernetes. As versões 1.43 e mais recentes do Config Connector são compatíveis com a geração automática do certificado, o que deve evitar esse problema.


Alternativa:

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 de excluir esses recursos, o certificado correto será gerado novamente.

Voltar ao início