Config Controller einrichten

Auf dieser Seite erfahren Sie, wie Sie Config Controller einrichten.

Config Controller bietet eine verwaltete Steuerungsebene, die auf Kubernetes basiert. Darüber hinaus sind auf Config Controller-Instanzen Policy Controller, Config Sync und Config Connector vorinstalliert. Mithilfe dieser Komponenten können Sie die Tools und Workflows von Kubernetes nutzen, um Google Cloud-Ressourcen zu verwalten und mit einem GitOps-Workflow für Konsistenz zu sorgen. Weitere Informationen finden Sie in der Übersicht über Config Controller.

Wenn Sie zum ersten Mal eine Config Controller-Instanz erstellen, lesen Sie die Kurzanleitung: Ressourcen mit Config Controller verwalten.

Beschränkungen

Da Config Controller-Instanzen vollständig verwaltet werden, können Sie sie nicht in einer Flotte registrieren.

Hinweise

Führen Sie die folgenden Schritte aus, bevor Sie Config Controller einrichten:

Installieren und initialisieren Sie die Google Cloud CLI, die die in dieser Anleitung verwendete Google Cloud CLI zur Verfügung stellt. Wenn Sie Cloud Shell verwenden, ist die Google Cloud CLI bereits installiert.
Da kubectl nicht standardmäßig von der Google Cloud-Befehlszeile installiert wird, installieren Sie es:
```
gcloud components install kubectl
```
Legen Sie das Google Cloud-Projekt fest, in dem Sie Config Controller hosten möchten:
```
gcloud config set project PROJECT_ID
```
Ersetzen Sie PROJECT_ID durch das Google Cloud-Projekt, das Config Controller hosten wird.

Aktivieren Sie die erforderlichen APIs:

gcloud services enable krmapihosting.googleapis.com \
    anthos.googleapis.com  \
    cloudresourcemanager.googleapis.com \
    serviceusage.googleapis.com

Config Controller-Instanz erstellen

Sie können eine Config Controller-Instanz erstellen, die von einem Standardcluster oder einem Autopilot-Cluster unterstützt wird. Beide Clustertypen sind privat.

Wählen Sie einen Standardcluster aus, wenn Sie weitere Anpassungsoptionen wünschen. Wählen Sie einen Autopilot-Cluster aus, wenn Sie eine schnellere Installation, horizontales und vertikales Pod-Autoscaling sowie erweiterte Sicherheitsfeatures wie Container-Optimized OS, Shielded GKE-Knoten, Workload Identity und Secure Boot wünschen.

Erstellen Sie eine Config Controller-Instanz:
Standard
Erstellen Sie eine Config Controller-Instanz, die von einem privaten GKE-Standardcluster unterstützt wird:
```
gcloud anthos config controller create CONFIG_CONTROLLER_NAME \
    --location=LOCATION
```
Ersetzen Sie Folgendes:
- CONFIG_CONTROLLER_NAME ist der Name, den Sie Ihrer Config Controller-Instanz geben möchten.
- LOCATION: Fügen Sie eine der folgenden Regionen hinzu:
  - us-central1
  - us-east1
  - us-east4
  - us-east5
  - us-west2
  - northamerica-northeast1
  - northamerica-northeast2
  - europe-north1
  - europe-west1
  - europe-west3
  - europe-west6
  - australia-southeast1
  - australia-southeast2
  - asia-northeast1
  - asia-northeast2
  - asia-southeast1
  Dies ist die Region, in der Ihre Config Controller-Instanz erstellt wird. Es werden keine anderen Regionen unterstützt.
Wenn Sie eine standardmäßige Config Controller-Instanz erstellen, können Sie mehrere optionale Parameter festlegen. Eine vollständige Liste der Optionen finden Sie in der Dokumentation zu gcloud anthos config controller create.
Autopilot
Führen Sie den folgenden Befehl aus, um eine Config Controller-Instanz zu erstellen, die von einem privaten Autopilot-GKE-Cluster unterstützt wird:
```
gcloud anthos config controller create CONFIG_CONTROLLER_NAME \
    --location=LOCATION \
    --full-management
```
Ersetzen Sie Folgendes:
- CONFIG_CONTROLLER_NAME: der Name, den Sie dem Controller geben möchten
- LOCATION: Fügen Sie eine der folgenden Regionen hinzu:
  - us-central1
  - us-east1
  - us-east4
  - us-east5
  - us-west2
  - northamerica-northeast1
  - northamerica-northeast2
  - europe-north1
  - europe-west1
  - europe-west3
  - europe-west6
  - australia-southeast1
  - australia-southeast2
  - asia-northeast1
  - asia-northeast2
  - asia-southeast1
  Es werden keine anderen Regionen unterstützt.
