Best Practices für Config Connector

Auf dieser Seite werden Best Practices für die Verwendung von Config Connector beschrieben.

API-Kontingentlimits verwalten

Wenn Sie auf Fehler stoßen, die darauf hinweisen, dass Sie das API-Kontingentlimit überschritten haben, haben Sie möglicherweise zu viele Config Connector-Ressourcen desselben Typs im selben Kontingentprojekt erstellt. Wenn Sie viele Ressourcen erstellen, können diese Ressourcen aufgrund der von Config Connector verwendeten Abstimmungsstrategie zu viele API-Anfragen an denselben API-Endpunkt generieren.

Eine Möglichkeit zur Behebung dieses Problems ist, eine Kontingenterhöhung zu beantragen. Wenn Sie bestätigt haben, dass der Kontingentfehler durch GET-Anfragen an die Google Cloud Ressourcen verursacht wird, die von Ihren Config Connector-Ressourcen verwaltet werden, können Sie neben einer Kontingenterhöhung eine der folgenden Optionen in Betracht ziehen:

Abstimmungsintervall verlängern

Sie können die Zeit zwischen dem Abgleich einer Ressource durch Config Connector verlängern, um API-Kontingente nicht zu überschreiten. Wir empfehlen, das Abgleichsintervall auf 1 Stunde festzulegen.

Wenn Sie das Abstimmungsintervall verlängern möchten, folgen Sie der Anleitung unter Abstimmungsintervall konfigurieren.

Ressourcen auf mehrere Projekte aufteilen

Bei diesem Ansatz werden Ihre Config Connector-Ressourcen auf verschiedene Projekte verteilt. Dieser Ansatz eignet sich gut zum Hinzufügen neuer Ressourcen. Das Aufteilen vorhandener Ressourcen kann jedoch riskant sein, 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 Datenverlust führen. Sie sollten Ihre Daten sichern, bevor Sie sie löschen.

So teilen Sie vorhandene Config Connector-Ressourcen in verschiedene Projekte auf:

  1. Entscheiden Sie, welche Config Connector-Ressourcen Sie in andere Projekte verschieben möchten.
  2. Config Connector-Ressourcen löschen Die Anmerkung cnrm.cloud.google.com/deletion-policy darf nicht auf abandon festgelegt sein.
  3. Aktualisieren Sie das Feld spec.projectRef oder die Annotation cnrm.cloud.google.com/project-id in der YAML-Konfiguration der Config Connector-Ressourcen, die Sie in die neuen Projekte verschieben möchten.
  4. Gewähren Sie dem IAM-Dienstkonto, das von Config Connector verwendet wird, die erforderlichen Berechtigungen für die neuen Projekte.
  5. Wenden Sie die aktualisierte YAML-Konfiguration an, um die Config Connector-Ressourcen zu erstellen.

Zum Namespace-Modus wechseln

Sie können verschiedene IAM-Dienstkonten, die zu verschiedenenGoogle Cloud -Projekten gehören, an verschiedene Namespaces binden, in denen Config Connector im Namespace-Modus installiert ist, und Ihre Ressourcen in verschiedene Namespaces aufteilen. Gehen Sie dazu so vor:

  1. Config Connector für die Ausführung im Namespace-Modus konfigurieren 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.

  2. Gewähren Sie den neuen IAM-Dienstkonten die erforderlichen Berechtigungen für das Projekt, das die Ressourcen enthält.

  3. Entscheiden Sie, welche Config Connector-Ressourcen Sie in andere Namespaces verschieben möchten.

  4. Aktualisieren Sie die YAML-Konfiguration der Config Connector-Ressourcen und legen Sie die Annotation cnrm.cloud.google.com/deletion-policy auf abandon fest.

  5. Wenden Sie die aktualisierte YAML-Konfiguration an, um die Löschrichtlinie der Config Connector-Ressourcen zu aktualisieren.

  6. Config Connector-Ressourcen aufgeben

  7. Aktualisieren Sie das Feld metadata.namespace in der YAML-Konfiguration der Config Connector-Ressourcen, die Sie in die verschiedenen Namespaces verschieben möchten.

  8. Wenden Sie die aktualisierte YAML-Konfiguration an, um die verlassenen Ressourcen zu übernehmen.

Knotenpools in GKE-Clustern verwalten

Möglicherweise treten Fehler auf, wenn Sie einen Cluster erstellen, indem Sie eine ContainerCluster-Ressource in Config Connector anwenden, und dann versuchen, die nodeConfig oder andere knotenbezogene Felder zu aktualisieren, indem Sie eine aktualisierte ContainerCluster-Konfiguration anwenden. Diese Fehler sind auf unveränderliche Felder wie nodeConfig, nodeConfig.labels und nodeConfig.taint zurückzuführen, was eine technische Einschränkung der zugrunde liegenden Google Cloud API ist.

Wenn Sie diese Felder aktualisieren müssen, können Sie die Ressource ContainerNodePool verwenden, um Knotenpools zu verwalten, in denen diese Felder nicht unveränderlich sind. Wenn Sie Knotenpools mit der ContainerNodePool-Ressource verwalten möchten, müssen Sie die Annotation cnrm.cloud.google.com/remove-default-node-pool: "true" angeben. Mit dieser Annotation wird der Standardknotenpool entfernt, der bei der Clustererstellung erstellt wird. Wenn Sie separate Knotenpools erstellen möchten, geben Sie nodeConfig-Felder in ContainerNodePool anstelle von ContainerCluster an. Ein Beispiel für eine ContainerNodePool-Ressource finden Sie als Referenz.

Sie sollten die Annotation cnrm.cloud.google.com/state-into-spec: absent sowohl für die ContainerCluster- als auch für die ContainerNodePool-Ressourcen festlegen. Diese Annotation verhindert potenzielle Abgleichsfehler bei der Interaktion zwischen dem Config Connector-Controller und den zugrunde liegenden APIs.

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