Questa pagina mostra come risolvere i problemi relativi ai combattimenti tra i titolari. Questi combattimenti consumano una quantità elevata di risorse e possono peggiorare le tue prestazioni. I combattimenti tra controller sono anche noti come contesa di risorse.
Config Sync monitora 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 dello stato desiderato 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 i combattimenti tra più oggetti RootSync e RepoSync. Per gli oggetti RepoSync, se il riconciliatore rileva che l'oggetto è già gestito da un altro riconciliatore, vengono ignorati ulteriori aggiornamenti.
Per gli oggetti RootSync, il riconciliatore tenta di adottare qualsiasi oggetto che sia
configurato per essere gestito, a meno che non sia gestito da un altro oggetto RootSync. In questo modo, i riconciliatori di Config Sync non combattono 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 di combattimento 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 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 questo 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 origine attendibile basata sullo spazio dei nomi.
Se vedi KNV2005 nei risultati, significa che è in corso un combattimento con il 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.
Indaga sui combattimenti dei controller
Per trovare ulteriori informazioni su qualsiasi combattimento 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 da affrontare.OBJECT_NAME: il nome dell'oggetto che viene combattuto.NAMESPACE: lo spazio dei nomi in cui si trova la risorsa oggetto di discussione.
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 l'applicazione degli aggiornamenti al server API. Usa uno strumento di confronto 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 titolare 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 cogestione specifici.
- Se il controller è di tua proprietà e causa il conflitto di risorse e il campo che stai modificando non è nella fonte attendibile, aggiorna il controller per eseguire l'applicazione di patch anziché l'aggiornamento. In questo modo la modifica sarà 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 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 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, verifica se si tratta di un problema noto.