Nicht angegebene Felder ignorieren

In diesem Dokument wird erläutert, wie Sie das Standardverhalten der Spezifikationsfelder mit der Annotation cnrm.cloud.google.com/state-into-spec ändern und wann Sie dies ändern müssen.

Wenn Config Connector eine Ressource in Google Cloud erstellt, übernehmen die in der Spezifikation nicht angegebenen Felder Werte aus der API, wie unter Felder extern verwalten beschrieben, es sei denn, sie sind nicht lesbar (z. B. nicht mit einer GET-HTTP-Anfrage verfügbar).

Das bedeutet, dass Felder, die in Ihrer ursprünglichen YAML-Datei nicht angegeben wurden, standardmäßig immer in der Spezifikation der Kubernetes-Ressource angezeigt werden. Wenn Sie also kubectl get <resource kind> <resource name> -oyaml ausführen, sind viele Felder der Ressourcenspezifikation nicht in der angewendeten YAML-Datei enthalten.

Angenommen, Sie können mit dem CRD-Schema zwei Felder mit den Namen foo und bar in der Spezifikation angeben, während in der angewendeten YAML-Datei nur foo angegeben ist:

spec:
  foo: "foo"

In der Kubernetes-Ressource wird ein weiteres Feld namens bar angezeigt, wenn die YAML-Datei erfolgreich angewendet wurde und die Ressource UpToDate ist:

spec:
  foo: "foo"
  bar: "bar"

Aufgrund der Komplexität der Interaktion zwischen Config Connector und Google Cloud APIs sollten Sie dieses Standardverhalten ändern und die Ressourcenspezifikation nicht mit nicht spezifizierten Feldern füllen.

Ausfüllen nicht angegebener Felder in der Spezifikation überspringen

Beim Erstellen der YAML-Datei können Sie den Wert der Annotation cnrm.cloud.google.com/state-into-spec als absent angeben. Dadurch wird das Ausfüllen nicht angegebener Felder in der Kubernetes-Ressourcenspezifikation übersprungen:

metadata:
  annotations:
    cnrm.cloud.google.com/state-into-spec: absent

Wenn keine Angabe erfolgt, hat diese Annotation den Standardwert merge. Das bedeutet, dass Config Connector alle nicht angegebenen Felder in die Spezifikation einfügt. Diese Annotation ist unveränderlich, d. h., Sie können den Annotationswert einer vorhandenen Config Connector-Ressource nicht aktualisieren.

Wenn Sie die Ressource bereits erstellt haben, aber den Wert dieser Annotation für ein anderes Befüllungsverhalten ändern möchten, gehen Sie so vor:

  1. Bearbeiten Sie die vorhandene Kubernetes-Ressource und fügen Sie sie cnrm.cloud.google.com/deletion-policy: abandon hinzu, damit beim Löschen im nächsten Schritt die zugrunde liegende Google Cloud-Ressource nicht gelöscht wird.

  2. Löschen Sie die Ressource aus dem Kubernetes-Cluster.

  3. Fügen Sie dem YAML-Code der Ressource die Annotation cnrm.cloud.google.com/state-into-spec: absent hinzu.

  4. (Optional) Entfernen Sie cnrm.cloud.google.com/deletion-policy: abandon aus dem YAML-Code.

  5. Wenden Sie die aktualisierte YAML-Datei an.

Zur weiteren Erläuterung des durch diese Annotation eingeführten Unterschieds wird davon ausgegangen, dass es eine Spezifikation mit dem folgenden Schema gibt:

foo1: string
foo2: string
bars:
- bar:
    br1: string
    br2: string
barz:
  bz1: string
  bz2: string

Nehmen wir außerdem an, dass Sie die Spezifikation in Ihrer YAML-Datei so angegeben haben:

spec:
  foo1: "foo1"
  bars:
  - br1: "1_br1"
  - br1: "2_br1"
  barz:
    bz1: "bz1"

Dann kann die ausgefüllte Spezifikation in der erstellten Kubernetes-Ressource standardmäßig so aussehen:

spec:
  foo1: "foo1"
  foo2: "foo2"
  bars:
  - br1: "1_br1"
    br2: "1_br2"
  - br1: "2_br1"
    br2: "2_br2"
  barz:
    bz1: "bz1"
    bz2: "bz2"

Wenn Sie cnrm.cloud.google.com/state-into-spec: absent festlegen, sieht die endgültige Spezifikation in der erstellten Kubernetes-Ressource so aus:

