Best Practices für Config Connector
Auf dieser Seite werden Best Practices erläutert, die Sie bei der Verwendung von Config Connector berücksichtigen sollten.
API-Kontingentlimits verwalten
Wenn Fehler auftreten, die darauf hinweisen, dass Sie das API-Kontingentlimit überschritten haben, haben Sie möglicherweise zu viele Config Connector-Ressourcen derselben Art im selben Kontingentprojekt erstellt. Wenn Sie viele Ressourcen erstellen, können diese Ressourcen aufgrund der von Config Connector verwendeten Abgleichsstrategie zu viele API-Anfragen an denselben API-Endpunkt generieren.
Eine Möglichkeit, dieses Problem zu beheben, besteht darin, eine Kontingenterhöhung anzufordern. Wenn Sie sich bestätigt haben, dass der Kontingentfehler durch GET-Anfragen für die Google Cloud-Ressourcen verursacht wird, die von Ihren Config Connector-Ressourcen verwaltet werden, können Sie neben der Kontingenterhöhung eine der folgenden Optionen in Betracht ziehen:
- Erhöhen Sie das Abgleichsintervall für Ihre Config Connector-Ressourcen
- Ressourcen auf mehrere Projekte aufteilen
- Config Connector in den Namespace-Modus wechseln
Abgleichsintervall erhöhen
Sie können die Zeit zwischen dem Abgleich einer Ressource durch den Config Connector verlängern, um eine Überschreitung der API-Kontingente zu vermeiden. Es wird empfohlen, das Abgleichsintervall auf 1 Stunde festzulegen.
Folgen Sie der Anleitung unter Abgleichsintervall konfigurieren, um das Abgleichsintervall zu verlängern.
Ressourcen in mehrere Projekte aufteilen
Bei diesem Ansatz werden die Config Connector-Ressourcen auf verschiedene Projekte verteilt. Dieser Ansatz funktioniert gut, wenn neue Ressourcen hinzugefügt werden. Es kann jedoch riskant sein, vorhandene Ressourcen aufzuteilen, da Sie die vorhandenen Ressourcen löschen und in anderen Projekten neu erstellen müssen. Das Löschen von Ressourcen kann bei einigen Ressourcentypen wie SpannerInstance
- oder BigtableTable
-Ressourcen zu Datenverlusten führen. Sie sollten Ihre Daten vor dem Löschen sichern.
Führen Sie die folgenden Schritte aus, um vorhandene Config Connector-Ressourcen auf verschiedene Projekte aufzuteilen:
- Entscheiden Sie, welche Config Connector-Ressourcen Sie in verschiedene Projekte verschieben möchten.
- Löschen Sie die Config Connector-Ressourcen.
Die Annotation
cnrm.cloud.google.com/deletion-policy
darf nicht aufabandon
festgelegt sein. - Aktualisieren Sie das Feld
spec.projectRef
oder die Annotationcnrm.cloud.google.com/project-id
in der YAML-Konfiguration der Config Connector-Ressourcen, die Sie in die neuen Projekte verschieben möchten. - Gewähren Sie dem von Config Connector verwendeten IAM-Dienstkonto die richtigen Berechtigungen für die neuen Projekte.
- Wenden Sie die aktualisierte YAML-Konfiguration an, um die Config Connector-Ressourcen zu erstellen.
In den Namespace-Modus wechseln
Sie können verschiedene IAM-Dienstkonten, die zu verschiedenen Google Cloud-Projekten gehören, an verschiedene Namespaces binden, in denen Config Connector im Namespace-Modus installiert ist, und Ihre Ressourcen in verschiedene Namespaces aufteilen. Führen Sie dazu die folgenden Schritte aus:
Konfigurieren Sie Config Connector für die Ausführung im Namespace-Modus. Erstellen Sie neue IAM-Dienstkonten aus verschiedenen Projekten und binden Sie sie an verschiedene Namespaces. Folgen Sie dazu der Anleitung zum Konfigurieren von Config Connector für jedes Projekt.
Gewähren Sie den neuen IAM-Dienstkonten die entsprechenden Berechtigungen für das Projekt, das die Ressourcen enthält.
Entscheiden Sie, welche Config Connector-Ressourcen Sie in verschiedene Namespaces verschieben möchten.
Aktualisieren Sie die YAML-Konfiguration der Config Connector-Ressourcen und legen Sie die
cnrm.cloud.google.com/deletion-policy
-Annotationabandon
fest.Wenden Sie die aktualisierte YAML-Konfiguration an, um die Löschrichtlinie der Config Connector-Ressourcen zu aktualisieren.
Aktualisieren Sie das Feld
metadata.namespace
in der YAML-Konfiguration der Config Connector-Ressourcen, die Sie in die verschiedenen Namespaces verschieben möchten.Wenden Sie die aktualisierte YAML-Konfiguration an, um die verworfenen Ressourcen zu beziehen.
Knotenpools in GKE-Clustern verwalten
Beim Erstellen eines Clusters können Fehler auftreten, wenn Sie eine ContainerCluster
-Ressource in Config Connector anwenden und dann versuchen, den nodeConfig
oder andere knotenbezogene Felder durch Anwenden einer aktualisierten ContainerCluster
-Konfiguration zu aktualisieren. Diese Fehler sind auf unveränderliche Felder wie nodeConfig
, nodeConfig.labels
und nodeConfig.taint
zurückzuführen. Dabei handelt es sich um eine technische Einschränkung der zugrunde liegenden Google Cloud API.
Wenn Sie diese Felder aktualisieren müssen, können Sie mit der Ressource ContainerNodePool
Knotenpools verwalten, bei denen diese Felder nicht unveränderlich sind. Zum Verwalten von Knotenpools mit der Ressource ContainerNodePool
müssen Sie die Annotation cnrm.cloud.google.com/remove-default-node-pool: "true"
angeben. Durch diese Annotation wird der Standardknotenpool entfernt, der während der Clustererstellung erstellt wird. Zum Erstellen separater Knotenpools geben Sie dann nodeConfig
-Felder in ContainerNodePool
und nicht in ContainerCluster
an. Weitere Informationen finden Sie im Beispiel für die Ressource ContainerNodePool
.
Sie sollten die Annotation cnrm.cloud.google.com/state-into-spec: absent
sowohl für die Ressourcen ContainerCluster
als auch ContainerNodePool
festlegen. Durch diese Annotation werden potenzielle Abgleichsfehler während der Interaktion zwischen dem Config Connector-Controller und den zugrunde liegenden APIs vermieden.
Die folgenden Beispiele zeigen eine ContainerCluster
- und eine ContainerNodePool
-Konfiguration mit diesen Annotationen:
apiVersion: container.cnrm.cloud.google.com/v1beta1 kind: ContainerCluster metadata: name: containercluster-sample annotations: cnrm.cloud.google.com/remove-default-node-pool: "true" cnrm.cloud.google.com/state-into-spec: absent spec: description: A sample cluster. location: us-west1 initialNodeCount: 1
apiVersion: container.cnrm.cloud.google.com/v1beta1 kind: ContainerNodePool metadata: labels: label-one: "value-one" name: containernodepool-sample annotations: cnrm.cloud.google.com/state-into-spec: absent spec: location: us-west1 autoscaling: minNodeCount: 1 maxNodeCount: 3 nodeConfig: machineType: n1-standard-1 preemptible: false oauthScopes: - "https://www.googleapis.com/auth/logging.write" - "https://www.googleapis.com/auth/monitoring" clusterRef: name: containercluster-sample