Dieser Vorgang kann bis zu 15 Minuten dauern. Wenn Sie beobachten möchten, was während der Erstellung passiert, können Sie den Log-Explorer in der Google Cloud Console aufrufen.

Zu „Log-Explorer“

Wenn beim Erstellen Fehler auftreten, finden Sie unter Fehlerbehebung für Config Controller Informationen zum Beheben häufiger Probleme.
Rufen Sie die Liste der Config Controller-Instanzen auf, um zu prüfen, ob Ihre Config Controller-Instanzen erstellt wurden:
```
gcloud anthos config controller list --location=LOCATION
```
In der Statusspalte sollte der Wert RUNNING stehen. Wenn der Status CREATING lautet, wird die Config Controller-Instanz noch erstellt und Sie sollten weiter warten. Wenn ERROR angezeigt wird, ist ein Problem aufgetreten, das Sie nicht selbst beheben können. Wenden Sie sich an den Google Cloud-Support.
Für die Kommunikation mit dem Config Controller-Endpunkt benötigen Sie die entsprechenden Anmeldedaten und Endpunktinformationen:
```
gcloud anthos config controller get-credentials CONFIG_CONTROLLER_NAME \
    --location LOCATION
```

Config Controller-Instanz verwenden

Nachdem Sie eine Config Controller-Instanz erstellt haben, können Sie die installierten Komponenten verwenden und die folgenden Aufgaben ausführen:

Verwenden Sie Config Connector, um Google Cloud-Ressourcen zu erstellen. Wenn Sie bereits Google Cloud-Ressourcen haben, die Sie mit Config Controller verwenden möchten, lesen Sie die Informationen zum Erwerben einer vorhandenen Ressource.
Mit Policy Controller können Sie Einschränkungen anwenden, um die Compliance mit gesetzlichen Vorschriften und Kubernetes-Standards durchzusetzen.
Nachdem Sie Config Sync konfiguriert haben, synchronisieren Sie im folgenden Abschnitt Ihre Config Controller-Instanz mit Konfigurationen (einschließlich Policy Controller-Einschränkungen und Config Connector-Ressourcen), die in einer Source of Truth gespeichert sind.

Ein interaktives Beispiel zum Ausführen dieser Aufgaben mit Config Controller finden Sie in der Kurzanleitung: Ressourcen mit Config Controller verwalten.

Config Controller-Instanz konfigurieren

In den folgenden Abschnitten wird erläutert, wie Sie die Komponenten Ihrer Config Controller-Instanz konfigurieren.

Config Connector konfigurieren

Sie müssen keine Einstellungen für die Config Connector-Installation verwalten. Sie müssen jedoch Config Controller-Berechtigungen zum Verwalten von Google Cloud-Ressourcen erteilen:

Legen Sie eine Umgebungsvariable für die E-Mail-Adresse Ihres Dienstkontos fest:

export SA_EMAIL="$(kubectl get ConfigConnectorContext -n config-control \
    -o jsonpath='{.items[0].spec.googleServiceAccount}' 2> /dev/null)"

Erstellen Sie die Richtlinienbindung:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:${SA_EMAIL}" \
    --role "ROLE" \
    --project PROJECT_ID
