Vorhandene Clusterobjekte verwalten

Wenn Config Sync ein Clusterobjekt verwaltet, überwacht es das Objekt und den Satz von Konfigurationen im entsprechenden Repository für das Objekt und sorgt dafür, dass beide synchron sind. In diesem Thema wird gezeigt, wie Sie mit der Verwaltung eines vorhandenen Objekts beginnen und die Verwaltung eines aktuell verwalteten Objekts beenden, ohne das Objekt zu löschen.

Übersicht

Ein Objekt in einem Cluster wird dann von Config Sync verwaltet, wenn es die Annotation configmanagement.gke.io/managed: enabled hat.

Ohne die Annotation configmanagement.gke.io/managed oder wenn für die Annotation nicht enabled festgelegt ist, wird das Objekt nicht verwaltet.

Im folgenden Flussdiagramm werden die Bedingungen dargestellt, unter denen ein Objekt verwaltet bzw. nicht verwaltet wird:

Diagramm: Kubernetes-Objekt mit Config Sync verwalten bzw. dessen Verwaltung aufheben

Im Diagramm sind drei separate Abläufe aufgeführt: Start der Verwaltung eines Objekts, Beenden der Verwaltung eines Objekts und Löschen eines verwalteten Objekts.

  1. Ich möchte ein Objekt verwalten. a. Hat das Objekt eine Konfiguration im Repository?
    • Nein: Erstellen Sie eine Konfiguration für das Objekt. Config Sync legt die Annotation configmanagement.gke.io/managed: enabled fest und beginnt mit der Objektverwaltung.
    • Ja: Legt die Konfiguration die Annotation configmanagement.gke.io/managed: disabled fest?
      • Nein: Das Objekt wird standardmäßig verwaltet.
      • Ja: Bearbeiten Sie die Konfiguration und entfernen Sie die Annotation configmanagement.gke.io/managed: disabled. Wenn die Änderung per Push in das Quell-Repository übertragen wird, erkennt Config Sync die Änderung und wendet die Annotation configmanagement.gke.io/managed: enabled und sowie die Konfiguration an.
  2. Ich möchte die Verwaltung eines Objekts beenden, dieses aber nicht löschen.
    • Bearbeiten Sie die Konfiguration für das Objekt im Repository und legen Sie die Annotation configmanagement.gke.io/managed: disabled fest. Sobald die Konfigurationsänderung erkannt wurde, beendet Config Sync die Verwaltung des Objekts.
  3. Ich möchte die Verwaltung eines Objekts beenden und es löschen.
    • Löschen Sie die Konfiguration des Objekts aus dem Repository. Wenn Sie eine Konfiguration für ein zuvor verwaltetes Objekt löschen, entfernt Config Sync das Objekt aus allen Clustern oder Namespaces, für die die Konfiguration gilt.

Abgesehen von der Annotation configmanagement.gke.io/managed: enabled wendet Config Sync auf alle Objekte, die es verwaltet, das Label app.kubernetes.io/managed-by: configmanagement.gke.io an. Mit diesem Label können Sie alle durch Config Sync verwalteten Objekte auf einfache Weise auflisten.

Warum kann ich die Annotation nicht einfach manuell anwenden?

Config Sync verwendet ein deklaratives Modell, um Konfigurationsänderungen auf Ihre Cluster anzuwenden. Dazu wird die gewünschte Konfiguration aus Ihrem Repository gelesen. Wenn Sie versuchen, die Annotation manuell anzuwenden (entweder mit dem kubectl-Befehl oder mit der Kubernetes API), überschreibt Config Sync die manuelle Festlegung automatisch mit dem Inhalt Ihres Repositorys.

Hinweis

Die folgenden Beispiele bauen auf der Kurzanleitung auf. Folgen Sie vor den im Folgenden aufgeführten Schritten der Kurzanleitung und führen Sie alle Schritte aus, bevor Sie Ihren Cluster und Ihr Repository prüfen.

Alle verwalteten Objekte auflisten

Um alle von Config Sync verwalteten Objekte in einem bestimmten Cluster oder Namespace aufzulisten, verwenden Sie eine Labelauswahl wie die folgende:

kubectl get object-type -l "app.kubernetes.io/managed-by=configmanagement.gke.io"

Um alle nicht von Config Sync verwalteten Objekte aufzulisten, verwenden Sie eine Labelauswahl wie die folgende:

kubectl get object-type -l "app.kubernetes.io/managed-by!=configmanagement.gke.io"

Dieser Befehl zeigt z. B. RoleBindings im Namespace shipping-dev an, die von Config Sync verwaltet werden:

kubectl get rolebindings -n shipping-dev \
    -l "app.kubernetes.io/managed-by=configmanagement.gke.io"
NAME           AGE
job-creators   12m
pod-creators   12m
sre-admin      12m
viewers        12m

