Gestisci gli oggetti cluster esistenti

Quando Config Sync gestisce un oggetto cluster, lo monitora e l'insieme di configurazioni nel repository che influiscono sull'oggetto e garantisce che siano sincronizzati. Questo argomento descrive come iniziare a gestire un oggetto esistente e come interrompere la gestione di un oggetto attualmente gestito senza eliminarlo.

Un oggetto in un cluster viene gestito da Config Sync se ha l'annotazione configmanagement.gke.io/managed: enabled e la sua annotazione configsync.gke.io/resource-id, che tiene traccia delle informazioni su gruppo, tipo, spazio dei nomi e nome dell'oggetto, è corretta.

Il formato dell'annotazione configsync.gke.io/resource-id è GROUP_KIND_NAMESPACE_NAME per un oggetto con ambito di spazio dei nomi e GROUP_KIND_NAME per un oggetto con ambito cluster.

Il seguente diagramma di flusso descrive alcune situazioni che fanno sì che un oggetto diventi gestito o non gestito:

Il grafico contiene tre flussi separati: 1) avvia la gestione di un oggetto, 2) interrompi la gestione di un oggetto e 3) elimina un oggetto gestito.

1. Voglio iniziare a gestire un oggetto. L'oggetto ha un manifest? O, in altre parole, l'oggetto ha una configurazione nel repository?
   • No: crea una configurazione per l'oggetto. Config Sync imposta l'annotazione configmanagement.gke.io/managed: enabled, imposta l'annotazione configsync.gke.io/resource-id in modo che corrisponda all'oggetto e inizia a gestire l'oggetto.
   • Sì: la configurazione imposta la seguente annotazione? configmanagement.gke.io/managed: disabled
     • No: l'oggetto viene gestito per impostazione predefinita.
     • Sì: modifica la configurazione per rimuovere l'annotazione configmanagement.gke.io/managed: disabled. Quando la modifica viene eseguita il push nel repository di origine, Config Sync rileva la modifica, applica l'annotazione configmanagement.gke.io/managed: enabled e l'annotazione configsync.gke.io/resource-id e applica la configurazione.
2. Voglio interrompere la gestione di un oggetto, ma non eliminarlo.
   • Modifica la configurazione dell'oggetto nel repository e imposta l'annotazione configmanagement.gke.io/managed: disabled. Quando viene rilevata la modifica della configurazione, Config Sync smette di gestire l'oggetto.
3. Voglio interrompere la gestione di un oggetto ed eliminarlo.
   • Elimina la configurazione dell'oggetto dal repository. Quando elimini una configurazione per un oggetto gestito in precedenza, Config Sync elimina l'oggetto da tutti i cluster o gli spazi dei nomi a cui si applica la configurazione.

Oltre all'annotazione configmanagement.gke.io/managed: enabled e all'annotazione configsync.gke.io/resource-id, Config Sync applica l'etichetta app.kubernetes.io/managed-by: configmanagement.gke.io a tutti gli oggetti che gestisce. Questa etichetta ti consente di elencare facilmente tutti gli oggetti per Config Sync.

Perché non applicare l'annotazione manualmente?

Config Sync utilizza un modello dichiarativo per applicare le modifiche alla configurazione ai cluster leggendo la configurazione desiderata dal repository. Se tenti di applicare l'annotazione manualmente (utilizzando il comando kubectl o l'API Kubernetes), Config Sync esegue automaticamente l'override dell'annotazione manuale con i contenuti del repository.

Prima di iniziare

Gli esempi riportati di seguito si basano su Inizia a utilizzare Config Sync. Prima di iniziare i seguenti passaggi, segui la guida rapida e completa tutti i passaggi prima di Esplorare e testare l'installazione di Config Sync.

Elenco di tutti gli oggetti gestiti

Per elencare tutti gli oggetti gestiti da Config Sync in un determinato cluster o spazio dei nomi, utilizza un selettore di etichette come il seguente:

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

Per elencare tutti gli oggetti non gestiti da Config Sync, utilizza un selettore di etichette come questo:

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

Ad esempio, questo comando elenca i RoleBinding nello spazio dei nomi gamestore che sono gestiti da Config Sync:

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

L'output è simile al seguente:

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

Questo comando elenca i RoleBinding nello spazio dei nomi kube-system che non sono gestiti da Config Sync:

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

L'output è simile al seguente:

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

Iniziare a gestire un oggetto esistente

