Risolvi i problemi di sincronizzazione delle configurazioni nel cluster

Questa pagina mostra come risolvere i problemi di sincronizzazione delle configurazioni nel cluster.

Risolvere gli errori di KNV 2009

KNV2009 errori indicano che Config Sync non è riuscito a sincronizzare alcune configurazioni con nel cluster. Le sezioni seguenti spiegano alcune delle cause più comuni e come risolverle.

È vietato l'utilizzo su determinate risorse

Poiché devi concedere agli oggetti RepoSync il loro RBAC, potrebbero mancare le autorizzazioni necessarie per applicare le risorse.

Puoi verificare che manchino le autorizzazioni recuperando la risorsa RepoSync stato:

kubectl get reposync repo-sync -n NAMESPACE -o yaml

Sostituisci NAMESPACE con lo spazio dei nomi che hai creato del repository dello spazio dei nomi.

Puoi utilizzare anche Comando nomos status.

Se nello stato vengono visualizzati i seguenti messaggi, significa che il riconciliatore NAMESPACE non dispone dell'autorizzazione necessaria per applicare risorsa:

KNV2009: deployments.apps "nginx-deployment" is forbidden: User "system:serviceaccount:config-management-system:ns-reconciler-default" cannot get resource "deployments" in API group "apps" in the namespace "default"

Per risolvere il problema, devi dichiarare una configurazione RoleBinding che conceda all'account di servizio per il riconciliatore l'autorizzazione per gestire la risorsa non riuscita nel relativo spazio dei nomi. I dettagli su come aggiungere un RoleBinding sono inclusi in Configurare la sincronizzazione da più repository.

Questo problema può interessare anche gli oggetti RootSync se hai utilizzato spec.override.roleRefs per cambiare i ruoli concessi all'oggetto RootSync. Se non hai impostato questo campo, per impostazione predefinita agli oggetti RootSync viene assegnato il ruolo cluster-admin.

L'oggetto ResourceGroup supera il limite di dimensioni degli oggetti etcd

Se viene visualizzato il seguente errore quando un riconciliatore tenta di applicare le configurazioni al cluster, l'oggetto ResourceGroup supera la dimensione dell'oggetto etcd limite:

KNV2009: too many declared resources causing ResourceGroup.kpt.dev, config-management-system/root-sync failed to be applied: task failed (action: "Inventory", name: "inventory-add-0"): Request entity too large: limit is 3145728. To fix, split the resources into multiple repositories.

Ti consigliamo di suddividere il tuo repository Git in più repository. Se non riesci a suddividere il file Git repository, perché l'oggetto è già troppo grande e le modifiche non vengono è permanente, puoi ridurlo configurando RootSync o RepoSync in modo che disabilita temporaneamente la scrittura dello stato dell'oggetto in ResourceGroup. Puoi farlo impostando il campo .spec.override.statusMode di RootSync o RepoSync oggetto in disabled. In questo modo, Config Sync smette di aggiornare lo stato delle risorse gestite nell'oggetto ResourceGroup. Questa azione riduce le dimensioni dell'oggetto ResourceGroup. Tuttavia, non puoi visualizzare lo stato della campagna di risorse di nomos status o gcloud alpha anthos config sync.

Se non visualizzi alcun errore nell'oggetto RootSync o RepoSync, significa che gli oggetti della tua origine attendibile sono stati sincronizzati con il cluster. Per verificare se La risorsa ResourceGroup supera il limite di dimensioni dell'oggetto etcd, controlla sia Stato della risorsa ResourceGroup e log del controller ResourceGroup:

  1. Controlla lo stato del gruppo di risorse:

    • Per controllare l'oggetto RootSync, esegui il seguente comando:

      kubectl get resourcegroup root-sync -n config-management-system

    • Per controllare l'oggetto RepoSync, esegui il seguente comando:

      kubectl get resourcegroup repo-sync -n NAMESPACE

      Sostituisci NAMESPACE con lo spazio dei nomi in cui hai creato il repository dello spazio dei nomi.

    L'output è simile all'esempio seguente:

    NAME        RECONCILING   STALLED   AGE
