Config Sync installieren

Der Config Sync Operator ist ein Controller, der Config Sync in einem Kubernetes-Cluster verwaltet. Führen Sie die folgenden Schritte aus, um den Operator in jedem Cluster zu installieren und zu konfigurieren, den Sie mit Config Sync verwalten möchten.

Hinweis: Auf dieser Seite erfahren Sie, wie Sie Config Sync als eigenständiges Produkt installieren. Wenn Sie Anthos verwenden, können Sie Config Sync mit Anthos Config Management installieren.

Ressourcenanforderungen

In der folgenden Tabelle sind die Kubernetes-Ressourcenanforderungen für Config Sync-Komponenten aufgeführt. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Ressourcen für Container verwalten.

Komponente	CPU	Speicher
Config Sync Operator	100 m	20 Mi
Config Sync	360 m	210 Mi

Hinweis

In diesem Abschnitt werden die Voraussetzungen beschrieben, die Sie vor der Installation von Config Sync in GKE erfüllen müssen.

Lokale Umgebung vorbereiten

Bevor Sie den Operator installieren, müssen Sie Ihre lokale Umgebung vorbereiten. Dazu führen Sie die folgenden Aufgaben aus:

• Installieren und initialisieren Sie das Cloud SDK, das die in dieser Anleitung verwendeten gcloud-, gsutil-, kubectl- und nomos-Befehle enthält. Wenn Sie Cloud Shell verwenden, ist Cloud SDK bereits installiert.

• kubectl wird vom Cloud SDK nicht standardmäßig installiert. Verwenden Sie zum Installieren von kubectl den folgenden Befehl:

  gcloud components install kubectl
  

• Authentifizieren Sie sich bei Google Cloud mit dem Befehl gcloud auth login, sodass Sie Komponenten von Config Sync herunterladen können.

Cluster vorbereiten

Ihre Cluster müssen die GKE-Version 1.14.x oder höher ausführen.

Berechtigungen vorbereiten

Der Google Cloud-Nutzer, der Config Sync installiert, benötigt IAM-Berechtigungen (Identity and Access Management – Identitäts- und Zugriffsverwaltung), um neue Rollen in Ihrem Cluster zu erstellen.

Cluster registrieren

Führen Sie die folgenden Schritte aus, um einen Cluster in Config Sync zu registrieren:

1. Operator bereitstellen
2. Operator Lesezugriff auf Git gewähren
3. Operator konfigurieren

Operator bereitstellen

Wenn Sie geprüft haben, ob alle Voraussetzungen erfüllt sind, können Sie den Operator bereitstellen, indem Sie ein YAML-Manifest herunterladen und anwenden.

1. Laden Sie die neueste Version der Operator-CRD mit dem folgenden Befehl herunter. Wenn Sie eine bestimmte Version herunterladen möchten, finden Sie unter Downloads weitere Informationen.

   gsutil cp gs://config-management-release/released/latest/config-sync-operator.yaml config-sync-operator.yaml
   

2. Wenden Sie die CRD an:

   kubectl apply -f config-sync-operator.yaml

Wenn dieser Schritt fehlschlägt, sollten Sie die Fehlerbehebung aufrufen.

Operator Lesezugriff auf Git gewähren

Config Sync benötigt Lesezugriff auf das Git-Repository, damit es die an das Repository übergebenen Konfigurationen lesen und auf Ihre Cluster anwenden kann. Wenn Anmeldedaten erforderlich sind, werden diese auf jedem registrierten Cluster im git-creds-Secret gespeichert.

Falls für den Lesezugriff auf Ihr Repository keine Authentifizierung erforderlich ist, können Sie mit der Konfiguration von Config Sync fortfahren und secretType auf none festlegen. Wenn Sie das Repository beispielsweise über eine Weboberfläche ohne Anmeldung aufrufen oder mit git clone einen Klon des Repositorys lokal erstellen können, ohne Anmeldedaten anzugeben oder gespeicherte Anmeldedaten zu verwenden, müssen Sie sich nicht authentifizieren. In diesem Fall brauchen Sie kein git-creds-Secret zu erstellen.

