Comparaison de la fonctionnalité EKS pour Argo CD à celle d'Argo CD autogéré - Amazon EKS
Différences par rapport à l'Argo CD en amontUtilisation de l'Argo CD CLI avec la fonctionnalité géréeChemin de migrationÉtapes suivantes

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.

Comparaison de la fonctionnalité EKS pour Argo CD à celle d'Argo CD autogéré

La fonctionnalité EKS pour Argo CD fournit une expérience Argo CD entièrement gérée qui s'exécute dans EKS. Pour une comparaison générale des fonctionnalités EKS par rapport aux solutions autogérées, voirConsidérations relatives aux fonctionnalités EKS. Cette rubrique se concentre sur les différences spécifiques à Argo CD, notamment l'authentification, la gestion multi-clusters et la prise en charge des fonctionnalités en amont.

Différences par rapport à l'Argo CD en amont

La fonctionnalité EKS pour Argo CD est basée sur le CD Argo en amont, mais elle diffère en termes d'accès, de configuration et d'intégration aux AWS services.

RBAC et authentification : cette fonctionnalité inclut trois rôles RBAC (administrateur, éditeur, lecteur) et utilise AWS Identity Center pour l'authentification au lieu de l'authentification intégrée d'Argo CD. Configurez les mappages de rôles via le rbacRoleMapping paramètre de la fonctionnalité pour mapper les groupes Identity Center aux rôles Argo CD, et non via Argo CD. argocd-rbac-cm ConfigMap L'interface utilisateur d'Argo CD est hébergée avec sa propre URL directe (trouvez-la dans la console EKS sous l'onglet Capabilities de votre cluster), et l'accès à l'API utilise AWS l'authentification et l'autorisation via IAM.

Configuration du cluster : cette fonctionnalité ne configure pas automatiquement le cluster local ou les hub-and-spoke topologies. Vous configurez vos clusters cibles de déploiement et vos entrées d'accès EKS. Cette fonctionnalité prend uniquement en charge les clusters Amazon EKS en tant que cibles de déploiement utilisant le cluster EKS ARNs (et non le serveur d'API Kubernetes). URLs La fonctionnalité n'ajoute pas automatiquement le cluster local (kubernetes.default.svc) en tant que cible de déploiement. Pour effectuer le déploiement sur le même cluster où la fonctionnalité a été créée, enregistrez explicitement ce cluster à l'aide de son ARN.

Accès aux clusters distants simplifié : cette fonctionnalité simplifie les déploiements multi-clusters en utilisant les entrées d'accès EKS pour accorder un accès Argo CD aux clusters distants, éliminant ainsi le besoin de configurer des rôles IAM pour les comptes de service (IRSA) ou de définir des hypothèses de rôles IAM entre comptes. Cette fonctionnalité fournit également un accès transparent à des clusters EKS entièrement privés sans nécessiter de peering VPC ou de configuration réseau spécialisée. Elle AWS gère automatiquement la connectivité entre la fonctionnalité Argo CD et les clusters distants privés.

Intégration directe des AWS services : la fonctionnalité fournit une intégration directe aux AWS services par le biais des autorisations IAM du rôle de capacité. Vous pouvez CodeCommit référencer des référentiels, des diagrammes ECR Helm et CodeConnections directement dans les ressources de l'application sans créer de configurations de référentiel. Cela simplifie l'authentification et élimine le besoin de gérer des informations d'identification distinctes pour les AWS services. Consultez Configuration de l'accès au référentiel pour plus de détails.

Prise en charge des espaces de noms : la fonctionnalité prend initialement en charge le déploiement d'applications dans un espace de noms unique, que vous spécifiez lors de la création de la fonctionnalité. Support pour les applications dans plusieurs espaces de noms peut être ajouté dans les futures versions.

