Risolvere i problemi relativi ai conflitti dei controller

Questa pagina mostra come risolvere i problemi relativi ai conflitti tra controller. Questi conflitti consumano una grande quantità di risorse e possono ridurre le prestazioni. I conflitti del controller sono noti anche come contesa delle risorse.

Config Sync monitora gli oggetti che applica al cluster e ripristina le modifiche apportate ai valori dichiarati nell'origine attendibile. Se queste modifiche vengono apportate da un altro titolare, la risorsa potrebbe passare da uno stato all'altro in base alle preferenze dei titolari 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 i 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 che è configurato per gestire, a meno che non sia gestito da un altro oggetto RootSync. In questo modo i riconciliatori di Config Sync non si scontrano tra loro e vengono segnalati errori nello stato di tutti gli oggetti RootSync e RepoSync coinvolti.

Identificare i conflitti 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 il seguente comando:

kubectl logs -n config-management-system \
    --selector "app=reconciler,configsync.gke.io/sync-name=root-sync" \
    --container reconciler

Per filtrare 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 con ambito dello spazio dei nomi.

Se nei risultati vedi KNV2005, significa che c'è una lotta tra 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 combattimenti con il controller

Per trovare ulteriori informazioni su eventuali conflitti del controller, monitora gli aggiornamenti del file YAML della risorsa eseguendo il comando seguente:

 kubectl get RESOURCE OBJECT_NAME \
     --namespace NAMESPACE \
     --watch -o yaml

Sostituisci quanto segue:

  • RESOURCE: il tipo di risorsa contesa.
  • OBJECT_NAME: il nome dell'oggetto conteso.
  • NAMESPACE: lo spazio dei nomi in cui si trova la risorsa contesa.

I risultati del log specificano la risorsa, il nome dell'oggetto e lo spazio dei nomi da aggiungere.

Questo comando restituisce un flusso 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 di controller

Esistono diversi modi per risolvere i conflitti tra controller. Scegli l'opzione più adatta alla tua configurazione di Config Sync:

  • Aggiorna il manifest delle risorse nella sorgente in modo che corrisponda al valore desiderato dall'altro controller.
  • Rimuovi il campo in questione dalla sorgente 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 specifiche o la cogestione.
  • Se possiedi il controller che causa la contesa delle risorse e il campo che viene modificato non si trova nella fonte attendibile, aggiorna il controller in modo che esegua la patch anziché l'aggiornamento. In questo modo, la modifica verrà consentita da Config Sync e non verrà annullata.

Esistono anche alcune risorse che devono 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 cluster Kubernetes rimuove i metadati di Config Sync, interrompi la gestione della risorsa con Config Sync. Per informazioni su come eseguire questa operazione, vedi 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 Ignora le mutazioni degli oggetti.

Passaggi successivi