Die meisten Nutzer müssen jedoch Anmeldedaten erstellen, da der Lesezugriff auf ihr Repository eingeschränkt ist. Config Sync unterstützt die folgenden Authentifizierungsmechanismen:

• SSH-Schlüsselpaar
• cookiefile
• Token
• Google-Dienstkonto (nur Google Source Repositories)

Welchen Mechanismus Sie wählen, hängt davon ab, was Ihr Repository unterstützt. Wenn alle Mechanismen verfügbar sind, empfiehlt sich die Verwendung eines SSH-Schlüsselpaars. GitHub, Cloud Source Repositories und Bitbucket unterstützten die Verwendung eines SSH-Schlüsselpaars. Wenn Ihr Repository von Ihrer Organisation gehostet wird und Sie nicht wissen, welche Authentifizierungsmethoden unterstützt werden, wenden Sie sich an Ihren Administrator.

SSH-Schlüsselpaar

Ein SSH-Schlüsselpaar besteht aus zwei Dateien, einem öffentlichen und einem privaten Schlüssel. Der öffentliche Schlüssel hat in der Regel die Erweiterung .pub.

Achtung: Sie sollten die mit diesem Befehl erstellten Dateien sichern, da sie den Lesezugriff auf das Repository ermöglichen.

Führen Sie die folgenden Schritte aus, um ein SSH-Schlüsselpaar zu verwenden:

1. Erstellen Sie ein SSH-Schlüsselpaar, damit sich Config Sync bei Ihrem Git-Repository authentifizieren kann. Dieser Schritt ist erforderlich, wenn Sie sich beim Repository authentifizieren müssen, um es zu klonen oder Daten daraus zu lesen. Überspringen Sie diesen Schritt, wenn Sie ein Schlüsselpaar von einem Sicherheitsadministrator erhalten. Sie können ein einziges Schlüsselpaar für alle Cluster oder ein Schlüsselpaar pro Cluster verwenden, je nach Ihren Sicherheits- und Complianceanforderungen.

   Mit dem folgenden Befehl wird ein 4.096-Bit-RSA-Schlüssel erstellt. Niedrigere Werte werden nicht empfohlen:

   ssh-keygen -t rsa -b 4096 \
   -C "GIT_REPOSITORY_USERNAME" \
   -N '' \
   -f /path/to/KEYPAIR_FILENAME
   

   Dabei gilt:

   • GIT_REPOSITORY_USERNAME: Fügen Sie den Nutzernamen hinzu, mit dem sich Config Sync beim Repository authentifizieren soll.
   • /path/to/KEYPAIR_FILENAME: Fügen Sie den Pfad zum Schlüsselpaar hinzu.

   Wenn Sie einen Drittanbieter-Host für das Git-Repository wie GitHub oder ein Dienstkonto mit Cloud Source Repositories nutzen möchten, empfehlen wir die Verwendung eines separaten Kontos.

   Hinweis: Sie müssen den SSH-Schlüssel ohne Passphrase erstellen. Config Sync unterstützt keine Passphrasen für SSH-Schlüssel.

2. Konfigurieren Sie Ihr Repository so, dass der neu erstellte öffentliche Schlüssel erkannt wird. Weitere Informationen finden Sie in der Dokumentation Ihres Git-Hostanbieters. Anleitungen für einige beliebte Git-Hostanbieter finden Sie hier:

   • Cloud Source Repositories
   • Bitbucket.
   • GitHub Wir empfehlen, separate Bereitstellungsschlüssel zu erstellen, um Lesezugriff auf ein einzelnes GitHub-Repository zu gewähren.
   • GitLab

3. Fügen Sie den privaten Schlüssel einem neuen Secret im Cluster hinzu:

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=ssh=/path/to/KEYPAIR_PRIVATE_KEY_FILENAME
   

   Ersetzen Sie /path/to/KEYPAIR_PRIVATE_KEY_FILENAME durch den Namen des privaten Schlüssels (den Namen ohne das Suffix .pub).

4. Löschen Sie den privaten Schlüssel vom lokalen Datenträger oder schützen Sie ihn anderweitig.

cookiefile

