Aidez à améliorer cette page

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page qui se trouve dans le volet droit de chaque page.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Résoudre les problèmes liés aux fonctionnalités d'Argo CD

La fonctionnalité est ACTIVE mais les applications ne sont pas synchronisées

Si l'ACTIVEétat de votre fonctionnalité Argo CD est affiché mais que les applications ne sont pas synchronisées, vérifiez l'état de santé de la fonctionnalité et de l'application.

Vérifiez l'état des capacités  :

Vous pouvez consulter les problèmes d'état et d'état des fonctionnalités dans la console EKS ou à l'aide de l' AWS interface de ligne de commande.

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

Causes courantes :

Vérifiez l'état de la demande  :

# 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}'

Vérifiez les conditions de candidature  :

# 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}'

Applications bloquées dans l'état « En cours »

Si une application s'affiche Progressing mais n'atteint jamaisHealthy, vérifiez l'état des ressources et les événements de l'application.

Vérifiez l'état de santé des ressources  :

# 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"

Causes courantes :

Vérifiez la configuration du cluster cible (pour les configurations multi-clusters) :

# 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

Échecs d'authentification du référentiel

Si Argo CD ne peut pas accéder à vos dépôts Git, vérifiez la configuration d'authentification.

Pour les CodeCommit référentiels  :

Vérifiez que le rôle de capacité IAM dispose des CodeCommit autorisations nécessaires :

# 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
      

Le rôle nécessite une codecommit:GitPull autorisation pour les référentiels.

Pour les dépôts Git privés :

Vérifiez que les informations d'identification du référentiel sont correctement configurées :

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

Assurez-vous que le secret contient les informations d'authentification correctes (clé SSH, jeton ou username/password).

Pour les référentiels utilisant 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 problèmes de déploiement

Si les applications ne sont pas déployées sur des clusters distants, vérifiez l'enregistrement du cluster et la configuration des accès.

Vérifiez l'enregistrement du 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

Assurez-vous que le server champ contient l'ARN du cluster EKS, et non l'URL de l'API Kubernetes.

Vérifiez l'entrée d'accès au cluster cible  :

Sur le cluster cible, vérifiez que le rôle de capacité Argo CD possède une entrée d'accès :

# 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
      

Vérifiez les autorisations IAM pour plusieurs comptes :

Pour les déploiements entre comptes, vérifiez que le rôle de capacité Argo CD possède une entrée d'accès sur le cluster cible. La fonctionnalité gérée utilise les entrées d'accès EKS pour l'accès entre comptes, et non l'hypothèse d'un rôle IAM.

Pour en savoir plus sur la configuration multi-clusters, consultezEnregistrer les clusters cibles.

Temps de synchronisation des applications accru

Si la synchronisation de vos applications prend plus de temps que prévu, suivez les étapes de diagnostic suivantes pour en identifier la cause.

Vérifiez l'heure de la dernière synchronisation

Confirmez le délai en vérifiant la date de dernière synchronisation des applications :

# 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}'

Vérifiez les conditions de candidature

Passez en revue les conditions de candidature concernant les délais de mise en attente de rapprochement :

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

Vérifiez la configuration de TargetRevision

Les applications qui utilisent targetRevision: HEAD invalident le cache du manifeste à chaque validation dans le référentiel, ce qui ralentit les temps de synchronisation :

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

Causes courantes

Atténuations

Applications synchronisées à plusieurs reprises ou désynchronisées

Si votre application se synchronise puis s'exécute immédiatementOutOfSync, ou si elle reste bloquée dans une boucle de synchronisation, cela est généralement dû à une dérive entre ce que Git définit et ce qui existe dans le cluster. Commencez par les diagnostics de base.

Recueillir des informations de diagnostic

# 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
         

La argocd app diff commande est le point de départ le plus utile. Il vous indique exactement quels champs sont à l'origine d'une désynchronisation de l'application.

Self-managed les certificats provoquent une dérive

Les contrôleurs tels que cert-manager, OPA Gatekeeper et KEDA génèrent des certificats lors de l'exécution. Ces valeurs d'exécution ne se trouvent pas dans Git. Argo CD détecte donc une dérive à chaque rapprochement.

Les symptômes sont les suivants :

Pour résoudre ce problème, ajoutez ignoreDifferences les champs concernés et activez-les RespectIgnoreDifferences dans vos options de synchronisation :

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 interrompt les charges de travail qui démarrent lentement

Lorsque cette option selfHeal est activée, Argo CD resynchronise l'application lorsqu'elle détecte une dérive. Si le démarrage de votre charge de travail prend entre 30 et 60 secondes, l'auto-guérison se déclenche avant que la charge de travail ne soit atteinte. Healthy Lorsque cette prune option est activée, les ressources partiellement démarrées peuvent être épuisées.

Pour résoudre ce problème, corrigez d'abord la dérive sous-jacente (voir le scénario du certificat). Si la dérive n'en est pas la cause, pensez à désactiver l'auto-guérison pour les charges de travail que vous gérez exclusivement via Git :

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

