Contribuisci a migliorare questa pagina

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Per contribuire a questa guida per l'utente, scegli il GitHub link Modifica questa pagina su che si trova nel riquadro destro di ogni pagina.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Risolvi i problemi relativi alle funzionalità Argo CD

La funzionalità è ATTIVA ma le applicazioni non si sincronizzano

Se la funzionalità del CD Argo mostra ACTIVE lo stato ma le applicazioni non si sincronizzano, controllate lo stato della funzionalità e l'applicazione.

Verifica lo stato della funzionalità:

È possibile visualizzare i problemi relativi all'integrità e allo stato delle funzionalità nella console EKS o utilizzando la AWS CLI.

Console:

AWS CLI:

# View capability status and health
aws eks describe-capability \
  --region region-code \
  --cluster-name my-cluster \
  --capability-name my-argocd

# Look for issues in the health section

Cause comuni:

Controlla lo stato della domanda:

# List applications
kubectl get application -n argocd

# View sync status
kubectl get application my-app -n argocd -o jsonpath='{.status.sync.status}'

# View application health
kubectl get application my-app -n argocd -o jsonpath='{.status.health}'

Verifica le condizioni della domanda:

# Describe application to see detailed status
kubectl describe application my-app -n argocd

# View application health
kubectl get application my-app -n argocd -o jsonpath='{.status.health}'

Applicazioni bloccate nello stato «In corso»

Se un'applicazione viene visualizzata Progressing ma non viene mai visualizzataHealthy, controlla lo stato delle risorse e gli eventi dell'applicazione.

Controlla lo stato delle risorse:

# View application resources
kubectl get application my-app -n argocd -o jsonpath='{.status.resources}'

# Check for unhealthy resources
kubectl describe application my-app -n argocd | grep -A 10 "Health Status"

Cause comuni:

Verifica la configurazione del cluster di destinazione (per configurazioni multi-cluster):

# List registered clusters
kubectl get secret -n argocd -l argocd.argoproj.io/secret-type=cluster

# View cluster secret details
kubectl get secret cluster-secret-name -n argocd -o yaml

Errori di autenticazione del repository

Se Argo CD non può accedere ai tuoi repository Git, verifica la configurazione di autenticazione.

Per CodeCommit i repository:

Verifica che il ruolo di capacità IAM disponga delle CodeCommit autorizzazioni:

# View IAM policies
aws iam list-attached-role-policies --role-name my-argocd-capability-role
aws iam list-role-policies --role-name my-argocd-capability-role

# Get specific policy details
aws iam get-role-policy --role-name my-argocd-capability-role --policy-name policy-name
      

Il ruolo richiede l'codecommit:GitPullautorizzazione per i repository.

Per i repository Git privati:

Verifica che le credenziali del repository siano configurate correttamente:

# Check repository secret exists
kubectl get secret -n argocd repo-secret-name -o yaml

Assicurati che il segreto contenga le credenziali di autenticazione corrette (chiave SSH, token o). username/password

Per i repository che utilizzano Secrets Manager:

# Verify IAM Capability Role has Secrets Manager permissions
aws iam list-attached-role-policies --role-name my-argocd-capability-role

# Test secret retrieval
aws secretsmanager get-secret-value --secret-id arn:aws:secretsmanager:region-code:111122223333:secret:my-secret
      

Multi-cluster problemi di distribuzione

Se le applicazioni non vengono distribuite su cluster remoti, verifica la registrazione del cluster e la configurazione dell'accesso.

Controlla la registrazione del cluster:

# List registered clusters
kubectl get secret -n argocd -l argocd.argoproj.io/secret-type=cluster

# Verify cluster secret format
kubectl get secret CLUSTER_SECRET_NAME -n argocd -o yaml

Assicurati che il server campo contenga l'ARN del cluster EKS, non l'URL dell'API Kubernetes.

Verifica la voce di accesso al cluster di destinazione:

Nel cluster di destinazione, verifica che il ruolo Argo CD Capability abbia una voce di accesso:

# List access entries (run on target cluster or use AWS CLI)
aws eks list-access-entries --cluster-name target-cluster

# Describe specific access entry
aws eks describe-access-entry \
  --cluster-name target-cluster \
  --principal-arn arn:aws:iam::111122223333:role/my-argocd-capability-role
      

Controlla le autorizzazioni IAM per più account:

Per le distribuzioni su più account, verifica che il ruolo Argo CD Capability abbia una voce di accesso nel cluster di destinazione. La funzionalità gestita utilizza EKS Access Entries per l'accesso tra più account, non l'assunzione del ruolo IAM.

Per ulteriori informazioni sulla configurazione multi-cluster, vedere. Registra i cluster di destinazione

Maggiore tempo di sincronizzazione delle applicazioni

