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 sur 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

Cette rubrique fournit des conseils de dépannage relatifs à la fonctionnalité EKS pour Argo CD, notamment les vérifications de l'état des fonctionnalités, les problèmes de synchronisation des applications, l'authentification des référentiels et les déploiements multiclusters.

La fonctionnalité est ACTIVE mais les applications ne se synchronisent pas

Si la fonctionnalité de votre Argo CD affiche l'ACTIVEétat mais que les applications ne se synchronisent pas, vérifiez l'état de la fonctionnalité et l'état de l'application.

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

Vous pouvez consulter les problèmes liés à l'état et à l'état des fonctionnalités dans la console EKS ou à l'aide de 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

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 jamais les Healthy objectifs, vérifiez l'état des ressources et les événements de l'application.

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

Défaillances d'authentification du référentiel

Si Argo CD ne peut pas accéder à vos référentiels Git, vérifiez la configuration de l'authentification.

Pour les CodeCommit référentiels :

Vérifiez que le rôle de capacité IAM dispose d' CodeCommit autorisations :

# 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 accéder aux référentiels.

Pour les référentiels 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 nom d'utilisateur/mot de passe).

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
      

Problèmes de déploiement multicluster

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 Argo CD Capability 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::[.replaceable]111122223333:role/my-argocd-capability-role
      

Vérifiez les autorisations IAM pour les comptes multiples :

Pour les déploiements entre comptes, vérifiez que le rôle Argo CD Capability 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 du rôle IAM.

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

Étapes suivantes