```
Ersetzen Sie Folgendes:
- PROJECT_ID: Ihre Projekt-ID.
- ROLE: Eine Reihe vordefinierter Rollen oder benutzerdefinierter Rollen, die Ihren Anforderungen entsprechen. Alternativ können Sie roles/owner für Nicht-Produktionsumgebungen verwenden. Weitere Informationen zu IAM-Berechtigungen für Config Controller finden Sie unter IAM-Berechtigungen für Config Controller.
Wenn der vorherige Vorgang fehlschlägt, prüfen Sie, ob die Controller bereit sind:
```
kubectl wait pod --all --all-namespaces --for=condition=Ready
```

Nachdem Sie diese Berechtigungen gewährt haben, können Sie Google Cloud-Ressourcen erstellen.

Policy Controller konfigurieren

Das Konfigurieren von Policy Controller ist optional, Sie können jedoch bei Bedarf Änderungen an der Standardinstallation vornehmen.

Zum Konfigurieren von Policy Controller bearbeiten Sie die spec.policyController-Felder des Objekts ConfigManagement mit dem Namen config-management. Config Controller erstellt dieses ConfigManagement-Objekt während der Installation automatisch. Legen Sie beim Bearbeiten des ConfigManagement-Objekts spec.policyController.enabled nicht auf false fest. Config Controller überschreibt diese Änderung automatisch. Für das Monitoring müssen Sie Policy Controller außerdem erlauben, Messwerte zu senden.

Erlauben Sie Policy Controller, Messwerte zu senden, indem Sie diesen Befehl ausführen:

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:PROJECT_ID.svc.id.goog[gatekeeper-system/gatekeeper-admin]" \
  --role=roles/monitoring.metricWriter

Ersetzen Sie PROJECT_ID durch die Google Cloud-Projekt-ID des Clusters.

Config Sync konfigurieren

Wenn die Config Controller-Instanz über Konfigurationen synchronisiert werden soll, die in einer Source of Truth gespeichert sind, müssen Sie Config Sync konfigurieren.

Wenn Sie Config Sync zum Erstellen von Config Connector-Ressourcen verwenden möchten, müssen Sie auch Config Controller die Berechtigung zum Verwalten von Ressourcen gewährt haben.

Erstellen und bearbeiten Sie ein RootSync-Objekt, um Config Sync zu konfigurieren:

Für die Synchronisierung von einem externen Repository (z. B. GitHub) richten Sie Cloud NAT mit GKE ein. Dies ist erforderlich, da private Clusterknoten keinen ausgehenden Internetzugriff haben.
Speichern Sie eines der folgenden Manifeste als root-sync.yaml. Verwenden Sie die Manifestversion, die dem Quelltyp für Ihre Konfigurationen entspricht.
Git
```
# root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  sourceType: git
  sourceFormat: ROOT_FORMAT
  git:
    repo: ROOT_REPOSITORY
    revision: ROOT_REVISION
    branch: ROOT_BRANCH
    dir: ROOT_DIRECTORY
    auth: ROOT_AUTH_TYPE
    gcpServiceAccountEmail: ROOT_EMAIL
    secretRef:
      name: ROOT_SECRET_NAME
    noSSLVerify: ROOT_NO_SSL_VERIFY
    caCertSecretRef:
      name: ROOT_CA_CERT_SECRET_NAME