Se la sincronizzazione delle applicazioni richiede più tempo del previsto, utilizza i seguenti passaggi diagnostici per identificare la causa.

Controlla l'ora dell'ultima sincronizzazione

Conferma il ritardo controllando l'ultima volta che le applicazioni sono state sincronizzate:

# View last sync time for all applications
kubectl get application -n argocd -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.operationState.finishedAt}{"\n"}{end}'

# View last sync time for a specific application
kubectl get application my-app -n argocd -o jsonpath='{.status.operationState.finishedAt}'

Verifica le condizioni dell'applicazione

Esamina le condizioni per la presentazione delle domande relative ai ritardi nelle code di riconciliazione:

# Check conditions on an application
kubectl get application my-app -n argocd -o jsonpath='{.status.conditions}'

Controlla la configurazione di TargetRevision

Le applicazioni che utilizzano targetRevision: HEAD invalidano la cache del manifesto a ogni commit nel repository, il che rallenta i tempi di sincronizzazione:

# List applications using HEAD as targetRevision
kubectl get application -n argocd -o jsonpath='{range .items[?(@.spec.source.targetRevision=="HEAD")]}{.metadata.name}{"\n"}{end}'

Cause comuni

Mitigazioni

Applicazioni che si sincronizzano ripetutamente o non sono sincronizzate

Se l'applicazione si sincronizza e poi viene eseguita immediatamenteOutOfSync, o se rimane bloccata in un ciclo di sincronizzazione, la causa è solitamente una deriva tra ciò che Git definisce e ciò che esiste nel cluster. Inizia con la diagnostica di base.

Raccogli informazioni diagnostiche

# View current sync and health status
argocd app get my-app

# Show exact fields that differ between Git and live state
argocd app diff my-app

# Check whether the app has ever reached a stable state
argocd app history my-app
         

Il argocd app diff comando è il punto di partenza più utile. Mostra esattamente quali campi fanno apparire l'applicazione non sincronizzata.

Self-managed i certificati causano una deriva

Controller come cert-manager, OPA Gatekeeper e KEDA generano certificati in fase di esecuzione. Questi valori di runtime non sono in Git, quindi Argo CD rileva una deriva in ogni riconciliazione.

I sintomi sono:

Per risolvere questo problema, aggiungi ignoreDifferences i campi interessati e abilita le opzioni RespectIgnoreDifferences di sincronizzazione:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
spec:
  ignoreDifferences:
    - group: admissionregistration.k8s.io
      kind: ValidatingWebhookConfiguration
      jsonPointers:
        - /webhooks/0/clientConfig/caBundle
    - group: ""
      kind: Secret
      jsonPointers:
        - /data/tls.crt
        - /data/tls.key
  syncPolicy:
    syncOptions:
      - RespectIgnoreDifferences=true

Self-heal interrompe i carichi di lavoro ad avvio lento

Quando selfHeal è abilitato, Argo CD risincronizza l'applicazione quando rileva una deriva. Se l'avvio del carico di lavoro impiega 30-60 secondi, l'autoriparazione si attiva prima che il carico di lavoro diventi effettivo. Healthy pruneSe abilitato, questo potrebbe ridurre le risorse parzialmente avviate.

Per risolvere questo problema, correggi innanzitutto la deriva sottostante (vedi lo scenario del certificato). Se la deriva non è la causa, valuta la possibilità di disabilitare la correzione automatica per i carichi di lavoro che gestisci esclusivamente tramite Git:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
spec:
  syncPolicy:
    automated:
      selfHeal: false
      prune: false

ApplicationSet o collisioni tra proprietà delle risorse

Se due applicazioni ApplicationSets gestiscono la stessa risorsa Kubernetes, Argo CD mostra un. SharedResourceWarning La risorsa non raggiunge mai uno stato stabile. Ciò si verifica in genere quando il nome di una risorsa condivisa non è definito per ambiente o cluster.

Per risolvere questo problema:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-appset
spec:
  syncPolicy:
    preserveResourcesOnDeletion: true

Eliminazione bloccata dai finalizzatori di risorse

Se un'applicazione è bloccata o mostra «N oggetti rimanenti da eliminare», il resources-finalizer.argocd.argoproj.io finalizzatore blocca la rimozione fino all'eliminazione di tutte le risorse gestite. Terminating Una risorsa gestita con un proprio finalizzatore non elaborabile blocca l'eliminazione a tempo indeterminato.

Per confermare, elenca le risorse che hanno un timestamp di eliminazione ma non sono state rimosse:

kubectl get all -n my-namespace -o json | \
  jq '.items[] | select(.metadata.deletionTimestamp != null) | {name: .metadata.name, kind: .kind, finalizers: .metadata.finalizers}'

