Config Controller einrichten

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

Config Controller bietet eine verwaltete, auf Kubernetes basierende Steuerungsebene. Außerdem sind auf Config Controller-Instanzen Policy Controller, Config Sync und Config Connector vorinstalliert. Mit diesen Komponenten können Sie die Tools und Workflows von Kubernetes verwenden, um Google Cloud-Ressourcen zu verwalten und mit einem GitOps-Workflow Konsistenz zu erreichen. Weitere Informationen finden Sie in der Config Controller-Übersicht.

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 bei einer Flotte registrieren.

Hinweise

Führen Sie vor der Einrichtung von Config Controller die folgenden Schritte aus:

  1. Installieren und initialisieren Sie die Google Cloud-CLI, die die in dieser Anleitung verwendete Google Cloud CLI enthält. Wenn Sie Cloud Shell verwenden, ist die Google Cloud CLI bereits installiert.

  2. Da kubectl nicht standardmäßig von der Google Cloud-CLI installiert wird, müssen Sie es installieren:

    gcloud components install kubectl

  3. 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, in dem Config Controller gehostet wird.

  4. Aktivieren Sie die erforderlichen APIs:

    gcloud services enable krmapihosting.googleapis.com \
    container.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 Arten von Clustern sind privat.

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

Die Erstellung eines neuen Clusters kann bis zu 15 Minuten dauern. Wenn Sie beobachten möchten, was während der Erstellung passiert, können Sie den Log-Explorer in derGoogle Cloud Console aufrufen.

Zu „Log-Explorer“

Wenn beim Erstellen Fehler auftreten, finden Sie unter Fehlerbehebung bei Config Controller Informationen zur Behebung häufiger Probleme.

Autopilot-Cluster erstellen

Führen Sie den folgenden Befehl aus, um eine Config Controller-Instanz in einem Autopilot-Cluster zu erstellen:

gcloud anthos config controller create CONFIG_CONTROLLER_NAME \
    --location=LOCATION \
    --full-management

Ersetzen Sie Folgendes:

  • CONFIG_CONTROLLER_NAME: den Namen, den Sie der Config Controller-Instanz geben möchten
  • LOCATION: der Ort, an dem Sie Ihre Config Controller-Instanz erstellen möchten, z. B. us-central. Eine Liste der unterstützten Standorte finden Sie unter Standorte.

Standardcluster erstellen

Führen Sie den folgenden Befehl aus, um eine Config Controller-Instanz in einem Standardcluster zu erstellen:

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

Ersetzen Sie Folgendes:

  • CONFIG_CONTROLLER_NAME: den Namen, den Sie der Config Controller-Instanz geben möchten
  • LOCATION: der Ort, an dem Sie Ihre Config Controller-Instanz erstellen möchten, z. B. us-central. Eine Liste der unterstützten Standorte finden Sie unter Standorte.

Beim Erstellen einer Standard-Config Controller-Instanz können Sie mehrere optionale Parameter festlegen. Eine vollständige Liste der Optionen finden Sie in der Dokumentation zu gcloud anthos config controller create.

Config Controller-Instanz bestätigen

So prüfen Sie, ob Ihre Config Controller-Instanz eingerichtet ist:

  1. Prüfen Sie anhand der Liste der Config Controller-Instanzen, ob die Instanz erstellt wurde:

    gcloud anthos config controller list --location=LOCATION

    In der Statusspalte sollte der Wert RUNNING angezeigt werden. Wenn der Status CREATING lautet, wird Ihre Config Controller-Instanz noch erstellt. Warten Sie bitte weiter. Wenn Sie ERROR sehen, ist ein Problem aufgetreten, das Sie nicht selbst beheben können. Wenden Sie sich an den Google Cloud-Support, um Unterstützung zu erhalten.

  2. Rufen Sie die entsprechenden Anmeldedaten und Endpunktinformationen ab, um mit dem Config Controller-Endpunkt zu kommunizieren:

    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:

  • Mit Config Connector Google Cloud Ressourcen erstellen Wenn Sie bereits Google Cloud -Ressourcen haben, die Sie mit Config Controller verwenden möchten, lesen Sie den Abschnitt Vorhandene Ressource abrufen.

  • Mit Policy Controller können Sie Einschränkungen anwenden, die die Einhaltung von gesetzlichen Bestimmungen und Kubernetes-Standards erzwingen.

  • 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 Anleitungsbeispiel, das zeigt, wie Sie diese Aufgaben mit Config Controller ausführen, finden Sie unter Kurzanleitung: Ressourcen mit Config Controller verwalten.

Config Controller-Instanz konfigurieren

In den folgenden Abschnitten wird beschrieben, 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 Config Controller jedoch Berechtigungen zum Verwalten vonGoogle Cloud -Ressourcen erteilen:

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

  2. Erstellen Sie die Richtlinienbindung:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:${SA_EMAIL}" \
    --role "ROLE" \
    --project PROJECT_ID

    Ersetzen Sie Folgendes:

    Prüfen Sie, ob die Controller bereit sind, wenn der vorherige Vorgang fehlschlägt.

    kubectl wait pod --all --all-namespaces --for=condition=Ready

Nachdem Sie diese Berechtigungen erteilt haben, können Sie mit dem Erstellen von Google CloudRessourcen beginnen.