```
Ersetzen Sie Folgendes:
- ROOT_SYNC_NAME: Fügen Sie den Namen Ihres RootSync-Objekts hinzu.
- ROOT_FORMAT: Fügen Sie unstructured hinzu, um ein unstrukturiertes Repository zu verwenden, oder fügen Sie hierarchy hinzu, um ein hierarchisches Repository zu verwenden. Bei diesen Werten wird zwischen Groß- und Kleinschreibung unterschieden. Dieses Feld ist optional und der Standardwert ist hierarchy. Wir empfehlen das Hinzufügen von unstructured, da Sie damit Ihre Konfigurationen so organisieren können, wie es für Sie am besten ist.
- ROOT_REPOSITORY: Fügen Sie die URL des Git-Repositorys hinzu, das als Stamm-Repository verwendet werden soll. Sie können URLs mithilfe des HTTPS- oder SSH-Protokolls eingeben. https://github.com/GoogleCloudPlatform/anthos-config-management-samples verwendet beispielsweise das HTTPS-Protokoll. Dies ist ein Pflichtfeld.
- ROOT_REVISION: Fügen Sie die Git-Überarbeitung (Tag oder Hash) hinzu, von der aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist HEAD. Ab Config Sync Version 1.17.0 können Sie auch einen Zweignamen im Feld revision angeben. Wenn ein Hash in Version 1.17.0 oder höher verwendet wird, muss es sich um einen vollständigen Hash und nicht um eine abgekürzte Form handeln.
- ROOT_BRANCH: Fügen Sie den Zweig des Repositorys hinzu, von dem aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist master. Ab Config Sync Version 1.17.0 empfiehlt es sich, einen Zweignamen der Einfachheit halber mit dem Feld revision anzugeben. Wenn sowohl das Feld revision als auch das Feld branch angegeben sind, hat revision Vorrang vor branch.
- ROOT_DIRECTORY: Fügen Sie den Pfad im Git-Repository zum Stammverzeichnis hinzu, das die Konfiguration enthält, mit der Sie die Synchronisierung durchführen möchten. Dieses Feld ist optional und die Standardeinstellung ist das Stammverzeichnis (/) des Repositorys.
- ROOT_AUTH_TYPE: Fügen Sie einen der folgenden Authentifizierungstypen hinzu:
  - none: Keine Authentifizierung verwenden
  - ssh: Ein SSH-Schlüsselpaar verwenden
  - cookiefile: Nutzen Sie einen cookiefile.
  - token: Ein Token verwenden
  - gcpserviceaccount: Mit einem Google-Dienstkonto auf Cloud Source Repositories zugreifen
  - gcenode: Mit einem Google-Dienstkonto auf Cloud Source Repositories zugreifen Wählen Sie diese Option nur aus, wenn Workload Identity nicht in Ihrem Cluster aktiviert ist.
  Weitere Informationen zu diesen Authentifizierungstypen finden Sie unter Config Sync Lesezugriff auf Git gewähren.
  
  Dies ist ein Pflichtfeld.
- ROOT_EMAIL: Wenn Sie gcpserviceaccount für ROOT_AUTH_TYPE angegeben haben, fügen Sie die E-Mail-Adresse Ihres Google-Dienstkontos hinzu. Beispiel: acm@PROJECT_ID.iam.gserviceaccount.com.
- ROOT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu. Ist dieses Feld festgelegt, müssen Sie dem Git-Anbieter den öffentlichen Schlüssel des Secrets hinzufügen. Dieses Feld ist optional.
- ROOT_NO_SSL_VERIFY: Setzen Sie dieses Feld auf true, um die SSL-Zertifikatsüberprüfung zu deaktivieren. Der Standardwert ist false.
- ROOT_CA_CERT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu. Ist dieses Feld festgelegt, muss Ihr Git-Anbieter ein Zertifikat verwenden, das von dieser Zertifizierungsstelle (CA, Certification Authority) ausgestellt wurde. Das Secret muss das CA-Zertifikat unter einem Schlüssel mit dem Namen cert enthalten. Dieses Feld ist optional.
  
  Weitere Informationen zum Konfigurieren des Secret-Objekts für das CA-Zertifikat finden Sie unter Operator für eine Zertifizierungsstelle konfigurieren.
Eine Erläuterung der Felder und eine vollständige Liste der Felder, die Sie dem Feld spec hinzufügen können, finden Sie unter RootSync-Felder.

Dieses Manifest erstellt ein RootSync-Objekt, das Git als Quelle verwendet.
OCI
```
# root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  sourceType: oci
  sourceFormat: ROOT_FORMAT
  oci:
    image: ROOT_IMAGE
    dir: ROOT_DIRECTORY
    auth: ROOT_AUTH_TYPE
    gcpServiceAccountEmail: ROOT_EMAIL