Mit dem folgenden Befehl werden die RoleBindings im Namespace kube-system aufgelistet, die von Config Sync nicht verwaltet werden:

kubectl get rolebindings -n kube-system \
    -l "app.kubernetes.io/managed-by!=configmanagement.gke.io"
NAME                                             AGE
fluentd-gcp-scaler-binding                       2d21h
gce:cloud-provider                               2d21h
heapster-binding                                 2d21h
metrics-server-auth-reader                       2d21h
system::leader-locking-kube-controller-manager   2d21h
system::leader-locking-kube-scheduler            2d21h
system:controller:bootstrap-signer               2d21h
system:controller:cloud-provider                 2d21h
system:controller:token-cleaner                  2d21h

Ein vorhandenes Objekt verwalten

In diesem Beispiel erstellen Sie manuell eine Rolle und verwalten diese dann mit Config Sync.

  1. Erstellen Sie die Rolle myrole im Namespace audit:

    kubectl create role -n audit myrole --verb=get --resource=pods
  2. Rufen Sie die Berechtigungen auf, die von der Rolle myrole erteilt werden:

    kubectl describe role -n audit myrole
    Name:         myrole
    Labels:       <none>
    Annotations:  <none>
    PolicyRule:
      Resources  Non-Resource URLs  Resource Names  Verbs
      ---------  -----------------  --------------  -----
      pods       []                 []              [get]
    

    Die Rolle hat nur Berechtigungen für get-Pods.

  3. An dieser Stelle ist die Rolle zwar im Cluster vorhanden, aber dies ist Config Sync nicht bekannt.

    1. Rufen Sie über ein Terminal den lokalen Klon Ihres Repositories auf.
    2. Mit dem folgenden Befehl können Sie für myrole ein YAML-Manifest erstellen und das Manifest in einer neuen Datei namens namespaces/audit/myrole.yaml speichern.

      kubectl get role myrole -n audit -o yaml > namespaces/audit/myrole.yaml
      
    3. Bearbeiten Sie die Datei myrole.yaml.

      1. Entfernen Sie alle Felder unter dem Schlüssel metadata mit Ausnahme von name und namespace.
      2. Fügen Sie im Listenfeld rules.verbs das Verb list nach get hinzu.

      Speichern Sie die Änderungen. Die Datei hat dann den folgenden Inhalt:

      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: myrole
        namespace: audit
      rules:
      - apiGroups:
        - ""
        resources:
        - pods
        verbs:
        - get
        - list
      
    4. Übernehmen Sie die Änderung für das Repository.

    5. Warten Sie einige Sekunden, bis Config Sync Operator den Commit bemerkt hat. Um festzustellen, ob die Rolle myrole jetzt von Config Sync verwaltet wird, führen Sie kubectl describe noch einmal aus.

      kubectl describe role myrole -n audit
      

Die Annotation configmanagement.gke.io/managed: enabled gibt an, dass das Objekt von Config Sync verwaltet wird. Beachten Sie auch die Annotationen, die den Pfad und den Namen der Dateien im Repository anzeigen, die die letzte Konfigurationsänderung für das Objekt verursacht haben, sowie den Git-Hash, der das Commit darstellt.

Name:         myrole
Labels:       app.kubernetes.io/managed-by=configmanagement.gke.io
Annotations:  configmanagement.gke.io/cluster-name: example-cluster-name
              configmanagement.gke.io/managed: enabled
              configmanagement.gke.io/source-path: namespaces/audit/myrole.yaml
              configmanagement.gke.io/token: 0836805a09f160f12aa934b9042527e7283c7030
PolicyRule:
Resources  Non-Resource URLs  Resource Names  Verbs
---------  -----------------  --------------  -----
pods       []                 []              [get list]

Verwaltung eines Objekts beenden

In diesem Beispiel wird gezeigt, wie die Verwaltung eines Objekts beendet wird, das derzeit von Config Sync verwaltet wird, z. B. der myrole-Rolle unter Mit der Verwaltung eines vorhandenen Objekts beginnen.

  1. Bearbeiten Sie die Datei namespaces/online/shipping-app-backend/shipping-dev/job-creator-rolebinding.yaml im lokalen Klon Ihres Repositorys und fügen Sie einen Abschnitt annotations: hinzu, der dem folgenden fett formatierten Text entspricht:

     kind: RoleBinding
     apiVersion: rbac.authorization.k8s.io/v1
     metadata:
       name: job-creators
     subjects:
     - kind: User
       name: sam@foo-corp.com
       apiGroup: rbac.authorization.k8s.io
     roleRef:
       kind: Role
       name: job-creator
       apiGroup: rbac.authorization.k8s.io
     annotations:
       configmanagement.gke.io/managed: disabled
    

    Speichern Sie die Datei.

  2. Erstellen Sie ein Git-Commit mit den Änderungen und übertragen Sie es per Push in das Repository.

  3. Warten Sie einige Sekunden, bis Config Sync diesen Vorgang erkannt hat und das neue Commit anwendet.

  4. Verwenden Sie den folgenden Befehl, um alle Annotationen für das job-creators-RoleBinding aufzulisten. Die Ausgabe wurde zur besseren Lesbarkeit gekürzt.

    kubectl get rolebinding job-creators -n audit -o yaml
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      annotations:
        configmanagement.gke.io/cluster-name: my-cluster
        configmanagement.gke.io/managed: disabled
        configmanagement.gke.io/source-path: namespaces/viewers-rolebinding.yaml
        configmanagement.gke.io/sync-token: fabdb51587d51a81c7e419eeb983aafcf293dc83
    ...
    

