Anthos Config Management installieren

Der Config Management Operator ist ein Controller, der Anthos Config Management 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 Anthos Config Management verwalten möchten.

Hinweis

In diesem Abschnitt werden die Voraussetzungen beschrieben, die Sie erfüllen müssen, bevor unterstützte Cluster in Anthos Config Management registriert werden.

Lokale Umgebung vorbereiten

Bevor Sie den Operator installieren, müssen Sie die lokale Umgebung vorbereiten, indem Sie die folgenden Aufgaben ausführen:

  • Für die Verwaltung von Anthos-Konfigurationen ist eine aktive Anthos-Berechtigung erforderlich. Weitere Informationen finden Sie unter Preise für Anthos.

  • Installieren Sie das Cloud SDK mit den in dieser Anleitung verwendeten Befehlen gcloud, gsutil und kubectl.

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

    gcloud components install kubectl
    
  • Installieren Sie den nomos Befehl, damit Sie den nomos status Unterbefehl verwenden können, um Probleme bei der Installation und Einrichtung zu erkennen.

  • Um Komponenten von Anthos Config Management herunterzuladen, müssen Sie mit dem Befehl gcloud auth login bei Google Cloud authentifiziert sein.

  • Sie müssen den Befehl kubectl konfigurieren, um eine Verbindung zu Ihren Clustern herzustellen. Die Schritte dazu sind für GKE- und GKE On-Prem-Cluster unterschiedlich:

  • Die Anthos-API muss für Ihr Projekt aktiviert sein:

gcloud

Führen Sie den folgenden Befehl aus, um die Anthos API zu aktivieren:

gcloud services enable anthos.googleapis.com

Console

Anthos API aktivieren

Cluster

  • Ihre Cluster müssen sich auf einer von Anthos unterstützten Plattform und Version befinden.

  • Ihre Cluster müssen mit Connect in einer Anthos-Umgebung registriert sein. Die Umgebung Ihres Projekts bietet eine einheitliche Möglichkeit zum Anzeigen und Verwalten Ihrer Cluster und ihrer. Workloads als Teil von Anthos, einschließlich Clustern außerhalb von Google Cloud. Anthos-Gebühren gelten nur für Ihre registrierten Cluster. Informationen zum Registrieren eines Clusters finden Sie unter Registrieren eines Clusters.

Berechtigungen

Der Google Cloud-Nutzer, der Anthos Config Management 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 Anthos Config Management zu registrieren:

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

Operator bereitstellen

Wenn Sie den Config Management Operator mit der Google Cloud Console installieren, wird der Operator automatisch bereitgestellt. Fahren Sie mit Secret git-creds erstellen fort.

Wenn Sie geprüft haben, ob alle Voraussetzungen erfüllt sind, können Sie den Operator bereitstellen, 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-management-operator.yaml config-management-operator.yaml
    
  2. Wenden Sie die CRD an:

    kubectl apply -f config-management-operator.yaml

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

Operator Lesezugriff auf Git gewähren

Der Operator benötigt Lesezugriff auf Ihr Git-Repository (das Repository), damit er die per Commit an das Repository übertragenen Konfigurationen lesen und auf Ihre Cluster anwenden kann. Wenn Anmeldedaten erforderlich sind, werden diese auf jedem registrierten Cluster im git-creds-Secret gespeichert.

Wenn für das Repository keine Authentifizierung oder Autorisierung für den schreibgeschützten Zugriff erforderlich ist, müssen Sie kein git-creds Geheimnis erstellen. Sie können zu Anthos Config Management konfigurieren springen und SecretType auf none setzen.

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

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. Derzeit unterstützen GitHub, Cloud Source Repositories und Bitbucket die Verwendung eines SSH-Schlüsselpaars. Wenn das Repository von Ihrer Organisation gehostet wird und Sie nicht wissen, welche Authentifizierungsmethoden unterstützt werden, wenden Sie sich an Ihren Administrator.

Nach dem Erstellen der Anmeldedaten fügen Sie diese als Secret zum Cluster hinzu. Wie Sie das Secret erstellen, hängt von der Authentifizierungsmethode ab. Weitere Informationen finden Sie unten im jeweiligen Abschnitt zu Ihrer Authentifizierungsmethode.

Wählen Sie aus den nachfolgenden Optionen die beste Methode zur Autorisierung Ihres Repositorys aus. Die von Ihnen gewählte Methode bestimmt auch den secretType, den Sie beim Konfigurieren des Operators verwenden.

SSH-Schlüsselpaar verwenden