```
Ersetzen Sie Folgendes:
- ROOT_SYNC_NAME: Fügen Sie den Namen Ihres RootSync-Objekts hinzu.
- ROOT_FORMAT: Fügen Sie unstructured hinzu, um ein unstrukturiertes Repository zu verwenden, oder fügen Sie hierarchy hinzu, um ein hierarchisches Repository zu verwenden. Bei diesen Werten wird zwischen Groß- und Kleinschreibung unterschieden. Dieses Feld ist optional und der Standardwert ist hierarchy. Wir empfehlen das Hinzufügen von unstructured, da Sie damit Ihre Konfigurationen so organisieren können, wie es für Sie am besten ist.
- ROOT_IMAGE: Die URL des OCI-Images, das als Root-Repository verwendet werden soll, z. B. LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Standardmäßig wird das Image aus dem Tag latest abgerufen, aber Sie können stattdessen Images von TAG oder DIGEST abrufen. Geben Sie TAG oder DIGEST im PACKAGE_NAME an:
  - Zum Abrufen von TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
  - Zum Abrufen von DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
Achtung :Für Config Sync muss die OCI-Ebene in tar oder tar+gzip komprimiert sein. Andere Formate (z. B. tar+bz2) werden von Config Sync nicht erkannt. Wenn Sie von einem gültigen REPO zu einem OCI-Image mit einem nicht unterstützten Format wechseln, werden verwaltete Ressourcen ohne Fehler bereinigt.
- ROOT_DIRECTORY: Fügen Sie den Pfad im Repository zum Stammverzeichnis hinzu, das die Konfiguration enthält, mit der Sie die Synchronisierung durchführen möchten. Dieses Feld ist optional und die Standardeinstellung ist das Stammverzeichnis (/) des Repositorys.
- ROOT_AUTH_TYPE: Fügen Sie einen der folgenden Authentifizierungstypen hinzu:
  - none: Keine Authentifizierung verwenden
  - gcenode: Verwenden Sie das Compute Engine-Standarddienstkonto, um auf ein Image in Artifact Registry zuzugreifen. Wählen Sie diese Option nur aus, wenn Workload Identity nicht in Ihrem Cluster aktiviert ist.
  - gcpserviceaccount: Verwenden Sie ein Google-Dienstkonto für den Zugriff auf ein Image.
  Dies ist ein Pflichtfeld.
- ROOT_EMAIL: Wenn Sie gcpserviceaccount für ROOT_AUTH_TYPE angegeben haben, fügen Sie die E-Mail-Adresse Ihres Google-Dienstkontos hinzu. Beispiel: acm@PROJECT_ID.iam.gserviceaccount.com.
Eine Erläuterung der Felder und eine vollständige Liste der Felder, die Sie dem Feld spec hinzufügen können, finden Sie unter RootSync-Felder.

Dieses Manifest erstellt ein RootSync-Objekt, das ein OCI-Image als Quelle verwendet.
Helm
```
# root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  sourceType: helm
  sourceFormat: ROOT_FORMAT
  helm:
    repo: ROOT_HELM_REPOSITORY
    chart: HELM_CHART_NAME
    version: HELM_CHART_VERSION
    releaseName: HELM_RELEASE_NAME
    namespace: HELM_RELEASE_NAMESPACE
    values:
      foo:
        bar: VALUE_1
      baz:
      - qux: VALUE_2
        xyz: VALUE_3
    includeCRDs: HELM_INCLUDE_CRDS
    auth: ROOT_AUTH_TYPE
      gcpServiceAccountEmail: ROOT_EMAIL
      secretRef:
        name: ROOT_SECRET_NAME