Hinweis: Die Verwendung von cookiefile-Anmeldedaten wird nur bei Cloud Source Repositories unterstützt. Wenn Sie GitHub mit der cookiefile-Authentifizierung verwenden möchten, können Sie Cloud Source Repositories verwenden, um das GitHub-Repository zu spiegeln.

Das Verfahren zum Abrufen eines cookiefile hängt von der Konfiguration Ihres Repositories ab. Ein Beispiel finden Sie in der Dokumentation zu Cloud Source Repositories unter Statische Anmeldedaten generieren. Die Anmeldedaten werden normalerweise in der Datei .gitcookies im Basisverzeichnis gespeichert. Sie können Ihnen aber auch von einem Sicherheitsadministrator zur Verfügung gestellt werden.

Führen Sie die folgenden Schritte aus, um ein cookiefile zu erstellen:

1. Nachdem Sie das cookiefile erstellt und abgerufen haben, fügen Sie es einem neuen Secret im Cluster hinzu.

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=cookie_file=/path/to/COOKIEFILE
   

   Ersetzen Sie /path/to/COOKIEFILE durch den entsprechenden Pfad und Dateinamen.

2. Schützen Sie den Inhalt des cookiefile, wenn Sie es noch lokal benötigen. Andernfalls können Sie es löschen.

Token

Wenn Ihre Organisation die Verwendung von SSH-Schlüsseln nicht zulässt, sollten Sie ein Token verwenden. Mit Config Sync können Sie die Personal Access Tokens (PAT) von GitHub oder das App-Passwort von Bitbucket als Token verwenden.

Führen Sie die folgenden Schritte aus, um mit dem Token ein Secret zu erstellen:

1. Erstellen Sie ein Token mit GitHub oder Bitbucket.

   • GitHub:Erstellen Sie ein PAT. Gewähren Sie dem Token den repo-Bereich, damit es aus privaten Repositories lesen kann. Da Sie ein PAT an ein GitHub-Konto binden, sollten Sie auch einen Computernutzer erstellen und Ihr PAT an den Computernutzer binden.

   • Bitbucket:Erstellen Sie ein App-Passwort.

2. Nachdem Sie das Token erstellt und abgerufen haben, fügen Sie es einem neuen Secret im Cluster hinzu.

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace="config-management-system" \
     --from-literal=username=USERNAME \
     --from-literal=token=TOKEN
   

   Dabei gilt:

   • USERNAME: Fügen Sie den gewünschten Nutzernamen hinzu.
   • TOKEN: Fügen Sie das Token hinzu, das Sie im vorherigen Schritt erstellt haben

3. Schützen Sie das Token, wenn Sie es noch lokal benötigen. Andernfalls können Sie es löschen.

Google-Dienstkonto

Hinweis: Der secretType gcenode funktioniert nur in GKE in Google Cloud.

Wenn sich Ihr Repository in Cloud Source Repositories befindet, können Sie secretType: gcenode verwenden, um Config Sync Zugriff auf ein Repository im selben Projekt wie Ihr verwalteter Cluster zu gewähren.

Vorbereitung

Bevor Sie beginnen, sollten Sie prüfen, dass die folgenden Voraussetzungen erfüllt sind:

• Zugriffsbereiche für die Knoten im Cluster müssen cloud-source-repos-ro enthalten. Das Compute Engine-Standarddienstkonto [e-mail] hat standardmäßig source.reader-Zugriff auf das Repository für dasselbe Projekt. Bei Bedarf können Sie die Rolle jedoch mit folgendem Befehl hinzufügen:

  gcloud projects add-iam-policy-binding PROJECT_ID \
    --member serviceAccount:[e-mail] \
    --role roles/source.reader
  

  Dabei gilt:

  • PROJECT_ID: Fügen Sie die Projekt-ID Ihrer Organisation hinzu.
  • PROJECT_NUMBER: Fügen Sie die Projektnummer Ihrer Organisation hinzu.

• Zugriffsbereiche für die Knoten im Cluster müssen cloud-source-repos-ro enthalten. Zum Hinzufügen dieses Bereichs können Sie cloud-source-repos-ro in die Liste --scopes aufnehmen, die beim Erstellen des Clusters angegeben wird, oder den Bereich cloud-platform verwenden, wenn Sie den Cluster erstellen:

  gcloud container clusters create example-cluster --scopes=cloud-platform
  

