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.

Ein Objekt in einem Cluster wird dann von Config Sync verwaltet, wenn es die Annotation configmanagement.gke.io/managed: enabled und dessen configsync.gke.io/resource-id-Annotation enthält. Damit werden die Informationen zu Gruppe, Art, Namespace und Name des Objekts aufgezeichnet und auf Korrektheit geprüft.

Das Format der Annotation configsync.gke.io/resource-id lautet GROUP_KIND_NAMESPACE_NAME für ein Namespace-bezogenes Objekt und GROUP_KIND_NAME für ein clusterbezogenes Objekt.

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

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

1. Ich möchte mit der Verwaltung eines Objekts beginnen. Hat das Objekt ein Manifest? Anders gesagt: 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 und für das Objekt die Annotation configsync.gke.io/resource-id fest und beginnt mit der Verwaltung des Objekts.
   • Ja: Legt die Konfiguration die folgende Annotation fest? configmanagement.gke.io/managed: disabled
     • 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 die Annotation configsync.gke.io/resource-id 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 den Annotationen configmanagement.gke.io/managed: enabled und configsync.gke.io/resource-id 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.

Hinweise

Die folgenden Beispiele bauen auf Erste Schritte mit Config Sync auf. Folgen Sie vor den im Folgenden aufgeführten Schritten der Kurzanleitung und führen Sie alle Schritte aus, bevor Sie die Config Sync-Installation untersuchen und testen.

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 -n namespace -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 -n namespace -l "app.kubernetes.io/managed-by!=configmanagement.gke.io"

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

kubectl get rolebindings -n gamestore \
    -l "app.kubernetes.io/managed-by=configmanagement.gke.io"

Die entsprechende Ausgabe sieht etwa so aus:

NAME                              ROLE                                          AGE
configsync.gke.io:ns-reconciler   ClusterRole/configsync.gke.io:ns-reconciler   34h
gamestore-admin                   ClusterRole/admin                             34h
gamestore-webstore-admin          ClusterRole/webstore-admin                    34h

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"

Die entsprechende Ausgabe sieht etwa so aus:

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

Sie können eine Konfiguration für ein vorhandenes Kubernetes-Objekt erstellen, z. B. einen Namespace, der bereits in Ihrem Cluster vorhanden ist, bevor Sie Config Sync installieren. Diese Konfiguration wird jedoch ignoriert, sofern das Objekt nicht die Annotation configmanagement.gke.io/managed: enabled und die richtige Annotation configsync.gke.io/resource-id hat. Bei einem vorhandenen Objekt müssen Sie die Annotation manuell anwenden.

Insbesondere bei Namespaces werden von Config Sync Konfigurationen angewendet, die neue Objekte innerhalb eines nicht annotierten Namespace erstellen. Auf diese Objekte werden anschließend die Annotationen configmanagement.gke.io/managed: enabled und configsync.gke.io/resource-id angewendet. Config Sync nimmt jedoch keine Änderungen an nicht annotierten Objekten eines Clusters vor und entfernt diese auch nicht. Das wird im Abschnitt Mit Konfigurationen arbeiten mithilfe eines Diagramms gezeigt.

Das folgende Beispiel zeigt, wie Sie ein vorhandenes Rollenobjekt verwalten. Erstellen Sie zuerst eine Rolle manuell und beginnen Sie dann mit der Verwaltung mit Config Sync.

1. Erstellen Sie die Rolle myrole im Namespace gamestore:

   kubectl create role -n gamestore myrole --verb=get --resource=pods

2. Rufen Sie die Berechtigungen auf, die von der Rolle myrole erteilt werden:

   kubectl describe role -n gamestore 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 gamestore-myrole.yaml speichern.

      kubectl get role myrole -n gamestore -o yaml > gamestore-myrole.yaml
      

   3. Bearbeiten Sie die Datei gamestore-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: gamestore
      rules:
      - apiGroups:
        - ""
        resources:
        - pods
        verbs:
        - get
        - list
      

   4. Übernehmen Sie die Änderung für das Repository.

   5. Warten Sie einige Sekunden, bis Config Management 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 gamestore
      

Die Annotation configmanagement.gke.io/managed: enabled gibt an, dass das Objekt von Config Sync verwaltet wird, und die Annotation configsync.gke.io/resource-id erfasst die Gruppen-, Art-, Namespace- und Namensinformationen. 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
              configsync.gke.io/declared-version=v1
