**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.
# Fonctionnalités d'EKS
**Astuce**
Pour commencer : [créer une fonctionnalité ACK](create-ack-capability.md) \$1 [Créer une fonctionnalité Argo CD \$1 Créer une fonctionnalité](create-argocd-capability.md) [Kro](create-kro-capability.md)
Amazon EKS Capabilities est un ensemble en couches de fonctionnalités de cluster entièrement gérées qui aident à accélérer la rapidité des développeurs et à se libérer de la complexité liée à la création et à la mise à l'échelle avec Kubernetes. Les fonctionnalités EKS sont des fonctionnalités natives de Kubernetes destinées au déploiement continu déclaratif, à la gestion des AWS ressources, ainsi qu'à la création et à l'orchestration des ressources Kubernetes, le tout entièrement géré par. AWS Grâce aux fonctionnalités d'EKS, vous pouvez vous concentrer davantage sur la création et le dimensionnement de vos charges de travail, en vous déchargeant de la charge opérationnelle liée à ces services de plateforme fondamentaux. AWS Ces fonctionnalités s'exécutent au sein d'EKS plutôt que dans vos clusters, ce qui élimine le besoin d'installer, de maintenir et de dimensionner les composants critiques de la plate-forme sur vos nœuds de travail.
Pour commencer, vous pouvez créer une ou plusieurs fonctionnalités EKS sur un cluster EKS nouveau ou existant. Pour ce faire, vous pouvez utiliser la AWS CLI, EKS AWS Management Console APIs, eksctl ou vos outils préférés infrastructure-as-code. Bien que les fonctionnalités EKS soient conçues pour fonctionner ensemble, il s'agit de ressources cloud indépendantes que vous pouvez sélectionner en fonction de votre cas d'utilisation et de vos exigences.
Toutes les versions de Kubernetes prises en charge par EKS sont prises en charge pour les fonctionnalités EKS.
**Note**
Les fonctionnalités EKS sont disponibles dans toutes les régions AWS commerciales où Amazon EKS est disponible. Pour obtenir la liste des régions prises en charge, consultez la section [Points de terminaison et quotas Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) dans le manuel de référence AWS général.
## Fonctionnalités disponibles
### AWS Contrôleurs pour Kubernetes (ACK)
ACK permet de gérer les AWS ressources à l'aide de Kubernetes APIs, ce qui vous permet de créer et de gérer des compartiments S3, des bases de données RDS, des rôles IAM et d'autres AWS ressources à l'aide des ressources personnalisées de Kubernetes. ACK concilie en permanence l'état souhaité avec l'état réel AWS, en corrigeant toute dérive au fil du temps afin de maintenir le bon fonctionnement de votre système et la configuration de vos ressources conformément aux spécifications. Vous pouvez gérer les AWS ressources parallèlement à vos charges de travail Kubernetes à l'aide des mêmes outils et flux de travail, avec la prise en charge de plus de 50 AWS services, dont S3, RDS, DynamoDB et Lambda. ACK prend en charge la gestion des ressources entre comptes et entre régions, permettant ainsi des architectures complexes de gestion de systèmes multi-comptes et multi-clusters. ACK prend en charge les ressources en lecture seule et l'adoption en lecture seule, facilitant ainsi la migration depuis d'autres infrastructures sous forme d'outils de code vers vos systèmes basés sur Kubernetes.
[En savoir plus sur ACK →](ack.md)
### Argo CD
Argo CD implémente un déploiement continu GitOps basé sur le déploiement pour vos applications, en utilisant les référentiels Git comme source fiable pour vos charges de travail et l'état de votre système. Argo CD synchronise automatiquement les ressources des applications avec vos clusters à partir de vos référentiels Git, détectant et corrigeant les dérives pour garantir que les applications déployées correspondent à l'état souhaité. Vous pouvez déployer et gérer des applications sur plusieurs clusters à partir d'une seule instance Argo CD, avec un déploiement automatique à partir des référentiels Git chaque fois que des modifications sont validées. L'utilisation conjointe d'Argo CD et d'ACK fournit un GitOps système de base, simplifiant la gestion des dépendances liées à la charge de travail et prenant en charge les conceptions de systèmes complets, y compris la gestion des clusters et des infrastructures à grande échelle. Argo CD s'intègre à AWS Identity Center pour l'authentification et l'autorisation, et fournit une interface utilisateur Argo hébergée pour visualiser l'état de l'application et l'état de déploiement.
[En savoir plus sur Argo CD →](argocd.md)
### kro (Kube Resource Orchestrator)
kro vous permet de créer des Kubernetes personnalisés APIs qui composent plusieurs ressources en abstractions de haut niveau, permettant aux équipes de la plateforme de définir des modèles réutilisables pour des combinaisons de ressources communes et des éléments de base du cloud. Avec kro, vous pouvez composer Kubernetes et les AWS ressources en abstractions unifiées, en utilisant une syntaxe simple pour permettre des configurations dynamiques et une logique conditionnelle. kro permet aux équipes de plateforme de fournir des fonctionnalités de libre-service avec des garde-fous appropriés, permettant aux développeurs de fournir une infrastructure complexe à l'aide de simples infrastructures spécialement conçues APIs tout en respectant les normes organisationnelles et les meilleures pratiques. les ressources kro sont simplement des ressources Kubernetes et sont spécifiées dans des manifestes Kubernetes qui peuvent être stockés dans Git Git, ou poussé vers OCI- registres compatibles tels qu'Amazon ECR pour une large distribution organisationnelle.
[En savoir plus sur Kro →](kro.md)
## Avantages des fonctionnalités d'EKS
Les fonctionnalités d'EKS sont entièrement gérées AWS, ce qui élimine le besoin d'installation, de maintenance et de mise à l'échelle des services de cluster de base. AWS gère les correctifs de sécurité, les mises à jour et la gestion opérationnelle, ce qui permet à vos équipes de se concentrer sur le développement AWS plutôt que sur les opérations du cluster. Contrairement aux modules complémentaires Kubernetes traditionnels qui consomment les ressources du cluster, les fonctionnalités s'exécutent dans EKS plutôt que sur vos nœuds de travail. Cela libère de la capacité et des ressources du cluster pour vos charges de travail tout en minimisant la charge opérationnelle liée à la gestion des contrôleurs intégrés au cluster et des autres composants de la plate-forme.
Grâce aux fonctionnalités d'EKS, vous pouvez gérer les déploiements, les AWS ressources, les ressources Kubernetes personnalisées et les compositions à l'aide de Kubernetes natifs et d'outils tels que. APIs `kubectl` Toutes les fonctionnalités fonctionnent dans le contexte de vos clusters, détectant et corrigeant automatiquement les dérives de configuration dans les ressources de l'application et de l'infrastructure cloud. Vous pouvez déployer et gérer des ressources sur plusieurs clusters, AWS comptes et régions à partir d'un point de contrôle unique, ce qui simplifie les opérations dans des environnements complexes et distribués.
Les fonctionnalités EKS sont conçues pour les GitOps flux de travail, fournissant une infrastructure déclarative contrôlée par version et une gestion des applications. Les modifications sont transmises par Git au système, fournissant des pistes d'audit, des fonctionnalités de restauration et des flux de travail collaboratifs qui s'intègrent à vos pratiques de développement existantes. Cette approche native de Kubernetes signifie que vous n'avez pas besoin d'utiliser plusieurs outils ou de gérer des infrastructure-as-code systèmes externes à vos clusters, et qu'il existe une seule source fiable à laquelle vous pouvez vous référer. L'état souhaité, défini dans la configuration déclarative Kubernetes contrôlée par version, est continuellement appliqué dans l'ensemble de votre environnement.
## Tarification
Avec EKS Capabilities, il n'y a aucun engagement initial ni aucun frais minimum. Chaque ressource de fonctionnalité vous est facturée pour chaque heure pendant laquelle elle est active sur votre cluster Amazon EKS. Les ressources Kubernetes spécifiques gérées par EKS Capabilities sont également facturées à un taux horaire.
Pour obtenir les informations tarifaires actuelles, consultez la [page de tarification d'Amazon EKS](https://aws.amazon.com/eks/pricing/).
**Astuce**
Vous pouvez utiliser AWS Cost Explorer et Cost and Usage Reports pour suivre les coûts de capacité séparément des autres frais EKS. Vous pouvez étiqueter vos capacités avec le nom du cluster, le type de capacité et d'autres informations à des fins de répartition des coûts.
## Comment fonctionnent les fonctionnalités d'EKS
Chaque fonctionnalité est une AWS ressource que vous créez sur votre cluster EKS. Une fois créée, la fonctionnalité s'exécute dans EKS et est entièrement gérée par AWS.
**Note**
Vous pouvez créer une ressource de capacité de chaque type (Argo CD, ACK et kro) pour un cluster donné. Vous ne pouvez pas créer plusieurs ressources de capacité du même type sur le même cluster.
Vous interagissez avec les fonctionnalités de votre cluster à l'aide de Kubernetes APIs et d'outils standard :
+ `kubectl`À utiliser pour appliquer des ressources personnalisées Kubernetes
+ Utiliser les référentiels Git comme source fiable pour GitOps les flux de travail
Des outils supplémentaires sont pris en charge pour certaines fonctionnalités. Par exemple :
+ Utilisez la CLI Argo CD pour configurer et gérer les référentiels et les clusters dans votre fonctionnalité Argo CD
+ Utilisez l'interface utilisateur d'Argo CD pour visualiser et gérer les applications gérées par votre fonctionnalité Argo CD
Les fonctionnalités sont conçues pour fonctionner ensemble, mais elles sont indépendantes et entièrement activées. Vous pouvez activer une, deux ou les trois fonctionnalités en fonction de vos besoins, et mettre à jour votre configuration en fonction de l'évolution de vos besoins.
Tous les types de calcul EKS sont compatibles avec les fonctionnalités EKS. Pour de plus amples informations, veuillez consulter [Gérer les ressources de calcul à l’aide de nœuds](eks-compute.md).
Pour la configuration de la sécurité et des informations sur les rôles IAM, consultez[Considérations relatives à la sécurité relatives aux fonctionnalités EKS](capabilities-security.md). Pour les modèles d'architecture multi-clusters, voir[Considérations relatives aux fonctionnalités EKS](capabilities-considerations.md).
## Cas d'utilisation courants
**GitOps pour les applications et l'infrastructure**
Utilisez Argo CD pour déployer des applications et des composants opérationnels et ACK pour gérer les configurations de clusters et provisionner l'infrastructure, tous deux à partir de référentiels Git. L'ensemble de votre pile (applications, bases de données, stockage et mise en réseau) est défini sous forme de code et automatiquement déployé.
Exemple : une équipe de développement introduit des modifications dans Git. Argo CD déploie l'application mise à jour et ACK approvisionne une nouvelle base de données RDS avec la configuration correcte. Toutes les modifications sont vérifiables, réversibles et cohérentes dans tous les environnements.
**Ingénierie de plateforme avec libre-service**
Utilisez kro pour créer des ressources personnalisées APIs qui composent les ressources ACK et Kubernetes. Les équipes de la plateforme définissent des modèles approuvés à l'aide de glissières de sécurité. Les équipes chargées des applications utilisent des outils simples et de haut niveau APIs pour approvisionner des stacks complets.
Exemple : une équipe de plateforme crée une API WebApplication « » qui fournit un compartiment de déploiement, de service, d'entrée et S3. Les développeurs utilisent cette API sans avoir besoin de comprendre la complexité ou AWS les autorisations sous-jacentes.
**Gestion des applications multi-clusters**
Utilisez Argo CD pour déployer des applications sur plusieurs clusters EKS dans différentes régions ou comptes. Gérez tous les déploiements à partir d'une seule instance Argo CD avec des politiques et des flux de travail cohérents.
Exemple : déployez la même application sur des clusters de développement, de préparation et de production répartis dans plusieurs régions. Argo CD garantit que chaque environnement reste synchronisé avec la branche Git correspondante.
**Gestion de plusieurs clusters**
Utilisez ACK pour définir et approvisionner des clusters EKS, kro pour personnaliser les configurations de clusters conformément aux normes organisationnelles et Argo CD pour gérer le cycle de vie et la configuration des clusters. Cela permet de gérer les end-to-end clusters depuis leur création jusqu'aux opérations en cours.
Exemple : définissez des clusters EKS à l'aide d'ACK et de kro pour provisionner et gérer l'infrastructure du cluster, en définissant les normes organisationnelles pour le réseau, les politiques de sécurité, les modules complémentaires et autres configurations. Utilisez Argo CD pour créer et gérer en permanence les clusters, les configurations et les mises à jour des versions de Kubernetes au sein de votre flotte en tirant parti de normes cohérentes et d'une gestion automatisée du cycle de vie.
**Migrations et modernisation**
Simplifiez la migration vers EKS grâce au provisionnement des ressources cloud et à des GitOps flux de travail natifs. Utilisez ACK pour adopter les AWS ressources existantes sans les recréer, et Argo CD pour opérationnaliser les déploiements de charges de travail à partir de Git.
Exemple : une équipe qui migre depuis EKS adopte ses bases de données RDS et ses compartiments S3 existants EC2 à l'aide d'ACK, puis utilise Argo CD pour déployer des applications conteneurisées à partir de Git. La voie de migration est claire et les opérations sont normalisées dès le premier jour.
**Démarrage des comptes et des régions**
Automatisez le déploiement de l'infrastructure entre les comptes et les régions en utilisant conjointement Argo CD et ACK. Définissez votre infrastructure sous forme de code dans Git et laissez les fonctionnalités s'occuper du déploiement et de la gestion.
Exemple : une équipe de plateforme gère des référentiels Git définissant les configurations de compte standard, les rôles IAMVPCs, les instances RDS et les stacks de surveillance. Argo CD déploie automatiquement ces configurations sur de nouveaux comptes et régions, garantissant ainsi la cohérence et réduisant le temps de configuration manuelle de plusieurs jours à quelques minutes.
# Utilisation des ressources en matière de capacités
Cette rubrique décrit les opérations courantes de gestion des ressources de capacité pour tous les types de capacités.
## Ressources relatives aux fonctionnalités d'EKS
Les fonctionnalités EKS sont AWS des ressources qui activent les fonctionnalités gérées sur votre cluster Amazon EKS. Les fonctionnalités sont exécutées dans EKS, ce qui élimine le besoin d'installer et de maintenir des contrôleurs et d'autres composants opérationnels sur vos nœuds de travail. Les fonctionnalités sont créées pour un cluster EKS spécifique et restent affiliées à ce cluster pendant tout son cycle de vie.
Chaque ressource de capacité possède :
+ Un nom unique au sein de votre cluster
+ Un type de capacité (ACK, ARGOCD ou KRO)
+ Un Amazon Resource Name (ARN), spécifiant à la fois le nom et le type
+ Un rôle IAM axé sur les capacités
+ Un statut qui indique son état actuel
+ Configuration, à la fois générique et spécifique au type de fonctionnalité
## Comprendre l'état des capacités
Les ressources de capacité ont un statut qui indique leur état actuel. Vous pouvez consulter l'état des fonctionnalités et l'état de santé dans la console EKS ou à l'aide de la AWS CLI.
**Console** :
1. Ouvrez la console Amazon EKS à l'adresse https://console.aws.amazon.com/eks/ home\$1/clusters.
1. Sélectionnez le nom de votre cluster.
1. Choisissez l'onglet **Fonctionnalités** pour afficher l'état de toutes les fonctionnalités.
1. Pour obtenir des informations détaillées sur l'état de santé, cliquez sur l'onglet **Observabilité**, puis sur **Surveiller le cluster**, puis sur l'onglet **Fonctionnalités**.
** AWS CLI** :
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-capability-name
```
### Statuts des capacités
**CRÉATION** : La capacité est en cours de configuration. Vous pouvez quitter la console : la fonctionnalité continuera de se créer en arrière-plan.
**ACTIF** : La fonctionnalité fonctionne et est prête à être utilisée. Si les ressources ne fonctionnent pas comme prévu, vérifiez l'état des ressources et les autorisations IAM. Pour obtenir des conseils, veuillez consulter [Dépannage des fonctionnalités EKS](capabilities-troubleshooting.md).
**MISE À JOUR** : Les modifications de configuration sont en cours d'application. Attendez que le statut revienne à`ACTIVE`.
**SUPPRESSION** : la fonctionnalité est supprimée du cluster.
**CREATE\$1FAILED** : le programme d'installation a rencontré une erreur. Les causes courantes incluent :
+ Politique de confiance des rôles IAM incorrecte ou manquante
+ Le rôle IAM n'existe pas ou n'est pas accessible
+ Problèmes d'accès au cluster
+ Paramètres de configuration non valides
Consultez la section sur l'état des fonctionnalités pour obtenir des informations spécifiques sur les erreurs.
**UPDATE\$1FAILED : La mise à jour de configuration a échoué**. Consultez la section sur l'état des fonctionnalités pour plus de détails et vérifiez les autorisations IAM.
**Astuce**
Pour obtenir des conseils de dépannage détaillés, voir :
[Dépannage des fonctionnalités EKS](capabilities-troubleshooting.md)- Résolution des problèmes généraux liés aux fonctionnalités
[Résoudre les problèmes liés aux fonctionnalités ACK](ack-troubleshooting.md)- Problèmes spécifiques à ACK
[Résoudre les problèmes liés aux fonctionnalités d'Argo CD](argocd-troubleshooting.md)- Problèmes spécifiques à Argo CD
[Résoudre les problèmes liés aux fonctionnalités Kro](kro-troubleshooting.md)- problèmes spécifiques à Kro
## Créez des capacités
Pour créer une fonctionnalité sur votre cluster, consultez les rubriques suivantes :
+ [Création d'une fonctionnalité ACK](create-ack-capability.md)— Créez une fonctionnalité ACK pour gérer les AWS ressources à l'aide de Kubernetes APIs
+ [Création d’une fonctionnalité Argo CD](create-argocd-capability.md)— Création d'une fonctionnalité Argo CD pour GitOps une livraison continue
+ [Création d'une fonctionnalité Kro](create-kro-capability.md)— Créez une capacité KRO pour la composition et l'orchestration des ressources
## Fonctionnalités de la liste
Vous pouvez répertorier toutes les ressources de capacité d'un cluster.
### Console
1. Ouvrez la console Amazon EKS à l'adresse https://console.aws.amazon.com/eks/ home\$1/clusters.
1. Sélectionnez le nom de votre cluster pour ouvrir la page détaillée du cluster.
1. Choisissez l'onglet **Fonctionnalités**.
1. Consultez les ressources relatives aux **capacités sous Fonctionnalités gérées**.
### AWS CLI
Utilisez la `list-capabilities` commande pour afficher toutes les fonctionnalités de votre cluster. Remplacez *region-code* par la AWS région dans laquelle se trouve votre cluster et remplacez *my-cluster* par le nom de votre cluster.
```
aws eks list-capabilities \
--region region-code \
--cluster-name my-cluster
```
```
{
"capabilities": [
{
"capabilityName": "my-ack",
"arn": "arn:aws:eks:us-west-2:111122223333:capability/my-cluster/ack/my-ack/abc123",
"type": "ACK",
"status": "ACTIVE",
"createdAt": "2025-11-02T10:30:00.000000-07:00",
"modifiedAt": "2025-11-02T10:32:15.000000-07:00",
},
{
"capabilityName": "my-kro",
"arn": "arn:aws:eks:us-west-2:111122223333:capability/my-cluster/kro/my-kro/abc123",
"type": "KRO",
"status": "ACTIVE",
"version": "v0.6.3",
"createdAt": "2025-11-02T10:30:00.000000-07:00",
"modifiedAt": "2025-11-02T10:32:15.000000-07:00",
},
{
"capabilityName": "my-argocd",
"arn": "arn:aws:eks:us-west-2:111122223333:capability/my-cluster/argocd/my-argocd/abc123",
"type": "ARGOCD",
"status": "ACTIVE",
"version": "3.1.8-eks-1",
"createdAt": "2025-11-21T08:22:28.486000-05:00",
"modifiedAt": "2025-11-21T08:22:28.486000-05:00"
}
]
}
```
## Décrire une fonctionnalité
Obtenez des informations détaillées sur une fonctionnalité spécifique, notamment sa configuration et son état.
### Console
1. Ouvrez la console Amazon EKS à l'adresse https://console.aws.amazon.com/eks/ home\$1/clusters.
1. Sélectionnez le nom de votre cluster pour ouvrir la page détaillée du cluster.
1. Choisissez l'onglet **Fonctionnalités**.
1. Choisissez la fonctionnalité que vous souhaitez afficher dans la section **Fonctionnalités gérées**.
1. Consultez les détails des fonctionnalités, notamment l'état, la configuration et l'heure de création.
### AWS CLI
Utilisez la `describe-capability` commande pour afficher des informations détaillées. Remplacez *region-code* par la AWS région dans laquelle se trouve votre cluster, remplacez *my-cluster* par le nom de votre cluster et remplacez par *capability-name* le nom de la fonctionnalité (ack, argocd ou kro).
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name capability-name
```
**Exemple de sortie :**
```
{
"capability": {
"capabilityName": "my-ack",
"capabilityArn": "arn:aws:eks:us-west-2:111122223333:capability/my-cluster/ack/my-ack/abc123",
"clusterName": "my-cluster",
"type": "ACK",
"roleArn": "arn:aws:iam::111122223333:role/AmazonEKSCapabilityACKRole",
"status": "ACTIVE",
"configuration": {},
"tags": {},
"health": {
"issues": []
},
"createdAt": "2025-11-19T17:11:30.242000-05:00",
"modifiedAt": "2025-11-19T17:11:30.242000-05:00",
"deletePropagationPolicy": "RETAIN"
}
}
```
## Mettre à jour la configuration d'une fonctionnalité
Vous pouvez mettre à jour certains aspects de la configuration d'une fonctionnalité après sa création. Les options de configuration spécifiques varient en fonction du type de fonctionnalité.
**Note**
Les ressources des fonctionnalités d'EKS sont entièrement gérées, y compris les correctifs et les mises à jour de version. La mise à jour d'une fonctionnalité met à jour la configuration des ressources et n'entraîne pas de mise à jour de version des composants de la fonctionnalité gérée.
### AWS CLI
Utilisez la `update-capability` commande pour modifier une fonctionnalité :
```
aws eks update-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name capability-name \
--role-arn arn:aws:iam::[.replaceable]111122223333:role/NewCapabilityRole
```
**Note**
Les propriétés des fonctionnalités ne peuvent pas toutes être mises à jour après leur création. Reportez-vous à la documentation spécifique aux fonctionnalités pour plus de détails sur ce qui peut être modifié.
## Supprimer une fonctionnalité
Lorsque vous n'avez plus besoin d'une fonctionnalité sur votre cluster, vous pouvez supprimer la ressource de capacité.
**Important**
**Supprimez les ressources du cluster avant de supprimer la fonctionnalité.**
La suppression d'une ressource de capacité ne supprime pas automatiquement les ressources créées par le biais de cette fonctionnalité :
Toutes les définitions de ressources personnalisées Kubernetes (CRDs) restent installées dans votre cluster.
Les ressources ACK restent dans votre cluster et les AWS ressources correspondantes restent dans votre compte
Les applications Argo CD et leurs ressources Kubernetes restent dans votre cluster
kro ResourceGraphDefinitions et les instances restent dans votre cluster
Vous devez supprimer ces ressources avant de supprimer la fonctionnalité afin d'éviter les ressources orphelines.
Vous pouvez éventuellement choisir de conserver les AWS ressources associées aux ressources ACK Kubernetes. Voir les [considérations relatives à l'ACK](ack-considerations.md)
### Console
1. Ouvrez la console Amazon EKS à l'adresse https://console.aws.amazon.com/eks/ home\$1/clusters.
1. Sélectionnez le nom de votre cluster pour ouvrir la page détaillée du cluster.
1. Choisissez l'onglet **Fonctionnalités**.
1. Sélectionnez la fonctionnalité que vous souhaitez supprimer dans la liste des **fonctionnalités gérées**.
1. Choisissez la **fonctionnalité Supprimer**.
1. Dans la boîte de dialogue de confirmation, tapez le nom de la fonctionnalité pour confirmer la suppression.
1. Sélectionnez **Delete (Supprimer)**.
### AWS CLI
Utilisez la `delete-capability` commande pour supprimer une ressource de capacité :
Remplacez *region-code* par la AWS région dans laquelle se trouve votre cluster, remplacez *my-cluster* par le nom de votre cluster et remplacez *capability-name* par le nom de la fonctionnalité à supprimer.
```
aws eks delete-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name capability-name
```
## Étapes suivantes
+ [Capacités : ressources Kubernetes](capability-kubernetes-resources.md)— Découvrez les ressources Kubernetes fournies par chaque type de fonctionnalité
+ [Concepts d'ACK](ack-concepts.md)— Comprendre les concepts ACK et le cycle de vie des ressources
+ [Travailler avec Argo CD](working-with-argocd.md)— Utilisation des fonctionnalités d'Argo CD pour GitOps les flux de travail
+ [concepts kro](kro-concepts.md)— Comprendre les concepts Kro et la composition des ressources
# Capacités : ressources Kubernetes
Une fois que vous avez activé une fonctionnalité sur votre cluster, vous interagissez le plus souvent avec elle en créant et en gérant des ressources personnalisées Kubernetes dans votre cluster. Chaque fonctionnalité fournit son propre ensemble de définitions de ressources personnalisées (CRDs) qui étendent l'API Kubernetes avec des fonctionnalités spécifiques aux fonctionnalités.
## Ressources sur Argo CD
Lorsque vous activez la fonctionnalité Argo CD, vous pouvez créer et gérer les ressources Kubernetes suivantes :
**Application**
Définit un déploiement depuis un dépôt Git vers un cluster cible. `Application`les ressources spécifient le référentiel source, l'espace de noms cible et la politique de synchronisation. Vous pouvez créer jusqu'à 1 000 `Application` ressources par instance de fonctionnalité Argo CD.
**ApplicationSet**
Génère plusieurs `Application` ressources à partir de modèles, permettant ainsi des déploiements multi-clusters et multi-environnements. `ApplicationSet`les ressources utilisent des générateurs pour créer `Application` des ressources dynamiquement en fonction de listes de clusters, de répertoires Git ou d'autres sources.
**AppProject**
Fournit un regroupement logique et un contrôle d'accès pour les `Application` ressources. `AppProject`les ressources définissent les référentiels, les clusters et les espaces de noms que les `Application` ressources peuvent utiliser, ce qui permet la mutualisation et les limites de sécurité.
Exemple `Application` de ressource :
```
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-app
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/org/repo
targetRevision: main
path: manifests
destination:
server: https://kubernetes.default.svc
namespace: production
```
Pour plus d'informations sur les ressources et les concepts d'Argo CD, consultez[Concepts d'Argo CD](argocd-concepts.md).
## ressources kro
Lorsque vous activez la fonctionnalité Kro, vous pouvez créer et gérer les ressources Kubernetes suivantes :
**ResourceGraphDefinition (RGD)**
Définit une API personnalisée qui compose plusieurs Kubernetes et AWS ressources dans une abstraction de niveau supérieur. Les équipes de la plateforme créent `ResourceGraphDefinition` des ressources pour fournir des modèles réutilisables avec des glissières de sécurité.
**Instances de ressources personnalisées**
Après avoir créé une `ResourceGraphDefinition` ressource, vous pouvez créer des instances de l'API personnalisée définie par le`ResourceGraphDefinition`. kro crée et gère automatiquement les ressources spécifiées dans le`ResourceGraphDefinition`.
Exemple `ResourceGraphDefinition` de ressource :
```
apiVersion: kro.run/v1alpha1
kind: ResourceGraphDefinition
metadata:
name: web-application
spec:
schema:
apiVersion: v1alpha1
kind: WebApplication
spec:
name: string
replicas: integer
resources:
- id: deployment
template:
apiVersion: apps/v1
kind: Deployment
# ... deployment spec
- id: service
template:
apiVersion: v1
kind: Service
# ... service spec
```
Exemple d'`WebApplication`instance :
```
apiVersion: v1alpha1
kind: WebApplication
metadata:
name: my-web-app
namespace: default
spec:
name: my-web-app
replicas: 3
```
Lorsque vous appliquez cette instance, kro crée automatiquement les `Service` ressources `Deployment` et définies dans le`ResourceGraphDefinition`.
Pour plus d'informations sur les ressources et les concepts de Kro, consultez[concepts kro](kro-concepts.md).
## Ressources de l'ACK
Lorsque vous activez la fonctionnalité ACK, vous pouvez créer et gérer des ressources à l'aide AWS des ressources personnalisées de Kubernetes. ACK en fournit plus de 200 CRDs pour plus de 50 AWS services, ce qui vous permet de définir AWS des ressources parallèlement à vos charges de travail Kubernetes et de gérer des ressources d' AWS infrastructure dédiées avec Kubernetes.
Exemples de ressources ACK :
**S3 Bucket**
`Bucket`les ressources créent et gèrent les compartiments Amazon S3 avec des politiques de versionnement, de chiffrement et de cycle de vie.
**RDS DBInstance**
`DBInstance`provisionner les ressources et gérer les instances de base de données Amazon RDS avec des sauvegardes et des fenêtres de maintenance automatisées.
**Tableau DynamoDB**
`Table`les ressources créent et gèrent des tables DynamoDB avec une capacité provisionnée ou à la demande.
**IAM Role**
`Role`les ressources définissent les rôles IAM avec des politiques de confiance et des politiques d'autorisation pour l'accès aux AWS services.
**Fonction Lambda**
`Function`les ressources créent et gèrent les fonctions Lambda avec la configuration du code, de l'exécution et des rôles d'exécution.
Exemple de spécification d'une `Bucket` ressource :
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: my-app-bucket
spec:
name: my-unique-bucket-name-12345
versioning:
status: Enabled
encryption:
rules:
- applyServerSideEncryptionByDefault:
sseAlgorithm: AES256
```
Pour plus d'informations sur les ressources et les concepts d'ACK, consultez[Concepts d'ACK](ack-concepts.md).
## Limites des ressources
Les capacités EKS sont soumises aux limites de ressources suivantes :
**Limites d'utilisation du CD Argo** :
+ 1 000 `Application` ressources maximum par instance de capacité Argo CD
+ Maximum de 100 clusters distants configurés par instance de capacité Argo CD
**Limites de configuration des ressources** :
+ 150 ressources Kubernetes maximum par `Application` ressource dans Argo CD
+ 64 ressources Kubernetes maximum par in kro `ResourceGraphDefinition`
**Note**
Ces limites s'appliquent au nombre de ressources gérées par chaque instance de fonctionnalité. Si vous avez besoin de limites plus élevées, vous pouvez déployer des fonctionnalités sur plusieurs clusters.
## Étapes suivantes
Pour les tâches spécifiques aux fonctionnalités et la configuration avancée, consultez les rubriques suivantes :
+ [Concepts d'ACK](ack-concepts.md)— Comprendre les concepts ACK et le cycle de vie des ressources
+ [Travailler avec Argo CD](working-with-argocd.md)— Utilisation des fonctionnalités d'Argo CD pour GitOps les flux de travail
+ [concepts kro](kro-concepts.md)— Comprendre les concepts Kro et la composition des ressources
# Considérations relatives aux fonctionnalités EKS
Cette rubrique aborde les considérations importantes relatives à l'utilisation des fonctionnalités EKS, notamment la conception du contrôle d'accès, le choix entre les fonctionnalités EKS et les solutions autogérées, les modèles architecturaux pour les déploiements multiclusters et les meilleures pratiques opérationnelles.
## Fonctionnalité : rôles IAM et Kubernetes RBAC
Chaque ressource de capacité EKS possède un rôle IAM de fonctionnalité configuré. Le rôle de capacité est utilisé pour accorder des autorisations de AWS service permettant aux fonctionnalités EKS d'agir en votre nom. Par exemple, pour utiliser la fonctionnalité EKS pour ACK afin de gérer les compartiments Amazon S3, vous devez accorder à cette fonctionnalité des autorisations administratives lui permettant de créer et de gérer des compartiments.
Une fois la fonctionnalité configurée, les ressources S3 dans AWS peuvent être créées et gérées avec les ressources personnalisées Kubernetes de votre cluster. Kubernetes RBAC est le mécanisme de contrôle d'accès intégré au cluster qui permet de déterminer quels utilisateurs et groupes peuvent créer et gérer ces ressources personnalisées. Par exemple, accordez à des utilisateurs et à des groupes Kubernetes RBAC spécifiques des autorisations pour créer et gérer des `Bucket` ressources dans les espaces de noms de votre choix.
Ainsi, IAM et Kubernetes RBAC sont les deux moitiés du système de contrôle d' end-to-endaccès qui régit les autorisations liées aux capacités et aux ressources d'EKS. Il est important de concevoir la bonne combinaison d'autorisations IAM et de politiques d'accès RBAC pour votre cas d'utilisation.
Pour plus d'informations sur les fonctionnalités, les rôles IAM et les autorisations Kubernetes, consultez. [Considérations relatives à la sécurité relatives aux fonctionnalités EKS](capabilities-security.md)
## Modèles d'architecture multi-clusters
Lorsque vous déployez des fonctionnalités sur plusieurs clusters, tenez compte des modèles architecturaux courants suivants :
**Hub and Spoke avec gestion centralisée**
Exécutez les trois fonctionnalités dans un cluster géré de manière centralisée pour orchestrer les charges de travail et gérer l'infrastructure cloud sur plusieurs clusters de charge de travail.
+ Argo CD sur le cluster de gestion déploie des applications sur des clusters de charge de travail situés dans différentes régions ou comptes
+ ACK sur le cluster de gestion fournit des AWS ressources (RDS, S3, IAM) pour tous les clusters
+ kro sur le cluster de gestion crée des abstractions de plate-forme portables qui fonctionnent sur tous les clusters
Ce modèle centralise la gestion de la charge de travail et de l'infrastructure cloud, et peut simplifier les opérations pour les entreprises qui gèrent de nombreux clusters.
**Décentralisé GitOps**
Les charges de travail et l'infrastructure cloud sont gérées par des fonctionnalités du même cluster sur lequel les charges de travail sont exécutées.
+ Argo CD gère les ressources de l'application sur le cluster local.
+ Les ressources ACK sont utilisées pour les besoins des clusters et des charges de travail.
+ les abstractions de la plateforme kro sont installées et orchestrent les ressources locales.
Ce modèle décentralise les opérations, les équipes gérant leurs propres services de plateforme dédiés dans un ou plusieurs clusters.
**Déploiement de Hub and Spoke avec Hybrid ACK**
Combinez des modèles centralisés et décentralisés, avec des déploiements d'applications centralisés et une gestion des ressources en fonction du périmètre et de la propriété.
+ Cluster central :
+ Argo CD gère les GitOps déploiements vers le cluster local et tous les clusters de charge de travail distants
+ ACK est utilisé sur le cluster de gestion pour les ressources administrées (bases de données de production, rôles IAM,) VPCs
+ kro est utilisé sur le cluster de gestion pour les abstractions de plateforme réutilisables
+ Clusters de rayons :
+ Les charges de travail sont gérées via Argo CD sur le cluster centralisé
+ ACK est utilisé localement pour les ressources limitées à la charge de travail (compartiments S3, instances, ElastiCache files d'attente SQS)
+ kro est utilisé localement pour les compositions de ressources et les modèles de blocs de construction
Ce schéma distingue les préoccupations : les équipes chargées des plateformes gèrent les infrastructures critiques de manière centralisée sur des clusters de gestion, y compris éventuellement des clusters de charge de travail, tandis que les équipes chargées des applications spécifient et gèrent les ressources cloud parallèlement aux charges de travail.
**Choisir un motif**
Tenez compte des facteurs suivants lors du choix d'une architecture :
+ **Structure organisationnelle** : les équipes centralisées privilégient les modèles de hub ; les équipes décentralisées peuvent préférer les capacités par cluster
+ **Étendue des ressources** : les ressources réservées aux administrateurs (bases de données, IAM) bénéficient souvent d'une gestion centralisée ; les ressources de charge de travail (compartiments, files d'attente) peuvent être gérées localement
+ **Libre-service** : les équipes centralisées de la plateforme peuvent créer et distribuer des ressources personnalisées prescriptives afin de permettre un libre-service sécurisé des ressources cloud pour les besoins de charge de travail courants
+ **Gestion du parc de** clusters : les clusters de gestion centralisée fournissent un plan de contrôle appartenant au client pour la gestion du parc de clusters EKS, ainsi que d'autres ressources destinées aux administrateurs
+ **Exigences de conformité** : certaines organisations ont besoin d'un contrôle centralisé pour l'audit et la gouvernance
+ **Complexité opérationnelle : la** diminution du nombre d'instances de capacité simplifie les opérations mais peut créer des goulots d'étranglement
**Note**
Vous pouvez commencer avec un modèle et évoluer vers un autre au fur et à mesure que votre plateforme mûrit. Les fonctionnalités sont indépendantes : vous pouvez les déployer différemment entre les clusters en fonction de vos besoins.
## Comparaison des fonctionnalités d'EKS avec les solutions autogérées
Les fonctionnalités EKS fournissent des expériences entièrement gérées pour les outils et contrôleurs Kubernetes les plus courants qui s'exécutent dans EKS. Cela diffère des solutions autogérées, que vous installez et exploitez dans votre cluster.
### Principales différences
**Déploiement et gestion**
AWS gère entièrement les fonctionnalités EKS sans qu'aucune installation, configuration ou maintenance des composants logiciels ne soit requise. AWS installe et gère automatiquement toutes les définitions de ressources personnalisées Kubernetes (CRDs) requises dans le cluster.
Avec les solutions autogérées, vous installez et configurez un logiciel de cluster à l'aide de graphiques Helm, de kubectl ou d'autres opérateurs. Vous avez le contrôle total du cycle de vie des logiciels et de la configuration d'exécution de vos solutions autogérées, en fournissant des personnalisations à tous les niveaux de la solution.
**Exploitation et maintenance**
AWS gère les correctifs et autres opérations du cycle de vie des logiciels pour EKS Capabilities, avec des mises à jour automatiques et des correctifs de sécurité. Les fonctionnalités EKS sont intégrées à des AWS fonctionnalités pour des configurations rationalisées, offrent une haute disponibilité et une tolérance aux pannes intégrées, et éliminent le dépannage des charges de travail des contrôleurs au sein du cluster.
Les solutions autogérées vous obligent à surveiller l'état de santé et les journaux des composants, à appliquer des correctifs de sécurité et des mises à jour de version, à configurer la haute disponibilité avec plusieurs répliques et des budgets d'interruption des pods, à résoudre les problèmes de charge de travail des contrôleurs et à gérer les versions et les versions. Vous avez le contrôle total de vos déploiements, mais cela nécessite souvent des solutions sur mesure pour l'accès aux clusters privés et d'autres intégrations qui doivent être conformes aux normes organisationnelles et aux exigences de conformité en matière de sécurité.
**Consommation de ressources**
Les fonctionnalités EKS s'exécutent dans EKS et hors de vos clusters, libérant ainsi des ressources de nœud et de cluster. Les fonctionnalités n'utilisent pas les ressources de charge de travail du cluster, ne consomment ni le processeur ni la mémoire de vos nœuds de travail, évoluent automatiquement et ont un impact minimal sur la planification de la capacité du cluster.
Les solutions autogérées exécutent des contrôleurs et d'autres composants sur vos nœuds de travail, consommant ainsi directement les ressources des nœuds de travail IPs, du cluster et d'autres ressources du cluster. La gestion des services de cluster nécessite une planification des capacités pour leurs charges de travail, ainsi que la planification et la configuration des demandes de ressources et des limites afin de gérer les exigences de scalabilité et de haute disponibilité.
**Support des fonctionnalités**
En tant que fonctionnalités de service entièrement gérées, les fonctionnalités EKS Capabilities sont, par nature, bien ancrées par rapport aux solutions autogérées. Bien que les fonctionnalités soient compatibles avec la plupart des fonctionnalités et des cas d'utilisation, il y aura une différence de couverture par rapport aux solutions autogérées.
Avec les solutions autogérées, vous contrôlez entièrement la configuration, les fonctionnalités optionnelles et les autres aspects des fonctionnalités de votre logiciel. Vous pouvez choisir d'exécuter vos propres images personnalisées, de personnaliser tous les aspects de la configuration et de contrôler entièrement les fonctionnalités de votre solution autogérée.
**Considérations relatives aux coûts**
Chaque ressource de capacité EKS a un coût horaire associé, qui varie en fonction du type de capacité. Les ressources du cluster gérées par cette fonctionnalité ont également un coût horaire associé à leur propre tarification. Pour plus d’informations, consultez les [tarifs Amazon EKS](https://aws.amazon.com/eks/pricing/).
Les solutions autogérées n'ont aucun coût direct lié aux AWS frais, mais vous payez pour les ressources de calcul du cluster utilisées par les contrôleurs et les charges de travail associées. Au-delà de la consommation des ressources des nœuds et des clusters, le coût total de possession des solutions autogérées inclut les frais d'exploitation et les dépenses de maintenance, de dépannage et de support.
### Choisir entre les fonctionnalités EKS et les solutions autogérées
**Capacités d'EKS** Envisagez ce choix lorsque vous souhaitez réduire les frais opérationnels et vous concentrer sur la valeur différenciée de vos logiciels et systèmes, plutôt que sur les opérations de plate-forme de cluster pour répondre à des exigences de base. Utilisez les fonctionnalités EKS lorsque vous souhaitez minimiser la charge opérationnelle liée aux correctifs de sécurité et à la gestion du cycle de vie des logiciels, libérer des ressources de nœuds et de clusters pour les charges de travail des applications, simplifier la configuration et la gestion de la sécurité, et bénéficier d'une couverture de AWS support. Les fonctionnalités EKS sont idéales pour la plupart des cas d'utilisation en production et constituent l'approche recommandée pour les nouveaux déploiements.
**Solutions autogérées** Envisagez ce choix lorsque vous avez besoin de versions spécifiques de l'API de ressources Kubernetes, de versions de contrôleurs personnalisées, de systèmes d'automatisation et d'outils existants basés sur des déploiements autogérés ou lorsque vous avez besoin d'une personnalisation approfondie des configurations d'exécution des contrôleurs. Les solutions autogérées offrent de la flexibilité pour les cas d'utilisation spécialisés et vous permettent de contrôler totalement votre déploiement et votre configuration d'exécution.
**Note**
Les fonctionnalités EKS peuvent coexister dans votre cluster avec des solutions autogérées, et des migrations par étapes sont possibles.
### Comparaisons spécifiques aux capacités
Pour des comparaisons détaillées, notamment les fonctionnalités spécifiques aux capacités, les différences en amont et les chemins de migration, voir :
+ [Comparaison de la capacité EKS pour ACK à une solution ACK autogérée](ack-comparison.md)
+ [Comparaison de la fonctionnalité EKS pour Argo CD à celle d'Argo CD autogéré](argocd-comparison.md)
+ [Comparaison entre la capacité EKS pour kro et celle pour kro autogérée](kro-comparison.md)
# Déployez AWS des ressources depuis Kubernetes avec AWS Controllers for Kubernetes (ACK)
AWS Controllers for Kubernetes (ACK) vous permet de définir et de gérer les ressources de AWS service directement depuis Kubernetes. Avec AWS Controllers for Kubernetes (ACK), vous pouvez gérer les ressources de charge de travail et l'infrastructure cloud à l'aide de ressources personnalisées Kubernetes, parallèlement aux charges de travail de vos applications à l'aide de Kubernetes et d'outils Kubernetes familiers. APIs
Grâce aux fonctionnalités d'EKS, ACK est entièrement géré par AWS, ce qui élimine le besoin d'installer, de maintenir et de dimensionner les contrôleurs ACK sur vos clusters.
## Comment fonctionne ACK
ACK traduit les spécifications de ressources personnalisées de Kubernetes en AWS appels d'API. Lorsque vous créez, mettez à jour ou supprimez une ressource personnalisée Kubernetes représentant une ressource de AWS service, ACK effectue les appels d' AWS API requis pour créer, mettre à jour ou supprimer la ressource. AWS
Chaque AWS ressource prise en charge par ACK possède sa propre définition de ressource personnalisée (CRD) qui définit le schéma de l'API Kubernetes pour spécifier sa configuration. Par exemple, ACK fournit CRDs S3, notamment des compartiments, des politiques de compartiment et d'autres ressources S3.
ACK concilie en permanence l'état de vos AWS ressources avec l'état souhaité défini dans vos ressources personnalisées Kubernetes. Si une ressource s'écarte de son état souhaité, ACK le détecte et prend des mesures correctives pour la remettre dans son alignement. Les modifications apportées aux ressources Kubernetes se répercutent immédiatement sur l'état AWS des ressources, tandis que la détection passive des dérives et la correction des modifications des AWS ressources en amont peuvent prendre jusqu'à 10 heures (période de resynchronisation), mais se produisent généralement bien plus tôt.
**Exemple de manifeste de ressources du compartiment S3**
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: my-ack-bucket
spec:
name: my-unique-bucket-name
```
Lorsque vous appliquez cette ressource personnalisée à votre cluster, ACK crée un compartiment Amazon S3 dans votre compte s'il n'existe pas encore. Les modifications ultérieures apportées à cette ressource, par exemple en spécifiant un niveau de stockage autre que celui par défaut ou en ajoutant une politique, seront appliquées à la ressource S3 dans AWS. Lorsque cette ressource est supprimée du cluster, le compartiment S3 AWS est supprimé par défaut.
## Avantages de l'ACK
ACK fournit une gestion des AWS ressources native de Kubernetes, vous permettant de gérer les AWS ressources en utilisant les mêmes Kubernetes APIs et les mêmes outils que ceux que vous utilisez pour vos applications. Cette approche unifiée simplifie le flux de travail de gestion de votre infrastructure en éliminant le besoin de passer d'un outil à l'autre ou d'apprendre à utiliser infrastructure-as-code des systèmes distincts. Vous définissez vos AWS ressources de manière déclarative dans les manifestes Kubernetes, en activant les GitOps flux de travail et l'infrastructure en tant que pratiques de code qui s'intègrent parfaitement à vos processus de développement existants.
ACK concilie en permanence l'état souhaité de vos AWS ressources avec leur état réel, en corrigeant les dérives et en garantissant la cohérence au sein de votre infrastructure. Ce rapprochement continu signifie que les out-of-band modifications impératives apportées aux AWS ressources sont automatiquement annulées pour correspondre à votre configuration déclarée, préservant ainsi l'intégrité de votre infrastructure sous forme de code. Vous pouvez configurer ACK pour gérer les ressources sur plusieurs AWS comptes et régions, en activant des architectures multicomptes complexes sans outils supplémentaires.
Pour les entreprises qui migrent depuis d'autres outils de gestion d'infrastructure, ACK prend en charge l'adoption des ressources, ce qui vous permet de placer les AWS ressources existantes sous la gestion d'ACK sans les recréer. ACK fournit également des ressources en lecture seule pour l'observation AWS des ressources sans accès aux modifications, ainsi que des annotations pour éventuellement conserver les AWS ressources même lorsque la ressource Kubernetes est supprimée du cluster.
Pour en savoir plus et commencer à utiliser la fonctionnalité EKS pour ACK, consultez [Concepts d'ACK](ack-concepts.md) et[Considérations relatives à l'ACK pour EKS](ack-considerations.md).
## AWS Services pris en charge
ACK prend en charge un large éventail de AWS services, y compris, mais sans s'y limiter :
+ Amazon EC2
+ Amazon S3
+ Amazon RDS
+ Amazon DynamoDB
+ Amazon ElastiCache
+ Amazon EKS
+ Amazon SQS
+ Amazon SNS
+ AWS Lambda
+ AWS IAM
Tous les AWS services répertoriés comme généralement disponibles en amont sont pris en charge par la fonctionnalité EKS pour ACK. Consultez la [liste complète des AWS services pris en charge](https://aws-controllers-k8s.github.io/community/docs/community/services/) pour plus de détails.
## Intégration avec d'autres fonctionnalités gérées par EKS
ACK s'intègre aux autres fonctionnalités gérées par EKS.
+ **Argo CD** : utilisez Argo CD pour gérer le déploiement des ressources ACK sur plusieurs clusters, en activant les GitOps flux de travail pour votre AWS infrastructure.
+ ACK étend les avantages de l' GitOps association avec ArgoCD, mais ACK ne nécessite pas d'intégration avec git.
+ **kro (Kube Resource Orchestrator)** : utilisez kro pour composer des ressources complexes à partir de ressources ACK, en créant des abstractions de haut niveau qui simplifient la gestion des ressources.
+ Vous pouvez créer des ressources personnalisées composites avec kro qui définissent à la fois les ressources Kubernetes et les ressources. AWS Les membres de l'équipe peuvent utiliser ces ressources personnalisées pour déployer rapidement des applications complexes.
## Débuter avec ACK
Pour commencer à utiliser la fonctionnalité EKS pour ACK :
1. Créez et configurez un rôle de capacité IAM avec les autorisations nécessaires pour qu'ACK gère les AWS ressources en votre nom.
1. [Créez une ressource de capacité ACK](create-ack-capability.md) sur votre cluster EKS via la AWS console, la AWS CLI ou votre infrastructure préférée en tant qu'outil de code.
1. Appliquez des ressources personnalisées Kubernetes à votre cluster pour commencer à gérer vos AWS ressources dans Kubernetes.
# Création d'une fonctionnalité ACK
Ce chapitre explique comment créer une fonctionnalité ACK sur votre cluster Amazon EKS.
## Conditions préalables
Avant de créer une fonctionnalité ACK, assurez-vous d'avoir :
+ Un cluster Amazon EKS
+ Un rôle de capacité IAM avec des autorisations permettant à ACK de gérer les ressources AWS
+ Autorisations IAM suffisantes pour créer des ressources de capacités sur les clusters EKS
+ L'outil CLI approprié installé et configuré, ou l'accès à la console EKS
Pour obtenir des instructions sur la création du rôle de capacité IAM, consultez[Fonctionnalité Amazon EKS : rôle IAM](capability-role.md).
**Important**
ACK est une fonctionnalité de gestion d'infrastructure qui permet de créer, de modifier et de supprimer AWS des ressources. Il s'agit d'une fonctionnalité réservée aux administrateurs qui doit être soigneusement contrôlée. Toute personne autorisée à créer des ressources Kubernetes dans votre cluster peut créer efficacement des AWS ressources via ACK, sous réserve des autorisations du rôle de capacité IAM. Le rôle de capacité IAM que vous fournissez détermine les AWS ressources qu'ACK peut créer et gérer. Pour obtenir des conseils sur la création d'un rôle approprié avec des autorisations de moindre privilège, consultez [Fonctionnalité Amazon EKS : rôle IAM](capability-role.md) et. [Considérations relatives à la sécurité relatives aux fonctionnalités EKS](capabilities-security.md)
## Choisissez votre outil
Vous pouvez créer une fonctionnalité ACK à l'aide de la AWS Management Console AWS CLI ou de eksctl :
+ [Création d'une fonctionnalité ACK à l'aide de la console](ack-create-console.md)- Utilisez la console pour une expérience guidée
+ [Création d'une fonctionnalité ACK à l'aide de la AWS CLI](ack-create-cli.md)- Utilisez la AWS CLI pour la création de scripts et l'automatisation
+ [Création d'une capacité ACK à l'aide de eksctl](ack-create-eksctl.md)- Utilisez eksctl pour une expérience native de Kubernetes
## Que se passe-t-il lorsque vous créez une fonctionnalité ACK ?
Lorsque vous créez une fonctionnalité ACK :
1. EKS crée le service de capacité ACK et le configure pour surveiller et gérer les ressources de votre cluster
1. Des définitions de ressources personnalisées (CRDs) sont installées dans votre cluster
1. Une entrée d'accès est automatiquement créée pour votre rôle de capacité IAM avec des politiques d'entrée d'accès spécifiques aux fonctionnalités qui accordent des autorisations Kubernetes de base (voir) [Considérations relatives à la sécurité relatives aux fonctionnalités EKS](capabilities-security.md)
1. La fonctionnalité assume le rôle de capacité IAM que vous fournissez.
1. ACK commence à surveiller ses ressources personnalisées dans votre cluster
1. L'état de capacité passe de `CREATING` à `ACTIVE`
Une fois active, vous pouvez créer des ressources personnalisées ACK dans votre cluster pour gérer les AWS ressources.
**Note**
L'entrée d'accès créée automatiquement inclut celle `AmazonEKSACKPolicy` qui accorde à ACK les autorisations nécessaires pour gérer les AWS ressources. Certaines ressources ACK qui font référence à des secrets Kubernetes (telles que les bases de données RDS avec mots de passe) nécessitent des politiques d'accès supplémentaires. Pour en savoir plus sur les entrées d'accès et comment configurer des autorisations supplémentaires, consultez[Considérations relatives à la sécurité relatives aux fonctionnalités EKS](capabilities-security.md).
## Étapes suivantes
Après avoir créé la fonctionnalité ACK :
+ [Concepts d'ACK](ack-concepts.md)- Comprenez les concepts ACK et commencez à utiliser les AWS ressources
+ [Concepts d'ACK](ack-concepts.md)- En savoir plus sur le rapprochement, les exportations sur le terrain et les modèles d'adoption des ressources
+ [Configurer les autorisations ACK](ack-permissions.md)- Configurer les autorisations IAM et les modèles multi-comptes
# Création d'une fonctionnalité ACK à l'aide de la console
Cette rubrique décrit comment créer une fonctionnalité AWS Controllers for Kubernetes (ACK) à l'aide du. AWS Management Console
## Création de la fonctionnalité ACK
1. Ouvrez la console Amazon EKS à l'adresse https://console.aws.amazon.com/eks/ home\$1/clusters.
1. Sélectionnez le nom de votre cluster pour ouvrir la page détaillée du cluster.
1. Choisissez l'onglet **Fonctionnalités**.
1. Dans le menu de navigation de gauche, choisissez ** AWS Controllers for Kubernetes (ACK).**
1. Choisissez **Create AWS Controllers pour la fonctionnalité Kubernetes**.
1. Pour le **rôle de capacité IAM** :
+ Si vous possédez déjà un rôle de capacité IAM, sélectionnez-le dans le menu déroulant
+ Si vous devez créer un rôle, choisissez **Créer un rôle d'administrateur**
Cela ouvre la console IAM dans un nouvel onglet avec la politique de confiance préremplie et la politique `AdministratorAccess` gérée. Vous pouvez désélectionner cette politique et ajouter d'autres autorisations si vous le souhaitez.
Après avoir créé le rôle, retournez à la console EKS et le rôle sera automatiquement sélectionné.
**Important**
La `AdministratorAccess` politique suggérée accorde des autorisations étendues et vise à rationaliser le démarrage. Pour une utilisation en production, remplacez-la par une politique personnalisée qui n'accorde que les autorisations nécessaires pour les AWS services spécifiques que vous prévoyez de gérer avec ACK. Pour obtenir des conseils sur la création de politiques de moindre privilège, consultez [Configurer les autorisations ACK](ack-permissions.md) et. [Considérations relatives à la sécurité relatives aux fonctionnalités EKS](capabilities-security.md)
1. Choisissez **Créer**.
Le processus de création de capacités commence.
## Vérifiez que la fonctionnalité est active
1. Dans l'onglet **Fonctionnalités**, consultez l'état de la fonctionnalité ACK.
1. Attendez que le statut passe de `CREATING` à`ACTIVE`.
1. Une fois active, la fonctionnalité est prête à être utilisée.
Pour plus d'informations sur l'état des fonctionnalités et la résolution des problèmes, consultez[Utilisation des ressources en matière de capacités](working-with-capabilities.md).
## Vérifiez que les ressources personnalisées sont disponibles
Une fois la fonctionnalité activée, vérifiez que les ressources personnalisées ACK sont disponibles dans votre cluster.
**Utilisation de la console**
1. Accédez à votre cluster dans la console Amazon EKS
1. Choisissez l'onglet **Ressources**
1. Choisissez les **extensions**
1. Choisissez **CustomResourceDefinitions**
Vous devriez voir un certain nombre de AWS ressources CRDs répertoriées.
**Utilisation de kubectl**
```
kubectl api-resources | grep services.k8s.aws
```
Vous devriez voir un certain nombre de AWS ressources APIs répertoriées.
**Note**
La fonctionnalité des AWS Controllers for Kubernetes installera un certain nombre de ressources CRDs pour diverses ressources. AWS
## Étapes suivantes
+ [Concepts d'ACK](ack-concepts.md)- Comprenez les concepts ACK et lancez-vous
+ [Configurer les autorisations ACK](ack-permissions.md)- Configurer les autorisations IAM pour les autres services AWS
+ [Utilisation des ressources en matière de capacités](working-with-capabilities.md)- Gérez votre ressource de capacité ACK
# Création d'une fonctionnalité ACK à l'aide de la AWS CLI
Cette rubrique décrit comment créer une fonctionnalité AWS Controllers for Kubernetes (ACK) à l'aide de la CLI. AWS
## Conditions préalables
+ ** AWS CLI** : version `2.12.3` ou ultérieure. Pour vérifier votre version, lancez`aws --version`. Pour plus d'informations, consultez la section [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) dans le guide de l'utilisateur de l'interface de ligne de AWS commande.
+ ** `kubectl` ** : outil de ligne de commande pour travailler avec des clusters Kubernetes. Pour de plus amples informations, veuillez consulter [Configuration de `kubectl` et `eksctl`](install-kubectl.md).
## Étape 1 : Création d'un rôle de capacité IAM
Créez un fichier de politique de confiance :
```
cat > ack-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
EOF
```
Créez le rôle IAM :
```
aws iam create-role \
--role-name ACKCapabilityRole \
--assume-role-policy-document file://ack-trust-policy.json
```
Associez la politique `AdministratorAccess` gérée au rôle :
```
aws iam attach-role-policy \
--role-name ACKCapabilityRole \
--policy-arn arn:aws:iam::aws:policy/AdministratorAccess
```
**Important**
La `AdministratorAccess` politique suggérée accorde des autorisations étendues et vise à rationaliser le démarrage. Pour une utilisation en production, remplacez-la par une politique personnalisée qui n'accorde que les autorisations nécessaires pour les AWS services spécifiques que vous prévoyez de gérer avec ACK. Pour obtenir des conseils sur la création de politiques de moindre privilège, consultez [Configurer les autorisations ACK](ack-permissions.md) et. [Considérations relatives à la sécurité relatives aux fonctionnalités EKS](capabilities-security.md)
## Étape 2 : Création de la fonctionnalité ACK
Créez la ressource de capacité ACK sur votre cluster. Remplacez *region-code* par la AWS région dans laquelle se trouve votre cluster et remplacez *my-cluster* par le nom de votre cluster.
```
aws eks create-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-ack \
--type ACK \
--role-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/ACKCapabilityRole \
--delete-propagation-policy RETAIN
```
La commande revient immédiatement, mais la fonctionnalité met un certain temps à devenir active car EKS crée l'infrastructure et les composants de capacité requis. EKS installera les définitions de ressources personnalisées Kubernetes associées à cette fonctionnalité dans votre cluster lors de sa création.
**Note**
Si vous recevez un message d'erreur indiquant que le cluster n'existe pas ou que vous n'êtes pas autorisé, vérifiez :
Le nom du cluster est correct
Votre AWS CLI est configurée pour la bonne région
Vous disposez des autorisations IAM requises
## Étape 3 : vérifier que la fonctionnalité est active
Attendez que la fonctionnalité soit activée. Remplacez *region-code* par la AWS région dans laquelle se trouve votre cluster et remplacez *my-cluster* par le nom de votre cluster.
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-ack \
--query 'capability.status' \
--output text
```
La fonctionnalité est prête lorsque l'état s'affiche`ACTIVE`. Ne passez pas à l'étape suivante tant que le statut n'est pas atteint`ACTIVE`.
Vous pouvez également consulter les détails complets des fonctionnalités :
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-ack
```
## Étape 4 : vérifier que les ressources personnalisées sont disponibles
Une fois la fonctionnalité activée, vérifiez que les ressources personnalisées ACK sont disponibles dans votre cluster :
```
kubectl api-resources | grep services.k8s.aws
```
Vous devriez voir un certain nombre de AWS ressources APIs répertoriées.
**Note**
La fonctionnalité des AWS Controllers for Kubernetes installera un certain nombre de ressources CRDs pour diverses ressources. AWS
## Étapes suivantes
+ [Concepts d'ACK](ack-concepts.md)- Comprenez les concepts ACK et lancez-vous
+ [Configurer les autorisations ACK](ack-permissions.md)- Configurer les autorisations IAM pour les autres services AWS
+ [Utilisation des ressources en matière de capacités](working-with-capabilities.md)- Gérez votre ressource de capacité ACK
# Création d'une capacité ACK à l'aide de eksctl
Cette rubrique décrit comment créer une fonctionnalité AWS Controllers for Kubernetes (ACK) à l'aide de eksctl.
**Note**
Les étapes suivantes nécessitent la version eksctl `0.220.0` ou une version ultérieure. Pour vérifier votre version, lancez`eksctl version`.
## Étape 1 : Création d'un rôle de capacité IAM
Créez un fichier de politique de confiance :
```
cat > ack-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
EOF
```
Créez le rôle IAM :
```
aws iam create-role \
--role-name ACKCapabilityRole \
--assume-role-policy-document file://ack-trust-policy.json
```
Associez la politique `AdministratorAccess` gérée au rôle :
```
aws iam attach-role-policy \
--role-name ACKCapabilityRole \
--policy-arn arn:aws:iam::aws:policy/AdministratorAccess
```
**Important**
La `AdministratorAccess` politique suggérée accorde des autorisations étendues et vise à rationaliser le démarrage. Pour une utilisation en production, remplacez-la par une politique personnalisée qui n'accorde que les autorisations nécessaires pour les AWS services spécifiques que vous prévoyez de gérer avec ACK. Pour obtenir des conseils sur la création de politiques de moindre privilège, consultez [Configurer les autorisations ACK](ack-permissions.md) et. [Considérations relatives à la sécurité relatives aux fonctionnalités EKS](capabilities-security.md)
**Important**
Cette politique accorde des autorisations pour la gestion des compartiments S3 avec`"Resource": "*"`, ce qui permet d'effectuer des opérations sur tous les compartiments S3.
Pour une utilisation en production :\$1 Limitez le `Resource` champ à des modèles de bucket ARNs ou de nom spécifiques \$1 Utilisez les clés de condition IAM pour limiter l'accès par balises de ressource \$1 N'accordez que les autorisations minimales nécessaires à votre cas d'utilisation
Pour les autres AWS services, voir[Configurer les autorisations ACK](ack-permissions.md).
Attachez la stratégie au rôle :
```
aws iam attach-role-policy \
--role-name ACKCapabilityRole \
--policy-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):policy/ACKS3Policy
```
## Étape 2 : Création de la fonctionnalité ACK
Créez la capacité ACK à l'aide de eksctl. Remplacez *region-code* par la AWS région dans laquelle se trouve votre cluster et remplacez *my-cluster* par le nom de votre cluster.
```
eksctl create capability \
--cluster [.replaceable]`my-cluster` \
--region [.replaceable]`region-code` \
--name ack \
--type ACK \
--role-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/ACKCapabilityRole \
--ack-service-controllers s3
```
**Note**
Le `--ack-service-controllers` drapeau est facultatif. En cas d'omission, ACK active tous les contrôleurs disponibles. Pour améliorer les performances et la sécurité, pensez à activer uniquement les contrôleurs dont vous avez besoin. Vous pouvez spécifier plusieurs contrôleurs : `--ack-service-controllers s3,rds,dynamodb`
La commande revient immédiatement, mais la fonctionnalité met un certain temps à devenir active.
## Étape 3 : vérifier que la fonctionnalité est active
Vérifiez l'état des capacités :
```
eksctl get capability \
--cluster [.replaceable]`my-cluster` \
--region [.replaceable]`region-code` \
--name ack
```
La fonctionnalité est prête lorsque l'état s'affiche`ACTIVE`.
## Étape 4 : vérifier que les ressources personnalisées sont disponibles
Une fois la fonctionnalité activée, vérifiez que les ressources personnalisées ACK sont disponibles dans votre cluster :
```
kubectl api-resources | grep services.k8s.aws
```
Vous devriez voir un certain nombre de AWS ressources APIs répertoriées.
**Note**
La fonctionnalité des AWS Controllers for Kubernetes installera un certain nombre de ressources CRDs pour diverses ressources. AWS
## Étapes suivantes
+ [Concepts d'ACK](ack-concepts.md)- Comprenez les concepts ACK et lancez-vous
+ [Configurer les autorisations ACK](ack-permissions.md)- Configurer les autorisations IAM pour les autres services AWS
+ [Utilisation des ressources en matière de capacités](working-with-capabilities.md)- Gérez votre ressource de capacité ACK
# Concepts d'ACK
ACK gère les AWS ressources via Kubernetes en APIs conciliant en permanence l'état souhaité dans vos manifestes avec l'état réel dans. AWS Lorsque vous créez ou mettez à jour une ressource personnalisée Kubernetes, ACK effectue les appels d' AWS API nécessaires pour créer ou modifier la AWS ressource correspondante, puis surveille sa dérive et met à jour le statut de Kubernetes pour refléter l'état actuel. Cette approche vous permet de gérer l'infrastructure à l'aide d'outils et de flux de travail Kubernetes familiers tout en maintenant la cohérence entre votre cluster et. AWS
Cette rubrique explique les concepts fondamentaux qui sous-tendent la façon dont ACK gère les AWS ressources via Kubernetes APIs.
## Commencer à utiliser ACK
Après avoir créé la fonctionnalité ACK (voir[Création d'une fonctionnalité ACK](create-ack-capability.md)), vous pouvez commencer à gérer les AWS ressources à l'aide de manifestes Kubernetes dans votre cluster.
Par exemple, créez ce manifeste de compartiment S3 dans`bucket.yaml`, en choisissant votre propre nom de compartiment unique.
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: my-test-bucket
namespace: default
spec:
name: my-unique-bucket-name-12345
```
Appliquez le manifeste :
```
kubectl apply -f bucket.yaml
```
Vérifiez le statut :
```
kubectl get bucket my-test-bucket
kubectl describe bucket my-test-bucket
```
Vérifiez que le bucket a été créé dans AWS :
```
aws s3 ls | grep my-unique-bucket-name-12345
```
Supprimez la ressource Kubernetes :
```
kubectl delete bucket my-test-bucket
```
Vérifiez que le bucket a été supprimé de AWS :
```
aws s3 ls | grep my-unique-bucket-name-12345
```
Le bucket ne doit plus apparaître dans la liste, ce qui prouve qu'ACK gère le cycle de vie complet des AWS ressources.
Pour plus d'informations sur la prise en main d'ACK, consultez [Getting Started with ACK](https://aws-controllers-k8s.github.io/community/docs/user-docs/getting-started/).
## Cycle de vie et réconciliation des ressources
ACK utilise une boucle de réconciliation continue pour garantir que vos AWS ressources correspondent à l'état souhaité défini dans vos manifestes Kubernetes.
**Comment fonctionne la réconciliation** :
1. Vous créez ou mettez à jour une ressource personnalisée Kubernetes (par exemple, un compartiment S3)
1. ACK détecte le changement et compare l'état souhaité avec l'état réel dans AWS
1. S'ils diffèrent, ACK effectue des appels d' AWS API pour concilier la différence
1. ACK met à jour le statut des ressources dans Kubernetes pour refléter l'état actuel
1. La boucle se répète en continu, généralement toutes les quelques heures
La réconciliation est déclenchée lorsque vous créez une nouvelle ressource Kubernetes, que vous mettez à jour une ressource existante ou lorsque ACK détecte une dérive due à des modifications manuelles effectuées en AWS dehors d'ACK. `spec` En outre, ACK effectue des rapprochements périodiques avec une période de resynchronisation de 10 heures. Les modifications apportées aux ressources Kubernetes déclenchent une réconciliation immédiate, tandis que la détection passive des modifications des AWS ressources en amont se produit lors de la resynchronisation périodique.
Lorsque vous suivez l'exemple de démarrage ci-dessus, ACK exécute les étapes suivantes :
1. Vérifie si le bucket existe dans AWS
1. Si ce n'est pas le cas, appelez `s3:CreateBucket`
1. Met à jour le statut de Kubernetes avec l'ARN et l'état du bucket
1. Poursuite de la surveillance de la dérive
Pour en savoir plus sur le fonctionnement d'ACK, consultez [ACK Reconciliation](https://aws-controllers-k8s.github.io/community/docs/user-docs/reconciliation/).
## Conditions relatives au statut
Les ressources ACK utilisent des conditions d'état pour communiquer leur état. La compréhension de ces conditions vous aide à résoudre les problèmes et à comprendre l'état des ressources.
+ **Prêt** : indique que la ressource est prête à être consommée (condition Kubernetes standardisée).
+ **ACK. ResourceSynced**: indique que la spécification de la ressource correspond à l'état de la AWS ressource.
+ **ACK.terminal** : indique qu'une erreur irrécupérable s'est produite.
+ **ACK.adopted** : indique que la ressource a été adoptée à partir d'une AWS ressource existante plutôt que créée.
+ **Ack.Recoverable** : indique une erreur récupérable qui peut être résolue sans mettre à jour les spécifications.
+ **ACK.advisory** : fournit des informations consultatives sur la ressource.
+ **ACK. LateInitialized**: indique si l'initialisation tardive des champs est terminée.
+ **ACK. ReferencesResolved**: indique si tous les `AWSResourceReference` champs ont été résolus.
+ **ACK. IAMRoleSélectionné** : indique si un IAMRole sélecteur a été sélectionné pour gérer cette ressource.
Vérifiez l'état de la ressource :
```
# Check if resource is ready
kubectl get bucket my-bucket -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}'
# Check for terminal errors
kubectl get bucket my-bucket -o jsonpath='{.status.conditions[?(@.type=="ACK.Terminal")]}'
```
Exemple de statut :
```
status:
conditions:
- type: Ready
status: "True"
lastTransitionTime: "2024-01-15T10:30:00Z"
- type: ACK.ResourceSynced
status: "True"
lastTransitionTime: "2024-01-15T10:30:00Z"
- type: ACK.Terminal
status: "True"
ackResourceMetadata:
arn: arn:aws:s3:::my-unique-bucket-name
ownerAccountID: "111122223333"
region: us-west-2
```
Pour en savoir plus sur le statut et les conditions de l'ACK, consultez la section [Conditions de l'ACK](https://aws-controllers-k8s.github.io/community/docs/user-docs/conditions/).
## Politiques de suppression
La politique de suppression d'ACK contrôle ce qui arrive aux AWS ressources lorsque vous supprimez la ressource Kubernetes.
**Supprimer (par défaut)**
La AWS ressource est supprimée lorsque vous supprimez la ressource Kubernetes : il s'agit du comportement par défaut.
```
# No annotation needed - this is the default
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: temp-bucket
spec:
name: temporary-bucket
```
La suppression de cette ressource entraîne la suppression du compartiment S3 dans AWS.
**Conserver**
La AWS ressource est conservée lorsque vous supprimez la ressource Kubernetes :
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: important-bucket
annotations:
services.k8s.aws/deletion-policy: "retain"
spec:
name: production-data-bucket
```
La suppression de cette ressource la supprime de Kubernetes mais laisse le compartiment S3 dedans. AWS
Cette `retain` politique est utile pour les bases de données de production qui doivent survivre à la ressource Kubernetes, pour les ressources partagées utilisées par plusieurs applications, pour les ressources contenant des données importantes qui ne doivent pas être supprimées accidentellement ou pour la gestion temporaire d'ACK dans le cadre de laquelle vous adoptez une ressource, la configurez, puis la relancez à la gestion manuelle.
Pour en savoir plus sur la politique de suppression d'ACK, consultez la section [Politique de suppression d'ACK](https://aws-controllers-k8s.github.io/community/docs/user-docs/deletion-policy/).
## Adoption des ressources
L'adoption vous permet de placer les AWS ressources existantes sous la gestion d'ACK sans les recréer.
Quand utiliser l'adoption :
+ Migration de l'infrastructure existante vers la gestion ACK
+ Récupération de AWS ressources orphelines en cas de suppression accidentelle de ressources dans Kubernetes
+ Importation de ressources créées par d'autres outils (CloudFormation, Terraform)
Comment fonctionne l'adoption :
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: existing-bucket
annotations:
services.k8s.aws/adoption-policy: "adopt-or-create"
spec:
name: my-existing-bucket-name
```
Lorsque vous créez cette ressource :
1. ACK vérifie si un bucket portant ce nom existe dans AWS
1. S'il est trouvé, ACK l'adopte (aucun appel d'API à créer)
1. ACK lit la configuration actuelle depuis AWS
1. ACK met à jour le statut de Kubernetes pour refléter l'état réel
1. Les mises à jour futures réconcilient normalement la ressource
Une fois adoptées, les ressources sont gérées comme n'importe quelle autre ressource ACK, et la suppression de la ressource Kubernetes entraîne la suppression de la AWS ressource, sauf si vous utilisez la `retain` politique de suppression.
Lors de l'adoption de ressources, AWS celles-ci doivent déjà exister et ACK a besoin d'autorisations de lecture pour les découvrir. La `adopt-or-create` politique adopte la ressource si elle existe ou la crée si elle n'existe pas. Cela est utile lorsque vous souhaitez un flux de travail déclaratif qui fonctionne, que la ressource existe ou non.
Pour en savoir plus sur l'adoption des ressources ACK, consultez la section [Adoption des ressources ACK](https://aws-controllers-k8s.github.io/community/docs/user-docs/adopted-resource/).
## Ressources entre comptes et entre régions
ACK peut gérer les ressources de différents AWS comptes et régions à partir d'un seul cluster.
**Annotations de ressources interrégionales**
Vous pouvez spécifier la région d'une AWS ressource à l'aide d'une annotation :
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: eu-bucket
annotations:
services.k8s.aws/region: eu-west-1
spec:
name: my-eu-bucket
```
Vous pouvez également spécifier la région de toutes les AWS ressources créées dans un espace de noms donné :
**Annotations relatives à l'espace de noms**
Définissez une région par défaut pour toutes les ressources d'un espace de noms :
```
apiVersion: v1
kind: Namespace
metadata:
name: production
annotations:
services.k8s.aws/default-region: us-west-2
```
Les ressources créées dans cet espace de noms utilisent cette région sauf si elles sont remplacées par une annotation au niveau des ressources.
**Compte croisé**
Utilisez les sélecteurs de rôles IAM pour associer des rôles IAM spécifiques à des espaces de noms :
```
apiVersion: services.k8s.aws/v1alpha1
kind: IAMRoleSelector
metadata:
name: target-account-config
spec:
arn: arn:aws:iam::444455556666:role/ACKTargetAccountRole
namespaceSelector:
names:
- production
```
Les ressources créées dans l'espace de noms mappé utilisent automatiquement le rôle spécifié.
Pour en savoir plus sur les sélecteurs de rôles IAM, consultez la section Gestion des [ressources entre comptes ACK](https://aws-controllers-k8s.github.io/docs/guides/cross-account). Pour plus de détails sur la configuration entre comptes, voir[Configurer les autorisations ACK](ack-permissions.md).
## Gestion des erreurs et comportement des nouvelles tentatives
ACK gère automatiquement les erreurs transitoires et réessaie les opérations qui ont échoué.
Réessayez la stratégie :
+ Les erreurs transitoires (limitation du débit, problèmes de service temporaires, autorisations insuffisantes) déclenchent de nouvelles tentatives automatiques
+ Le recul exponentiel évite le surmenage AWS APIs
+ Le nombre maximal de tentatives varie en fonction du type d'erreur
+ Erreurs permanentes (paramètres non valides, conflits de noms de ressources), ne réessayez pas
Vérifiez l'état de la ressource pour obtenir des informations détaillées sur les erreurs en utilisant `kubectl describe` :
```
kubectl describe bucket my-bucket
```
Recherchez les conditions d'état avec des messages d'erreur, les événements indiquant les récentes tentatives de rapprochement et le `message` champ des conditions d'état expliquant les échecs. Les erreurs courantes incluent des autorisations IAM insuffisantes, des conflits de noms de ressources AWS, des valeurs de configuration non valides dans le `spec` et des quotas de AWS service dépassés.
Pour résoudre les erreurs courantes, consultez[Résoudre les problèmes liés aux fonctionnalités ACK](ack-troubleshooting.md).
## Composition des ressources avec kro
Pour composer et connecter plusieurs ressources ACK ensemble, utilisez la fonctionnalité EKS pour kro (Kube Resource Orchestrator). kro fournit un moyen déclaratif de définir des groupes de ressources, en transmettant la configuration entre les ressources afin de gérer simplement des modèles d'infrastructure complexes.
Pour des exemples détaillés de création de compositions de ressources personnalisées avec des ressources ACK, voir [concepts kro](kro-concepts.md)
## Étapes suivantes
+ [Considérations relatives à l'ACK pour EKS](ack-considerations.md)- Modèles et stratégies d'intégration spécifiques à EKS
# Configurer les autorisations ACK
ACK nécessite des autorisations IAM pour créer et gérer AWS des ressources en votre nom. Cette rubrique explique comment IAM fonctionne avec ACK et fournit des conseils sur la configuration des autorisations pour différents cas d'utilisation.
## Comment IAM travaille avec ACK
ACK utilise des rôles IAM pour s'authentifier auprès de vos ressources AWS et effectuer des actions sur celles-ci. Il existe deux manières de fournir des autorisations à ACK :
**Rôle de capacité : rôle** IAM que vous fournissez lors de la création de la fonctionnalité ACK. Ce rôle est utilisé par défaut pour toutes les opérations ACK.
**Sélecteurs de rôles IAM** : rôles IAM supplémentaires pouvant être mappés à des espaces de noms ou à des ressources spécifiques. Ces rôles remplacent le rôle de capacité pour les ressources relevant de leur champ d'application.
Lorsqu'ACK doit créer ou gérer une ressource, il détermine le rôle IAM à utiliser :
1. Vérifiez si un IAMRole sélecteur correspond à l'espace de noms de la ressource
1. Si une correspondance est trouvée, supposons que le rôle IAM
1. Sinon, utilisez le rôle de capacité
Cette approche permet une gestion flexible des autorisations, qu'il s'agisse de configurations simples à rôle unique ou de configurations complexes impliquant plusieurs comptes et plusieurs équipes.
## Mise en route : configuration simple des autorisations
Pour le développement, les tests ou les cas d'utilisation simples, vous pouvez ajouter toutes les autorisations de service nécessaires directement au rôle de capacité.
Cette approche fonctionne bien lorsque :
+ Vous commencez à utiliser ACK
+ Toutes les ressources se trouvent dans le même AWS compte
+ Une seule équipe gère toutes les ressources de l'ACK
+ Vous êtes sûr que tous les utilisateurs d'ACK ont les mêmes autorisations
## Bonnes pratiques de production : sélecteurs de rôles IAM
Pour les environnements de production, utilisez les sélecteurs de rôle IAM pour implémenter l'accès avec le moindre privilège et l'isolation au niveau de l'espace de noms.
Lorsque vous utilisez des sélecteurs de rôle IAM, le rôle de capacité n'a besoin que d'`sts:TagSession`autorisations pour assumer `sts:AssumeRole` les rôles spécifiques au service. Vous n'avez pas besoin d'ajouter d'autorisations de AWS service (comme S3 ou RDS) au rôle de capacité lui-même. Ces autorisations sont accordées aux rôles IAM individuels assumés par le rôle de capacité.
**Choix entre les modèles d'autorisation** :
Utilisez **des autorisations directes** (ajout d'autorisations de service au rôle de capacité) lorsque :
+ Vous êtes sur le point de démarrer et vous souhaitez la configuration la plus simple
+ Toutes les ressources se trouvent dans le même compte que votre cluster
+ Vous avez des exigences en matière d'autorisations administratives à l'échelle du cluster
+ Toutes les équipes peuvent partager les mêmes autorisations
Utilisez les **sélecteurs de rôles IAM** lorsque :
+ Gestion des ressources sur plusieurs AWS comptes
+ Des équipes ou des espaces de noms différents ont besoin d'autorisations différentes
+ Vous avez besoin d'un contrôle d'accès précis par espace de noms
+ Vous souhaitez suivre les pratiques de sécurité fondées sur le principe du moindre privilège
Vous pouvez commencer par des autorisations directes et migrer vers les sélecteurs de rôle IAM ultérieurement à mesure que vos besoins augmentent.
**Pourquoi utiliser les sélecteurs de rôles IAM en production :**
+ **Privilège minimal** : chaque espace de noms ne reçoit que les autorisations dont il a besoin
+ **Isolement** de l'équipe : l'équipe A ne peut pas utiliser accidentellement les autorisations de l'équipe B
+ **Audit simplifié** : mappage clair de l'espace de noms qui utilise quel rôle
+ **Support multicompte** : nécessaire pour gérer les ressources de plusieurs comptes
+ **Séparation des préoccupations** : différents services ou environnements utilisent des rôles différents
### Configuration de base du sélecteur de rôle IAM
**Étape 1 : créer un rôle IAM spécifique au service**
Créez un rôle IAM avec des autorisations pour des AWS services spécifiques :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": "*"
}
]
}
```
Configurez la politique de confiance pour permettre au rôle de capacité de l'assumer :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/ACKCapabilityRole"
},
"Action": ["sts:AssumeRole", "sts:TagSession"]
}
]
}
```
**Étape 2 : Accorder AssumeRole l'autorisation à Capability Role**
Ajoutez l'autorisation au rôle de capacité pour assumer le rôle spécifique au service :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["sts:AssumeRole", "sts:TagSession"],
"Resource": "arn:aws:iam::111122223333:role/ACK-S3-Role"
}
]
}
```
**Étape 3 : créer un IAMRole sélecteur**
Mappez le rôle IAM à un espace de noms :
```
apiVersion: services.k8s.aws/v1alpha1
kind: IAMRoleSelector
metadata:
name: s3-namespace-config
spec:
arn: arn:aws:iam::111122223333:role/ACK-S3-Role
namespaceSelector:
names:
- s3-resources
```
**Étape 4 : créer des ressources dans l'espace de noms mappé**
Les ressources de l'espace de `s3-resources` noms utilisent automatiquement le rôle spécifié :
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: my-bucket
namespace: s3-resources
spec:
name: my-production-bucket
```
## Gestion de plusieurs comptes
Utilisez les sélecteurs de rôle IAM pour gérer les ressources de plusieurs AWS comptes.
**Étape 1 : créer un rôle IAM entre comptes**
Dans le compte cible (444455556666), créez un rôle qui fait confiance au rôle de capacité du compte source :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/ACKCapabilityRole"
},
"Action": ["sts:AssumeRole", "sts:TagSession"]
}
]
}
```
Associez des autorisations spécifiques au service à ce rôle.
**Étape 2 : Accorder AssumeRole l'autorisation**
Dans le compte source (111122223333), autorisez le rôle de capacité à assumer le rôle de compte cible :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["sts:AssumeRole", "sts:TagSession"],
"Resource": "arn:aws:iam::444455556666:role/ACKTargetAccountRole"
}
]
}
```
**Étape 3 : créer un IAMRole sélecteur**
Associez le rôle multicompte à un espace de noms :
```
apiVersion: services.k8s.aws/v1alpha1
kind: IAMRoleSelector
metadata:
name: production-account-config
spec:
arn: arn:aws:iam::444455556666:role/ACKTargetAccountRole
namespaceSelector:
names:
- production
```
**Étape 4 : Création de ressources**
Les ressources de l'espace de `production` noms sont créées dans le compte cible :
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: my-bucket
namespace: production
spec:
name: my-cross-account-bucket
```
## Balises de session
La fonctionnalité EKS ACK définit automatiquement les balises de session pour toutes les demandes AWS d'API. Ces balises permettent un contrôle d'accès et un audit précis en identifiant la source de chaque demande.
### Tags de session disponibles
Les balises de session suivantes sont incluses dans chaque appel AWS d'API effectué par ACK :
| Clé de tag | Description |
| --- | --- |
| `eks:eks-capability-arn` | L'ARN de la capacité EKS à l'origine de la demande |
| `eks:kubernetes-namespace` | L'espace de noms Kubernetes de la ressource gérée |
| `eks:kubernetes-api-group` | Le groupe d'API Kubernetes de la ressource (par exemple,) `s3.services.k8s.aws` |
### Utilisation de balises de session pour le contrôle d'accès
Vous pouvez utiliser ces balises de session dans les conditions de politique IAM pour limiter les ressources qu'ACK peut gérer. Cela fournit une couche de sécurité supplémentaire au-delà des sélecteurs de rôles IAM basés sur des espaces de noms.
**Exemple : Restreindre par espace de noms**
Autorisez ACK à créer des compartiments S3 uniquement lorsque la demande provient de l'`production`espace de noms :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:CreateBucket",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/eks:kubernetes-namespace": "production"
}
}
}
]
}
```
**Exemple : Restreindre en fonction de la capacité**
Autoriser les actions uniquement à partir d'une fonctionnalité ACK spécifique :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/eks:eks-capability-arn": "arn:aws:eks:us-west-2:111122223333:capability/my-cluster/ack/my-ack"
}
}
}
]
}
```
**Note**
Les balises de session sont différentes de l'ACK autogéré, qui ne définit pas ces balises par défaut. Cela permet un contrôle d'accès plus granulaire grâce à la fonctionnalité gérée.
## Modèles de sélection de rôles IAM avancés
Pour une configuration avancée, y compris les sélecteurs d'étiquettes, le mappage des rôles spécifiques aux ressources et des exemples supplémentaires, consultez la documentation [ACK](https://aws-controllers-k8s.github.io/community/docs/user-docs/irsa/) IRSA.
## Étapes suivantes
+ [Concepts d'ACK](ack-concepts.md)- Comprendre les concepts ACK et le cycle de vie des ressources
+ [Concepts d'ACK](ack-concepts.md)- En savoir plus sur les politiques d'adoption et de suppression des ressources
+ [Considérations relatives à la sécurité relatives aux fonctionnalités EKS](capabilities-security.md)- Comprendre les meilleures pratiques en matière de sécurité en termes de fonctionnalités
# Considérations relatives à l'ACK pour EKS
Cette rubrique couvre les considérations importantes relatives à l'utilisation de la fonctionnalité EKS pour ACK, notamment la configuration IAM, les modèles multi-comptes et l'intégration avec d'autres fonctionnalités EKS.
## Modèles de configuration IAM
La fonctionnalité ACK utilise un rôle de capacité IAM pour s'authentifier. AWS Choisissez le modèle IAM adapté à vos besoins.
### Simple : rôle de capacité unique
Pour le développement, les tests ou les cas d'utilisation simples, accordez toutes les autorisations nécessaires directement au rôle de capacité.
**Quand utiliser** :
+ Commencer à utiliser ACK
+ Déploiements à compte unique
+ Toutes les ressources sont gérées par une seule équipe
+ Environnements de développement et de test
**Exemple** : ajoutez des autorisations S3 et RDS à votre rôle de capacité avec des conditions de balisage des ressources :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:*"],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": ["us-west-2", "us-east-1"]
}
}
},
{
"Effect": "Allow",
"Action": ["rds:*"],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": ["us-west-2", "us-east-1"]
},
}
}
]
}
```
Cet exemple limite les opérations S3 et RDS à des régions spécifiques et exige que les ressources RDS soient dotées d'une `ManagedBy: ACK` balise.
### Production : Sélecteurs de rôles IAM
Pour les environnements de production, utilisez les sélecteurs de rôle IAM pour implémenter l'accès avec le moindre privilège et l'isolation au niveau de l'espace de noms.
**Quand utiliser** :
+ Environnements de production
+ Clusters multi-équipes
+ Gestion des ressources multi-comptes
+ Exigences de sécurité relatives au moindre privilège
+ Les différents services nécessitent des autorisations différentes
**Avantages** :
+ Chaque espace de noms ne reçoit que les autorisations dont il a besoin
+ Isolement de l'équipe - L'équipe A ne peut pas utiliser les autorisations de l'équipe B
+ Audit et conformité simplifiés
+ Nécessaire pour la gestion des ressources entre comptes
Pour une configuration détaillée du sélecteur de rôle IAM, consultez. [Configurer les autorisations ACK](ack-permissions.md)
## Intégration avec d'autres fonctionnalités d'EKS
### GitOps avec Argo CD
Utilisez le CD EKS Capability for Argo pour déployer des ressources ACK à partir de référentiels Git, permettant ainsi des GitOps flux de travail pour la gestion de l'infrastructure.
**Considérations :**
+ Stockez les ressources ACK à côté des manifestes d'applications pour end-to-end GitOps
+ Organisez par environnement, service ou type de ressource en fonction de la structure de votre équipe
+ Utilisez la synchronisation automatique d'Argo CD pour un rapprochement continu
+ Activez l'élagage pour supprimer automatiquement les ressources supprimées
+ Envisagez hub-and-spoke des modèles de gestion de l'infrastructure multi-clusters
GitOps fournit des pistes d'audit, des fonctionnalités de restauration et une gestion déclarative de l'infrastructure. Pour en savoir plus sur Argo CD, voir[Travailler avec Argo CD](working-with-argocd.md).
### Composition des ressources avec kro
Utilisez la fonctionnalité EKS pour kro (Kube Resource Orchestrator) pour composer plusieurs ressources ACK en abstractions de niveau supérieur et personnalisées. APIs
**Quand utiliser Kro avec ACK** :
+ Créez des modèles réutilisables pour les piles d'infrastructure courantes (base de données, sauvegarde et surveillance)
+ Créez des plateformes en libre-service simplifiées APIs pour les équipes d'application
+ Gérer les dépendances des ressources et transmettre des valeurs entre les ressources (fonction ARN du compartiment S3 vers Lambda)
+ Standardisez les configurations d'infrastructure entre les équipes
+ Réduisez la complexité en masquant les détails de mise en œuvre derrière des ressources personnalisées
**Exemples de modèles** :
+ Pile d'applications : compartiment S3, file d'attente SQS et configuration des notifications
+ Configuration de la base de données : instance RDS \$1 groupe de paramètres \$1 groupe de sécurité \$1 secrets
+ Mise en réseau : VPC \$1 sous-réseaux \$1 tables de routage \$1 groupes de sécurité
kro gère l'ordre des dépendances, la propagation des statuts et la gestion du cycle de vie des ressources composées. Pour en savoir plus sur Kro, voir[concepts kro](kro-concepts.md).
## Organisation de vos ressources
Organisez les ressources ACK à l'aide des espaces de noms et des balises de AWS ressources Kubernetes pour améliorer la gestion, le contrôle d'accès et le suivi des coûts.
### Organisation de l'espace de noms
Utilisez les espaces de noms Kubernetes pour séparer logiquement les ressources ACK par environnement (production, développement, développement), par équipe (plateforme, données, ml) ou par application.
**Avantages** :
+ RBAC limité à l'espace de noms pour le contrôle d'accès
+ Définissez les régions par défaut par espace de noms à l'aide d'annotations
+ Gestion et nettoyage des ressources simplifiés
+ Séparation logique alignée sur la structure organisationnelle
### Étiquette des ressources
La fonctionnalité EKS ACK applique automatiquement des balises par défaut à toutes les AWS ressources qu'elle crée. Ces étiquettes diffèrent de l'ACK autogéré et offrent une meilleure traçabilité.
**Balises par défaut appliquées par la fonctionnalité** :
| Clé de tag | Description |
| --- | --- |
| `eks:controller-version` | La version du contrôleur ACK |
| `eks:kubernetes-namespace` | L'espace de noms Kubernetes de la ressource ACK |
| `eks:kubernetes-resource-name` | Le nom de la ressource Kubernetes |
| `eks:kubernetes-api-group` | Le groupe d'API Kubernetes (par exemple,) `s3.services.k8s.aws` |
| `eks:eks-capability-arn` | L'ARN de la fonctionnalité EKS ACK |
**Note**
L'ACK autogéré utilise différentes balises par défaut : `services.k8s.aws/controller-version` et`services.k8s.aws/namespace`. Les balises de la fonctionnalité utilisent le `eks:` préfixe par souci de cohérence avec les autres fonctionnalités d'EKS.
**Tags supplémentaires recommandés** :
Ajoutez des balises personnalisées pour la répartition des coûts, le suivi de la propriété et à des fins organisationnelles :
+ Environnement (production, mise en scène, développement)
+ Propriété d'une équipe ou d'un département
+ Centre de coûts pour la répartition de la facturation
+ Nom de l'application ou du service
## Migration depuis d'autres Infrastructure-as-code outils
De nombreuses entreprises trouvent la valeur de la standardisation sur Kubernetes au-delà de l'orchestration de leur charge de travail. La migration de la gestion de l'infrastructure et AWS des ressources vers ACK vous permet de standardiser la gestion de l'infrastructure à l'aide de Kubernetes APIs parallèlement aux charges de travail de vos applications.
**Avantages de la standardisation sur Kubernetes** pour l'infrastructure :
+ **Source unique de vérité** : gérez à la fois les applications et l'infrastructure dans Kubernetes, permettant ainsi une pratique end-to-end GitOps
+ **Outillage unifié** : les équipes utilisent les ressources et les outils Kubernetes plutôt que d'apprendre plusieurs outils et frameworks
+ **Réconciliation cohérente** : ACK réconcilie en permanence les AWS ressources, comme le fait Kubernetes pour les charges de travail, en détectant et en corrigeant les dérives par rapport aux outils indispensables
+ **Compositions natives** : avec kro et ACK combinés, référencez les AWS ressources directement dans les manifestes d'applications et de ressources, en passant des chaînes de connexion et ARNs entre les ressources
+ **Opérations simplifiées** : un seul plan de contrôle pour les déploiements, les annulations et l'observabilité sur l'ensemble de votre système
ACK prend en charge l'adoption AWS des ressources existantes sans les recréer, ce qui permet une migration sans interruption depuis CloudFormation Terraform ou des ressources externes au cluster.
**Adoptez une ressource existante** :
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: existing-bucket
annotations:
services.k8s.aws/adoption-policy: "adopt-or-create"
spec:
name: my-existing-bucket-name
```
Une fois adoptée, la ressource est gérée par ACK et peut être mise à jour via les manifestes Kubernetes. Vous pouvez effectuer une migration incrémentielle, en adoptant des ressources selon vos besoins, tout en conservant les outils IaC existants pour d'autres ressources.
ACK prend également en charge les ressources en lecture seule. Pour les ressources gérées par d'autres équipes ou les outils que vous souhaitez référencer mais ne pas modifier, combinez l'adoption avec la politique de `retain` suppression et accordez uniquement des autorisations de lecture IAM. Cela permet aux applications de découvrir une infrastructure partagée (rôles IAMVPCs, clés KMS) via Kubernetes APIs sans risquer de modifications.
Pour en savoir plus sur l'adoption des ressources, voir[Concepts d'ACK](ack-concepts.md).
## Politiques de suppression
Les politiques de suppression contrôlent ce qu'il advient AWS des ressources lorsque vous supprimez la ressource Kubernetes correspondante. Choisissez la bonne politique en fonction du cycle de vie des ressources et de vos exigences opérationnelles.
### Supprimer (par défaut)
La AWS ressource est supprimée lorsque vous supprimez la ressource Kubernetes. Cela permet de maintenir la cohérence entre votre cluster et AWS de garantir que les ressources ne s'accumulent pas.
**Quand utiliser la suppression** :
+ Environnements de développement et de test dans lesquels le nettoyage est important
+ Ressources éphémères liées au cycle de vie des applications (bases de données de test, compartiments temporaires)
+ Ressources qui ne devraient pas durer plus longtemps que l'application (files d'attente SQS, clusters) ElastiCache
+ Optimisation des coûts : nettoyage automatique des ressources inutilisées
+ Environnements gérés avec GitOps lesquels la suppression des ressources de Git devrait supprimer l'infrastructure
La politique de suppression par défaut s'aligne sur le modèle déclaratif de Kubernetes : le contenu du cluster correspond à ce qui existe dans. AWS
### Conserver
La AWS ressource est conservée lorsque vous supprimez la ressource Kubernetes. Cela protège les données critiques et permet aux ressources de survivre à leur représentation sur Kubernetes.
**Quand utiliser Retain** :
+ Bases de données de production contenant des données critiques qui doivent résister aux modifications des clusters
+ Compartiments de stockage à long terme soumis à des exigences de conformité ou d'audit
+ Ressources partagées utilisées par plusieurs applications ou équipes
+ Migration des ressources vers différents outils de gestion
+ Scénarios de reprise après sinistre dans lesquels vous souhaitez préserver l'infrastructure
+ Ressources présentant des dépendances complexes qui nécessitent une mise hors service minutieuse
```
apiVersion: rds.services.k8s.aws/v1alpha1
kind: DBInstance
metadata:
name: production-db
annotations:
services.k8s.aws/deletion-policy: "retain"
spec:
dbInstanceIdentifier: prod-db
# ... configuration
```
**Important**
Les ressources conservées continuent d'entraîner des AWS coûts et doivent être supprimées manuellement AWS lorsqu'elles ne sont plus nécessaires. Utilisez le balisage des ressources pour suivre les ressources conservées à des fins de nettoyage.
Pour en savoir plus sur les politiques de suppression, consultez[Concepts d'ACK](ack-concepts.md).
## Documentation en amont
Pour des informations détaillées sur l'utilisation d'ACK :
+ [Guide d'utilisation d'ACK](https://aws-controllers-k8s.github.io/community/docs/user-docs/usage/) - Création et gestion de ressources
+ [Référence de l'API ACK](https://aws-controllers-k8s.github.io/community/reference/) - Documentation complète sur les API pour tous les services
+ [Documentation ACK - Documentation](https://aws-controllers-k8s.github.io/community/docs/) utilisateur complète
## Étapes suivantes
+ [Configurer les autorisations ACK](ack-permissions.md)- Configurer les autorisations IAM et les modèles multi-comptes
+ [Concepts d'ACK](ack-concepts.md)- Comprendre les concepts ACK et le cycle de vie des ressources
+ [Résoudre les problèmes liés aux fonctionnalités ACK](ack-troubleshooting.md)- Résoudre les problèmes d'ACK
+ [Travailler avec Argo CD](working-with-argocd.md)- Déployez les ressources ACK avec GitOps
+ [concepts kro](kro-concepts.md)- Composez les ressources ACK en abstractions de niveau supérieur
# Résoudre les problèmes liés aux fonctionnalités ACK
Cette rubrique fournit des conseils de dépannage relatifs à la fonctionnalité EKS pour ACK, notamment les vérifications de l'état des fonctionnalités, la vérification de l'état des ressources et les problèmes d'autorisation IAM.
**Note**
Les fonctionnalités EKS sont entièrement gérées et exécutées en dehors de votre cluster. Vous n'avez pas accès aux journaux ni aux espaces de noms des contrôleurs. Le dépannage se concentre sur l'état des capacités, l'état des ressources et la configuration IAM.
## La capacité est ACTIVE mais les ressources ne sont pas créées
Si votre fonctionnalité ACK affiche un `ACTIVE` état mais que les ressources n'y sont pas créées AWS, vérifiez l'état de la fonctionnalité, l'état des ressources et les autorisations IAM.
**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 la AWS CLI.
**Console** :
1. Ouvrez la console Amazon EKS à l'adresse https://console.aws.amazon.com/eks/ home\$1/clusters.
1. Sélectionnez le nom de votre cluster.
1. Sélectionnez l’onglet **Observabilité**.
1. Sélectionnez **Surveiller le cluster**.
1. Choisissez l'onglet **Fonctionnalités** pour afficher l'état et l'état de toutes les fonctionnalités.
** AWS CLI** :
```
# View capability status and health
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-ack
# Look for issues in the health section
```
**Causes courantes :**
+ **Autorisations IAM manquantes** : le rôle de capacité ne dispose pas d'autorisations pour le service AWS
+ **Mauvais espace de noms** : ressources créées dans l'espace de noms sans sélecteur approprié IAMRole
+ **Spécification de ressource non valide :** vérifiez les conditions d'état des ressources pour détecter les erreurs de validation
+ Limitation de **l'API : les** limites de débit des AWS API sont atteintes
+ **Webhooks d'admission** : webhooks d'admission empêchant le contrôleur de corriger le statut des ressources
**Vérifiez l'état des ressources** :
```
# Describe the resource to see conditions and events
kubectl describe bucket my-bucket -n default
# Look for status conditions
kubectl get bucket my-bucket -n default -o jsonpath='{.status.conditions}'
# View resource events
kubectl get events --field-selector involvedObject.name=my-bucket -n default
```
**Vérifiez les autorisations IAM** :
```
# View the Capability Role's policies
aws iam list-attached-role-policies --role-name my-ack-capability-role
aws iam list-role-policies --role-name my-ack-capability-role
# Get specific policy details
aws iam get-role-policy --role-name my-ack-capability-role --policy-name policy-name
```
## Ressources créées dans Kubernetes AWS mais non affichées
ACK suit uniquement les ressources qu'il crée via les manifestes Kubernetes. Pour gérer les AWS ressources existantes avec ACK, utilisez la fonctionnalité d'adoption.
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: existing-bucket
annotations:
services.k8s.aws/adoption-policy: "adopt-or-create"
spec:
name: my-existing-bucket-name
```
Pour en savoir plus sur l'adoption des ressources, voir[Concepts d'ACK](ack-concepts.md).
## Les ressources entre comptes ne sont pas créées
Si aucune ressource n'est créée dans un AWS compte cible lors de l'utilisation des sélecteurs de rôle IAM, vérifiez la relation de confiance et la configuration du IAMRole sélecteur.
**Vérifiez la relation de confiance** :
```
# Check the trust policy in the target account role
aws iam get-role --role-name cross-account-ack-role --query 'Role.AssumeRolePolicyDocument'
```
La politique de confiance doit permettre au rôle de capacité du compte source de l'assumer.
**Confirmez la configuration IAMRole du sélecteur** :
```
# List IAMRoleSelectors (cluster-scoped)
kubectl get iamroleselector
# Describe specific selector
kubectl describe iamroleselector my-selector
```
**Vérifiez l'alignement de l'espace de noms** :
IAMRoleLes sélecteurs sont des ressources limitées à un cluster mais ciblent des espaces de noms spécifiques. Assurez-vous que vos ressources ACK se trouvent dans un espace de noms qui correspond au IAMRole sélecteur d'espace de noms du sélecteur :
```
# Check resource namespace
kubectl get bucket my-cross-account-bucket -n production
# List all IAMRoleSelectors (cluster-scoped)
kubectl get iamroleselector
# Check which namespace the selector targets
kubectl get iamroleselector my-selector -o jsonpath='{.spec.namespaceSelector}'
```
**Vérifiez la condition IAMRole sélectionnée** :
Vérifiez que le IAMRole sélecteur a bien été mis en correspondance avec votre ressource en vérifiant la `ACK.IAMRoleSelected` condition suivante :
```
# Check if IAMRoleSelector was matched
kubectl get bucket my-cross-account-bucket -n production -o jsonpath='{.status.conditions[?(@.type=="ACK.IAMRoleSelected")]}'
```
Si la condition est `False` ou absente, le IAMRole sélecteur d'espace de noms du sélecteur ne correspond pas à l'espace de noms de la ressource. Vérifiez que le sélecteur `namespaceSelector` correspond aux libellés d'espace de noms de votre ressource.
**Vérifiez les autorisations relatives aux rôles de capacité** :
Le rôle de capacité a besoin `sts:AssumeRole` et `sts:TagSession` autorisations pour le rôle de compte cible :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["sts:AssumeRole", "sts:TagSession"],
"Resource": "arn:aws:iam::[.replaceable]`444455556666`:role/[.replaceable]`cross-account-ack-role`"
}
]
}
```
Pour une configuration détaillée entre comptes, voir[Configurer les autorisations ACK](ack-permissions.md).
## Étapes suivantes
+ [Considérations relatives à l'ACK pour EKS](ack-considerations.md)- Considérations et meilleures pratiques relatives à l'ACK
+ [Configurer les autorisations ACK](ack-permissions.md)- Configurer les autorisations IAM et les modèles multi-comptes
+ [Concepts d'ACK](ack-concepts.md)- Comprendre les concepts ACK et le cycle de vie des ressources
+ [Dépannage des fonctionnalités EKS](capabilities-troubleshooting.md)- Conseils généraux de résolution des problèmes liés aux fonctionnalités
# Comparaison de la capacité EKS pour ACK à une solution ACK autogérée
La capacité EKS pour ACK fournit les mêmes fonctionnalités que les contrôleurs ACK autogérés, mais avec des avantages opérationnels significatifs. Pour une comparaison générale des fonctionnalités EKS par rapport aux solutions autogérées, voir[Considérations relatives aux fonctionnalités EKS](capabilities-considerations.md). Cette rubrique se concentre sur les différences spécifiques à ACK.
## Différences par rapport à l'ACK en amont
La capacité EKS pour ACK est basée sur les contrôleurs ACK en amont, mais elle diffère en termes d'intégration IAM.
Rôle de **capacité IAM : la fonctionnalité utilise un rôle** IAM dédié avec une politique de confiance qui autorise le principal du `capabilities.eks.amazonaws.com` service, et non l'IRSA (rôles IAM pour les comptes de service). Vous pouvez associer des politiques IAM directement au rôle de capacité sans avoir à créer ou à annoter des comptes de service Kubernetes ou à configurer des fournisseurs OIDC. Une bonne pratique pour les cas d'utilisation en production consiste à configurer les autorisations de service à l'aide de`IAMRoleSelector`. Pour plus d’informations, consultez [Configurer les autorisations ACK](ack-permissions.md).
**Balises de session** : la fonctionnalité gérée définit automatiquement les balises de session pour toutes les demandes d' AWS API, ce qui permet un contrôle d'accès et un audit précis. Les balises incluent `eks:eks-capability-arn``eks:kubernetes-namespace`, et`eks:kubernetes-api-group`. Cela diffère de l'ACK autogéré, qui ne définit pas ces balises par défaut. Consultez [Configurer les autorisations ACK](ack-permissions.md) pour plus de détails sur l'utilisation des balises de session dans les politiques IAM.
**Balises de ressources** : la fonctionnalité applique des balises par défaut différentes aux AWS ressources par rapport à l'ACK autogéré. La fonctionnalité utilise des balises `eks:` préfixées (telles que`eks:kubernetes-namespace`,`eks:eks-capability-arn`) au lieu des `services.k8s.aws/` balises utilisées par ACK autogéré. Consultez [Considérations relatives à l'ACK pour EKS](ack-considerations.md) la liste complète des balises de ressources par défaut.
**Compatibilité des ressources** : les ressources personnalisées ACK fonctionnent de la même manière que les ressources ACK en amont, sans aucune modification de vos fichiers YAML de ressources ACK. La fonctionnalité utilise les mêmes Kubernetes APIs et CRDs les outils `kubectl` fonctionnent donc de la même manière. Tous les contrôleurs GA et les ressources de l'ACK en amont sont pris en charge.
Pour consulter la documentation complète d'ACK et les guides spécifiques aux services, consultez la documentation [ACK](https://aws-controllers-k8s.github.io/community/).
## Voie de migration
Vous pouvez passer d'un ACK autogéré à une fonctionnalité gérée sans aucune interruption de service :
1. Mettez à jour votre contrôleur ACK autogéré pour l'utiliser `kube-system` pour les baux électoraux des dirigeants, par exemple :
```
helm upgrade --install ack-s3-controller \
oci://public.ecr.aws/aws-controllers-k8s/s3-chart \
--namespace ack-system \
--set leaderElection.namespace=kube-system
```
Cela déplace le bail du contrôleur vers`kube-system`, ce qui permet à la capacité gérée de se coordonner avec celui-ci.
1. Créez la fonctionnalité ACK sur votre cluster (voir[Création d'une fonctionnalité ACK](create-ack-capability.md))
1. La fonctionnalité gérée reconnaît les AWS ressources existantes gérées par ACK et prend en charge le rapprochement
1. Diminuez ou supprimez progressivement les déploiements de contrôleurs autogérés :
```
helm uninstall ack-s3-controller --namespace ack-system
```
Cette approche permet aux deux contrôleurs de coexister en toute sécurité pendant la migration. La fonctionnalité gérée adopte automatiquement les ressources précédemment gérées par des contrôleurs autogérés, garantissant ainsi un rapprochement continu sans conflits.
## Étapes suivantes
+ [Création d'une fonctionnalité ACK](create-ack-capability.md)- Création d'une ressource de capacité ACK
+ [Concepts d'ACK](ack-concepts.md)- Comprendre les concepts ACK et le cycle de vie des ressources
+ [Configurer les autorisations ACK](ack-permissions.md)- Configurer l'IAM et les autorisations
# Déploiement continu avec Argo CD
Argo CD est un outil de diffusion GitOps continue déclaratif pour Kubernetes. Avec Argo CD, vous pouvez automatiser le déploiement et la gestion du cycle de vie de vos applications sur plusieurs clusters et environnements. Argo CD prend en charge plusieurs types de sources, notamment les référentiels Git, les registres Helm (HTTP et OCI) et les images OCI, offrant ainsi de la flexibilité aux entreprises ayant des exigences de sécurité et de conformité différentes.
Grâce aux fonctionnalités d'EKS, Argo CD est entièrement géré par AWS, ce qui élimine le besoin d'installer, de maintenir et de dimensionner les contrôleurs Argo CD et leurs dépendances vis-à-vis de vos clusters.
## Comment fonctionne Argo CD
Argo CD suit le GitOps modèle selon lequel la source de votre application (dépôt Git, registre Helm ou image OCI) est la source fiable pour définir l'état souhaité de l'application. Lorsque vous créez une `Application` ressource Argo CD, vous spécifiez la source contenant les manifestes de votre application ainsi que le cluster et l'espace de noms Kubernetes cibles. Argo CD surveille en permanence l'état source et l'état réel du cluster, synchronisant automatiquement les modifications pour s'assurer que l'état du cluster correspond à l'état souhaité.
**Note**
Grâce à la fonctionnalité EKS pour Argo CD, le logiciel Argo CD s'exécute dans le plan de AWS contrôle, et non sur vos nœuds de travail. Cela signifie que vos nœuds de travail n'ont pas besoin d'un accès direct aux référentiels Git ou aux registres Helm : la fonctionnalité gère l'accès aux sources depuis le compte. AWS
Argo CD fournit trois types de ressources principaux :
+ **Application** : définit un déploiement depuis un dépôt Git vers un cluster cible
+ **ApplicationSet**: Génère plusieurs applications à partir de modèles pour les déploiements multi-clusters
+ **AppProject**: fournit un regroupement logique et un contrôle d'accès pour les applications
**Exemple : création d'une application Argo CD**
L'exemple suivant montre comment créer une `Application` ressource Argo CD :
```
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/argoproj/argocd-example-apps.git
targetRevision: HEAD
path: guestbook
destination:
name: in-cluster
namespace: guestbook
syncPolicy:
automated:
prune: true
selfHeal: true
```
**Note**
`destination.name`À utiliser avec le nom du cluster que vous avez utilisé lors de l'enregistrement du cluster (comme `in-cluster` pour le cluster local). Le `destination.server` champ fonctionne également avec le cluster EKS ARNs, mais il est recommandé d'utiliser des noms de clusters pour une meilleure lisibilité.
## Avantages d'Argo CD
Argo CD implémente un GitOps flux de travail dans lequel vous définissez les configurations de vos applications dans les référentiels Git et Argo CD synchronise automatiquement vos applications pour qu'elles correspondent à l'état souhaité. Cette approche centrée sur le GIT fournit une piste d'audit complète de toutes les modifications, permet des annulations faciles et s'intègre naturellement à vos processus de révision et d'approbation de code existants. Argo CD détecte et réconcilie automatiquement la dérive entre l'état souhaité dans Git et l'état réel dans vos clusters, garantissant ainsi la cohérence de vos déploiements avec votre configuration déclarée.
Avec Argo CD, vous pouvez déployer et gérer des applications sur plusieurs clusters à partir d'une seule instance Argo CD, ce qui simplifie les opérations dans les environnements multiclusters et multirégions. L'interface utilisateur d'Argo CD fournit des fonctionnalités de visualisation et de surveillance, vous permettant de visualiser l'état de déploiement, l'état de santé et l'historique de vos applications. L'interface utilisateur s'intègre à AWS Identity Center (anciennement AWS SSO) pour une authentification et une autorisation fluides, vous permettant de contrôler l'accès à l'aide de votre infrastructure de gestion des identités existante.
Dans le cadre des fonctionnalités gérées par EKS, Argo CD est entièrement géré par AWS, ce qui élimine le besoin d'installer, de configurer et de maintenir l'infrastructure Argo CD. AWS gère le dimensionnement, l'application de correctifs et la gestion opérationnelle, permettant à vos équipes de se concentrer sur la livraison des applications plutôt que sur la maintenance des outils.
## Intégration à AWS Identity Center
EKS Managed Capabilities fournit une intégration directe entre Argo CD et AWS Identity Center, permettant ainsi une authentification et une autorisation fluides pour vos utilisateurs. Lorsque vous activez la fonctionnalité Argo CD, vous pouvez configurer l'intégration AWS d'Identity Center pour mapper les groupes et les utilisateurs d'Identity Center aux rôles RBAC d'Argo CD, ce qui vous permet de contrôler qui peut accéder aux applications dans Argo CD et les gérer.
## Intégration avec d'autres fonctionnalités gérées par EKS
Argo CD s'intègre aux autres fonctionnalités gérées par EKS.
+ ** AWS Contrôleurs pour Kubernetes (ACK)** : utilisez Argo CD pour gérer le déploiement des ressources ACK sur plusieurs clusters, en activant les GitOps flux de travail pour votre infrastructure. AWS
+ **kro (Kube Resource Orchestrator)** : utilisez Argo CD pour déployer des compositions kro sur plusieurs clusters, permettant ainsi une composition cohérente des ressources dans l'ensemble de votre parc Kubernetes.
## Commencer à utiliser Argo CD
Pour commencer à utiliser la fonctionnalité EKS pour Argo CD :
1. Créez et configurez un rôle de capacité IAM avec les autorisations nécessaires pour qu'Argo CD puisse accéder à vos sources et gérer les applications.
1. [Créez une ressource de capacité Argo CD](create-argocd-capability.md) sur votre cluster EKS via la AWS console, la AWS CLI ou votre infrastructure préférée en tant qu'outil de code.
1. Configurez l'accès au référentiel et enregistrez les clusters pour le déploiement des applications.
1. Créez des ressources d'application pour déployer vos applications à partir de vos sources déclaratives.
# Création d’une fonctionnalité Argo CD
Cette rubrique explique comment créer une fonctionnalité Argo CD sur votre cluster Amazon EKS.
## Conditions préalables
Avant de créer une fonctionnalité Argo CD, assurez-vous de disposer des éléments suivants :
+ Un cluster Amazon EKS existant exécutant une version de Kubernetes prise en charge (toutes les versions du support standard et étendu sont prises en charge)
+ ** AWS Identity Center configuré** - Nécessaire pour l'authentification sur Argo CD (les utilisateurs locaux ne sont pas pris en charge)
+ Un rôle de capacité IAM avec des autorisations pour Argo CD
+ Autorisations IAM suffisantes pour créer des ressources de capacités sur les clusters EKS
+ `kubectl`configuré pour communiquer avec votre cluster
+ (Facultatif) L'Argo CD CLI est installée pour faciliter la gestion des clusters et des référentiels
+ (Pour CLI/ekSCTL) L'outil CLI approprié est installé et configuré
Pour obtenir des instructions sur la création du rôle de capacité IAM, consultez[Fonctionnalité Amazon EKS : rôle IAM](capability-role.md). Pour la configuration d'Identity Center, consultez [Getting Started with AWS Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html).
**Important**
Le rôle de capacité IAM que vous fournissez détermine les AWS ressources auxquelles Argo CD peut accéder. Cela inclut l'accès au dépôt Git via CodeConnections et les secrets dans Secrets Manager. Pour obtenir des conseils sur la création d'un rôle approprié avec des autorisations de moindre privilège, consultez [Fonctionnalité Amazon EKS : rôle IAM](capability-role.md) et. [Considérations relatives à la sécurité relatives aux fonctionnalités EKS](capabilities-security.md)
## Choisissez votre outil
Vous pouvez créer une fonctionnalité Argo CD à l'aide de la AWS Management Console AWS CLI ou de eksctl :
+ [Création d'une fonctionnalité Argo CD à l'aide de la console](argocd-create-console.md)- Utilisez la console pour une expérience guidée
+ [Création d'une fonctionnalité Argo CD à l'aide de la CLI AWS](argocd-create-cli.md)- Utilisez la AWS CLI pour la création de scripts et l'automatisation
+ [Création d'une fonctionnalité Argo CD à l'aide de eksctl](argocd-create-eksctl.md)- Utilisez eksctl pour une expérience native de Kubernetes
## Que se passe-t-il lorsque vous créez une fonctionnalité Argo CD
Lorsque vous créez une fonctionnalité Argo CD :
1. EKS crée le service de capacité Argo CD dans le plan de AWS contrôle
1. Des définitions de ressources personnalisées (CRDs) sont installées dans votre cluster
1. Une entrée d'accès est automatiquement créée pour votre rôle de capacité IAM avec des politiques d'entrée d'accès spécifiques aux fonctionnalités qui accordent des autorisations Kubernetes de base (voir) [Considérations relatives à la sécurité relatives aux fonctionnalités EKS](capabilities-security.md)
1. Argo CD commence à rechercher ses ressources personnalisées (Applications, ApplicationSets, AppProjects)
1. L'état de capacité passe de `CREATING` à `ACTIVE`
1. L'interface utilisateur d'Argo CD devient accessible via son URL
Une fois actives, vous pouvez créer des applications Argo CD dans votre cluster pour les déployer à partir de vos sources déclaratives.
**Note**
L'entrée d'accès créée automatiquement n'accorde pas l'autorisation de déployer des applications sur des clusters. Pour déployer des applications, vous devez configurer des autorisations Kubernetes RBAC supplémentaires pour chaque cluster cible. Consultez [Enregistrer les clusters cibles](argocd-register-clusters.md) pour plus de détails sur l'enregistrement des clusters et la configuration de l'accès.
## Étapes suivantes
Après avoir créé la fonctionnalité Argo CD :
+ [Concepts d'Argo CD](argocd-concepts.md)- Découvrez GitOps les principes, les politiques de synchronisation et les modèles multi-clusters
+ [Travailler avec Argo CD](working-with-argocd.md)- Configurer l'accès au référentiel, enregistrer les clusters cibles et créer des applications
+ [Considérations relatives à Argo CD](argocd-considerations.md)- Explorez les modèles d'architecture multi-clusters et la configuration avancée
# Création d'une fonctionnalité Argo CD à l'aide de la console
Cette rubrique décrit comment créer une fonctionnalité Argo CD à l'aide du AWS Management Console.
## Conditions préalables
+ ** AWS Identity Center configuré** : Argo CD nécessite AWS Identity Center pour l'authentification. Les utilisateurs locaux ne sont pas pris en charge. Si AWS Identity Center n'est pas configuré, consultez [Commencer à utiliser AWS Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html) pour créer une instance d'Identity Center, et [Ajouter des utilisateurs et Ajouter](https://docs.aws.amazon.com/singlesignon/latest/userguide/addusers.html) [des groupes](https://docs.aws.amazon.com/singlesignon/latest/userguide/addgroups.html) pour créer des utilisateurs et des groupes pour accéder à Argo CD.
## Création de la fonctionnalité Argo CD
1. Ouvrez la console Amazon EKS à l'adresse https://console.aws.amazon.com/eks/ home\$1/clusters.
1. Sélectionnez le nom de votre cluster pour ouvrir la page détaillée du cluster.
1. Choisissez l'onglet **Fonctionnalités**.
1. Dans le menu de navigation de gauche, choisissez **Argo CD**.
1. Choisissez la **fonctionnalité Create Argo CD.**
1. Pour le **rôle de capacité IAM** :
+ Si vous possédez déjà un rôle de capacité IAM, sélectionnez-le dans le menu déroulant
+ Si vous devez créer un rôle, choisissez **Créer un rôle Argo CD**
Cela ouvre la console IAM dans un nouvel onglet avec une politique de confiance préremplie et un accès complet en lecture à Secrets Manager. Aucune autre autorisation n'est ajoutée par défaut, mais vous pouvez les ajouter si nécessaire. Si vous prévoyez d'utiliser CodeCommit des référentiels ou d'autres AWS services, ajoutez les autorisations appropriées avant de créer le rôle.
Après avoir créé le rôle, retournez à la console EKS et le rôle sera automatiquement sélectionné.
**Note**
Si vous envisagez d'utiliser les intégrations facultatives avec AWS Secrets Manager or AWS CodeConnections, vous devrez ajouter des autorisations au rôle. Pour des exemples de politique IAM et des conseils de configuration, reportez-vous aux sections [Gérez les secrets des applications avec AWS Secrets Manager](integration-secrets-manager.md) et[Connectez-vous aux référentiels Git avec AWS CodeConnections](integration-codeconnections.md).
1. Configurer AWS l'intégration d'Identity Center :
1. Sélectionnez **Activer AWS l'intégration d'Identity Center**.
1. Choisissez votre instance Identity Center dans le menu déroulant.
1. Configurez les mappages de rôles pour RBAC en affectant des utilisateurs ou des groupes à des rôles Argo CD (ADMIN, EDITOR ou VIEWER)
1. Choisissez **Créer**.
Le processus de création de capacités commence.
## Vérifiez que la fonctionnalité est active
1. Dans l'onglet **Fonctionnalités**, consultez l'état des capacités de l'Argo CD.
1. Attendez que le statut passe de `CREATING` à`ACTIVE`.
1. Une fois active, la fonctionnalité est prête à être utilisée.
Pour plus d'informations sur l'état des fonctionnalités et la résolution des problèmes, consultez[Utilisation des ressources en matière de capacités](working-with-capabilities.md).
## Accédez à l'interface utilisateur d'Argo CD
Une fois la fonctionnalité activée, vous pouvez accéder à l'interface utilisateur d'Argo CD :
1. Sur la page des fonctionnalités d'Argo CD, choisissez **Ouvrir l'interface utilisateur d'Argo CD**.
1. L'interface utilisateur d'Argo CD s'ouvre dans un nouvel onglet du navigateur.
1. Vous pouvez désormais créer des applications et gérer les déploiements via l'interface utilisateur.
## Étapes suivantes
+ [Travailler avec Argo CD](working-with-argocd.md)- Configurer des référentiels, enregistrer des clusters et créer des applications
+ [Considérations relatives à Argo CD](argocd-considerations.md)- Architecture multi-clusters et configuration avancée
+ [Utilisation des ressources en matière de capacités](working-with-capabilities.md)- Gérez vos ressources de capacités Argo CD
# Création d'une fonctionnalité Argo CD à l'aide de la CLI AWS
Cette rubrique décrit comment créer une fonctionnalité Argo CD à l'aide de la AWS CLI.
## Conditions préalables
+ ** AWS CLI** : version `2.12.3` ou ultérieure. Pour vérifier votre version, lancez`aws --version`. Pour plus d'informations, consultez la section [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) dans le guide de l'utilisateur de l'interface de ligne de AWS commande.
+ ** `kubectl` ** : outil de ligne de commande pour travailler avec des clusters Kubernetes. Pour de plus amples informations, veuillez consulter [Configuration de `kubectl` et `eksctl`](install-kubectl.md).
+ ** AWS Identity Center configuré** : Argo CD nécessite AWS Identity Center pour l'authentification. Les utilisateurs locaux ne sont pas pris en charge. Si AWS Identity Center n'est pas configuré, consultez [Commencer à utiliser AWS Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html) pour créer une instance d'Identity Center, et [Ajouter des utilisateurs et Ajouter](https://docs.aws.amazon.com/singlesignon/latest/userguide/addusers.html) [des groupes](https://docs.aws.amazon.com/singlesignon/latest/userguide/addgroups.html) pour créer des utilisateurs et des groupes pour accéder à Argo CD.
## Étape 1 : Création d'un rôle de capacité IAM
Créez un fichier de politique de confiance :
```
cat > argocd-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
EOF
```
Créez le rôle IAM :
```
aws iam create-role \
--role-name ArgoCDCapabilityRole \
--assume-role-policy-document file://argocd-trust-policy.json
```
**Note**
Si vous envisagez d'utiliser les intégrations facultatives avec AWS Secrets Manager or AWS CodeConnections, vous devrez ajouter des autorisations au rôle. Pour des exemples de politique IAM et des conseils de configuration, reportez-vous aux sections [Gérez les secrets des applications avec AWS Secrets Manager](integration-secrets-manager.md) et[Connectez-vous aux référentiels Git avec AWS CodeConnections](integration-codeconnections.md).
## Étape 2 : Création de la fonctionnalité Argo CD
Créez la ressource de capacité Argo CD sur votre cluster.
Définissez d'abord les variables d'environnement pour la configuration de votre Identity Center :
```
# Get your Identity Center instance ARN (replace region if your IDC instance is in a different region)
export IDC_INSTANCE_ARN=$(aws sso-admin list-instances --region [.replaceable]`region` --query 'Instances[0].InstanceArn' --output text)
# Get a user ID for RBAC mapping (replace with your username and region if needed)
export IDC_USER_ID=$(aws identitystore list-users \
--region [.replaceable]`region` \
--identity-store-id $(aws sso-admin list-instances --region [.replaceable]`region` --query 'Instances[0].IdentityStoreId' --output text) \
--query 'Users[?UserName==`your-username`].UserId' --output text)
echo "IDC_INSTANCE_ARN=$IDC_INSTANCE_ARN"
echo "IDC_USER_ID=$IDC_USER_ID"
```
Créez la fonctionnalité grâce à l'intégration d'Identity Center. *region-code*Remplacez-le par la AWS région où se trouve votre cluster, *my-cluster* par le nom de votre cluster et *idc-region-code* par le code de région dans lequel votre centre d'identité IAM a été configuré :
```
aws eks create-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-argocd \
--type ARGOCD \
--role-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/ArgoCDCapabilityRole \
--delete-propagation-policy RETAIN \
--configuration '{
"argoCd": {
"awsIdc": {
"idcInstanceArn": "'$IDC_INSTANCE_ARN'",
"idcRegion": "'[.replaceable]`idc-region-code`'"
},
"rbacRoleMappings": [{
"role": "ADMIN",
"identities": [{
"id": "'$IDC_USER_ID'",
"type": "SSO_USER"
}]
}]
}
}'
```
La commande revient immédiatement, mais la fonctionnalité met un certain temps à devenir active car EKS crée l'infrastructure et les composants de capacité requis. EKS installera les définitions de ressources personnalisées Kubernetes associées à cette fonctionnalité dans votre cluster lors de sa création.
**Note**
Si vous recevez un message d'erreur indiquant que le cluster n'existe pas ou que vous n'êtes pas autorisé, vérifiez :
Le nom du cluster est correct
Votre AWS CLI est configurée pour la bonne région
Vous disposez des autorisations IAM requises
## Étape 3 : vérifier que la fonctionnalité est active
Attendez que la fonctionnalité soit activée. Remplacez *region-code* par la AWS région où se trouve votre cluster et *my-cluster* par le nom de votre cluster.
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-argocd \
--query 'capability.status' \
--output text
```
La fonctionnalité est prête lorsque l'état s'affiche`ACTIVE`. Ne passez pas à l'étape suivante tant que le statut n'est pas atteint`ACTIVE`.
Vous pouvez également consulter les détails complets des fonctionnalités :
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-argocd
```
## Étape 4 : vérifier que les ressources personnalisées sont disponibles
Une fois la fonctionnalité activée, vérifiez que les ressources personnalisées Argo CD sont disponibles dans votre cluster :
```
kubectl api-resources | grep argoproj.io
```
Vous devriez voir apparaître une liste `Application` `ApplicationSet` des types de ressources.
## Étapes suivantes
+ [Travailler avec Argo CD](working-with-argocd.md)- Configurer des référentiels, enregistrer des clusters et créer des applications
+ [Considérations relatives à Argo CD](argocd-considerations.md)- Architecture multi-clusters et configuration avancée
+ [Utilisation des ressources en matière de capacités](working-with-capabilities.md)- Gérez vos ressources de capacités Argo CD
# Création d'une fonctionnalité Argo CD à l'aide de eksctl
Cette rubrique décrit comment créer une fonctionnalité Argo CD à l'aide de eksctl.
**Note**
Les étapes suivantes nécessitent la version eksctl `0.220.0` ou une version ultérieure. Pour vérifier votre version, lancez`eksctl version`.
## Étape 1 : Création d'un rôle de capacité IAM
Créez un fichier de politique de confiance :
```
cat > argocd-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
EOF
```
Créez le rôle IAM :
```
aws iam create-role \
--role-name ArgoCDCapabilityRole \
--assume-role-policy-document file://argocd-trust-policy.json
```
**Note**
Pour cette configuration de base, aucune politique IAM supplémentaire n'est nécessaire. Si vous prévoyez d'utiliser Secrets Manager pour les informations d'identification du référentiel CodeConnections, vous devez également ajouter des autorisations au rôle. Pour des exemples de politique IAM et des conseils de configuration, reportez-vous aux sections [Gérez les secrets des applications avec AWS Secrets Manager](integration-secrets-manager.md) et[Connectez-vous aux référentiels Git avec AWS CodeConnections](integration-codeconnections.md).
## Étape 2 : obtenir la configuration de votre AWS Identity Center
Obtenez l'ARN et l'ID utilisateur de votre instance Identity Center pour la configuration du RBAC :
```
# Get your Identity Center instance ARN
aws sso-admin list-instances --query 'Instances[0].InstanceArn' --output text
# Get a user ID for admin access (replace 'your-username' with your Identity Center username)
aws identitystore list-users \
--identity-store-id $(aws sso-admin list-instances --query 'Instances[0].IdentityStoreId' --output text) \
--query 'Users[?UserName==`your-username`].UserId' --output text
```
Notez ces valeurs, vous en aurez besoin à l'étape suivante.
## Étape 3 : Création d'un fichier de configuration eksctl
Créez un fichier nommé `argocd-capability.yaml` avec le contenu suivant. Remplacez les valeurs de l'espace réservé par le nom de votre cluster, la région du cluster, l'ARN du rôle IAM, l'ARN de l'instance Identity Center, la région du centre d'identité et l'ID utilisateur :
```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: cluster-region-code
capabilities:
- name: my-argocd
type: ARGOCD
roleArn: arn:aws:iam::[.replaceable]111122223333:role/ArgoCDCapabilityRole
deletePropagationPolicy: RETAIN
configuration:
argocd:
awsIdc:
idcInstanceArn: arn:aws:sso:::instance/ssoins-123abc
idcRegion: idc-region-code
rbacRoleMappings:
- role: ADMIN
identities:
- id: 38414300-1041-708a-01af-5422d6091e34
type: SSO_USER
```
**Note**
Vous pouvez ajouter plusieurs utilisateurs ou groupes aux mappages RBAC. Pour les groupes, utilisez `type: SSO_GROUP` et fournissez l'ID du groupe. Les rôles disponibles sont `ADMIN``EDITOR`, et`VIEWER`.
## Étape 4 : Création de la fonctionnalité Argo CD
Appliquez le fichier de configuration :
```
eksctl create capability -f argocd-capability.yaml
```
La commande revient immédiatement, mais la fonctionnalité met un certain temps à devenir active.
## Étape 5 : vérifier que la fonctionnalité est active
Vérifiez l'état des capacités. Remplacez *region-code* par la AWS région dans laquelle se trouve votre cluster et remplacez *my-cluster* par le nom de votre cluster.
```
eksctl get capability \
--region region-code \
--cluster my-cluster \
--name my-argocd
```
La fonctionnalité est prête lorsque l'état s'affiche`ACTIVE`.
## Étape 6 : vérifier que les ressources personnalisées sont disponibles
Une fois la fonctionnalité activée, vérifiez que les ressources personnalisées Argo CD sont disponibles dans votre cluster :
```
kubectl api-resources | grep argoproj.io
```
Vous devriez voir apparaître une liste `Application` `ApplicationSet` des types de ressources.
## Étapes suivantes
+ [Travailler avec Argo CD](working-with-argocd.md)- Apprenez à créer et à gérer des applications Argo CD
+ [Considérations relatives à Argo CD](argocd-considerations.md)- Configurer l'accès SSO et multi-clusters
+ [Utilisation des ressources en matière de capacités](working-with-capabilities.md)- Gérez vos ressources de capacités Argo CD
# Concepts d'Argo CD
Argo CD implémente Git GitOps en considérant Git comme la seule source fiable pour vos déploiements d'applications. Cette rubrique présente un exemple pratique, puis explique les concepts de base que vous devez comprendre lorsque vous travaillez avec l'EKS Capability for Argo CD.
## Commencer à utiliser Argo CD
Après avoir créé la fonctionnalité Argo CD (voir[Création d’une fonctionnalité Argo CD](create-argocd-capability.md)), vous pouvez commencer à déployer des applications. Cet exemple décrit l'enregistrement d'un cluster et la création d'une application.
### Étape 1 : Configurer
**Enregistrez votre cluster** (obligatoire)
Enregistrez le cluster dans lequel vous souhaitez déployer des applications. Dans cet exemple, nous allons enregistrer le même cluster sur lequel Argo CD est exécuté (vous pouvez utiliser le nom `in-cluster` pour des raisons de compatibilité avec la plupart des exemples d'Argo CD) :
```
# Get your cluster ARN
CLUSTER_ARN=$(aws eks describe-cluster \
--name my-cluster \
--query 'cluster.arn' \
--output text)
# Register the cluster using Argo CD CLI
argocd cluster add $CLUSTER_ARN \
--aws-cluster-name $CLUSTER_ARN \
--name in-cluster \
--project default
```
**Note**
Pour plus d'informations sur la configuration de l'Argo CD CLI pour qu'elle fonctionne avec la fonctionnalité Argo CD dans EKS, consultez. [Utilisation de l'Argo CD CLI avec la fonctionnalité gérée](argocd-comparison.md#argocd-cli-configuration)
Vous pouvez également enregistrer le cluster à l'aide d'un secret Kubernetes (voir [Enregistrer les clusters cibles](argocd-register-clusters.md) pour plus de détails).
**Configurer l'accès au référentiel** (facultatif)
Cet exemple utilise un GitHub référentiel public, aucune configuration de référentiel n'est donc requise. Pour les référentiels privés, configurez l'accès à l'aide de AWS Secrets Manager ou de Kubernetes Secrets (voir [Configuration de l'accès au référentiel](argocd-configure-repositories.md) pour plus de détails). CodeConnections
Pour les AWS services (ECR pour les graphiques Helm CodeConnections, et CodeCommit), vous pouvez les référencer directement dans les ressources de l'application sans créer de référentiel. Le rôle de capacité doit disposer des autorisations IAM requises. Consultez [Configuration de l'accès au référentiel](argocd-configure-repositories.md) pour plus de détails.
### Étape 2 : Créer une application
Créez ce manifeste d'application dans `my-app.yaml` :
```
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/argoproj/argocd-example-apps.git
targetRevision: HEAD
path: guestbook
destination:
name: in-cluster
namespace: guestbook
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true
```
Appliquez l'application :
```
kubectl apply -f my-app.yaml
```
Après avoir appliqué cette application, Argo CD : 1. Synchronise l'application de Git avec votre cluster (déploiement initial) 2. Surveille les modifications apportées au dépôt Git 3. Synchronise automatiquement les modifications ultérieures sur votre cluster 4. Détecte et corrige toute dérive par rapport à l'état souhaité 5. Fournit l'état de santé et l'historique de synchronisation dans l'interface utilisateur
Consultez le statut de la demande :
```
kubectl get application guestbook -n argocd
```
Vous pouvez également afficher l'application à l'aide de l'interface de ligne de commande Argo CD ou de l'interface utilisateur du CD Argo (accessible depuis la console EKS sous l'onglet Capabilities de votre cluster).
**Note**
Lorsque vous utilisez l'Argo CD CLI avec la fonctionnalité gérée, spécifiez les applications avec le préfixe d'espace de noms :. `argocd app get argocd/guestbook`
**Note**
Utilisez le nom du cluster dans `destination.name` (le nom que vous avez utilisé lors de l'enregistrement du cluster). La fonctionnalité gérée ne prend pas en charge la valeur par défaut locale au sein du cluster (`kubernetes.default.svc`).
## Concepts de base
### GitOps principes et types de sources
Argo CD implémente GitOps, où la source de votre application est la seule source fiable pour les déploiements :
+ **Déclaratif** - L'état souhaité est déclaré à l'aide de manifestes YAML, de graphiques Helm ou de superpositions Kustomize
+ **Versionné** : chaque modification est suivie grâce à une piste d'audit complète
+ **Automatisé** : Argo CD surveille en permanence les sources et synchronise automatiquement les modifications
+ **Autoréparation** : détecte et corrige le décalage entre l'état souhaité et l'état réel du cluster
**Types de sources pris** en charge :
+ **Référentiels Git** - GitHub GitLab, Bitbucket, CodeCommit (HTTPS, SSH ou) CodeConnections
+ **Registres Helm : registres** HTTP (similaires`https://aws.github.io/eks-charts`) et registres OCI (similaires) `public.ecr.aws`
+ Images **OCI : images** de conteneurs contenant des manifestes ou des diagrammes Helm (similaires`oci://registry-1.docker.io/user/my-app`)
Cette flexibilité permet aux entreprises de choisir les sources qui répondent à leurs exigences de sécurité et de conformité. Par exemple, les organisations qui limitent l'accès à Git depuis les clusters peuvent utiliser l'ECR pour les diagrammes Helm ou les images OCI.
Pour plus d'informations, consultez la section [Sources d'applications](https://argo-cd.readthedocs.io/en/stable/user-guide/application-sources/) dans la documentation Argo CD.
### Synchronisation et réconciliation
Argo CD surveille en permanence vos sources et vos clusters afin de détecter et de corriger les différences :
1. Interroge les sources pour connaître les modifications (par défaut : toutes les 6 minutes)
1. Compare l'état souhaité avec l'état du cluster
1. Marque les applications comme `Synced` ou `OutOfSync`
1. Synchronise les modifications automatiquement (si elles sont configurées) ou attend une approbation manuelle
1. Surveille l'état des ressources après la synchronisation
**Les ondes de synchronisation** contrôlent l'ordre de création des ressources à l'aide d'annotations :
```
metadata:
annotations:
argocd.argoproj.io/sync-wave: "0" # Default if not specified
```
Les ressources sont appliquées par ordre de vague (les nombres les plus bas d'abord, y compris les nombres négatifs comme`-1`). Wave `0` est la valeur par défaut si elle n'est pas spécifiée. Cela vous permet de créer des dépendances telles que des espaces de noms (wave`-1`) avant les déploiements (wave`0`) avant les services (wave`1`).
**L'autoréparation** annule automatiquement les modifications manuelles :
```
spec:
syncPolicy:
automated:
selfHeal: true
```
**Note**
La fonctionnalité gérée utilise le suivi des ressources basé sur les annotations (et non sur les étiquettes) pour une meilleure compatibilité avec les conventions Kubernetes et les autres outils.
Pour des informations détaillées sur les phases de synchronisation, les hooks et les modèles avancés, consultez la [documentation de synchronisation Argo CD](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-waves/).
### État de santé des applications
Argo CD surveille l'état de toutes les ressources de votre application :
**État de santé :\$1** **Sain** - Toutes les ressources fonctionnent comme prévu \$1 **Progression** - Ressources en cours de création ou de mise à jour \$1 **Dégradée** - Certaines ressources ne sont pas saines (pods tombent en panne, tâches échouent) \$1 **Suspendue** - Application interrompue intentionnellement \$1 **Manquante** - Les ressources définies dans Git ne sont pas présentes dans le cluster
Argo CD intègre des contrôles de santé pour les ressources Kubernetes courantes (déploiements, tâches StatefulSets, etc.) et prend en charge les contrôles de santé personnalisés pour. CRDs
L'état de santé de l'application est déterminé par toutes ses ressources. Si une ressource l'est`Degraded`, c'est bien l'application qui l'est`Degraded`.
Pour plus d'informations, consultez [Resource Health](https://argo-cd.readthedocs.io/en/stable/operator-manual/health/) dans la documentation d'Argo CD.
### Modèles multi-clusters
Argo CD prend en charge deux modèles de déploiement principaux :
**H ub-and-spoke** - Exécutez Argo CD sur un cluster de gestion dédié qui se déploie sur plusieurs clusters de charge de travail :\$1 Contrôle et visibilité centralisés \$1 Politiques cohérentes sur tous les clusters \$1 Une instance Argo CD à gérer \$1 Séparation claire entre le plan de contrôle et les charges de travail
**Par cluster** : exécutez Argo CD sur chaque cluster, en gérant uniquement les applications de ce cluster :\$1 Séparation des clusters (une défaillance n'affecte pas les autres) \$1 Simplification du réseau (aucune communication entre clusters) \$1 Configuration initiale plus facile (pas d'enregistrement du cluster)
Choisissez hub-and-spoke pour les équipes de plateforme qui gèrent de nombreux clusters, ou par cluster pour les équipes indépendantes ou lorsque les clusters doivent être complètement isolés.
Pour une configuration multicluster détaillée, voir[Considérations relatives à Argo CD](argocd-considerations.md).
### Projets
Les projets fournissent un regroupement logique et un contrôle d'accès pour les applications :
+ **Restrictions relatives aux sources** - Limitez les référentiels Git pouvant être utilisés
+ **Restrictions de destination** : limitez les clusters et les espaces de noms pouvant être ciblés
+ **Restrictions de ressources** : limitez les types de ressources Kubernetes pouvant être déployés
+ **Intégration RBAC : associez** les projets à l'utilisateur et au groupe AWS Identity Center IDs
Les candidatures appartiennent à un seul projet. S'il n'est pas spécifié, ils utilisent le `default` projet, qui n'est soumis à aucune restriction par défaut. Pour une utilisation en production, modifiez le `default` projet pour en restreindre l'accès et créez de nouveaux projets avec les restrictions appropriées.
Pour la configuration du projet et les modèles RBAC, voir[Configurer les autorisations d'Argo CD](argocd-permissions.md).
### Options de synchronisation
Ajustez le comportement de synchronisation à l'aide des options courantes :
+ `CreateNamespace=true`- Création automatique d'un espace de noms de destination
+ `ServerSideApply=true`- Utilisez l'application côté serveur pour une meilleure résolution des conflits
+ `SkipDryRunOnMissingResource=true`- Ignorez l'exécution à sec lorsque cela CRDs n'existe pas encore (utile pour les instances Kro)
```
spec:
syncPolicy:
syncOptions:
- CreateNamespace=true
- ServerSideApply=true
- SkipDryRunOnMissingResource=true
```
Pour une liste complète des options de synchronisation, consultez la [documentation des options de synchronisation Argo CD](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-options/).
## Étapes suivantes
+ [Configuration de l'accès au référentiel](argocd-configure-repositories.md)- Configurer l'accès au dépôt Git
+ [Enregistrer les clusters cibles](argocd-register-clusters.md)- Enregistrez les clusters cibles pour le déploiement
+ [Création d'applications](argocd-create-application.md)- Créez votre première application
+ [Considérations relatives à Argo CD](argocd-considerations.md)- Modèles spécifiques à EKS, intégration d'Identity Center et configuration multi-clusters
+ Documentation [Argo CD - Documentation](https://argo-cd.readthedocs.io/en/stable/) complète sur Argo CD, y compris les crochets de synchronisation, les contrôles de santé et les modèles avancés
# Configurer les autorisations d'Argo CD
La fonctionnalité gérée par Argo CD s'intègre à AWS Identity Center pour l'authentification et utilise des rôles RBAC intégrés pour l'autorisation. Cette rubrique explique comment configurer les autorisations pour les utilisateurs et les équipes.
## Comment fonctionnent les autorisations avec Argo CD
La fonctionnalité Argo CD utilise AWS Identity Center pour l'authentification et fournit trois rôles RBAC intégrés pour l'autorisation.
Lorsqu'un utilisateur accède à Argo CD :
1. Ils s'authentifient à l'aide AWS d'Identity Center (qui peut être fédéré auprès de votre fournisseur d'identité d'entreprise)
1. AWS Identity Center fournit des informations sur les utilisateurs et les groupes à Argo CD
1. Argo CD associe les utilisateurs et les groupes aux rôles RBAC en fonction de votre configuration
1. Les utilisateurs ne voient que les applications et les ressources auxquelles ils sont autorisés à accéder
## Rôles RBAC intégrés
La fonctionnalité Argo CD fournit trois rôles intégrés que vous pouvez associer aux utilisateurs et aux groupes AWS d'Identity Center. Il s'agit de **rôles de portée mondiale** qui contrôlent l'accès aux ressources Argo CD telles que les projets, les clusters et les référentiels.
**Important**
Les rôles globaux contrôlent l'accès à Argo CD lui-même, et non aux ressources liées au projet, telles que les applications. Les utilisateurs de EDITOR et VIEWER ne peuvent pas voir ou gérer les applications par défaut. Ils ont besoin de rôles de projet pour accéder aux ressources spécifiques au projet. Consultez [Rôles du projet et accès délimité par le projet](#project-roles) pour plus de détails sur l'octroi de l'accès aux applications et à d'autres ressources liées au projet.
**ADMINISTRATEUR**
Accès complet à toutes les ressources et à tous les paramètres d'Argo CD :
+ Créez, mettez à jour et supprimez des applications et ApplicationSets dans n'importe quel projet
+ Gérer la configuration d'Argo CD
+ Enregistrez et gérez les clusters cibles de déploiement
+ Configuration de l'accès au référentiel
+ Création et gestion de projets
+ Afficher l'état et l'historique de toutes les demandes
+ Répertorier et accéder à tous les clusters et référentiels
**RÉDACTEUR**
Peut mettre à jour des projets et configurer les rôles des projets, mais ne peut pas modifier les paramètres globaux d'Argo CD :
+ Mettre à jour les projets existants (impossible de créer ou de supprimer des projets)
+ Configuration des rôles et des autorisations du projet
+ Afficher les clés et certificats GPG
+ Impossible de modifier la configuration globale d'Argo CD
+ Impossible de gérer directement les clusters ou les référentiels
+ Impossible de voir ou de gérer les applications sans rôles dans le projet
**SPECTATEUR**
Accès en lecture seule aux ressources Argo CD :
+ Afficher les configurations de projet
+ Répertorier tous les projets (y compris les projets auxquels l'utilisateur n'est pas affecté)
+ Afficher les clés et certificats GPG
+ Impossible de répertorier les clusters ou les référentiels
+ Impossible d'apporter des modifications
+ Impossible de voir ou de gérer les applications sans rôles dans le projet
**Note**
Pour accorder aux utilisateurs EDITOR ou VIEWER l'accès aux applications, un ADMINISTRATEUR ou un ÉDITEUR doit créer des rôles de projet qui associent les groupes Identity Center à des autorisations spécifiques au sein d'un projet.
## Rôles du projet et accès délimité par le projet
Les rôles globaux (ADMIN, EDITOR, VIEWER) contrôlent l'accès à Argo CD lui-même. Les rôles de projet contrôlent l'accès aux ressources et aux capacités au sein d'un projet spécifique, notamment :
+ **Ressources** : applications, informations d'identification du référentiel ApplicationSets, informations d'identification du cluster
+ **Fonctionnalités** : accès aux journaux, accès exec aux modules de l'application
**Comprendre le modèle d'autorisation à deux niveaux** :
+ **Portée globale** : les rôles intégrés déterminent ce que les utilisateurs peuvent faire avec les projets, les clusters, les référentiels et les paramètres d'Argo CD
+ **Portée du** projet : les rôles du projet déterminent ce que les utilisateurs peuvent faire avec les ressources et les capacités d'un projet spécifique
Autrement dit :
+ Les utilisateurs ADMIN peuvent accéder à toutes les ressources et fonctionnalités du projet sans configuration supplémentaire
+ Les utilisateurs EDITOR et VIEWER doivent se voir attribuer des rôles de projet pour accéder aux ressources et aux capacités du projet
+ Les utilisateurs de l'ÉDITEUR peuvent créer des rôles de projet pour s'accorder, ainsi qu'à d'autres, un accès au sein de projets qu'ils peuvent mettre à jour
**Exemple de flux de travail** :
1. Un ADMINISTRATEUR associe un groupe Identity Center au rôle EDITOR à l'échelle mondiale
1. Un ADMIN crée un projet pour une équipe
1. L'ÉDITEUR configure les rôles du projet au sein de ce projet pour permettre aux membres de l'équipe d'accéder aux ressources définies dans le cadre du projet.
1. Les membres de l'équipe (qui peuvent avoir un rôle global VIEWER) peuvent désormais voir et gérer les applications de ce projet en fonction de leurs autorisations de rôle dans le projet
Pour plus de détails sur la configuration des rôles du projet, consultez[Contrôle d'accès basé sur le projet](#_project_based_access_control).
## Configuration des mappages de rôles
Associez les utilisateurs et les groupes AWS d'Identity Center aux rôles Argo CD lors de la création ou de la mise à jour de la fonctionnalité.
**Exemple de mappage des rôles** :
```
{
"rbacRoleMapping": {
"ADMIN": ["AdminGroup", "alice@example.com"],
"EDITOR": ["DeveloperGroup", "DevOpsTeam"],
"VIEWER": ["ReadOnlyGroup", "bob@example.com"]
}
}
```
**Note**
Les noms de rôles distinguent les majuscules des minuscules et doivent être en majuscules (ADMIN, EDITOR, VIEWER).
**Important**
L'intégration d'EKS Capabilities à AWS Identity Center prend en charge jusqu'à 1 000 identités par fonctionnalité Argo CD. Une identité peut être un utilisateur ou un groupe.
**Mettre à jour les mappages de rôles** :
```
aws eks update-capability \
--region us-east-1 \
--cluster-name cluster \
--capability-name capname \
--endpoint "https://eks.ap-northeast-2.amazonaws.com" \
--role-arn "arn:aws:iam::[.replaceable]111122223333:role/[.replaceable]`EKSCapabilityRole`" \
--configuration '{
"argoCd": {
"rbacRoleMappings": {
"addOrUpdateRoleMappings": [
{
"role": "ADMIN",
"identities": [
{ "id": "686103e0-f051-7068-b225-e6392b959d9e", "type": "SSO_USER" }
]
}
]
}
}
}'
```
## Utilisation du compte administrateur
Le compte administrateur est conçu pour la configuration initiale et les tâches administratives telles que l'enregistrement de clusters et la configuration de référentiels.
**Lorsque le compte administrateur est approprié** :
+ Configuration et configuration initiales des fonctionnalités
+ Développement en solo ou démonstrations rapides
+ Tâches administratives (enregistrement du cluster, configuration du référentiel, création de projets)
**Bonnes pratiques pour le compte administrateur** :
+ Ne confiez pas les jetons de compte au contrôle de version
+ Faites pivoter les jetons immédiatement s'ils sont exposés
+ Limitez l'utilisation des jetons de compte aux tâches de configuration et d'administration
+ Définissez des délais d'expiration courts (maximum 12 heures)
+ Seuls 5 jetons de compte peuvent être créés à un moment donné
**Quand utiliser plutôt l'accès basé sur le projet** :
+ Environnements de développement partagés avec plusieurs utilisateurs
+ Tout environnement similaire à celui de la production
+ Lorsque vous avez besoin de pistes d'audit pour savoir qui a effectué des actions
+ Lorsque vous devez appliquer des restrictions de ressources ou des limites d'accès
Pour les environnements de production et les scénarios multi-utilisateurs, utilisez le contrôle d'accès basé sur le projet avec des rôles RBAC dédiés mappés aux groupes Identity Center. AWS
## Contrôle d'accès basé sur le projet
Utilisez Argo CD Projects (AppProject) pour fournir un contrôle d'accès précis et une isolation des ressources aux équipes.
**Important**
Avant d'affecter des utilisateurs ou des groupes à des rôles spécifiques au projet, vous devez d'abord les associer à un rôle Argo CD global (ADMIN, EDITOR ou VIEWER) dans la configuration des fonctionnalités. Les utilisateurs ne peuvent pas accéder à Argo CD sans mappage global des rôles, même s'ils sont affectés à des rôles de projet.
Envisagez de mapper les utilisateurs au rôle VIEWER de manière globale, puis d'accorder des autorisations supplémentaires via des rôles spécifiques au projet. Cela fournit un accès de base tout en permettant un contrôle précis au niveau du projet.
Les projets fournissent :
+ **Restrictions relatives aux sources** : limite les référentiels Git pouvant être utilisés
+ **Restrictions de destination** : limitez les clusters et les espaces de noms pouvant être ciblés
+ **Restrictions de ressources** : limitez les types de ressources Kubernetes pouvant être déployés
+ **Intégration RBAC : associez** les projets à des groupes AWS Identity Center ou à des rôles Argo CD
**Exemple de projet pour isoler une équipe** :
```
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: team-a
namespace: argocd
spec:
description: Team A applications
# Required: Specify which namespaces this project watches for Applications
sourceNamespaces:
- argocd
# Source restrictions
sourceRepos:
- https://github.com/myorg/team-a-apps
# Destination restrictions
destinations:
- namespace: team-a-*
server: arn:aws:eks:us-west-2:111122223333:cluster/production
# Resource restrictions
clusterResourceWhitelist:
- group: ''
kind: Namespace
namespaceResourceWhitelist:
- group: 'apps'
kind: Deployment
- group: ''
kind: Service
- group: ''
kind: ConfigMap
```
### Espaces de noms sources
Lorsque vous utilisez la fonctionnalité EKS Argo CD, le `spec.sourceNamespaces` champ est obligatoire dans AppProject les définitions. Ce champ indique quel espace de noms peut contenir des applications ou ApplicationSets qui font référence à ce projet.
**Important**
La fonctionnalité EKS Argo CD ne prend en charge qu'un seul espace de noms pour les applications, à savoir l'espace de ApplicationSets noms que vous avez spécifié lors de la création de la fonctionnalité (généralement). `argocd` Cela diffère de l'Argo CD open source qui prend en charge plusieurs espaces de noms.
**AppProject configuration**
Tous AppProjects doivent inclure l'espace de noms configuré pour la fonctionnalité dans `sourceNamespaces` :
```
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: team-a-project
namespace: argocd
spec:
description: Applications for Team A
# Required: Specify the capability's configured namespace (configuration.argoCd.namespace)
sourceNamespaces:
- argocd # Must match your capability's namespace configuration
# Source repositories this project can deploy from
sourceRepos:
- 'https://github.com/my-org/team-a-*'
# Destination restrictions
destinations:
- namespace: 'team-a-*'
server: arn:aws:eks:us-west-2:111122223333:cluster/my-cluster
```
**Note**
Si vous omettez l'espace de noms de la fonctionnalité dans`sourceNamespaces`, les applications ou ApplicationSets dans cet espace de noms ne peuvent pas faire référence à ce projet, ce qui entraîne des échecs de déploiement.
**Affecter des utilisateurs à des projets** :
Les rôles de projet permettent aux utilisateurs de EDITOR et VIEWER d'accéder aux ressources du projet (applications ApplicationSets, informations d'identification du référentiel et du cluster) et aux fonctionnalités (journaux, exec) du projet. Sans rôles de projet, ces utilisateurs ne peuvent pas accéder à ces ressources même s'ils disposent d'un accès global aux rôles.
Les utilisateurs ADMIN ont accès à toutes les applications sans avoir besoin de rôles de projet.
**Exemple : accorder l'accès à l'application aux membres de l'équipe**
```
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: team-a
namespace: argocd
spec:
# ... project configuration ...
sourceNamespaces:
- argocd
# Project roles grant Application-level access
roles:
- name: developer
description: Team A developers - can manage Applications
policies:
- p, proj:team-a:developer, applications, *, team-a/*, allow
- p, proj:team-a:developer, clusters, get, *, allow # See cluster names in UI
groups:
- 686103e0-f051-7068-b225-e6392b959d9e # Identity Center group ID
- name: viewer
description: Team A viewers - read-only Application access
policies:
- p, proj:team-a:viewer, applications, get, team-a/*, allow
- p, proj:team-a:viewer, clusters, get, *, allow # See cluster names in UI
groups:
- 786203e0-f051-7068-b225-e6392b959d9f # Identity Center group ID
```
**Note**
Incluez `clusters, get, *, allow` les rôles dans le projet pour permettre aux utilisateurs de voir les noms des clusters dans l'interface utilisateur. Sans cette autorisation, le cluster de destination s'affiche comme « inconnu ».
**Comprendre les politiques relatives aux rôles du projet** :
Le format de la politique est le suivant : `p, proj::, , ,