Hinweis: Sie können Zugriffsbereiche nicht ändern, nachdem Sie einen Knotenpool erstellt haben. Allerdings haben Sie die Möglichkeit, unter Verwendung desselben Clusters einen neuen Knotenpool mit dem richtigen Zugriffsbereich zu erstellen. Der Standardbereich gke-default enthält nicht cloud-source-repos-ro.

Cloud Source Repositories als SyncRepo verwenden

Wenn diese Voraussetzungen erfüllt sind, legen Sie spec.git.syncRepo als URL des gewünschten Cloud Source Repositories fest, wenn Sie den Operator konfigurieren.

Führen Sie die folgenden Schritte aus, um Cloud Source Repositories als SyncRepo zu verwenden:

1. Listen Sie alle Repositories auf:

   gcloud source repos list
   

2. Kopieren Sie aus der Ausgabe die URL des Repositorys, das Sie verwenden möchten:

   REPO_NAME  PROJECT_ID  URL
   my-repo    my-project  https://source.developers.google.com/p/my-project/r/my-repo-csr
   

3. Fügen Sie die URL als Ihr syncRepo hinzu. Beispiele:

   spec.git.syncRepo: https://source.developers.google.com/p/my-project/r/my-repo-csr
   

Cloud Source Repositories mit Workload Identity verwenden

Wenn Workload Identity in Ihrem Cluster aktiviert ist, sind für die Verwendung von secretType: gcenode zusätzliche Schritte erforderlich. Nachdem Sie die vorherigen Schritte ausgeführt und Config Sync konfiguriert haben (im folgenden Abschnitt), erstellen Sie eine IAM-Richtlinienbindung zwischen dem Kubernetes-Dienstkonto und dem Google-Dienstkonto. Das Kubernetes-Dienstkonto wird erst erstellt, wenn Sie Config Sync zum ersten Mal konfigurieren.

Durch diese Bindung kann das Kubernetes-Dienstkonto von Config Sync als Compute Engine-Standarddienstkonto verwendet werden:

gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[config-management-system/importer]" \
  [e-mail]

Ersetzen Sie Folgendes: * PROJECT_ID: die Projekt-ID Ihrer Organisation * PROJECT_NUMBER: die Projektnummer Ihrer Organisation

Hinweis: Zum Erstellen dieser Richtlinienbindung ist die Berechtigung iam.serviceAccounts.setIamPolicy erforderlich.

Nachdem Sie die Bindung erstellt haben, fügen Sie dem Kubernetes-Dienstkonto von Config Sync eine annotation mit der E-Mail-Adresse des Compute Engine-Standarddienstkontos hinzu:

kubectl annotate serviceaccount -n config-management-system importer \
  iam.gke.io/gcp-service-account=[e-mail]

Ersetzen Sie PROJECT_NUMBER durch die Projektnummer Ihrer Organisation.

Operator konfigurieren

Erstellen Sie zum Konfigurieren des Verhaltens von Config Sync eine Konfigurationsdatei für die CustomResource von ConfigManagement und wenden Sie sie mit dem Befehl kubectl apply an:

1. Erstellen Sie eine Datei config-management.yaml und kopieren Sie die folgende YAML-Datei in diese Datei.

   # config-management.yaml
   
   apiVersion: configmanagement.gke.io/v1
   kind: ConfigManagement
   metadata:
     name: config-management
   spec:
     # clusterName is required and must be unique among all managed clusters
     clusterName: CLUSTER_NAME
     git:
       syncRepo: REPO
       syncBranch: BRANCH
       secretType: TYPE
       policyDir: "DIRECTORY"
   

   Dabei gilt:

   • CLUSTER_NAME: Fügen Sie den Namen des registrierten Clusters hinzu, auf den Sie diese Konfiguration anwenden möchten.
   • REPO: Fügen Sie die URL des Git-Repositorys hinzu, das als „Source of Truth“ verwendet werden soll. Dies ist ein Pflichtfeld.
   • BRANCH: Fügen Sie den Zweig des Repositorys hinzu, von dem aus synchronisiert werden soll. Die Standardeinstellung ist der Hauptzweig (Master).

   • TYPE: Fügen Sie einen der folgenden SecretTypes hinzu:

     • none
     • ssh
     • cookiefile
     • token
     • gcenode

   • DIRECTORY: Fügen Sie den Pfad zur obersten Ebene der zu synchronisierenden Richtlinienhierarchie im Repository hinzu. Standardmäßig wird das Stammverzeichnis des Repositorys verwendet.

   Hinweis: Zum Speichern von config-management.yaml in Ihrem Git-Repository müssen Sie policyDir auf ein Unterverzeichnis festlegen und alle Konfigurationen in diesem Unterverzeichnis ablegen. Speichern Sie die Datei config-management.yaml nicht im Unterverzeichnis policyDir.

   Eine vollständige Liste der Felder, die Sie dem Feld spec hinzufügen können, finden Sie im Abschnitt Konfiguration für das Git-Repository. Ändern Sie keine Konfigurationswerte außerhalb des Felds „spec“.

2. Wenden Sie die Konfiguration mit dem Befehl kubectl apply an:

   kubectl apply -f config-management.yaml
   

   Möglicherweise müssen Sie separate Konfigurationsdateien für jeden Cluster oder jeden Clustertyp erstellen. Sie können den Cluster mit der Option --context angeben:

   kubectl apply -f config-management1.yaml --context=CLUSTER_NAME
   

   Ersetzen Sie CLUSTER_NAME durch den Namen des Clusters, den Sie verwenden möchten.

Konfiguration für das Git-Repository

Schlüssel	Beschreibung
spec.git.syncRepo	Die URL des Git-Repositorys, das als „Source of Truth“ verwendet werden soll. Erforderlich.
spec.git.syncBranch	Der Zweig des Repositories, von dem aus synchronisiert werden soll. Standardeinstellung: master.
spec.git.policyDir	Der Pfad im Git-Repository, der die oberste Ebene des zu synchronisierenden Repositories darstellt. Standardeinstellung: das Stammverzeichnis des Repositorys.
spec.git.syncWait	Zeitraum in Sekunden zwischen aufeinanderfolgenden Synchronisierungen. Standardeinstellung: 15.
spec.git.syncRev	Git-Revision (Tag oder Hash) zum Auschecken. Standardeinstellung: HEAD.
spec.git.secretType	Die Art des Secrets, das für den Zugriff auf das Git-Repository konfiguriert ist. Entweder ssh, cookiefile, token, gcenode oder none. Erforderlich.
spec.sourceFormat	Wenn dieser Parameter auf unstructured gesetzt ist, wird ein nicht hierarchisches Repository konfiguriert. Standardeinstellung: hierarchy.

Proxykonfiguration für das Git-Repository

Wenn Sie gemäß den Sicherheitsrichtlinien Ihrer Organisation Traffic über einen HTTP(S)-Proxy weiterleiten müssen, können Sie Config Sync für die Kommunikation mit Ihrem Git-Host über den URI des Proxys konfigurieren.

Schlüssel	Beschreibung
spec.git.proxy.httpProxy	httpProxy definiert eine HTTP_PROXY-Umgebungsvariable, die für den Zugriff auf das Git-Repository verwendet wird.
spec.git.proxy.httpsProxy	httpsProxy definiert eine HTTPS_PROXY-Umgebungsvariable, die für den Zugriff auf das Git-Repository verwendet wird.

Wenn sowohl das Feld httpProxy als auch httpsProxy angegeben wurde, wird httpProxy ignoriert.

Konfiguration für das Verhalten des ConfigManagement-Objekts

Schlüssel	Beschreibung
spec.clusterName	Der benutzerdefinierte Name für den Cluster, der von ClusterSelectors zum Gruppieren von Clustern verwendet wird. Er ist innerhalb einer Config Sync-Installation eindeutig.

Installation prüfen

Mit dem Befehl nomos status können Sie prüfen, ob der Operator erfolgreich installiert wurde. Eine gültige Installation ohne Probleme hat den Status PENDING oder SYNCED. Eine ungültige oder unvollständige Installation hat den Status NOT INSTALLED ODER NOT CONFIGURED. Die Ausgabe enthält auch alle gemeldeten Fehler.