ApplicationSet ou des conflits entre propriétaires de ressources

Si deux applications ApplicationSets gèrent la même ressource Kubernetes, Argo CD affiche un. SharedResourceWarning La ressource n'atteint jamais un état stable. Cela se produit généralement lorsqu'un nom de ressource partagée n'est pas défini par environnement ou cluster.

Pour résoudre ce problème :

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

Suppression bloquée dans les finaliseurs de ressources

Si une application est bloquée ou affiche « N objets restant à Terminating supprimer », le resources-finalizer.argocd.argoproj.io finaliseur bloque la suppression jusqu'à ce que toutes les ressources gérées soient supprimées. Une ressource gérée dotée de son propre finaliseur impossible à traiter bloque la suppression indéfiniment.

Pour confirmer, répertoriez les ressources qui ont un horodatage de suppression mais qui n'ont pas été supprimées :

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

Pour résoudre ce problème :

À l'aide de la liste des finaliseurs que la commande précédente a imprimée, définissez dans la liste les finaliseurs que vous souhaitez conserver et omettez uniquement celui qui bloque. Remplacer finalizer-a et finalizer-b par les noms suivants :

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

Si le finaliseur de blocage est le seul sur la ressource, transmettez une liste vide :. --type merge -p '{"metadata":{"finalizers":[]}}'

L'échec de la synchronisation ne permet pas de revenir automatiquement à la même révision

En cas d'échec de la synchronisation avec une révision spécifique, Argo CD ne réessaie pas automatiquement la même révision. Cela se produit généralement en raison d'un défaut manifeste, tel qu'une clé de variable d'environnement dupliquée ComparisonError provenant d'une clé de variable d'environnement.

Confirmez en vérifiant l'état de la demande :

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

Pour résoudre ce problème, corrigez le défaut manifeste dans votre dépôt Git et envoyez un nouveau commit. Vous pouvez également déclencher une synchronisation manuelle :

argocd app sync my-app
         

Le churn des commits de Monorepo déclenche une vaste régénération

Si de nombreuses applications sont HEAD suivies sur le même référentiel, toute validation dans ce référentiel est modifiée HEAD pour toutes les applications. Cela déclenche la régénération du manifeste pour chaque application, même celles dont les fichiers n'ont pas été modifiés. Pour plus d'informations sur la mise en cache targetRevision et la mise en cache, consultez la section « Augmentation du temps de synchronisation des applications » sur cette page.

Pour étendre la régénération aux seuls fichiers utilisés par chaque application, ajoutez l'manifest-generate-pathsannotation suivante :

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

Grâce à cette annotation, Argo CD ne régénère les manifestes que lorsque les fichiers se trouvant sous le chemin spécifié changent. Pour les bibliothèques partagées utilisées entre les applications, vous pouvez spécifier plusieurs chemins séparés par des points-virgules (). ;

Dans la mesure du possible, épinglez targetRevision plutôt le nom ou l'étiquette d'une succursaleHEAD.

Les webhooks par défaut et mutants de Kubernetes provoquent des différences fantômes

Si votre application s'affiche OutOfSync immédiatement après une synchronisation, vérifiez la différence entre les champs que vous n'avez jamais définis (tels que terminationGracePeriodSecondsdnsPolicy, ou/spec/replicas). Le serveur API Kubernetes ou un webhook en mutation a ajouté ces champs au moment de l'application.

Pour résoudre ce problème pour les champs gérés par un autre contrôleur (par exemple /spec/replicas lorsqu'un HPA gère le dimensionnement), ajoutez ignoreDifferences :

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

Pour les champs ajoutés par les webhooks par défaut ou en mutation de Kubernetes, vous pouvez activer le diff côté serveur sur l'application :

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

Server-side diff effectue une application à sec par ressource, ce qui augmente la charge sur le serveur d'API Kubernetes. Testez cette option sur un petit nombre d'applications avant de l'activer à grande échelle.

High-churn ressources appartenant au contrôleur

Certains contrôleurs génèrent un grand nombre de ressources éphémères ou fréquemment mises à jour. Les exemples incluent les objets de nœud Karpenter, les objets d'identité et de point de terminaison Cilium et les rapports de politique Kyverno. Si ces ressources génèrent un volume élevé d'événements de surveillance et entraînent un ralentissement de la synchronisation, vous pouvez réduire la charge en excluant ces types de ressources ou en filtrant les événements de surveillance. Ces modifications nécessitent la configuration du contrôleur au niveau de l'instance.

Sur la fonctionnalité gérée, ouvrez un dossier de AWS support pour demander l'exclusion de ressources ou le filtrage des événements de surveillance pour ces types de ressources.

Bonnes pratiques

Quand contacter AWS Support

Ouvrez un dossier d' AWS assistance dans les situations suivantes :

Incluez les résultats de argocd app get et argocd app diff pour les applications concernées dans votre dossier de support.

Étapes suivantes