Bekannte Probleme

Auf dieser Seite sind bekannte Probleme mit Config Connector aufgeführt.

Viele der hier aufgeführten Probleme wurden behoben. In der Spalte Version, in der der Fehler behoben wurde wird die Version angegeben, in der die Fehlerbehebung eingeführt wurde. Wenn Sie diese Fehlerbehebung erhalten möchten, führen Sie ein Upgrade auf die aufgeführte Version oder höher aus.

Wenn Sie am Google Developer Program teilnehmen, können Sie diese Seite speichern, um Benachrichtigungen zu erhalten, wenn eine Versionshinweis zu dieser Seite veröffentlicht wird. Weitere Informationen finden Sie unter Gespeicherte Seiten.

Zum Filtern der bekannten Probleme nach einer Produktversion oder -kategorie wählen Sie in den folgenden Drop-down-Menüs die gewünschten Filter aus.

Wählen Sie die Config Connector-Version aus:

Wählen Sie die Problemkategorie aus:

Sie können auch nach bekannten Problemen filtern:

Kategorie Früheste identifizierte Version Korrigierte Version Problem und Problemumgehung
Ressourcen 1.126.0 1.134.1

Wenn Sie versuchen, neue Config Connector-Ressourcen zu erstellen oder anzuwenden, lehnt der Kubernetes API-Server die Anfrage ab und blockiert die Ressourcenerstellung. Sie können keine neuen Ressourcen bereitstellen, aber vorhandene Ressourcen werden möglicherweise weiterhin normal abgeglichen. Dieses Problem wird durch eine bekannte Race-Bedingung in der Komponente cnrm-webhook-manager in Config Connector-Versionen vor 1.134.1 verursacht.

In Ihren Bereitstellungsausgaben oder API-Server-Logs wird möglicherweise ein Fehler wie der folgende angezeigt:

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
      

In den Logs des cnrm-webhook-manager-Pods wird möglicherweise Folgendes angezeigt:

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

Workaround:

Wenn Sie die Ressourcenerstellung sofort wieder freigeben möchten, können Sie die Webhook-Manager-Pods dazu zwingen, die richtigen Zertifikatsdaten zu synchronisieren und abzurufen. Starten Sie dazu das Deployment mit dem folgenden Befehl neu:

kubectl rollout restart deployment cnrm-webhook-manager -n cnrm-system
      
Ressourcen 1,134 1.134.2

Betroffene SQLInstance-Ressourcen bleiben möglicherweise im Status Updating hängen und es wird eine Fehlermeldung zur Annotation state-into-spec angezeigt.

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

Dieses Problem tritt auf, weil eine strengere Validierung, die in Version 1.134.0 eingeführt wurde, die „Zusammenführen“-Strategie für SQLInstance-Ressourcen fälschlicherweise abgelehnt hat, selbst wenn sie als Standard angewendet wurde. Dieser Fehler wurde in höheren Versionen behoben.

Direkter Abgleich 1,131 1,134

In Config Connector-Version 1.132.0 wurden Probleme eingeführt, die sich auf Ressourcen auswirken, die den direkten Abgleich verwenden.

Fehler: mehrfach vorhandener Controllername

In Version 1.132.0 können Ressourcen wie SpannerInstance und SecretManagerSecret möglicherweise nicht abgeglichen werden. Es wird ein Fehler angezeigt, der darauf hinweist, dass bereits ein Controller mit demselben Namen vorhanden ist:

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

SecretManagerSecret-Fehler „last-applied-configuration“

Wenn Sie den direkten Abgleich für eine SecretManagerSecret (mit der Annotation alpha.cnrm.cloud.google.com/reconciler: direct) in den Versionen 1.131.0 bis 1.133 aktivieren, schlägt der Abgleich möglicherweise mit einem API-Fehler fehl:

[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
      

Dies liegt daran, dass Config Connector fälschlicherweise versucht, interne Kubernetes-Annotationen als Labels an die Secret Manager API zu übergeben.

Installation, Netzwerk Kubernetes 1.19 1,43

Wenn Sie einen Fehler wie im folgenden Beispiel erhalten, liegt möglicherweise ein Problem mit Zertifikaten vor:

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
      

Dieses Problem tritt bei Kubernetes-Versionen ab 1.19 auf. Config Connector-Versionen ab 1.43 unterstützen die automatische Generierung des Zertifikats, was dieses Problem verhindern sollte.


Workaround:

Sie können das Problem umgehen, indem Sie die entsprechenden Zertifikate und Pods löschen:

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"
      

Nachdem Sie diese Ressourcen gelöscht haben, sollte das richtige Zertifikat neu generiert werden.

Nach oben