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:

1. Entscheiden Sie, welche Config Connector-Ressourcen Sie in verschiedene Projekte verschieben möchten.
2. Löschen Sie die Config Connector-Ressourcen. Die Annotation 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 von Config Connector verwendeten IAM-Dienstkonto die richtigen Berechtigungen für die neuen Projekte.
5. Wenden Sie die aktualisierte YAML-Konfiguration an, um die Config Connector-Ressourcen zu erstellen.

In den Namespace-Modus wechseln

Hinweis: Wenn Sie requestProjectPolicy und billingProject in ConfigConnectorContext verwenden möchten, um das Kontingentprojekt anzugeben, müssen Sie keine IAM-Dienstkonten verwenden, die verschiedenen Google Cloud-Projekten gehören. Sie sollten jedoch verschiedene Google Cloud-Projekte als billingProject für verschiedene ConfigConnectorContext-Objekte verwenden, um das Problem mit dem API-Kontingentlimit zu beheben.

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:

1. 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.

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

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

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

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

6. Verwerfen Sie die Config Connector-Ressourcen.

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 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