Policy Controller konfigurieren

Möglicherweise müssen Sie die IAM-Richtlinie hinzufügen oder aktualisieren, damit Policy Controller Messwerte senden kann.

Erlauben Sie dem Policy Controller, Messwerte zu senden, indem Sie den folgenden 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 Projekt-ID des Clusters. Google Cloud

Config Sync konfigurieren

Wenn Ihre Config Controller-Instanz Konfigurationen synchronisieren 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 erteilt haben.

Wenn Sie Config Sync konfigurieren möchten, erstellen und bearbeiten Sie ein RootSync-Objekt:

  1. Wenn Sie die Synchronisierung von einem externen Repository (z. B. GitHub) einrichten möchten, richten Sie Cloud NAT mit GKE ein. Das ist erforderlich, da private Clusterknoten keinen ausgehenden Internetzugang haben.

  2. 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-Revision (Tag oder Hash) oder den Zweig hinzu, von dem aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist HEAD. Wenn Sie einen Hash verwenden, muss es sich um einen vollständigen Hash (nicht um eine abgekürzte Form) handeln.
    • ROOT_BRANCH: Der Zweig des Repositorys, von dem aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist master. Wir empfehlen, das Feld revision zu verwenden, um einen Branch-Namen anzugeben. Wenn sowohl das Feld revision als auch das Feld branch angegeben ist, 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 Federation for GKE 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 namens cert enthalten. Dieses Feld ist optional.

      Weitere Informationen zum Konfigurieren des Secret-Objekts für das CA-Zertifikat finden Sie unter 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
    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_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
    • 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 Federation for GKE in Ihrem Cluster nicht 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_CA_CERT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu. Ist dieses Feld festgelegt, muss IhrOCI-Anbieter ein Zertifikat verwenden, das von dieser Zertifizierungsstelle (CA, Certification Authority) ausgestellt wurde. Das Secret muss das CA-Zertifikat unter einem Schlüssel namens cert enthalten. Dieses Feld ist optional.

    Weitere Informationen zum Konfigurieren des Secret-Objekts für das CA-Zertifikat finden Sie unter 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 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
    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_HELM_REPOSITORY: die URL des Helm-Repositorys, 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.
    • HELM_CHART_NAME: Fügen Sie den Namen Ihres Helm-Charts hinzu. Dies ist ein Pflichtfeld.
    • HELM_CHART_VERSION: die Version Ihres Diagramms. Dieses Feld ist optional. Wenn kein Wert angegeben ist, wird die aktuelle Version verwendet.
    • HELM_RELEASE_NAME: Der Name des Helm-Release. Dieses Feld ist optional.
    • HELM_RELEASE_NAMESPACE: der Ziel-Namespace für einen Release. Ein Namespace wird nur für Ressourcen festgelegt, die in ihren Vorlagen namespace: {{ .Release.Namespace }} enthalten. Dieses Feld ist optional. Wenn kein Wert angegeben ist, wird der Standard-Namespace config-management-system verwendet.
    • HELM_INCLUDE_CRDS: Auf true setzen, wenn das Helm-Template auch eine CustomResourceDefinition generieren soll. Dieses Feld ist optional. Wenn kein Wert angegeben ist, lautet der Standardwert false und es wird keine CRD generiert.
    • VALUE: Anstelle der Standardwerte des Helm-Diagramms zu verwendende Werte Formatieren Sie dieses Feld genauso wie die Datei values.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 Federation for GKE in Ihrem Cluster nicht 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.

    • ROOT_CA_CERT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu. Ist dieses Feld festgelegt, muss Ihr Helm-Anbieter ein Zertifikat verwenden, das von dieser Zertifizierungsstelle (CA, Certification Authority) ausgestellt wurde. Das Secret muss das CA-Zertifikat unter einem Schlüssel namens cert enthalten. Dieses Feld ist optional.

    Weitere Informationen zum Konfigurieren des Secret-Objekts für das CA-Zertifikat finden Sie unter 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 Helm als Quelle verwendet.

  3. Erstellen Sie ein RootSync-Objekt, indem Sie das Manifest anwenden, um die Config Sync-Konfiguration zu erstellen:

    kubectl apply -f root-sync.yaml

  4. So prüfen Sie, 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, wird er von Google automatisch aktualisiert. Weitere Informationen zu neuen Funktionen und dazu, welche Versionen von Config Sync, Policy Controller und Config Connector von Config Controller verwendet werden, finden Sie in den Versionshinweisen zu Config Controller.

Config Controller-Instanz löschen

Wenn Sie die Verwendung einer Config Controller-Instanz beenden möchten, bereinigen Sie alle bereits erstellten Config Connector-Ressourcen, bevor Sie den Config Controller-Cluster selbst löschen.

Wenn Sie Ihren Config Controller-Instanz löschen, ohne zuerst die bereitgestellten Ressourcen zu löschen, bleiben die Ressourcen im Status "Verworfen". Die Ressourcen sind weiterhin in Google Cloud vorhanden und es fallen Gebühren an, sie werden jedoch nicht über die deklarative Konfiguration verwaltet.

Nachdem alle Ressourcen gelöscht wurden, löschen Sie den 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.

Nächste Schritte