Questa pagina mostra come risolvere i problemi relativi ai combattimenti dei controller. Questi combattimenti consumano un'elevata quantità di risorse e possono compromettere le prestazioni. I combattimenti tra controller sono noti anche come contesa delle risorse.
Config Sync monitora gli oggetti che applica sul cluster e ripristina le modifiche apportate ai valori dichiarati nella fonte di riferimento. Se queste modifiche vengono apportate da un altro controller, la risorsa potrebbe alternare 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 combattimento, registra la deviazione e segnala l'errore nello stato dell'oggetto RootSync o RepoSync.
Config Sync ha una logica speciale per rilevare combattimenti tra più oggetti RootSync e RepoSync. Per gli oggetti RepoSync, se il riconciliatore vede che l'oggetto è già gestito da un altro strumento di riconciliazione, ulteriori aggiornamenti vengono ignorati.
Per gli oggetti RootSync, il riconciliatore tenta di adottare qualsiasi oggetto per cui è configurato, a meno che non sia gestito da un altro oggetto RootSync. In questo modo
i riconciliatori di Config Sync non possono entrare in conflitto tra loro e
segnala errori nello stato di tutti gli oggetti RootSync e RepoSync coinvolti.
Identifica i combattimenti tra controller
Puoi esaminare gli errori dei combattimenti utilizzando il comando nomos status o controllando il campo di stato nell'oggetto RootSync o RepoSync.
Se non hai installato lo strumento a riga di comando nomos, puoi esaminare i log del riconciliazione 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 comando seguente:
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 fonte di riferimento basata sullo spazio dei nomi.
Se vedi KNV2005 nei risultati, significa che c'è una lotta tra controller.
Il seguente messaggio di errore è un esempio del tipo di errore che potresti vedere nei 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.
Indaga sui combattimenti tra i controller
Per trovare ulteriori informazioni su qualsiasi lotta tra controller, guarda gli aggiornamenti al file YAML della risorsa eseguendo questo comando:
kubectl get RESOURCE OBJECT_NAME \
--namespace NAMESPACE \
--watch -o yaml
Sostituisci quanto segue:
RESOURCE: il tipo di risorsa che viene combattuta.OBJECT_NAME: il nome dell'oggetto che viene combattuto.NAMESPACE: lo spazio dei nomi in cui si trova la risorsa oggetto di contrasto.
I risultati del log specificano la risorsa, il nome dell'oggetto e lo spazio dei nomi che devi aggiungere.
Questo comando restituisce un flusso dello stato della risorsa dopo che gli aggiornamenti sono stati applicati al server API. Usa uno strumento per il confronto dei file per confrontare l'output.
Risolvi i combattimenti dei controller
Esistono diversi modi per risolvere i combattimenti tra controller. Scegli l'opzione più adatta alla configurazione di Config Sync:
- Aggiorna il manifest della risorsa nell'origine in modo che corrisponda al valore richiesto dall'altro controller.
- Rimuovi il campo in questione dall'origine per consentire all'altro controller di gestirlo.
- Disattiva o disinstalla l'altro controller.
- Rimuovi la risorsa dall'origine e gestiscila manualmente o con un controller personalizzato che tollera modifiche o co-gestione specifiche.
- Se il controller che causa la contesa delle risorse è di tua proprietà e il campo modificato non è l'origine attendibile, aggiorna il controller in modo che esegua l'applicazione di patch anziché aggiornarlo. In questo modo la modifica verrà consentita da Config Sync e non verrà annullata.
Esistono anche alcune risorse che dovrebbero appartenere ad altri controller (ad esempio, alcuni operatori installano o gestiscono CRD). Questi altri controller rimuovono automaticamente tutti i metadati specifici di Config Sync. Se un altro componente nel cluster Kubernetes rimuove i metadati di Config Sync, interrompi la gestione della risorsa con Config Sync. Per informazioni su come eseguire questa operazione, vedi Arrestare 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 in 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 il tuo problema è un problema noto.