root-sync   True          False     35m

    Se il valore nella colonna RECONCILING è True, significa che la risorsa ResourceGroup è ancora in fase di riconciliazione.

  2. Controlla i log del controller ResourceGroup:

    kubectl logs deployment resource-group-controller-manager -c manager -n resource-group-system

    Se nell'output viene visualizzato un errore simile all'esempio seguente, La risorsa ResourceGroup è troppo grande e supera il limite di dimensioni degli oggetti etcd:

    "error":"etcdserver: request is too large"

Per evitare che ResourceGroup diventi troppo grande, riduci il numero di tutte le risorse del tuo repository Git. Puoi suddividere un repository principale in più repository principali.

Timeout di riconciliazione dell'applicazione delle dipendenze

Se stavi sincronizzando oggetti con dipendenze, potresti ricevere un errore simile all'esempio seguente quando il riconciliatore tenta di applicare gli oggetti con l'annotazione config.kubernetes.io/depends-on al cluster:

KNV2009: skipped apply of Pod, bookstore/pod4: dependency apply reconcile timeout: bookstore_pod3__Pod  For more information, see https://g.co/cloud/acm-errors#knv2009

Questo errore significa che l'oggetto delle dipendenze non è stato riconciliato all'interno del valore predefinito per la riconciliazione di cinque minuti. Config Sync non può applicare l'oggetto dipendente perché, con l'annotazione config.kubernetes.io/depends-on, Config Sync applica gli oggetti solo nell'ordine che preferisci. Puoi eseguire l'override il timeout predefinito della riconciliazione su un tempo più lungo impostando spec.override.reconcileTimeout

È anche possibile che la dipendenza si riconcilia dopo la sincronizzazione iniziale tentativo completato. In questo caso, la dipendenza dovrebbe essere rilevata come riconciliata al successivo tentativo di ripetizione della sincronizzazione, sbloccando l'applicazione di eventuali elementi dipendenti. In questo caso, l'errore potrebbe essere segnalato brevemente e poi rimosso. Allungare il timeout di riconciliazione potrebbe contribuire a evitare che l'errore venga segnalato in modo intermittente.

Le informazioni sull'inventario sono pari a zero

Se viene visualizzato il seguente errore quando il riconciliatore tenta di applicare le configurazioni al cluster, è probabile che l'inventario non abbia risorse o il file manifest ha un'annotazione non gestita:

KNV2009: inventory info is nil\n\nFor more information, see https://g.co/cloud/acm-errors#knv2009

Per risolvere il problema, prova a procedere nel seguente modo:

  1. Evita di configurare sincronizzazioni in cui tutte le risorse hanno l'annotazione configmanagement.gke.io/managed: disabled, assicurandoti che almeno una risorsa sia gestita da Config Sync.
  2. Aggiungi l'annotazione configmanagement.gke.io/managed: disabled solo dopo aver completato una sincronizzazione iniziale della risorsa senza questa annotazione.

Più modelli di oggetto inventario

Se viene visualizzato il seguente errore quando il riconciliatore tenta di presentare domanda al cluster, è probabile che tu abbia una configurazione inventario generate da kpt nella fonte attendibile, ad esempio un repository Git:

KNV2009: Package has multiple inventory object templates.  The package should have one and only one inventory object template.   For more information, see https://g.co/cloud/acm-errors#knv2009

Il problema si verifica perché Config Sync gestisce la propria configurazione dell'inventario. A risolvere il problema, eliminare la configurazione dell'inventario nella fonte attendibile.

Impossibile apportare modifiche ai campi immutabili

Non puoi modificare i campi immutabili di una configurazione modificando il valore nella una fonte attendibile. Il tentativo di apportare una modifica di questo tipo genera un errore simile al seguente:

KNV2009: failed to apply RESOURCE: admission webhook "deny-immutable-field-updates.cnrm.cloud.google.com" denied the request: cannot make changes to immutable field(s):

Se devi aggiornare un campo immutabile, elimina manualmente l'oggetto nel cluster. Config Sync può quindi ricreare l'oggetto con il nuovo valore del campo.

Rilevamento dell'API non riuscito

Se viene visualizzato un messaggio di errore simile al seguente, è possibile che si tratti di un errore di rilevamento dell'API:

KNV2002: API discovery failed: APIServer error: unable to retrieve the complete list of server APIs: external.metrics.k8s.io/v1beta1: received empty response for: external.metrics.k8s.io/v1beta1

