**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.
# 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