Wenn Ihr Repository die Verwendung eines SSH-Schlüsselpaars zur Autorisierung unterstützt, führen Sie zum Erstellen der Secret-Materialien die Schritte in diesem Abschnitt aus. Andernfalls sollten Sie die Anleitung unter cookiefile verwenden nutzen.

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.

  1. Erstellen Sie ein SSH-Schlüsselpaar, damit sich der Operator bei Ihrem Git-Repository authentifizieren kann. Dies ist erforderlich, wenn Sie sich beim Repository authentifizieren müssen, um es zu klonen oder 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 4096-Bit-RSA-Schlüssel erstellt. Niedrigere Werte werden nicht empfohlen. Ersetzen Sie [GIT REPOSITORY USERNAME] und /path/to/[KEYPAIR-FILENAME] durch die Werte, die der Operator zur Authentifizierung beim Repository verwenden soll. Sie sollten ein separates Konto verwenden, wenn Sie einen Git-Repository-Host eines Drittanbieters wie GitHub verwenden. Wenn Sie Cloud Source Repositories verwenden, sollten Sie ein Dienstkonto nutzen.

    ssh-keygen -t rsa -b 4096 \
     -C "[GIT REPOSITORY USERNAME]" \
     -N '' \
     -f [/path/to/KEYPAIR-FILENAME]
    
  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:

  3. Fügen Sie den privaten Schlüssel zu einem neuen Secret im Cluster hinzu. Fügen Sie bei /path/to/[KEYPAIR-PRIVATE-KEY-FILENAME] den Namen des privaten Schlüssels (den Namen ohne das Suffix .pub) ein.

    kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=ssh=/path/to/[KEYPAIR-PRIVATE-KEY-FILENAME]
    
  4. Löschen Sie den privaten Schlüssel vom lokalen Datenträger oder schützen Sie ihn anderweitig.

cookiefile verwenden

Wenn Ihr Repository das Verwenden eines SSH-Schlüsselpaars für die Autorisierung nicht unterstützt, können Sie ein cookiefile oder ein persönliches Zugriffstoken verwenden.

Folgen Sie den Schritten in diesem Abschnitt, um die cookiefile-Secret-Materialien zu erstellen.

Das Verfahren zum Abrufen eines cookiefile hängt von der Konfiguration Ihres Repositories ab. Informationen hierzu bietet der Artikel über das Generieren statischer Anmeldedaten in Cloud Source Repositories. Die Anmeldedaten werden normalerweise in der Datei .gitcookies im Basisverzeichnis des Nutzers gespeichert. Sie können Ihnen aber auch von einem Sicherheitsadministrator zur Verfügung gestellt werden.

  1. Nachdem Sie das cookiefile erstellt und abgerufen haben, fügen Sie es einem neuen Secret im Cluster hinzu. Ersetzen Sie /path/to/[COOKIEFILE] durch den entsprechenden Pfad und Dateinamen.

    kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=cookie_file=/path/to/[COOKIEFILE]
    
  2. Schützen Sie unbedingt den Inhalt des cookiefile, wenn Sie dieses noch lokal benötigen. Andernfalls können Sie es löschen.

Token verwenden

Wenn Ihre Organisation die Verwendung von SSH-Schlüsseln nicht zulässt, sollten Sie ein Token verwenden. Mit Anthos Config Management 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 eine PAT. Gewähren Sie dem Token den Bereich repo, damit es aus privaten Repositories lesen kann. Da Sie ein PAT an ein GitHub-Konto binden, sollten Sie auch einen Computernutzer erstellen und Ihre 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. Ersetzen Sie [USERNAME] durch den gewünschten Nutzernamen und [TOKEN] durch das Token, das Sie im vorherigen Schritt erstellt haben:

    kubectl create secret generic git-creds \
        --namespace="config-management-system" \
        --from-literal=username=[USERNAME] \
        --from-literal=token=[TOKEN]
    
  3. Schützen Sie das Token, wenn Sie es noch lokal benötigen. Andernfalls können Sie es löschen.

Google-Dienstkonto mit einem Google Source Repository verwenden

Wenn sich Ihr Repository in einem Google Source Repository befindet, können Sie secretType: gcenode verwenden, um Anthos Config Management Zugriff auf ein Repository im Projekt Ihres verwalteten Clusters zu gewähren.

Bevor Sie beginnen, sollten Sie sicherstellen, dass die folgenden Voraussetzungen erfüllt sind.

  • Das Compute Engine-Standarddienstkonto PROJECT_NUMBER-compute@developer.gserviceaccount.com für den Cluster muss source.reader-Zugriff auf das Repository haben.

    gcloud projects add-iam-policy-binding [PROJECT_ID] \
    --member serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
    --role roles/source.reader
    
  • Zugriffsbereiche für die Knoten im Cluster müssen cloud-source-repos-ro enthalten. Dies kann erreicht werden, indem Sie cloud-source-repos-ro in die Liste --scopes aufnehmen, die bem Erstellen des Clusters angegeben wurde, oder indem Sie den Bereich cloud-platform beim Erstellen des Clusters verwenden:

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