Config Sync utilizza Rilevamento delle API Kubernetes per cercare le risorse supportate dal cluster. In questo modo, Config Sync può convalidare i tipi di risorse specificati nell'origine e monitorare le modifiche apportate a queste risorse nel cluster.

Prima della versione 1.28 di Kubernetes, ogni volta che il backend di APIService non era in stato di salute o restituiva un risultato di elenco vuoto, la scoperta dell'API non andava a buon fine, causando errori in Config Sync e in molti altri componenti di Kubernetes. Molti dei comuni I backend APIService non sono ad alta disponibilità, quindi questo può avvenire relativamente di frequente, semplicemente aggiornando il backend o facendolo riprogrammare in un altro nodo.

Esempi di backend APIService con una singola replica includono metrics-server e custom-metrics-stackdriver-adapter. Alcuni backend APIService restituiscono sempre risultati in elenco vuoti, ad esempio custom-metrics-stackdriver-adapter. Un altro modo comune La causa dell'errore di rilevamento delle API è che i webhook non sono integri.

Dopo la versione 1.28 di Kubernetes, con la funzionalità di ricerca aggregata abilitata, un backend APIService non valido non causa più errori non gestiti. Invece il gruppo di risorse gestito da questo APIService non ha risorse. In questo modo, la sincronizzazione continua, a condizione che la risorsa non funzionante non sia specificata nell'origine.

Riparazione automatica ritardata

La riparazione automatica controlla le risorse gestite, rileva la deviazione dall'origine della verità e la ripristina.

La riparazione automatica viene messa in pausa durante il tentativo di sincronizzazione. Questo comportamento significa che la riparazione automatica potrebbe essere ritardata, soprattutto se si verificano errori di sincronizzazione che impediscono il completamento del riconciliatore. Per riattivare la riparazione automatica, risolvi tutti i problemi sono stati segnalati errori di sincronizzazione.

Numero elevato di richieste API Kubernetes

Config Sync utilizza una strategia di istanze multiple per scalare e isolare i tenant e i domini di errore. Per questo motivo, ogni RootSync e RepoSync riceve il proprio del riconciliatore di rete. Oltre a sincronizzarsi ogni volta che vengono apportate modifiche all'origine, ogni istanza di riconciliatore si sincronizza periodicamente nell'ambito del proprio comportamento di riparazione automatica per ripristinare eventuali modifiche non rilevate dalla correzione della deriva attiva. Quando aggiungi oggetti RootSync o RepoSync, viene generata una visualizzazione aumento del numero di richieste API effettuate dai riconciliatori che sincronizzano le risorse a Kubernetes. Pertanto, se hai molti oggetti RootSync e RepoSync, a volte questo può causare un carico di traffico significativo sull'API Kubernetes.

Per eseguire la sincronizzazione, Config Sync utilizza Applicazione lato server. Questo sostituisce il normale flusso di richieste GET e PATCH con una singola richiesta PATCH. riducendo il numero totale di chiamate API, aumentando il numero di PATCH chiamate. Ciò garantisce che le modifiche apportate siano corrette, anche quando la risorsa la versione del gruppo nell'origine non corrisponde alla versione predefinita del gruppo di risorse nella in un cluster Kubernetes. Tuttavia, potresti visualizzare richieste PATCH nel log di controllo, anche se non siano state apportate modifiche all'origine o deviazioni dallo stato desiderato. È normale, ma può sorprenderti.

Quando la sincronizzazione genera un errore, viene riprovato fino a quando non va a buon fine. Tuttavia, se questo richiede l'interazione umana, Config Sync potrebbe generare errori e riprovare per un po' di tempo, aumentando il numero di richieste all'API Kubernetes. I tentativi di nuovo si riducono in modo esponenziale, ma se la sincronizzazione di molti oggetti RootSync o RepoSync non riesce contemporaneamente, questo può causare un carico di traffico significativo sull'API Kubernetes.

Per limitare questi problemi, prova una delle seguenti opzioni:

  • Correggi rapidamente gli errori di configurazione, in modo che non si accumulino.
  • Combina più oggetti RootSync o RepoSync, per ridurre il numero di riconciliatori che effettuano richieste API Kubernetes.

