Best Practices für Config Connector

Auf dieser Seite werden Best Practices für die Verwendung von Config Connector erläutert.

API-Kontingentlimits verwalten

Wenn Sie Fehler erhalten, die darauf hinweisen, dass Sie das API-Kontingent ü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 aufgrund der Abgleichsstrategie, die Config Connector verwendet, zu viele API-Anfragen an denselben API-Endpunkt generieren.

Eine Möglichkeit zur Behebung dieses Problems ist, eine Kontingenterhöhung anzufordern. Wenn Sie festgestellt haben, dass der Kontingentfehler durch GET-Anfragen an die Google Cloud von Ihrem Config Connector verwalteten Ressourcen verursacht wird, können Sie neben einer Kontingenterhöhung eine der folgenden Optionen in Betracht ziehen:

Intervall für die Abgleiche verlängern

Sie können die Zeit zwischen den Abgleichvorgängen von Config Connector für eine Ressource verlängern, um API-Kontingente nicht zu überschreiten. Wir empfehlen, das Intervall für die Abgleiche auf 1 Stunde festzulegen.

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

Ressourcen auf mehrere Projekte aufteilen

Bei diesem Ansatz werden Ihre 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 verschiedenen Projekten neu erstellen müssen. Das Löschen von Ressourcen kann bei einigen Arten von Ressourcen zu Datenverlusten führen, z. B. bei SpannerInstance- oder BigtableTable-Ressourcen. 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. Löschen Sie die Config Connector-Ressourcen. Die Anmerkung cnrm.cloud.google.com/deletion-policy darf nicht auf abandon festgelegt sein.
  3. Aktualisieren Sie das Feld spec.projectRef oder die cnrm.cloud.google.com/project-id-Anmerkung 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 cnrm.cloud.google.com/deletion-policy-Anmerkung abandon fest.

  5. Wenden Sie die aktualisierte YAML-Konfiguration an, um die Richtlinie zum Löschen von Config Connector-Ressourcen zu aktualisieren.

  6. Lassen Sie die Config Connector-Ressourcen los.

  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 aufgegebenen Ressourcen abzurufen.

Knotenpools in GKE-Clustern verwalten

Wenn Sie einen Cluster erstellen, indem Sie eine ContainerCluster-Ressource in Config Connector anwenden, und dann versuchen, das Feld nodeConfig oder andere netzwerkbezogene Felder durch Anwenden einer aktualisierten ContainerCluster-Konfiguration zu aktualisieren, treten möglicherweise Fehler auf. Diese Fehler sind auf unveränderliche Felder wie nodeConfig, nodeConfig.labels und nodeConfig.taint zurückzuführen. Dies ist eine technische Einschränkung der zugrunde liegenden Google Cloud API.

Wenn Sie diese Felder aktualisieren müssen, können Sie die Ressource ContainerNodePool verwenden, um Knotenpools zu verwalten, bei 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 Anmerkung wird der Standardknotenpool entfernt, der beim Erstellen des Clusters erstellt wird. Wenn Sie separate Knotenpools erstellen möchten, geben Sie die nodeConfig-Felder in ContainerNodePool anstelle von ContainerCluster an. Weitere Informationen finden Sie im Beispiel für die ContainerNodePool-Ressource.

Sie sollten die Anmerkung cnrm.cloud.google.com/state-into-spec: absent sowohl für die ContainerCluster- als auch für die ContainerNodePool-Ressource festlegen. Mit dieser Anmerkung werden potenzielle Abgleichsfehler bei der Interaktion zwischen dem Config Connector-Controller und den zugrunde liegenden APIs vermieden.

Die folgenden Beispiele zeigen eine ContainerCluster- und eine ContainerNodePool-Konfiguration mit den folgenden Anmerkungen:

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