Questa pagina mostra come risolvere i problemi relativi ai combattimenti tra controller. Questi combattimenti consumano una grande quantità di risorse e possono ridurre le prestazioni. I combattimenti tra controller sono anche noti come contesa di risorse.
Config Sync controlla gli oggetti che applica al cluster e ripristina le modifiche apportate ai valori dichiarati nella fonte attendibile. Se queste modifiche sono
da un altro controller, la risorsa potrebbe spostarsi tra
gli stati desiderati dai controller concorrenti. 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
è già gestito da un altro strumento di riconciliazione, ulteriori aggiornamenti 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.
Identifica i combattimenti tra 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 consultare
i log del riconciliatore RootSync eseguendo questo 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 nella i tuoi 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 trovare ulteriori informazioni su qualsiasi combattimento con il controller, guarda gli aggiornamenti nella YAML della risorsa eseguendo questo comando:
kubectl get RESOURCE OBJECT_NAME \
--namespace NAMESPACE \
--watch -o yaml
Sostituisci quanto segue:
RESOURCE: il tipo di risorsa essere oggetto di contesa.OBJECT_NAME: il nome dell'oggetto che viene ha combattuto.NAMESPACE: lo spazio dei nomi a cui appartiene la risorsa è stato combattuto.
I risultati del log specificano la risorsa, il nome dell'oggetto e lo spazio dei nomi di cui aggiungere.
Questo comando restituisce uno stream dello stato della risorsa dopo l'applicazione degli aggiornamenti al server API. Utilizza uno strumento per il confronto di file per confrontare come output.
Risolvere i conflitti dei controller
Esistono diversi modi per risolvere i conflitti dei controller. Scegli l'opzione che funziona la soluzione migliore per la configurazione di Config Sync:
- Aggiorna il manifest della risorsa nell'origine in modo che corrisponda al valore dell'altro un controller di rete.
- Rimuovi il campo in questione dall'origine per consentire all'altra controller per gestirlo.
- Disattiva o disinstalla l'altro controller.
- Rimuovi la risorsa dall'origine e gestiscila manualmente o con un un controller personalizzato che tollera 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, operatori installare o mantenere CRD). Questi altri controller rimuovono automaticamente specifici di Config Sync. Se un altro componente in Kubernetes il cluster rimuove i metadati di Config Sync e smette di gestire la 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
di oggetti nel cluster, puoi aggiungere
client.lifecycle.config.k8s.io/mutation: ignore sull'oggetto che
vuoi che Config Sync ignori le mutazioni. Per informazioni su come fare
Vedi Ignorare le mutazioni degli oggetti.
Passaggi successivi
- Se i problemi persistono, controlla se si tratta di un problema noto.