Abgleichsstrategie

Config Connector ist letztendlich konsistent

Bei der deklarativen Konfiguration definieren Sie den gewünschten Status des Systems. Das System versucht dann kontinuierlich, diesen Status so weit wie möglich zu gewährleisten. Weitere Informationen finden Sie unter Deklarative Verwaltung von Kubernetes-Objekten mithilfe von Konfigurationsdateien.

Mit Config Connector können Sie Ressourcen unabhängig von Abhängigkeitsbeziehungen in beliebiger Reihenfolge erstellen und aktualisieren. GKE verschiebt Ihre deklarierte Konfiguration in Richtung Eventual Consistency mit dem gewünschten Status.

Wenn Sie beispielsweise eine PubSubSubscription vor der entsprechenden PubSubTopic erstellen, wartet Config Connector, bis das Thema erstellt wurde, bevor Sie das zugehörige Abo erstellen.

Wie lange Ihre Config Connector-Installation inkonsistent bleibt, hängt von der Anzahl und der Art der verwalteten Ressourcen ab. Änderungen an einem GKE-Cluster werden in der Regel in Sekunden ausgeführt. Der Zeitraum zum Erstellen von Google Cloud-Ressourcen kann jedoch je nach Ressourcentyp variieren. Beispielsweise dauert das Erstellen eines einzelnen PubSubTopic Sekunden. Google Cloud-Ressourcen erreichen erst Konsistenz, wenn sie erstellt sind. Wenn Sie beispielsweise eine SQLInstance und eine SQLDatabase erstellen, ist das System für Minuten inkonsistent, während die Datenbank erstellt wird.

GKE und Config Connector gleichen jede Ressource mit jeder Aktualisierung oder nach einem Jitter-Perioid mit durchschnittlich 10 Minuten ab. Wenn beim Abgleich ein Fehler auftritt, wiederholt Config Connector ihn mit exponentiellem Backoff, wobei der maximale Backoff zwei Minuten beträgt. Sie können alle Fehler in den Ereignissen einer bestimmten Ressource aufrufen.

Änderbare, aber nicht lesbare Felder werden nur bei Änderungen berücksichtigt

Einige APIs enthalten nicht lesbare Felder, die jedoch geändert werden können (z. B. das Passwort für einen SQL-Nutzer). Da nicht ausgelesen werden kann, ob diese Felder geändert wurden, werden änderbare, aber nicht lesbare Felder nur aktualisiert, wenn die benutzerdefinierte Ressource geändert wird.

Ressourcen werden bei der Änderung unveränderlicher Felder nicht neu erstellt

Einige Felder in einer Ressource sind unveränderlich und können nicht abgeglichen werden, ohne die Zielressource zu löschen und anschließend neu zu erstellen.

In diesen Fällen gibt der Config Connector das Kubernetes-Ereignis „UpdatedFailed“ für die Ressource aus, anstatt diesen Vorgang neu zu erstellen. Der Nutzer muss dann die Ressource löschen und neu erstellen.

Beispielereignis:

Warning  UpdateFailed  37m (x643 over 15d)    computeinstance-controller  Update call failed: the desired mutation for the following field(s) is invalid: [bootDisk.0.InitializeParams.0.Image networkInterface.0.NetworkIp]