Questa pagina mostra come risolvere i problemi relativi ai conflitti dei controller. Questi combattimenti consumano una grande quantità di risorse e possono ridurre le prestazioni. I conflitti dei controller sono noti anche come concorrenza per le risorse.
Config Sync controlla gli oggetti che applica al cluster e ripristina
le modifiche apportate ai valori dichiarati nella fonte attendibile. Se queste modifiche vengono apportate da un altro controller, la risorsa potrebbe passare da uno stato all'altro in base agli stati voluti dai controller in competizione. Un sintomo di questo comportamento è che
i campi metadata.generation e metadata.resourceVersion aumentano
rapidamente. Per questo motivo, se un oggetto gestito viene aggiornato più di cinque volte
al minuto, Config Sync rileva il conflitto, registra la deriva e segnala
l'errore nello stato dell'oggetto RootSync o RepoSync.
Config Sync ha una logica speciale per rilevare conflitti tra più oggetti RootSync
e RepoSync. Per gli oggetti RepoSync, se il riconciliatore rileva che l'oggetto è già gestito da un altro riconciliatore, gli aggiornamenti successivi vengono ignorati.
Per gli oggetti RootSync, il riconciliatore tenta di adottare qualsiasi oggetto per la cui gestione è configurato, a meno che non sia gestito da un altro oggetto RootSync. In questo modo,
viene impedito ai riconciliatori di Config Sync di entrare in conflitto tra loro e
vengono segnalati errori nello stato di tutti gli oggetti RootSync e RepoSync coinvolti.
Identificare i conflitti dei controller
Puoi esaminare gli errori della campagna utilizzando il comando
nomos status o controllando il campo stato nell'oggetto RootSync o RepoSync.
Se non hai installato lo strumento a riga di comando nomos, puoi esaminare
i log del riconciliatore RootSync eseguendo il seguente comando:
kubectl logs -n config-management-system \
--selector "app=reconciler,configsync.gke.io/sync-name=root-sync" \
--container reconciler
Per filtrare in base a riconciliatori RepoSync specifici, esegui il seguente comando:
kubectl logs -n config-management-system \
--selector "app=reconciler,configsync.gke.io/sync-namespace=NAMESPACE" \
--container reconciler
Sostituisci NAMESPACE con lo spazio dei nomi in cui hai creato la tua fonte attendibile basata sullo spazio dei nomi.
Se vedi KNV2005 nei risultati, significa che c'è un conflitto di controller.
Il seguente messaggio di errore è un esempio del tipo di errore che potresti visualizzare nei log:
KNV2005: detected excessive object updates, approximately 6 times per
minute. This may indicate Config Sync is fighting with another controller over
the object.
Esaminare i conflitti dei controller
Per saperne di più su eventuali conflitti dei controller, controlla gli aggiornamenti del file YAML della risorsa eseguendo il seguente comando:
kubectl get RESOURCE OBJECT_NAME \
--namespace NAMESPACE \
--watch -o yaml
Sostituisci quanto segue:
RESOURCE: il tipo di risorsa per la quale si sta combattendo.OBJECT_NAME: il nome dell'oggetto per cui si sta litigando.NAMESPACE: lo spazio dei nomi in cui si trova la risorsa in discussione.
I risultati del log specificano la risorsa, il nome dell'oggetto e lo spazio dei nomi da aggiungere.
Questo comando restituisce uno stream dello stato della risorsa dopo l'applicazione degli aggiornamenti al server API. Utilizza uno strumento di confronto dei file per confrontare l'output.
Risolvere i conflitti dei controller
Esistono diversi modi per risolvere i conflitti dei controller. Scegli l'opzione più adatta alla tua configurazione di Config Sync:
- Aggiorna il manifest della risorsa nell'origine in modo che corrisponda al valore voluto dall'altro controllore.
- Rimuovi il campo in questione dall'origine per consentire all'altro controllore di gestirlo.
- Disattiva o disinstalla l'altro controller.
- Rimuovi la risorsa dall'origine e gestiscila manualmente o con un controllo personalizzato che ammette modifiche specifiche o la cogestione.
- Se sei il proprietario del controller che causa la contesa delle risorse e il campo modificato non è nella fonte attendibile, aggiorna il controller per eseguire il patching anziché l'aggiornamento. In questo modo, la modifica verrà consentita da Config Sync e non verrà ripristinata.
Esistono anche alcune risorse che dovrebbero appartenere ad altri controller (ad esempio, alcuni operatori installano o gestiscono i CRD). Questi altri controller rimuovono automaticamente tutti i metadati specifici di Config Sync. Se un altro componente del tuo cluster Kubernetes rimuove i metadati di Config Sync, interrompi la gestione della risorsa con Config Sync. Per informazioni su come eseguire questa operazione, consulta Interrompere la gestione di un oggetto gestito.
In alternativa, se non vuoi che Config Sync ripristini le modifiche agli oggetti gestiti nel cluster, puoi aggiungere l'annotazione client.lifecycle.config.k8s.io/mutation: ignore all'oggetto per cui vuoi che Config Sync ignori le mutazioni. Per informazioni su come eseguire questa operazione, consulta Ignorare le mutazioni degli oggetti.
Passaggi successivi
- Se i problemi persistono, controlla se si tratta di un problema noto.