Sobald diese Voraussetzungen erfüllt sind, setzen Sie spec.git.syncRepo auf die URL des gewünschten Google Source Repository, wenn Sie den Operator konfigurieren. Beispiel:

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

Dies würde Folgendes erfordern:

spec.git.syncRepo: https://source.developers.google.com/p/my-project/r/my-repo-csr
Google Source Repository 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 obigen Schritte ausgeführt haben, erstellen Sie eine IAM-Richtlinienbindung zwischen dem Kubernetes-Dienstkonto und dem Google-Dienstkonto. Durch diese Bindung kann das Anthos Config Management Kubernetes-Dienstkonto als Compute Engine-Standarddienstkonto ausgeführt werden:

gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:[PROJECT_ID].svc.id.goog[config-management-system/importer]" \
  [PROJECT_NUMBER]-compute@developer.gserviceaccount.com

Fügen Sie schließlich dem Kubernetes-Dienstkonto von Anthos Config Management eine annotation hinzu. Verwenden Sie dazu die E-Mail-Adresse des Compute Engine-Standarddienstkontos:

kubectl annotate serviceaccount -n config-management-system importer \
  iam.gke.io/gcp-service-account=[PROJECT_NUMBER]-compute@developer.gserviceaccount.com

Keine Authentifizierung verwenden

Wenn für den Lesezugriff auf Ihr Repository keine Authentifizierung erforderlich ist, können Sie mit der Konfiguration des Operators fortfahren und spec.git.secretType auf none setzen.

Operator konfigurieren

Sie können den Operator für Ihren Cluster mit kubectl oder der Google Cloud Console konfigurieren.

kubectl

Erstellen Sie zum Konfigurieren des Verhaltens des Operators eine Konfigurationsdatei für die ConfigManagement-CustomResource und wenden Sie diese mit dem Befehl kubectl apply an.

Erstellen Sie beispielsweise eine Datei config-management.yaml und kopieren Sie die folgende YAML-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: my-cluster
  git:
    syncRepo: git@github.com:my-github-username/csp-config-management.git
    syncBranch: 1.0.0
    secretType: ssh
    policyDir: "foo-corp"

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

Verwenden Sie den Befehl kubectl apply, um die Konfiguration anzuwenden:

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-1
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 Wert auf unstructured gesetzt ist, wird ein nicht hierarchisches Repository konfiguriert. Standardeinstellung: hierarchy.
Proxykonfiguration für das Git-Repository

Wenn die Sicherheitsrichtlinien Ihrer Organisation verlangen, dass Sie den Traffic über einen HTTP(S)-Proxy leiten, können Sie Anthos Config Management für die Kommunikation mit Ihrem Git-Host mithilfe des 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 Benutzerdefinierter Name des Clusters, der von ClusterSelectors zum Gruppieren von Clustern verwendet wird. Eindeutiger Name in einer Anthos Config Management-Installation.
Konfiguration für Integrationen

Diese Felder ermöglichen die Integration mit Config Connector und Policy Controller.

Schlüssel Beschreibung
spec.configConnector.enabled Wenn true, wird Config Connector installiert. Die Standardeinstellung ist false.
spec.policyController.enabled Wenn true, wird Policy Controller aktiviert. Die Standardeinstellung ist false.
spec.policyController.templateLibraryInstalled Wenn true, wird die Einschränkungsvorlagenbibliothek installiert. Die Standardeinstellung ist true.

Console

Beschränkungen

Für die Konfiguration von Anthos Config Management in der Google Cloud Console gelten die folgenden Einschränkungen:

  • Sie können Folgendes nicht installieren oder konfigurieren:
    • Policy Controller
    • Config Connector
    • Hierarchy Controller
  • Nur ein Teil der Konfigurationsoptionen für Config Sync wird unterstützt. Nicht unterstützte Config Sync-Konfigurationen sind:
    • spec.git.proxy
    • spec.git.secretType: gcenode
    • spec.git.secretType: token
    • spec.sourceFormat

Wenn Sie eine dieser Optionen verwenden möchten, sollten Sie die Cloud Console nicht verwenden.

Operator konfigurieren