Annotations:  config.k8s.io/owning-inventory: config-management-system_root-sync
              configmanagement.gke.io/cluster-name: my-cluster
              configmanagement.gke.io/managed: enabled
              configmanagement.gke.io/source-path: config-sync-quickstart/multirepo/root/gamestore-myrole.yaml
              configmanagement.gke.io/token: 747b843a7ddbd945c0616034a935cf648b58e7b5
              configsync.gke.io/declared-fields: {"f:rules":{}}
              configsync.gke.io/git-context: {"repo":"https://github.com/GoogleCloudPlatform/anthos-config-management-samples","branch":"main","rev":"HEAD"}
              configsync.gke.io/manager: :root
              configsync.gke.io/resource-id: rbac.authorization.k8s.io_role_gamestore_myrole
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 config-sync-quickstart/multirepo/root/rolebinding-gamestore-webstore-admin.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:
      annotations:
        configmanagement.gke.io/managed: disabled
      name: gamestore-webstore-admin
      namespace: gamestore
    subjects:
    - kind: ServiceAccount
      name: ns-reconciler-gamestore
      namespace: config-management-system
    roleRef:
      kind: ClusterRole
      name: webstore-admin
      apiGroup: rbac.authorization.k8s.io
   

   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. Mit dem folgenden Befehl prüfen Sie, ob die Annotationen und Labels der RoleBinding gamestore-webstore-admin leer sind. Config Sync legt die Annotation configmanagement.gke.io/managed für das Objekt nicht auf disabled fest.

   kubectl get rolebinding gamestore-webstore-admin -n gamestore -o yaml
   

   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     annotations:
     name: gamestore-webstore-admin
     namespace: gamestore
   subjects:
   - kind: ServiceAccount
     name: ns-reconciler-gamestore
     namespace: config-management-system
   roleRef:
     kind: ClusterRole
     name: webstore-admin
     apiGroup: rbac.authorization.k8s.io
   

Nachdem Sie geprüft haben, dass das Objekt jetzt deaktiviert ist, können Sie die Konfiguration aus Ihrem Repository entfernen und kontrollieren, dass das jetzt nicht verwaltete Objekt nicht aus dem Namespace gelöscht ist. Wenn Sie das Objekt noch einmal verwalten möchten, müssen Sie die Konfiguration wieder in Ihr Repository einfügen. 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 gamestore-webstore-admin-RoleBinding nicht entfernt wurde.

1. Wenn Sie beim letzten Commit das gamestore-webstore-admin-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 config-sync-quickstart/multirepo/root/rolebinding-gamestore-webstore-admin.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 Annotationen configmanagement.gke.io/managed: enabled und configsync.gke.io/resource-id an: Das Objekt wird jetzt verwaltet.
   • Wendet die Konfiguration so an, wie es 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 gamestore-webstore-admin -n gamestore -o yaml

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     annotations:
       configmanagement.gke.io/cluster-name: my-cluster
       configmanagement.gke.io/managed: enabled
       configsync.gke.io/resource-id: rbac.authorization.k8s.io_rolebinding_gamestore_gamestore-webstore-admin
   ...
   

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. Hinweis: Alle Objekte im Namespace müssen diese Annotation haben.

2. Führen Sie für die Änderungen ein Commit aus 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 Abgleicher etwaige Fehler in Logs. Andere Konfigurationen werden jedoch weiterhin normal synchronisiert.

Verwaltete Ressourcen löschen

Wenn Sie eine einzelne Ressource aus einer verlässlichen Quelle entfernen, wird dieses Objekt aus dem Cluster gelöscht, wenn Config Sync die verlässliche Quelle das nächste Mal synchronisiert. Alternativ können Sie die Löschweitergabe aktivieren, um Objekte im Bulk-Verfahren zu löschen.

Einzelne Objekte löschen

Wenn Sie beim Standardverhalten von Config Sync ein Objekt aus einer "Source of Truth" entfernen, wird dieses Objekt aus dem Cluster gelöscht, wenn Config Sync aus der "Source of Truth" synchronisiert wird.

Es gibt mehrere Möglichkeiten, den Status von Config Sync oder den Status bestimmter Objekte zu prüfen:

• Verwenden Sie nomos status.
• Verwenden Sie kubectl zum Prüfen von Ressourcen.
• gcloud alpha anthos config sync resources-Befehl ausführen
• Verwenden Sie das Config Sync-Dashboard.