Puoi creare una configurazione per un oggetto Kubernetes esistente, ad esempio uno spazio dei nomi già presente nel cluster prima di installare Config Sync. Tuttavia, questa configurazione viene ignorata a meno che l'oggetto non abbia l'annotazione configmanagement.gke.io/managed: enabled e l'annotazione configsync.gke.io/resource-id corretta. Per un oggetto esistente, devi applicare l'annotazione manualmente.

Per gli spazi dei nomi in particolare, Config Sync applica le configurazioni che creano nuovi oggetti all'interno di uno spazio dei nomi non annotato e applica le annotazioni configmanagement.gke.io/managed: enabled e configsync.gke.io/resource-id a questi oggetti. Tuttavia, Config Sync si rifiuta di modificare o rimuovere qualsiasi oggetto con ambito cluster non annotato da un cluster. Ciò è illustrato nel diagramma in Utilizzo delle configurazioni nel tempo.

Il seguente esempio mostra come gestire un oggetto Role esistente. Innanzitutto, crea un ruolo manualmente, quindi inizia a gestirlo con Config Sync.

1. Crea il ruolo myrole nello spazio dei nomi gamestore:

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

2. Visualizza le autorizzazioni concesse dal ruolo myrole:

   kubectl describe role -n gamestore myrole

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

   Il ruolo ha l'autorizzazione solo per i pod get.

3. A questo punto, il ruolo esiste nel cluster, ma Config Sync non lo conosce.

   1. In un terminale, vai al clone locale del repository.

   2. Utilizza il comando seguente per creare un manifest YAML per myrole e salvare il manifest in un nuovo file denominato gamestore-myrole.yaml.

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

   3. Modifica il file gamestore-myrole.yaml.

      1. Rimuovi tutti i campi sotto la chiave metadata, tranne name e namespace.
      2. Aggiungi il verbo list dopo get nel campo dell'elenco rules.verbs.

      Salva le modifiche. Il file risultante ha i seguenti contenuti:

      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: myrole
        namespace: gamestore
      rules:
      - apiGroups:
        - ""
        resources:
        - pods
        verbs:
        - get
        - list
      

   4. Esegui il commit della modifica nel repository.

   5. Attendi qualche istante affinché l'operatore ConfigManagement rilevi il commit. Per verificare che il ruolo myrole sia ora gestito da Config Sync, esegui di nuovo kubectl describe.

      kubectl describe role myrole -n gamestore
      

Nota l'annotazione configmanagement.gke.io/managed: enabled, che indica che l'oggetto è gestito da Config Sync, e l'annotazione configsync.gke.io/resource-id, che tiene traccia delle informazioni su gruppo, tipo, spazio dei nomi e nome. Nota anche le annotazioni che mostrano il percorso e il nome file nel repository che ha causato la modifica più recente della configurazione dell'oggetto e l'hash Git che rappresenta il commit.

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]

Interrompere la gestione di un oggetto gestito

Questo esempio mostra come interrompere la gestione di un oggetto attualmente gestito da Config Sync, ad esempio il ruolo myrole in Avvia la gestione di un oggetto esistente.

Nota: prima di rimuovere uno spazio dei nomi dalla gestione, assicurati di comprendere cosa succede agli oggetti all'interno di quello spazio dei nomi che sono ancora gestiti.

1. Modifica il file config-sync-quickstart/multirepo/root/rolebinding-gamestore-webstore-admin.yaml nel clone locale del repository e aggiungi una sezione annotations: che corrisponda al testo in grassetto riportato di seguito:

    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
   

   Salva il file.

2. Crea un commit Git con le modifiche e invialo al tuo repository.

3. Attendi qualche istante affinché Config Sync rilevi e applichi il nuovo commit.

4. Utilizza il seguente comando per verificare che le annotazioni e le etichette della risorsa RoleBinding gamestore-webstore-admin siano entrambe vuote. Config Sync non imposta l'annotazione configmanagement.gke.io/managed su disabled nell'oggetto.

   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
   

Dopo aver verificato che l'oggetto è ora disattivato, puoi rimuovere la configurazione dal repository e verificare che l'oggetto non gestito non venga eliminato dallo spazio dei nomi. Se vuoi gestire di nuovo l'oggetto, devi aggiungere di nuovo la sua configurazione al repository. Per questo motivo, potresti voler annullare la gestione degli oggetti e lasciare le relative configurazioni nel repository.

Ora che l'oggetto non è gestito, non viene creato o ricreato in cluster nuovi o esistenti e non viene rimosso anche se esiste. Per riprendere la gestione di un oggetto che hai interrotto in precedenza, vedi l'esempio successivo, Riprendere la gestione di un oggetto precedentemente non gestito.

Riprendere la gestione di un oggetto precedentemente non gestito