Disinstallazione di KubeVirt bloccata dai finalizzatori

KubeVirt è un pacchetto Kubernetes che utilizza più finalizzatori, che richiedono un ordine di eliminazione preciso per facilitare la pulizia. Se gli oggetti KubeVirt vengono eliminati nell'ordine sbagliato, l'eliminazione di altri oggetti KubeVirt potrebbe bloccarsi smetteranno di rispondere a tempo indeterminato.

Se hai tentato di disinstallare KubeVirt ma l'operazione è stata bloccata, segui le istruzioni per la configurazione eliminazione di KubeVirt.

Per limitare il problema in futuro, dichiarare le dipendenze tra gli oggetti risorsa per assicurarti che vengano eliminate in ordine inverso.

Eliminazione degli oggetti bloccata dai finalizzatori

Finalizzatori Kubernetes sono voci di metadati che indicano a Kubernetes di non consentire la rimozione di un oggetto fino a quando un controller specifico non ha eseguito la pulizia. Ciò può causare il fallimento della sincronizzazione o della riconciliazione se le condizioni per la pulizia non sono soddisfatte o se il controller che esegue la pulizia della risorsa non è in stato operativo o è stato eliminato.

Per mitigare il problema, identifica la risorsa ancora in fase di finalizzazione e quella controller deve eseguire la pulizia.

Se il controller non è in stato di esecuzione, la correzione della causa principale dovrebbe consentire il completamento della pulizia della risorsa, sbloccando la rimozione dell'oggetto.

Se il controller è in stato di esecuzione, deve aver applicato una condizione di stato all'oggetto da eliminare per spiegare il motivo dell'interruzione della pulizia. Se non è necessario, controlla i log del controller per verificare la causa principale.

Spesso, l'impossibilità di eliminare un oggetto è un'indicazione del fatto che gli oggetti sono stati eliminati nell'ordine sbagliato. Per evitare questo tipo di problema in futuro, dichiarare le dipendenze tra gli oggetti risorsa, per assicurarti che vengano eliminate in ordine inverso.

I campi ResourceGroup cambiano continuamente

Quando si prova a eseguire la sincronizzazione, l'inventario viene aggiornato in modo da modificare lo stato della risorsa. in In attesa. Se la sincronizzazione non riesce, l'inventario viene aggiornato per modificare la risorsa. su Non riuscito. Se si ripete la sincronizzazione dopo un errore, il pattern si ripete, generando aggiornamenti periodici all'inventario. Di conseguenza, ResourceGroupresourceVersion aumenta a ogni aggiornamento e lo stato di sincronizzazione oscilla. È normale, ma può sorprendere.

Gli errori di sincronizzazione possono essere causati da diversi problemi. Uno dei più comuni è autorizzazioni insufficienti per gestire le risorse specificate nell'origine. Per risolvere il problema per questo errore, aggiungi i RoleBindings o ClusterRoleBinding appropriati per concedere l'autorizzazione del riconciliatore RepoSync o RootSync per gestire le risorse mancata sincronizzazione.

L'applicazione lato server non rimuove o ripristina i campi non specificati nell'origine

Config Sync utilizza Server-Side Apply per applicare i manifest dall'origine a Kubernetes. Questa operazione è necessaria per Consenti ad altri controller di gestire i campi metadata e spec. Un esempio di Horizontal Pod Autoscaler, che aggiorna il numero di repliche per il deployment. Per questo motivo, Config Sync gestisce solo i campi specificati il manifest di origine. Questo ha l'effetto collaterale che, quando si adottano oggetti di risorse esistenti, i campi non specificati nell'origine non vengono modificati, il che a volte può causare l'invalidità o l'errore della configurazione unita.

Per evitare questo problema quando adotti una risorsa, utilizza gli stessi campi in dell'origine quando la prima adotti e poi modifichi i campi al suo interno dopo la sincronizzazione, in modo che Config Sync rimuova correttamente i campi precedentemente applicati e li sostituisce con i nuovi campi dell'origine. Un altro modo per evitare questo problema è eliminare prima la risorsa dal cluster e consentire a Config Sync di applicare la nuova versione.

Passaggi successivi

  • Se i problemi persistono, controlla se si tratta di un problema noto.