Objekte im Bulk löschen

Wenn Sie ein RootSync- oder RepoSync-Objekt löschen, werden die Objekte, die zuvor aus der verlässlichen Quelle angewendet wurden, standardmäßig von Config Sync verworfen. Alternativ können Sie die Löschweitergabe aktivieren, um alle zuvor angewendeten Objekte zu löschen.

Wenn Sie die Löschweitergabe für ein RootSync- oder RepoSync-Objekt aktivieren und dieses Objekt dann löschen, löscht Config Sync automatisch alle Objekte, die von diesem RootSync- oder RepoSync-Objekt verwaltet wurden.

Die Löschweitergabe kann das Bereinigen von Ressourcen erleichtern, z. B. wenn Sie zu einem neuen Namespace oder Cluster migrieren, eine Bereinigung nach einer Demo oder einem Test durchführen oder eine Anwendung deinstallieren.

Optionen für die Löschweitergabe

Die Löschen-Weitergabe ist standardmäßig deaktiviert. Um die Löschweitergabe zu aktivieren, fügen Sie Ihrem RootSync- oder RepoSync-Objekt die Annotation configsync.gke.io/deletion-propagation-policy: Foreground hinzu, wie im folgenden Beispiel:

# example-rootsync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: example-rootsync
  namespace: config-management-system
  annotations:
    configsync.gke.io/deletion-propagation-policy: Foreground
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
    branch: init
    dir: config-sync-quickstart/multirepo/root
    auth: none
    period: 30s

Alternativ können Sie ein vorhandenes RootSync oder RepoSync aktualisieren, um die Löschweitergabe zu verwenden. Führen Sie dazu den folgenden Befehl aus:

kubectl patch RootSync ROOTSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'

kubectl patch RepoSync REPOSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'

Entfernen Sie die Annotation oder ändern Sie den Wert in configsync.gke.io/deletion-propagation-policy: Orphan, um die Löschweitergabe zu deaktivieren:

kubectl patch RootSync ROOTSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Orphan"}}}'

kubectl patch RepoSync REPOSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Orphan"}}}'

Objektlöschungen weitergeben

In diesem Beispiel wird gezeigt, wie Sie die Löschweitergabe auf ein RootSync- oder RepoSync-Objekt anwenden und anschließend RootSync oder RepoSync löschen, um alle Objekte zu löschen, die von RootSync oder RepoSync verwaltet wurden.

Löschen von Kubernetes-Objekten verhindern

Nachdem Sie ein Kubernetes-Objekt aus einem Git-Repository entfernt haben, das von Config Sync verwaltet wird, wird dieses Objekt auch aus dem Cluster gelöscht, wenn das neue Commit mit dem Cluster synchronisiert wird.

Um zu verhindern, dass das Objekt von Config Sync gelöscht wird, wenn dessen Konfiguration aus dem Git-Repository entfernt wird, können Sie die folgenden Schritte ausführen:

1. Fügen Sie der Objektkonfiguration im Git-Repository die Annotation client.lifecycle.config.k8s.io/deletion: detach hinzu.

2. Führen Sie ein Commit der Änderung durch und übertragen Sie sie an das Repository.

3. Warten Sie, bis die Änderung mit dem Cluster synchronisiert wurde.

Nachdem Sie diese Schritte ausgeführt haben, löscht Config Sync dieses Objekt nicht aus dem Cluster, wenn dessen Konfiguration aus dem Git-Repository entfernt wird. Es kann jedoch von anderen Clients gelöscht werden.

Objekt in der "Source of Truth" ignorieren

Möglicherweise möchten Sie, dass Config Sync ein Objekt in Ihrer "Source of Truth" ignoriert. Beispielsweise soll vielleicht eine kpt-Funktionskonfiguration nie auf den Cluster angewendet werden.

Für Objekte, die von Config Sync ignoriert werden sollen, fügen Sie dem Objekt die Annotation config.kubernetes.io/local-config: "true" hinzu. Nachdem Sie diese Annotation hinzugefügt haben, ignoriert Config Sync dieses Objekt, als ob es aus der "Source of Truth" entfernt wäre. Ressourcen, bei denen die Annotation local-config auf einen anderen Wert als "false" festgelegt ist, werden so behandelt, als wäre sie auf "true" gesetzt, und werden ignoriert.