Fonctionnalités non prises en charge : les fonctionnalités suivantes ne sont pas disponibles dans la fonctionnalité gérée :

  • Plugins de gestion de configuration (CMPs) pour la génération de manifestes personnalisés

  • Scripts Lua personnalisés pour l'évaluation de l'état des ressources (les contrôles de santé intégrés pour les ressources standard sont pris en charge)

  • Le contrôleur des notifications

  • Outil de mise à jour d'images Argo CD

  • Fournisseurs SSO personnalisés (seul AWS Identity Center est pris en charge, y compris l'identité fédérée tierce via AWS Identity Center)

  • Extensions d'interface utilisateur et bannières personnalisées

  • Accès direct à argocd-cmargocd-params, et autres configurations ConfigMaps

Compatibilité : les applications ApplicationSets fonctionnent de la même manière qu'Argo CD en amont, sans aucune modification de vos manifestes. La fonctionnalité utilise les mêmes Kubernetes APIs et CRDs les outils kubectl fonctionnent donc de la même manière. Cette fonctionnalité prend entièrement en charge les applications et ApplicationSets les GitOps flux de travail avec synchronisation automatique, les déploiements multiclusters, les politiques de synchronisation (automatisées, élagage, auto-guérison), les vagues de synchronisation et les hooks, l'évaluation de l'état des ressources Kubernetes standard, les fonctionnalités de restauration, les sources de référentiel Git (HTTPS et SSH), Helm, Kustomize et les manifestes YAML simples, les informations d'identification des GitHub applications, les projets de mutualisation, les exclusions et inclusions de ressources.

Utilisation de l'Argo CD CLI avec la fonctionnalité gérée

L'Argo CD CLI fonctionne de la même manière que l'Argo CD en amont pour la plupart des opérations, mais l'authentification et l'enregistrement du cluster diffèrent.

Conditions préalables

Installez l'Argo CD CLI en suivant les instructions d'installation en amont.

Configuration

Configurez la CLI à l'aide de variables d'environnement :

  1. Obtenez l'URL du serveur Argo CD depuis la console EKS (sous l'onglet Capabilities de votre cluster) ou à l'aide de la AWS CLI :

    export ARGOCD_SERVER=$(aws eks describe-capability \
  --cluster-name my-cluster \
  --capability-name my-argocd \
  --query 'capability.configuration.argoCd.serverUrl' \
  --output text \
  --region region-code)

  2. Générez un jeton de compte depuis l'interface utilisateur d'Argo CD (Paramètres → Comptes → admin → Générer un nouveau jeton), puis définissez-le comme variable d'environnement :

    export ARGOCD_AUTH_TOKEN="your-token-here"
Important

Cette configuration utilise le jeton de compte administrateur pour la configuration initiale et les flux de travail de développement. Pour les cas d'utilisation en production, utilisez des rôles et des jetons adaptés au projet afin de respecter le principe du moindre privilège. Pour plus d'informations sur la configuration des rôles de projet et du RBAC, consultezConfigurer les autorisations d'Argo CD.

  1. Définissez l'option gRPC requise :

    export ARGOCD_OPTS="--grpc-web"

Une fois ces variables d'environnement définies, vous pouvez utiliser l'Argo CD CLI sans la argocd login commande.

Principales différences

La fonctionnalité gérée présente les limites de la CLI suivantes :

  • argocd adminles commandes ne sont pas prises en charge (elles nécessitent un accès direct au pod)

  • argocd loginn'est pas pris en charge (utilisez plutôt des jetons de compte ou de projet)

  • argocd cluster addnécessite l'--aws-cluster-nameindicateur avec l'ARN du cluster EKS

Exemple : enregistrer un cluster

Enregistrez un cluster EKS pour le déploiement d'applications :

# Get the cluster ARN
CLUSTER_ARN=$(aws eks describe-cluster \
  --name my-cluster \
  --query 'cluster.arn' \
  --output text)

# Register the cluster
argocd cluster add $CLUSTER_ARN \
  --aws-cluster-name $CLUSTER_ARN \
  --name in-cluster \
  --project default

Pour la documentation complète de la CLI Argo CD, consultez la référence de la CLI Argo CD.

Chemin de migration

Vous pouvez passer d'un Argo CD autogéré à la fonctionnalité gérée :

  1. Vérifiez la configuration actuelle de votre Argo CD pour détecter les fonctionnalités non prises en charge (contrôleur de notifications CMPs, bilans de santé personnalisés)

  2. Faites évoluer vos contrôleurs de CD Argo autogérés jusqu'à ce qu'il n'y ait plus de répliques

  3. Créez une ressource de capacité Argo CD sur votre cluster

  4. Exportez vos applications existantes ApplicationSets, et AppProjects

  5. Migrer les informations d'identification du référentiel, les secrets du cluster et les modèles d'informations d'identification du référentiel (records)

  6. Si vous utilisez des clés GPG, des certificats TLS ou des hôtes connus SSH, migrez également ces configurations

  7. Mettre à jour destination.server les champs pour utiliser les noms de clusters ou les clusters EKS ARNs

  8. Appliquez-les à l'instance Argo CD gérée

  9. Vérifiez que les applications se synchronisent correctement

  10. Mettez hors service votre installation autogérée d'Argo CD

La fonctionnalité gérée utilise le même CD Argo APIs et les mêmes définitions de ressources, de sorte que vos manifestes existants fonctionnent avec un minimum de modifications.

Étapes suivantes