So konfigurieren Sie den Operator in der Cloud Console:

  1. Rufen Sie in der Google Cloud Console das Menü von Anthos Config Management auf.

    Zum Anthos Config Management-Menü

  2. Wählen Sie Ihre registrierten Cluster aus und klicken Sie auf Configure (Konfigurieren).

  3. Führen Sie im Abschnitt Git Repository Authentication für ACM Folgendes aus:

    1. Wählen Sie als Secret-Typ eine der folgenden Optionen aus:

      • None. Wählen Sie aus, ob für Ihr Repository keine Authentifizierung für den schreibgeschützten Zugriff erforderlich ist.
      • SSH
      • cookiefile

      Wenn Sie token oder gcenode auswählen möchten, konfigurieren Sie den Operator mit kubectl.

    2. Klicken Sie auf Weiter.

  4. Führen Sie im Abschnitt ACM-Einstellungen für Ihre Cluster folgende Schritte aus:

    1. Fügen Sie im Feld URL die URL des Git-Repositorys hinzu, das als "Source of Truth" verwendet werden soll. Das ist ein Pflichtfeld.
    2. Fügen Sie im Feld Branch den Branch des Repositorys hinzu, von dem aus synchronisiert werden soll. Der Standardwert ist der Master. Das ist ein Pflichtfeld.
    3. Fügen Sie im übermittelten Tag Tag/Commit die Git-Revision (Tag oder Hash) hinzu, um zur Kasse zu gehen. Die Standardeinstellung ist HEAD.
    4. Klicken Sie auf Show advanced options.
    5. Fügen Sie im Feld Richtlinienverzeichnis den zu synchronisierenden Pfad im Repository oben in der Richtlinienhierarchie ein. Standardmäßig wird .das Stammverzeichnis des Repositorys verwendet.
    6. Geben Sie im Feld Synchronisierungswartezeit den Zeitraum zwischen aufeinanderfolgenden Synchronisierungen in Sekunden ein. Der Standardwert beträgt 15 Sekunden.
  5. Klicken Sie auf Fertig. Sie werden zum Anthos Config Management-Menü zurückgeleitet. Aktualisieren Sie nach einigen Minuten die Seite. In der Statusspalte neben den von Ihnen konfigurierten Clustern sollte Synced angezeigt werden.

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 in 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 ermitteln, 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 Anthos Config Management 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.

Fehlerbehebung

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

Unzureichende CPU

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

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

So beheben Sie diesen Fehler:

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

Fehler: Versuch, zusätzliche Berechtigungen zu erteilen

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

Dieser Fehler weist darauf hin, dass der derzeitige Nutzer weniger Berechtigungen hat, als für die Installation erforderlich sind. Weitere Informationen finden Sie in der Kubernetes Engine-Dokumentation unter Voraussetzungen für die Nutzung der rollenbasierten Zugriffssteuerung.

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

Weitere Fehler werden unter Umständen in Zukunft hinzugefügt.

Beheben Sie den Konfigurationsfehler, um das Problem zu beheben. Je nach Fehlertyp müssen Sie das ConfigManagement-Manifest eventuell noch einmal auf den Cluster anwenden.

Wenn das Problem darin besteht, dass Sie vergessen haben, das Secret git-creds zu erstellen, erkennt der Operator das Secret, sobald Sie es erstellt haben, und Sie müssen die Konfiguration nicht noch einmal anwenden.

Aktualisieren

Dieser Abschnitt bietet nur eine allgemeine Anleitung zum Aktualisieren auf die aktuelle Version. Lesen Sie vor dem Upgrade die Versionshinweise, um eine spezifische Anleitung zu erhalten.

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

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

  2. Wenden Sie das Operator-Manifest an:

    kubectl apply -f config-management-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. Führen Sie diese Schritte für jeden Cluster aus, den Sie nicht mehr mit Anthos Config Management verwalten möchten.

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

    kubectl delete configmanagement --all

    Dies hat folgende Auswirkungen:

    • Alle von Anthos Config Management im Cluster erstellten ClusterRoles und ClusterRoleBindings werden aus dem Cluster gelöscht.
    • Alle von Anthos Config Management installierten Admission-Controller-Konfigurationen werden gelöscht.
    • Der Inhalt des Namespace config-management-system wird mit Ausnahme des Secrets git-creds gelöscht. Anthos Config Management funktioniert ohne den Namespace config-management-system nicht. Alle von Anthos Config Management erstellten oder geänderten CustomResourceDefinitions werden aus den Clustern entfernt, in denen sie erstellt oder geändert wurden. Die CustomResourceDefinitions (CRDs), die zum Ausführen des Config Management Operator erforderlich sind, sind noch vorhanden, da sie aus 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. An diesem Punkt ist der Operator noch in Ihrem Cluster vorhanden, führt jedoch keine Aktionen aus. Wenn Sie GKE On-Prem verwenden, können Sie den Operator nicht manuell entfernen.

    Wenn Sie GKE verwenden und entscheiden, dass Sie Anthos Config Management überhaupt nicht mehr verwenden möchten, können Sie den Operator folgendermaßen 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 Anthos Config Management-Objekte aus dem Namespace kube-system:

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

Nächste Schritte