Gestisci gli oggetti cluster esistenti
Quando Config Sync gestisce un oggetto cluster, controlla l'oggetto e il set di configurazioni nel repository che interessano l'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 eliminare l'oggetto.
Un oggetto in un cluster viene gestito da Config Sync se include l'annotazione configmanagement.gke.io/managed: enabled
e l'annotazione configsync.gke.io/resource-id
, che monitora le informazioni relative a gruppo, tipo, spazio dei nomi e nome dell'oggetto.
Il formato dell'annotazione configsync.gke.io/resource-id
è GROUP_KIND_NAMESPACE_NAME
per un oggetto con ambito dello spazio dei nomi e GROUP_KIND_NAME
per un oggetto con ambito cluster.
Il seguente diagramma di flusso descrive alcune situazioni in cui un oggetto diventa gestito o non gestito:
Il grafico contiene tre flussi separati: 1) inizia a gestire un oggetto, 2) interrompi la gestione di un oggetto e 3) elimina un oggetto gestito.
- 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'annotazioneconfigsync.gke.io/resource-id
in modo che corrisponda all'oggetto e inizia a gestire l'oggetto. - Sì: il file di configurazione imposta la seguente annotazione?
configmanagement.gke.io/managed: disabled
- No: l'oggetto è gestito per impostazione predefinita.
- Sì: modifica la configurazione per rimuovere l'annotazione
configmanagement.gke.io/managed: disabled
. Quando viene eseguito il push della modifica al repository di origine, Config Sync rileva la modifica, applica l'annotazioneconfigmanagement.gke.io/managed: enabled
e l'annotazioneconfigsync.gke.io/resource-id
e applica la configurazione.
- No: crea una configurazione per l'oggetto. Config Sync imposta l'annotazione
- 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.
- Modifica la configurazione dell'oggetto nel repository e imposta l'annotazione
- 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 dagli 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 consente di elencare facilmente tutti gli oggetti tramite Config Sync.
Perché non applicare l'annotazione manualmente?
Config Sync utilizza un modello dichiarativo per applicare 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 sostituisce automaticamente il manuale con i contenuti del repository.
Prima di iniziare
I seguenti esempi si basano su Inizia a utilizzare Config Sync. Prima di iniziare i passaggi seguenti, 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 su 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 il seguente:
kubectl get object-type -n namespace -l "app.kubernetes.io/managed-by!=configmanagement.gke.io"
Ad esempio, questo comando elenca i ruoli RoleBinding nello spazio dei nomi gamestore
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 ruoli 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
Inizia a gestire un oggetto esistente
Puoi creare una configurazione per un oggetto Kubernetes esistente, ad esempio uno spazio dei nomi già esistente 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 abbia 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 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 da un cluster qualsiasi oggetto con ambito cluster non annotato. come illustrato nel diagramma in Utilizzo delle configurazioni nel tempo.
L'esempio seguente mostra come gestire un oggetto Role esistente. Per prima cosa, crei un ruolo manualmente, quindi inizi a gestirlo con Config Sync.
Crea il ruolo
myrole
nello spazio dei nomigamestore
:kubectl create role -n gamestore myrole --verb=get --resource=pods
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
get
pod.A questo punto, il ruolo esiste nel cluster, ma Config Sync non ne è a conoscenza.
- In un terminale, vai al clone locale del repository.
Utilizza il comando seguente per creare un manifest YAML per
myrole
e salvare il manifest in un nuovo file denominatogamestore-myrole.yaml
.kubectl get role myrole -n gamestore -o yaml > gamestore-myrole.yaml
Modifica il file
gamestore-myrole.yaml
.- Rimuovi tutti i campi sotto la chiave
metadata
, ad eccezione diname
enamespace
. - Aggiungi il verbo
list
dopoget
nel campo dell'elencorules.verbs
.
Salva le modifiche. Il file risultante ha il seguente contenuto:
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: myrole namespace: gamestore rules: - apiGroups: - "" resources: - pods verbs: - get - list
- Rimuovi tutti i campi sotto la chiave
Esegui il commit della modifica nel repository.
Attendi qualche momento affinché l'operatore ConfigManagement rilevi il commit. Per verificare che il ruolo
myrole
sia ora gestito da Config Sync, esegui di nuovokubectl describe
.kubectl describe role myrole -n gamestore
Osserva 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 monitora le informazioni relative a gruppo, tipo, spazio dei nomi e nome. Osserva anche le annotazioni che mostrano il percorso e il nome del 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]
Interrompi 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 Iniziare a gestire un oggetto esistente.
Modifica il file
config-sync-quickstart/multirepo/root/rolebinding-gamestore-webstore-admin.yaml
nel clone locale del repository e aggiungi una sezioneannotations:
corrispondente 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.
Crea un commit Git con le tue modifiche ed esegui il push del commit nel repository.
Attendi qualche momento affinché Config Sync rilevi e applichi il nuovo commit.
Usa il seguente comando per verificare che le annotazioni e le etichette di
gamestore-webstore-admin
RoleBinding siano entrambe vuote. Config Sync non imposta l'annotazioneconfigmanagement.gke.io/managed
sudisabled
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 sia disabilitato, puoi rimuovere la configurazione dal repository e verificare che l'oggetto ora non gestito non venga eliminato dallo spazio dei nomi. Per gestire nuovamente l'oggetto, devi aggiungere di nuovo la 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 su cluster nuovi o esistenti e non viene rimosso nemmeno se esiste. Per riprendere la gestione di un oggetto di cui avevi interrotto la gestione, vedi l'esempio successivo, Riprendi la gestione di un oggetto non gestito in precedenza.
Riprendi la gestione di un oggetto non gestito in precedenza
Questo esempio mostra come riprendere la gestione di un oggetto rimosso in precedenza dalla gestione, come in Interrompere la gestione di un oggetto esistente. Presuppone che tu non abbia rimosso la configurazione per l'associazione dei ruoli gamestore-webstore-admin
.
Se hai eliminato
gamestore-webstore-admin
RoleBinding dal tuo repository nell'ultimo commit, segui questi passaggi.Usa
git revert
per ripristinare l'ultimo commit:git revert HEAD~1
Viene richiesto di confermare l'operazione di ripristino.
Esegui il push del commit di ripristino nel repository.
git push
Modifica il file
config-sync-quickstart/multirepo/root/rolebinding-gamestore-webstore-admin.yaml
nel clone locale del repository e rimuovi l'annotazioneconfigmanagement.gke.io/managed: disabled
. Salva il file.Esegui il commit della modifica ed eseguine il push. Config Sync esegue quanto segue:
- Nota la modifica
- Applica l'annotazione
configmanagement.gke.io/managed: enabled
e l'annotazioneconfigsync.gke.io/resource-id
; l'oggetto ora è gestito. - Applica la configurazione, come accadrebbe con qualsiasi oggetto gestito.
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 ...
Interrompi la gestione di uno spazio dei nomi
Puoi interrompere la gestione di uno spazio dei nomi nello 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:
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.Esegui il commit delle modifiche ed eseguine il push nel repository. Attendi che l'operatore effettui la sincronizzazione con il repository.
Eliminare le risorse non gestite dal repository.
Se all'interno di una directory dello spazio dei nomi non gestita sono presenti configurazioni per le configurazioni gestite, il log di riconciliazione del riconciliare 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, in Config Sync versione 1.16.0 e successive, puoi abilitare la propagazione dell'eliminazione, che consente di eliminare collettivamente gli oggetti.
Eliminare singoli oggetti
Con il comportamento predefinito di Config Sync, quando rimuovi un oggetto da una fonte attendibile 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:
- Utilizza
nomos status
. - Utilizza
kubectl
per esaminare le risorse. - Utilizza il comando
gcloud alpha anthos config sync resources
. - Utilizza la dashboard di Config Sync.
Eliminare gli oggetti in blocco
Per impostazione predefinita, l'eliminazione di un metodo RootSync o RepoSync causa l'abbandono di Config Sync dagli oggetti applicati in precedenza dalla fonte attendibile. In Config Sync versione 1.16.0 e successive, puoi abilitare la propagazione dell'eliminazione per eliminare tutti gli oggetti applicati in precedenza.
Quando abiliti la propagazione dell'eliminazione su un oggetto RootSync o RepoSync e poi elimini quell'oggetto, Config Sync elimina automaticamente tutti gli oggetti gestiti da tali oggetti RootSync o RepoSync.
La propagazione dell'eliminazione può semplificare la pulizia delle risorse, ad esempio se stai eseguendo la migrazione a un nuovo spazio dei nomi o un nuovo cluster, se esegui la pulizia dopo una demo o un esperimento oppure se disinstalli un'applicazione.
Opzioni di propagazione dell'eliminazione
La propagazione dell'eliminazione è disabilitata 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: init
dir: config-sync-quickstart/multirepo/root
auth: none
period: 30s
In alternativa, puoi aggiornare un metodo RootSync o RepoSync esistente per utilizzare la propagazione dell'eliminazione eseguendo questo 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 del file 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 disabilitare la propagazione dell'eliminazione, rimuovi l'annotazione o modifica il valore in configsync.gke.io/deletion-propagation-policy: Orphan
:
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 del file 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"}}}'
Propaga eliminazione degli oggetti
Questo esempio mostra come applicare la propagazione dell'eliminazione a un oggetto RootSync o RepoSync, quindi eliminare RootSync o RepoSync per eliminare tutti gli oggetti gestiti da RootSync o RepoSync.
RootSync
Applica l'annotazione a un oggetto RootSync per abilitare 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"}}}'
Elimina l'oggetto RootSync e attendi che Config Sync lo elimini:
kubectl delete RootSync example-rootsync --namespace config-management-system --wait
Il completamento dell'eliminazione di RootSync può richiedere alcuni minuti.
RepoSync
Applica l'annotazione a un oggetto RepoSync per abilitare la propagazione dell'eliminazione:
kubectl patch RepoSync example-reposync \ --namespace example-namespace \ --type merge \ --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'
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.
Impedisci l'eliminazione degli oggetti Kubernetes
Dopo aver rimosso un oggetto Kubernetes da un repository Git gestito da Config Sync, questo oggetto viene eliminato dal cluster quando il nuovo commit viene sincronizzato con il cluster.
Se vuoi impedire a Config Sync di eliminare l'oggetto quando la relativa configurazione viene rimossa dal repository Git, puoi seguire questi passaggi:
Aggiungi l'annotazione
client.lifecycle.config.k8s.io/deletion: detach
alla configurazione degli oggetti nel repository Git.Esegui il commit della modifica ed esegui il push della modifica nel repository Git.
Attendi che la modifica venga sincronizzata con il cluster.
Dopo aver completato questi passaggi, Config Sync non eliminerà questo oggetto dal cluster quando la relativa configurazione viene rimossa dal repository Git, ma può comunque essere eliminato da altri client.
Ignora un oggetto nella fonte di riferimento
Potresti volere che Config Sync ignori un oggetto nella tua origine di riferimento. Ad esempio, una configurazione della 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 dei dati. Le risorse con l'annotazione local-config
impostata su un valore diverso da "false"
vengono trattate come se fosse impostata su "true"
e vengano ignorate.