Best Practices für Config Connector

Auf dieser Seite werden Best Practices erläutert, die Sie bei der Verwendung von Config Connector.

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 innerhalb desselben Kontingentprojekts. 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, dieses Problem zu beheben, besteht darin, eine Kontingenterhöhung anzufordern. Wenn Sie festgestellt haben, dass der Kontingentfehler durch GET-Anfragen an die von Ihren Config Connector-Ressourcen verwalteten Google Cloud-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. Es empfiehlt sich, den Abgleich mit Intervall auf 1 Stunde festlegen.

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 eignet sich gut für das Hinzufügen neuer Ressourcen, Es ist riskant, vorhandene Ressourcen aufzuteilen, da die vorhandenen gelöscht werden müssen. und unter verschiedenen Projekten neu erstellen. Das Löschen von Ressourcen führen bei einigen Ressourcentypen zu Datenverlusten, z. B. SpannerInstance oder BigtableTable Ressourcen. Sie sollten Ihre Daten sichern, bevor Sie sie löschen.

Wenn Sie vorhandene Config Connector-Ressourcen in verschiedene Projekte aufteilen möchten, führen Sie Folgendes aus: führen Sie die folgenden Schritte aus:

  1. Entscheiden Sie, welche Config Connector-Ressourcen Sie in andere Projekte verschieben möchten.
  2. Löschen Sie die Config Connector-Ressourcen. Die Annotation cnrm.cloud.google.com/deletion-policy darf nicht festgelegt sein an abandon.
  3. Aktualisieren Sie das Feld spec.projectRef oder die Anmerkung 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.

In 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. 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. Binden Sie sie nach 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 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 den Config Connector zu aktualisieren Ressourcen Löschrichtlinie.

  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. Aktualisierte YAML-Konfiguration anwenden auf verworfene Ressourcen zu erwerben.

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 als nodeConfig, nodeConfig.labels, nodeConfig.taint, ein technisches Einschränkung der zugrunde liegenden Google Cloud API.

Wenn Sie diese Felder aktualisieren müssen, verwenden Sie die Methode ContainerNodePool Ressource zum Verwalten von Knotenpools, bei denen diese Felder nicht unveränderlich sind. Wenn Sie Knotenpools mit der ContainerNodePool-Ressource verwalten möchten, müssen Sie eine Annotation cnrm.cloud.google.com/remove-default-node-pool: "true" angeben. Mit dieser Anmerkung wird der Standardknotenpool entfernt, der bei der Clustererstellung erstellt wird. Geben Sie dann zum Erstellen separater Knotenpools nodeConfig-Felder an ContainerNodePool statt in ContainerCluster. Weitere Informationen finden Sie in der Beispiel für ContainerNodePool-Ressource als Referenz.

Sie sollten die Annotation cnrm.cloud.google.com/state-into-spec: absent für die Ressourcen ContainerCluster und ContainerNodePool. Dieses vermeiden Sie mögliche Abgleichsfehler während der Interaktion zwischen den Config Connector-Controller und die zugrunde liegenden APIs.

Die folgenden Beispiele zeigen einen ContainerCluster und einen ContainerNodePool Konfiguration mit folgenden Annotationssätzen:

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