Nachdem Sie überprüft haben, ob das Objekt jetzt deaktiviert ist, können Sie die Konfiguration entfernen. Beachten Sie, dass das nicht mehr verwaltete Objekt dann nicht aus dem Namespace gelöscht wird. Wenn Sie das Objekt noch einmal verwalten möchten, müssen Sie dessen Konfiguration neu erstellen. Aus diesem Grund ist es eventuell sinnvoll, die Verwaltung von Objekten zu beenden, aber deren Konfiguration im Repository zu belassen.

Da das Objekt jetzt nicht mehr verwaltet wird, wird es weder in neuen noch in vorhandenen Clustern erstellt oder neu erstellt und es wird auch nicht entfernt, wenn es bereits vorhanden ist. Wenn Sie ein Objekt, das Sie bereits verwaltet hatten, wieder verwalten möchten, finden Sie dazu Informationen im nächsten Beispiel Verwaltung eines nicht mehr verwalteten Objekts fortsetzen.

Verwaltung eines nicht mehr verwalteten Objekts fortsetzen

In diesem Beispiel wird gezeigt, wie Sie die Verwaltung eines Objekts wieder aufnehmen, dessen Verwaltung Sie zuvor beendet haben, wie unter Verwaltung eines Objekts beenden gezeigt. Es wird dabei davon ausgegangen, dass die Konfiguration für das job-creators-RoleBinding nicht entfernt wurde.

  1. Wenn Sie beim letzten Commit das job-creators-RoleBinding aus Ihrem Repository gelöscht haben, führen Sie die im Folgenden aufgeführten Schritte aus.

    1. Verwenden Sie git revert, um das letzte Commit zurückzusetzen:

      git revert HEAD~1
      

      Sie werden aufgefordert, den Wiederherstellungsvorgang zu bestätigen.

    2. Übertragen Sie den zurückgesetzten Commit per Push in Ihr Repository.

      git push
      
  2. Bearbeiten Sie die Datei namespaces/online/shipping-app-backend/shipping-dev/job-creator-rolebinding.yaml im lokalen Klon des Repositories und entfernen Sie die Annotation configmanagement.gke.io/managed: disabled. Speichern Sie die Datei.

  3. Führen Sie einen Commit durch und übertragen Sie die Änderung: Config Sync geht dann so vor:

    • Erkennt die Änderung.
    • Wendet die Annotation configmanagement.gke.io/managed: enabled an; das Objekt wird jetzt verwaltet.
    • Wendet die Konfiguration an, was bei jedem verwalteten Objekt der Fall wäre.
  4. Wenn Sie sehen möchten, ob das Objekt jetzt verwaltet wird, lassen Sie sich seine Annotationen auflisten:

    kubectl get rolebinding job-creators -n audit -o yaml
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      annotations:
        configmanagement.gke.io/cluster-name: my-cluster
        configmanagement.gke.io/managed: enabled
    ...
    

Verwaltung eines Namespace beenden

Sie können die Verwaltung eines Namespace auf die gleiche Weise aufheben, wie Sie die Verwaltung eines beliebigen Objekttyps beenden. Wenn Sie die Verwaltung anderer Ressourcen im Namespace beenden möchten, führen Sie die folgenden Schritte aus:

  1. Fügen Sie der Namespace-Konfiguration und allen Konfigurationen im selben Namespace die Annotation configmanagement.gke.io/managed:disabled hinzu.

  2. Führen Sie für die Änderungen ein Commit durch und übertragen Sie die Änderungen per Push in das Repository. Warten Sie, bis durch den Operator das Repository synchronisiert wurde.

  3. Löschen Sie die nicht verwalteten Ressourcen aus dem Repository.

Wenn in einem Verzeichnis eines nicht verwalteten Namespace Konfigurationen für verwaltete Konfigurationen vorhanden sind, erfasst der Syncer etwaige Fehler in Logs. Andere Konfigurationen werden jedoch weiterhin normal synchronisiert.

Nächste Schritte