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 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à di Argo CD

La funzionalità è ATTIVA ma le applicazioni non si sincronizzano

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

Verifica lo stato della capacità:

È possibile visualizzare i problemi relativi allo stato 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 dell'applicazione:

# 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 arriva maiHealthy, 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 a più 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 IAM Capability Role 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 l'accesso al cluster di destinazione:

Sul cluster di destinazione, verifica che Argo CD Capability Role abbia un Access Entry:

# 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 tra account, verifica che Argo CD Capability Role abbia un Access Entry sul cluster di destinazione. La funzionalità gestita utilizza EKS Access Entries per l'accesso su più account, non l'assunzione di ruoli IAM.

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

Tempo di sincronizzazione delle applicazioni aumentato

Se le applicazioni si sincronizzano ma impiegano più tempo del previsto, utilizzate i seguenti passaggi diagnostici per identificare la causa.

Controlla l'ora dell'ultima sincronizzazione

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

# 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 dell'applicazione per i 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 va immediatamenteOutOfSync, o se rimane bloccata in un ciclo di sincronizzazione, la causa di solito è la 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 deviazioni

I 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 ad ogni riconciliazione.

I sintomi sono:

Per risolvere il problema, aggiungi ignoreDifferences i campi interessati e abilita RespectIgnoreDifferences nelle opzioni 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. Healthy pruneSe abilitato, ciò potrebbe comportare la perdita di risorse parzialmente avviate.

Per risolvere questo problema, correggi innanzitutto la deriva sottostante (vedi lo scenario del certificato). Se la deriva non è la causa, prendi in considerazione 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 conflitti tra la 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ò accade in genere quando il nome di una risorsa condivisa non rientra nell'ambito di un ambiente o di un 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 che 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 il problema:

kubectl patch resource-kind
            resource-name -n my-namespace \
  --type json -p '[{"op": "remove", "path": "/metadata/finalizers/0"}]'

La sincronizzazione fallita non riprova automaticamente alla stessa revisione

Dopo un errore di sincronizzazione con una revisione specifica, Argo CD non riprova automaticamente la stessa revisione. Ciò accade in genere 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 del manifesto nel tuo repository Git e invia un nuovo commit. In alternativa, attiva una sincronizzazione manuale:

argocd app sync my-app
         

Monorepo commit churn innesca un'ampia rigenerazione

Se molte applicazioni eseguono il tracciamento HEAD sullo stesso repository, qualsiasi commit verso 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 targetRevision e sulla memorizzazione nella cache, consultate la sezione «Maggiore tempo di sincronizzazione delle applicazioni» in questa pagina.

Per estendere la rigenerazione solo ai file utilizzati da ciascuna applicazione, aggiungi l'annotazionemanifest-generate-paths:

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 manifest 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, aggiungete targetRevision il nome o il tag di un ramo anziché. HEAD

I webhook predefiniti e mutanti di Kubernetes causano differenze fantasma

Se l'applicazione viene visualizzata OutOfSync immediatamente dopo una sincronizzazione, controlla la differenza 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, che aumenta il carico sul server dell'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 di frequente. Gli esempi includono gli oggetti del nodo Karpenter, gli oggetti Cilium Identity and Endpoint e i report sulle policy di Kyverno. Se queste risorse generano un volume elevato di eventi di visualizzazione e causano un abbandono della sincronizzazione, puoi ridurre il carico escludendo tali tipi di risorse o filtrando gli eventi di visualizzazione. Queste modifiche richiedono una configurazione del controller a livello di istanza.

Sulla funzionalità gestita, apri un caso AWS Support per richiedere l'esclusione delle risorse o il filtraggio degli eventi di visualizzazione per questi tipi di risorse.

Best practice

Quando contattare AWS Supporto

Apri una AWS richiesta di assistenza nelle seguenti situazioni:

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

Fasi successive