Wenn der Operator erfolgreich bereitgestellt wurde, wird er im Namespace kube-system auf einem Pod ausgeführt, dessen Name mit config-management-operator beginnt. Es kann einen Moment dauern, bis der Pod initialisiert ist. Prüfen Sie, ob der Pod ausgeführt wird:

kubectl -n kube-system get pods | grep config-management

Wenn der Pod ausgeführt wird, sieht die Antwort des Befehls in etwa so aus (aber nicht genau so):

config-management-operator-6f988f5fdd-4r7tr 1/1 Running 0 26s

Sie können auch prüfen, ob der Namespace config-management-system vorhanden ist:

kubectl get ns | grep 'config-management-system'

Die Befehlsausgabe sieht in etwa so aus:

config-management-system Active 1m

Wenn die Befehle vollkommen andere Ausgabewerte als in diesem Beispiel zurückgeben, können Sie anhand der Logs feststellen, was schiefgelaufen ist:

kubectl -n kube-system logs -l k8s-app=config-management-operator

Sie können auch kubectl get events verwenden, um zu prüfen, ob Config Sync Ereignisse erstellt hat.

kubectl get events -n kube-system

Es ist möglich, dass eine ungültige Konfiguration nicht sofort erkannt wird, z. B. ein fehlendes oder ungültiges git-creds-Secret. Informationen zur Fehlerbehebung finden Sie im Abschnitt "Fehlerbehebung" dieses Themas unter Gültiges, aber falsches ConfigManagement-Objekt.

Config Sync-Versionen aktualisieren

Dieser Abschnitt enthält eine allgemeine Anleitung zum Upgrade auf die aktuelle Version. Lesen Sie vor dem Upgrade die Versionshinweise, um eine spezifische Anleitung zu erhalten.

Hinweis: Überspringen Sie beim Upgrade keine Nebenversionen.

Führen Sie diese Befehle für jeden registrierten Cluster aus.

1. Laden Sie das Operator-Manifest und die nomos-Befehle für die neue Version herunter.

2. Wenden Sie das Operator-Manifest an:

   kubectl apply -f config-sync-operator.yaml
   

   Mit diesem Befehl wird das Operator-Image aktualisiert. Kubernetes ruft die neue Version ab und startet den Operator-Pod mit der neuen Version neu. Wenn der Operator gestartet wird, führt er eine Abgleichsschleife aus, die die im neuen Image gebündelten Manifeste anwendet. Dadurch wird jeder Komponenten-Pod aktualisiert und neu gestartet.

3. Ersetzen Sie auf allen Clients den Befehl nomos oder nomos.exe durch die neue Version. Dadurch wird sichergestellt, dass der Befehl nomos immer den Status aller registrierten Cluster abrufen und für sie Konfigurationen prüfen kann.

Operator aus einem Cluster deinstallieren

Folgen Sie dieser Anleitung, um den Operator aus einem Cluster zu deinstallieren. Sie müssen diese Schritte für jeden Cluster ausführen, den Sie nicht mehr mit Config Sync verwalten möchten.

Hinweise zur Deinstallation von Config Sync

• Die Deinstallation von Config Sync wirkt sich nicht auf die Konfigurationen in Ihrem Repository aus und entfernt keine Konfigurationen aus Ihren Clustern.
• Bevor Sie Config Sync für einen Cluster deinstallieren können, muss der Operator ausgeführt werden.

1. Löschen Sie das ConfigManagement-Objekt aus dem Cluster:

   kubectl delete configmanagement --all

   Dies hat folgende Auswirkungen:

   • Alle von Config Sync im Cluster erstellten ClusterRoles und ClusterRoleBindings werden aus dem Cluster gelöscht.
   • Alle von Config Sync installierten Admission-Controller-Konfigurationen werden gelöscht.
   • Der Inhalt des Namespace config-management-system wird mit Ausnahme des Secrets git-creds gelöscht. Config Sync funktioniert ohne den Namespace config-management-system nicht. Alle von Config Sync erstellten oder geänderten CustomResourceDefinitions werden aus den Clustern entfernt, in denen sie erstellt oder geändert wurden. Die zum Ausführen des Operators erforderlichen CustomResourceDefinitions (CRDs) sind noch vorhanden, da sie aus der Sicht von Kubernetes von dem Nutzer hinzugefügt wurden, der den Operator installiert hat. Wie Sie diese CRDs entfernen, erfahren Sie im nächsten Schritt.