Questo esempio mostra come riprendere la gestione di un oggetto che hai rimosso in precedenza dalla gestione, come in Interrompere la gestione di un oggetto esistente. Presuppone che non sia stata rimossa la configurazione per il RoleBinding gamestore-webstore-admin.

1. Se hai eliminato la risorsa gamestore-webstore-admin RoleBinding dal tuo repository nell'ultimo commit, segui questi passaggi.

   1. Utilizza git revert per ripristinare l'ultimo commit:

      git revert HEAD~1
      

      Ti viene chiesto di confermare l'operazione di rollback.

   2. Esegui il push del commit di ripristino nel tuo repository.

      git push
      

2. Modifica il file config-sync-quickstart/multirepo/root/rolebinding-gamestore-webstore-admin.yaml nel clone locale del tuo repository e rimuovi l'annotazione configmanagement.gke.io/managed: disabled. Salva il file.

3. Esegui il commit e il push della modifica. Config Sync esegue le seguenti operazioni:

   • Nota la modifica
   • Applica l'annotazione configmanagement.gke.io/managed: enabled e l'annotazione configsync.gke.io/resource-id; l'oggetto ora è gestito.
   • Applica la configurazione, come avverrebbe con qualsiasi oggetto gestito.

4. Per verificare che l'oggetto sia ora gestito, elenca le relative annotazioni:

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

Interrompere la gestione di uno spazio dei nomi

Puoi interrompere la gestione di uno spazio dei nomi allo stesso modo in cui interrompi la gestione di qualsiasi tipo di oggetto. Se vuoi interrompere la gestione di altre risorse all'interno dello spazio dei nomi, segui questi passaggi:

1. Aggiungi l'annotazione configmanagement.gke.io/managed:disabled alla configurazione dello spazio dei nomi e a tutte le configurazioni nello stesso spazio dei nomi. Tutti gli oggetti nello spazio dei nomi devono avere questa annotazione.

   Attenzione :in un'origine attendibile gerarchica, se lo spazio dei nomi viene ereditato da un spazio dei nomi astratto, non può essere non gestito.

2. Esegui il commit e il push delle modifiche nel repository. Attendi che l'operatore si sincronizzi con il repository.

3. Elimina le risorse non gestite dal repository.

   Avviso :è un problema noto che se non utilizzi le API RootSync e RepoSync, l'eliminazione dello spazio dei nomi non gestito dal repository comporta l'eliminazione dallo spazio dei nomi dal cluster live. Per le risorse non gestite eliminate accidentalmente, devi aggiungerle di nuovo manualmente nel cluster, ad esempio utilizzando kubectl apply. Per utilizzare le API RootSync e RepoSync, devi eseguire la migrazione dell'oggetto ConfigManagement.

Se esistono configurazioni per le configurazioni gestite all'interno di una directory dello spazio dei nomi non gestito, il riconciliatore registra gli errori, ma le altre configurazioni continuano a essere sincronizzate normalmente.

Elimina risorse gestite

Quando rimuovi una singola risorsa da una fonte attendibile, l'oggetto viene eliminato dal cluster alla successiva sincronizzazione di Config Sync dalla fonte attendibile. In alternativa, puoi attivare la propagazione dell'eliminazione, che ti consente di eliminare gli oggetti in blocco.

Eliminare singoli oggetti

Con il comportamento predefinito di Config Sync, quando rimuovi un oggetto da una fonte attendibile, questo viene eliminato dal cluster quando Config Sync esegue la sincronizzazione dalla fonte attendibile.

Esistono diversi modi per controllare lo stato di Config Sync o di oggetti specifici:

• Utilizzare nomos status.
• Usa kubectl per esaminare le risorse.
• Utilizza la dashboard di Config Sync.

Eliminare oggetti in blocco

Anteprima

Questo prodotto o questa funzionalità sono soggetti ai "Termini dell'offerta pre-GA" nella sezione Termini di servizio generali dei Termini specifici dei servizi. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Per impostazione predefinita, l'eliminazione di un oggetto RootSync o RepoSync fa sì che Config Sync abbandoni gli oggetti applicati in precedenza dalla fonte attendibile. In alternativa, puoi attivare la propagazione dell'eliminazione per eliminare tutti gli oggetti applicati in precedenza.

Quando abiliti la propagazione dell'eliminazione su un oggetto RootSync o RepoSync ed elimini l'oggetto, Config Sync elimina automaticamente ogni oggetto gestito da RootSync o RepoSync.

