Config Controller einrichten

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

Config Controller bietet eine verwaltete Steuerungsebene auf der Grundlage von Kubernetes. Außerdem sind auf Config Controller-Instanzen Policy Controller, Config Sync und Config Connector vorinstalliert. Durch die Verwendung dieser Komponenten können Sie die Tools und Workflows von Kubernetes nutzen, um Google Cloud-Ressourcen zu verwalten und mithilfe eines GitOps-Workflows Konsistenz zu erreichen. Weitere Informationen finden Sie in der Config Controller-Übersicht.

Wenn Sie zum ersten Mal eine Config Controller-Instanz erstellen, finden Sie weitere Informationen unter Kurzanleitung: Ressourcen mit Config Controller verwalten.

Beschränkungen

  • Da Config Controller-Instanzen vollständig verwaltet sind, 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 das Google Cloud CLI bereits installiert.

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

    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, das Config Controller hostet.

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

  1. Config Controller-Instanz erstellen:

    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: den Namen, den Sie der Config Controller-Instanz geben möchten

    • LOCATION: Fügen Sie eine der folgenden Regionen hinzu:

      • us-central1
      • us-east1
      • us-east4
      • us-east5
      • us-west1
      • us-west2
      • us-west3
      • us-west4
      • us-south1
      • northamerica-northeast1
      • northamerica-northeast2
      • southamerica-west1
      • southamerica-east1
      • europe-north1
      • europe-west1
      • europe-west3
      • europe-west4
      • europe-west6
      • europe-west9
      • europe-west10
      • europe-west12
      • europe-central2
      • europe-southwest1
      • australia-southeast1
      • australia-southeast2
      • asia-east1
      • asia-east2
      • asia-northeast1
      • asia-northeast2
      • asia-northeast3
      • asia-southeast1
      • asia-southeast2
      • asia-south1
      • asia-south2
      • africa-south1
      • me-west1
      • me-central1

      Dies ist die Region, in der Ihre Config Controller-Instanz erstellt wird. Es werden keine anderen Regionen unterstützt.

    Sie können mehrere optionale Parameter festlegen, wenn Sie eine Config Controller-Standardinstanz erstellen. 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 geschieht, können Sie den Log-Explorer in der Google Cloud Console aufrufen.

    Zu „Log-Explorer“

    Wenn während der Erstellung Fehler auftreten, finden Sie unter Fehlerbehebung bei Config Controller Informationen zur Behebung häufiger Probleme.

  2. Prüfen Sie in der Liste der Config Controller-Instanzen, ob Ihre Config Controller-Instanzen erstellt wurden:

    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 und Sie sollten weiter warten. Wenn ERROR angezeigt wird, ist ein Problem aufgetreten, das Sie nicht selbst lösen können. Wenn Sie Hilfe benötigen, wenden Sie sich an den Google Cloud-Support.

  3. Rufen Sie für die Kommunikation mit dem Config Controller-Endpunkt die entsprechenden Anmeldedaten und Endpunktinformationen ab:

    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 unter Vorhandene Ressource abrufen.

  • Verwenden Sie Policy Controller, um Einschränkungen anzuwenden, die die Einhaltung gesetzlicher Vorschriften 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 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 Config Controller jedoch Berechtigungen zum Verwalten von Google 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 Cloud-Ressourcen beginnen.

Policy Controller konfigurieren

Möglicherweise müssen Sie die IAM-Richtlinie hinzufügen oder aktualisieren, damit der 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 Google Cloud-Projekt-ID des Clusters.

Config Sync konfigurieren

Wenn Sie möchten, dass Ihre Config Controller-Instanz aus Konfigurationen synchronisiert wird, 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 zum Konfigurieren von Config Sync ein RootSync-Objekt:

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

  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) 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 Sie einen Hash in Version 1.17.0 oder höher 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. Ab Config Sync Version 1.17.0 wird empfohlen, das Feld revision zu verwenden, um einen Zweignamen 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 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 des 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 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: Legen Sie 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: 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 zum Erstellen der Config Sync-Konfiguration ein RootSync-Objekt. Wenden Sie dazu das Manifest an:

    kubectl apply -f root-sync.yaml

  4. Rufen Sie das RootSync-Objekt auf, um zu prüfen, ob die Ä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 Features und dazu, welche Config Sync-, Policy Controller- und Config Connector-Versionen Config Controller verwendet, 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