Per risolvere questo problema:

Usando l'elenco dei finalizzatori stampato con il comando precedente, imposta l'elenco sui finalizzatori che desideri conservare e tralascia solo quello di blocco. Sostituisci finalizer-a e con questi nomifinalizer-b:

kubectl patch resource-kind
            resource-name -n my-namespace \
  --type merge -p '{"metadata":{"finalizers":["finalizer-a","finalizer-b"]}}'

Se il finalizzatore di blocco è l'unico sulla risorsa, passa un elenco vuoto:. --type merge -p '{"metadata":{"finalizers":[]}}'

La sincronizzazione non riuscita non comporta il riavvio automatico della stessa revisione

Se una sincronizzazione con una revisione specifica fallisce, Argo CD non riprova automaticamente la stessa revisione. Ciò accade comunemente a causa di un difetto manifesto, ad esempio una chiave di variabile di ambiente ComparisonError duplicata.

Conferma controllando lo stato dell'applicazione:

argocd app get my-app
# Look for: Operation: Sync  Phase: Failed  Revision: <sha>

Per risolvere questo problema, correggi il difetto manifesto nel tuo repository Git e invia un nuovo commit. In alternativa, attiva una sincronizzazione manuale:

argocd app sync my-app
         

Il commit churn di Monorepo attiva un'ampia rigenerazione

Se molte applicazioni vengono registrate HEAD sullo stesso repository, qualsiasi commit in quel repository cambia per tutte le applicazioni. HEAD Ciò attiva la rigenerazione del manifesto per ogni applicazione, anche per quelle i cui file non sono stati modificati. Per ulteriori informazioni sulla memorizzazione nella cache targetRevision e sulla memorizzazione nella cache, vedere la sezione «Tempo di sincronizzazione delle applicazioni aumentato» in questa pagina.

Per limitare la rigenerazione solo ai file utilizzati da ciascuna applicazione, aggiungete l'manifest-generate-pathsannotazione:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  annotations:
    argocd.argoproj.io/manifest-generate-paths: /apps/my-app
spec:
  source:
    repoURL: https://github.com/my-org/my-monorepo.git
    targetRevision: HEAD
    path: apps/my-app

Con questa annotazione, Argo CD rigenera i manifesti solo quando i file nel percorso specificato cambiano. Per le librerie condivise utilizzate tra le applicazioni, è possibile specificare più percorsi separati da punto e virgola (). ;

Ove possibile, aggiungi targetRevision il nome o il tag di una filiale invece di. HEAD

I webhook predefiniti e mutanti di Kubernetes causano differenze fantasma

Se la tua applicazione viene visualizzata OutOfSync subito dopo una sincronizzazione, controlla le differenze per i campi che non hai mai impostato (come,, o). terminationGracePeriodSeconds dnsPolicy /spec/replicas Il server API Kubernetes o un webhook mutante hanno aggiunto questi campi al momento dell'applicazione.

Per risolvere questo problema per i campi gestiti da un altro controller (ad esempio /spec/replicas quando un HPA gestisce la scalabilità), aggiungi: ignoreDifferences

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
spec:
  ignoreDifferences:
    - group: apps
      kind: Deployment
      jsonPointers:
        - /spec/replicas
  syncPolicy:
    syncOptions:
      - RespectIgnoreDifferences=true

Per i campi aggiunti dai webhook predefiniti o mutanti di Kubernetes, puoi abilitare la differenza lato server sull'applicazione:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  annotations:
    argocd.argoproj.io/compare-options: ServerSideDiff=true,IncludeMutationWebhook=true

Server-side diff esegue un'applicazione a secco per risorsa, il che aumenta il carico sul server API Kubernetes. Provalo su un numero limitato di applicazioni prima di abilitarlo su larga scala.

High-churn risorse di proprietà del controller

Alcuni controller generano un gran numero di risorse di breve durata o aggiornate frequentemente. Gli esempi includono gli oggetti dei nodi Karpenter, gli oggetti identificativi ed endpoint Cilium e i report sulle policy di Kyverno. Se queste risorse generano un volume elevato di eventi di monitoraggio e causano l'interruzione della sincronizzazione, puoi ridurre il carico escludendo tali tipi di risorse o filtrando gli eventi di monitoraggio. Queste modifiche richiedono una configurazione del controller a livello di istanza.

Per quanto riguarda la funzionalità gestita, apri un caso di AWS supporto per richiedere l'esclusione delle risorse o il filtro degli eventi di controllo per questi tipi di risorse.

Best practice

Quando contattare AWS Supporto

Aprire una richiesta di AWS assistenza nelle seguenti situazioni:

Includi l'output delle argocd app get e argocd app diff per le applicazioni interessate nel tuo caso di supporto.

Fasi successive