La propagazione dell'eliminazione può semplificare la pulizia delle risorse, ad esempio se esegui la migrazione a un nuovo spazio dei nomi o cluster, la pulizia dopo una demo o un esperimento o la disinstallazione di un'applicazione.

Opzioni di propagazione dell'eliminazione

La propagazione dell'eliminazione è disattivata per impostazione predefinita. Per attivare la propagazione dell'eliminazione, aggiungi l'annotazione configsync.gke.io/deletion-propagation-policy: Foreground all'oggetto RootSync o RepoSync, come nell'esempio seguente:

# 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: main
    dir: config-sync-quickstart/multirepo/root
    auth: none
    period: 30s

In alternativa, puoi aggiornare un RootSync o RepoSync esistente per utilizzare la propagazione dell'eliminazione eseguendo il seguente comando:

RootSync

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

Sostituisci ROOTSYNC_NAME con il nome di RootSync che vuoi aggiornare.

RepoSync

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

Sostituisci REPOSYNC_NAME con il nome del RepoSync che vuoi aggiornare.

Per disattivare la propagazione dell'eliminazione, rimuovi l'annotazione o modifica il valore in configsync.gke.io/deletion-propagation-policy: Orphan:

Nota: a partire dalla versione 1.21.0, Config Sync interrompe la gestione di tutti gli oggetti quando viene utilizzata la norma di propagazione dell'eliminazione Orphan. Prima della versione 1.21.0, Config Sync annotava gli oggetti come gestiti dall'oggetto RootSync o RepoSync eliminato. Il nuovo comportamento garantisce che gli oggetti orfani possano essere aggiornati da altri client o adottati da un nuovo oggetto RootSync o RepoSync.

RootSync

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

Sostituisci ROOTSYNC_NAME con il nome di RootSync che vuoi aggiornare.

RepoSync

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

Propagazione dell'eliminazione dell'oggetto

Questo esempio mostra come applicare la propagazione dell'eliminazione a un oggetto RootSync o RepoSync e poi eliminare RootSync o RepoSync per eliminare tutti gli oggetti gestiti da RootSync o RepoSync.

Attenzione: per gli oggetti RepoSync, non eliminare lo spazio dei nomi in cui si trova RepoSync prima che l'eliminazione sia completata. In questo modo, RoleBinding può essere eliminato prima che la propagazione dell'eliminazione sia completata, causando un deadlock che può bloccare l'eliminazione sia di RepoSync che dello spazio dei nomi.

RootSync

1. Applica l'annotazione a un oggetto RootSync per attivare la propagazione dell'eliminazione:

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

2. Elimina l'oggetto RootSync e attendi che Config Sync lo elimini:

   kubectl delete RootSync example-rootsync --namespace config-management-system --wait
   

   L'eliminazione di RootSync può richiedere alcuni minuti.

RepoSync

1. Applica l'annotazione a un oggetto RepoSync per attivare la propagazione dell'eliminazione:

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

2. Elimina l'oggetto RepoSync e attendi che Config Sync lo elimini:

   kubectl delete RepoSync example-reposync --namespace example-namespace --wait
   

   L'eliminazione di RepoSync può richiedere alcuni minuti.

Impedire l'eliminazione per gli oggetti Kubernetes

Dopo aver rimosso un oggetto Kubernetes da un repository Git gestito da Config Sync, questo oggetto viene eliminato anche dal cluster quando il nuovo commit viene sincronizzato con il cluster.

Se vuoi impedire a Config Sync di eliminare l'oggetto quando la sua configurazione viene rimossa dal repository Git, puoi procedere nel seguente modo:

1. Aggiungi l'annotazione client.lifecycle.config.k8s.io/deletion: detach alla configurazione dell'oggetto nel repository Git.

2. Esegui il commit e il push della modifica nel repository Git.

3. Attendi la sincronizzazione della modifica con il cluster.

Una volta completati questi passaggi, Config Sync non eliminerà questo oggetto dal cluster quando la sua configurazione viene rimossa dal repository Git, ma può comunque essere eliminato da altri client.

Ignorare un oggetto nella fonte attendibile

Potresti voler che Config Sync ignori un oggetto nella tua fonte attendibile. Ad esempio, una configurazione di funzione kpt non deve mai essere applicata al cluster.

Per gli oggetti che vuoi che Config Sync ignori, aggiungi l'annotazione config.kubernetes.io/local-config: "true" all'oggetto. Dopo aver aggiunto questa annotazione, Config Sync ignora questo oggetto come se fosse stato rimosso dalla fonte attendibile. Le risorse con l'annotazione local-config impostata su un valore diverso da "false" vengono trattate come se fosse impostata su "true" e vengono ignorate.