spec:
  foo1: "foo1"
  bars:
  - br1: "1_br1"
  - br1: "2_br1"
  barz:
    bz1: "bz1"

Verwendung von cnrm.cloud.google.com/state-into-spec: absent

Es gibt einige häufige Szenarien, in denen Sie eventuell cnrm.cloud.google.com/state-into-spec: absent festlegen sollten.

Nicht angegebene Felder in einer Liste extern verwalten

Config Connector behandelt alle Listenfelder in der Ressourcenspezifikation als atomare Felder. Daher wird Ihre Änderung, die außerhalb von Config Connector an einem Unterfeld in der Liste vorgenommen wurde, standardmäßig von Config Connector rückgängig gemacht. Sie können diese Annotation jedoch verwenden, damit Config Connector die Verwaltung von untergeordneten Feldern in der Liste aufhebt. Weitere Informationen finden Sie unter Verhalten für Listenfelder in der Ressourcenspezifikation.

Streitigkeiten zwischen Tools zur Konfigurationsverwaltung und Config Connector beheben

Wenn Sie Tools zur Konfigurationsverwaltung wie Config Sync oder Argo CD verwenden, stellen Sie möglicherweise einen Konflikt zwischen dem Konfigurationsverwaltungstool und Config Connector fest. Ein Beispiel hierfür ist der KNV2005-Fehler, der in der Anleitung zur Fehlerbehebung erläutert wird. Die Ursache für diese Art von Problemen sind folgende:

  1. Config Connector füllt die Werte aus und enthält standardmäßig nicht angegebene Werte in der Liste in der Spezifikation. spec.bars[0].br2 ist ein Beispiel.
  2. Sowohl die Konfigurationsverwaltungstools als auch Config Connector behandeln Listenfelder als atomar. Daher wird der hinzugefügte spec.bars[0].br2 von den Konfigurationsverwaltungstools als Drift behandelt und entfernt, um den drift zu korrigieren.

Zum Beheben dieser Probleme können Sie cnrm.cloud.google.com/state-into-spec: absent so festlegen, dass Config Connector kein nicht spezifiziertes Feld spec.bars[0].br2 in die Spezifikation einfügt.

Symmetrieprobleme beim GET/PUT beheben

Die GET/PUT-Symmetrie bezieht sich auf ein Designprinzip in der REST API. Insbesondere bedeutet dies, dass, wenn eine GET-Antwort als PUT-Anfrage an dieselbe URL gesendet wird, die Antwort "HTTP 200 OK" ohne Änderung des Status der zugrunde liegenden REST-Ressource als Ergebnis zurückgegeben wird.

Die nicht angegebenen Felder, die von Config Connector in der Ressourcenspezifikation ausgefüllt werden, stammen aus einer GET-Anfrage. Dies bedeutet, dass Config Connector bei zukünftigen Abgleichen möglicherweise eine PUT/PATCH-Anfrage an die zugrunde liegende Google Cloud API sendet, wobei diese nicht angegebenen Feldwerte aus der GET-Anfrage übernommen werden. Dies ist normalerweise kein Problem, aber es ist möglich, dass einige Google Cloud APIs die PUT/PATCH-Anfrage aufgrund dieser nicht angegebenen Feldwerte ablehnen. Im selben Beispiel kann der mit dem Wert „bz2“ ausgefüllte spec.barz.bz2 zu einem HTTP 400-Clientfehler oder anderen unerwarteten Antworten führen, wenn die API-Implementierung gegen das Symmetrieprinzip GET/PUT verstößt.

Um diese Kategorie von Problemen zu vermeiden, können Sie mit der Einstellung cnrm.cloud.google.com/state-into-spec: absent experimentieren und prüfen, ob die Fehler während des Abgleichs verschwinden werden.

Wann cnrm.cloud.google.com/state-into-spec: absent vermieden werden sollte

Sie sollten cnrm.cloud.google.com/state-into-spec: absent nicht festlegen, wenn Ihre Lösung von den Werten aus nicht festgelegten Feldern abhängt. Wenn Sie beispielsweise eine ComputeAddress-Ressource verwenden und den vom Server generierten spec.address-Wert benötigen, der in der ursprünglichen YAML-Datei möglicherweise ein nicht spezifiziertes Feld ist, sollten Sie diese Annotation nicht verwenden, da der Wert von spec.address dann nicht in die Kubernetes-Ressourcenspezifikation aufgenommen wird.