```
Ersetzen Sie Folgendes:
- ROOT_SYNC_NAME: Fügen Sie den Namen Ihres RootSync-Objekts hinzu.
- ROOT_FORMAT: Fügen Sie unstructured hinzu, um ein unstrukturiertes Repository zu verwenden, oder fügen Sie hierarchy hinzu, um ein hierarchisches Repository zu verwenden. Bei diesen Werten wird zwischen Groß- und Kleinschreibung unterschieden. Dieses Feld ist optional und der Standardwert ist hierarchy. Wir empfehlen das Hinzufügen von unstructured, da Sie damit Ihre Konfigurationen so organisieren können, wie es für Sie am besten ist.
- ROOT_HELM_REPOSITORY: Die URL des Helm-Repositorys, das als Root-Repository verwendet werden soll. Sie können URLs entweder mit dem HTTPS- oder SSH-Protokoll eingeben. https://github.com/GoogleCloudPlatform/anthos-config-management-samples verwendet beispielsweise das HTTPS-Protokoll. Dies ist ein Pflichtfeld.
- HELM_CHART_NAME: Fügen Sie den Namen Ihres Helm-Diagramms hinzu. Dies ist ein Pflichtfeld.
- HELM_CHART_VERSION: die Version Ihres Diagramms. Dieses Feld ist optional. Wenn kein Wert angegeben ist, wird die neueste Version verwendet.
- HELM_RELEASE_NAME: der Name der Helm-Version. Dieses Feld ist optional.
- HELM_RELEASE_NAMESPACE: Der Ziel-Namespace für einen Release. Es wird nur für Ressourcen, die namespace: {{ .Release.Namespace }} in ihren Vorlagen enthalten, ein Namespace festgelegt. Dieses Feld ist optional. Wenn kein Wert angegeben ist, wird der Standard-Namespace config-management-system verwendet.
- HELM_INCLUDE_CRDS: Legen Sie diesen Wert auf true fest, wenn die Helm-Vorlage auch eine CustomResourceDefinition generieren soll. Dieses Feld ist optional. Wenn kein Wert angegeben ist, ist der Standardwert false und es wird keine CRD generiert.
- VALUE: Werte, die anstelle der Standardwerte für das Helm-Diagramm verwendet werden. Formatieren Sie dieses Feld genauso wie die Datei value.yaml des Helm-Diagramms. Dieses Feld ist optional.
- ROOT_AUTH_TYPE: Fügen Sie einen der folgenden Authentifizierungstypen hinzu:
  - none: Keine Authentifizierung verwenden
  - token: Verwenden Sie einen Nutzernamen und ein Passwort, um auf ein privates Helm-Repository zuzugreifen.
  - gcenode: Verwenden Sie das Compute Engine-Standarddienstkonto, um auf ein Image in Artifact Registry zuzugreifen. Wählen Sie diese Option nur aus, wenn Workload Identity nicht in Ihrem Cluster aktiviert ist.
  - gcpserviceaccount: Verwenden Sie ein Google-Dienstkonto für den Zugriff auf ein Image.
  Dies ist ein Pflichtfeld.
- ROOT_EMAIL: Wenn Sie gcpserviceaccount für ROOT_AUTH_TYPE angegeben haben, fügen Sie die E-Mail-Adresse Ihres Google-Dienstkontos hinzu. Beispiel: acm@PROJECT_ID.iam.gserviceaccount.com.
- ROOT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu, wenn token der ROOT_AUTH_TYPE ist. Dieses Feld ist optional.
Eine Erläuterung der Felder und eine vollständige Liste der Felder, die Sie dem Feld spec hinzufügen können, finden Sie unter RootSync-Felder.

Dieses Manifest erstellt ein RootSync-Objekt, das Helm als Quelle verwendet.
Erstellen Sie zum Erstellen der Config Sync-Konfiguration ein RootSync-Objekt, indem Sie das Manifest anwenden:
```
kubectl apply -f root-sync.yaml
```
Rufen Sie das RootSync-Objekt auf, um zu prüfen, ob Ihre Änderungen angewendet wurden:
```
kubectl describe rootsync ROOT_SYNC_NAME -n config-management-system
```

Config Controller aktualisieren

Da Config Controller ein verwalteter Dienst ist, führt Google für ihn automatisch Upgrades durch. Weitere Informationen zu neuen Features und Informationen dazu, welche Config Sync-, Policy Controller- und Config Connector-Versionen Config Controller verwendet, finden Sie in den Versionshinweisen für Config Controller.

Config Controller-Instanz löschen

Wenn Sie eine Config Controller-Instanz nicht mehr verwenden möchten, bereinigen Sie alle Config Connector-Ressourcen, die vor dem Löschen des Config Controller-Clusters erstellt wurden.

Wenn Sie Ihre Config Controller-Instanz löschen, ohne zuvor die bereitgestellten Ressourcen zu löschen, bleiben die Ressourcen im Status „abgebrochen“. Die Ressourcen sind weiterhin in Google Cloud vorhanden (und fallen in Rechnung), werden aber nicht über die deklarative Konfiguration verwaltet.

Nachdem alle Ressourcen gelöscht wurden, löschen Sie Ihren Config Controller-Cluster:

gcloud anthos config controller delete \
    --location=LOCATION CONFIG_CONTROLLER_NAME

Überlegungen zur Produktion

Bei der Produktion sollten Sie zuerst die Überlegungen zur Hochverfügbarkeit für Config Controller lesen.