2. Zu diesem Zeitpunkt ist der Operator zwar noch in Ihrem Cluster vorhanden, führt jedoch keine Aktionen aus.

   Wenn Sie GKE verwenden und Config Sync überhaupt nicht mehr verwenden möchten, können Sie den Operator so deinstallieren:

   1. Nachdem Sie im vorherigen Schritt das ConfigManagement-Objekt gelöscht haben, prüfen Sie jetzt, ob der Namespace config-management-system leer ist. Warten Sie, bis der Befehl kubectl -n config-management-system get all den Wert No resources found. zurückgibt.

   2. Löschen Sie den Namespace config-management-system:

      kubectl delete ns config-management-system
      

   3. Löschen Sie die ConfigManagement CustomResourceDefinition:

      kubectl delete crd configmanagements.configmanagement.gke.io
      

   4. Löschen Sie alle Config Sync-Objekte aus dem Namespace kube-system:

      kubectl -n kube-system delete all -l k8s-app=config-management-operator
      

Fehlerbehebung

In den folgenden Abschnitten erfahren Sie, wie Sie Fehler bei der Installation von Config Sync beheben.

Unzureichende CPU

Die Ausgabe von kubectl get events kann ein Ereignis vom Typ FailedScheduling enthalten. Das Ereignis sieht in etwa so aus:

LAST SEEN   TYPE      REASON              OBJECT                                             MESSAGE
9s          Warning   FailedScheduling    pod/config-management-operator-74594dc8f6    0/1 nodes are available: 1 Insufficient cpu.

Wählen Sie eine der folgenden Optionen, um diesen Fehler zu beheben:

• Fügen Sie einem vorhandenen GKE-Knotenpool einen Knoten hinzu.
• Erstellen Sie einen Knotenpool mit größeren Knoten.

Fehler: Versuch, zusätzliche Berechtigungen zu erteilen

Wenn Sie die folgende Fehlermeldung erhalten:

Error from server (Forbidden): error when creating "config-sync-operator.yaml": clusterroles.rbac.authorization.k8s.io "config-management-operator" is forbidden: attempt to grant extra privileges: [...] ruleResolutionErrors=[]

Wenn Sie versuchen, die Datei config-management-operator.yaml anzuwenden, haben Sie weniger Berechtigungen als für die Installation erforderlich ist. Lesen Sie den Abschnitt Berechtigungen vorbereiten, damit Sie die erforderlichen Berechtigungen haben.

Gültiges, aber falsches ConfigManagement-Objekt

Wenn die Installation aufgrund eines Problems mit dem ConfigManagement-Objekt fehlschlägt, das nicht auf einen YAML- oder JSON-Syntaxfehler zurückzuführen ist, wird das ConfigManagement-Objekt unter Umständen im Cluster instanziiert, funktioniert jedoch eventuell nicht ordnungsgemäß. In diesem Fall können Sie mit dem Befehl nomos status im ConfigManagement-Objekt nach Fehlern suchen.

Eine gültige Installation ohne Probleme hat den Status PENDING oder SYNCED.

Eine ungültige Installation hat den Status NOT CONFIGURED und führt einen der folgenden Fehler auf:

• missing git-creds Secret
• missing required syncRepo field
• git-creds Secret is missing the key specified by secretType

Beheben Sie den Konfigurationsfehler, um das Problem zu lösen. Je nach Art des Fehlers müssen Sie möglicherweise das ConfigManagement-Manifest noch einmal auf den Cluster anwenden.

Wenn das Problem darin bestand, dass Sie das git-creds-Secret nicht erstellt haben, wird es nach seiner Erstellung von Config Sync sofort erkannt. Sie müssen die Konfiguration nicht noch einmal anwenden.

Nächste Schritte

• Kurzanleitung ansehen
• Konfigurationen erstellen
• nomos-Befehl ausführen