

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.

# Modules complémentaires
<a name="addons"></a>

Cette rubrique décrit comment gérer les modules complémentaires Amazon EKS pour vos clusters Amazon EKS à l'aide d'eksctl. Les modules complémentaires EKS sont une fonctionnalité qui vous permet d'activer et de gérer le logiciel opérationnel Kubernetes via l'API EKS, simplifiant ainsi le processus d'installation, de configuration et de mise à jour des modules complémentaires de cluster.

**Avertissement**  
eksctl installe désormais des addons par défaut (vpc-cni, coredns, kube-proxy) en tant qu'addons EKS au lieu d'addons autogérés. Cela signifie que vous devez utiliser des commandes à la `eksctl update addon` place des `eksctl utils update-*` commandes pour les clusters créés avec eksctl v0.184.0 et versions ultérieures.

Vous pouvez créer des clusters sans aucun addon réseau par défaut lorsque vous souhaitez utiliser des plugins CNI alternatifs tels que Cilium et Calico.

Les modules complémentaires EKS prennent désormais en charge la réception d'autorisations IAM via EKS Pod Identity Associations, ce qui leur permet de se connecter aux services AWS en dehors du cluster

## Création d'addons
<a name="addons-create"></a>

Eksctl offre plus de flexibilité pour gérer les extensions de cluster :

Dans votre fichier de configuration, vous pouvez spécifier les extensions que vous souhaitez et (si nécessaire) le rôle ou les politiques à leur associer :

```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: example-cluster
  region: us-west-2

iam:
  withOIDC: true

addons:
- name: vpc-cni
  # all below properties are optional
  version: 1.7.5
  tags:
    team: eks
  # you can specify at most one of:
  attachPolicyARNs:
  - arn:aws:iam::account:policy/AmazonEKS_CNI_Policy
  # or
  serviceAccountRoleARN: arn:aws:iam::account:role/AmazonEKSCNIAccess
  # or
  attachPolicy:
    Statement:
    - Effect: Allow
      Action:
      - ec2:AssignPrivateIpAddresses
      - ec2:AttachNetworkInterface
      - ec2:CreateNetworkInterface
      - ec2:DeleteNetworkInterface
      - ec2:DescribeInstances
      - ec2:DescribeTags
      - ec2:DescribeNetworkInterfaces
      - ec2:DescribeInstanceTypes
      - ec2:DetachNetworkInterface
      - ec2:ModifyNetworkInterfaceAttribute
      - ec2:UnassignPrivateIpAddresses
      Resource: '*'
```

Vous pouvez spécifier au plus l'une des valeurs `attachPolicy` suivantes : `attachPolicyARNs` et`serviceAccountRoleARN`.

Si aucune de ces options n'est spécifiée, l'addon sera créé avec un rôle auquel sont associées toutes les politiques recommandées.

**Note**  
Pour associer des politiques aux modules complémentaires, votre cluster doit avoir été `OIDC` activé. S'il n'est pas activé, nous ignorons les politiques associées.

Vous pouvez ensuite créer ces addons lors du processus de création du cluster :

```
eksctl create cluster -f config.yaml
```

Ou créez les addons de manière explicite après la création du cluster à l'aide du fichier de configuration ou des indicateurs de la CLI :

```
eksctl create addon -f config.yaml
```

```
eksctl create addon --name vpc-cni --version 1.7.5 --service-account-role-arn <role-arn>
```

```
eksctl create addon --name aws-ebs-csi-driver --namespace-config 'namespace=custom-namespace'
```

**Astuce**  
Utilisez l'`--namespace-config`indicateur pour déployer des modules complémentaires dans un espace de noms personnalisé au lieu de l'espace de noms par défaut.

Lors de la création de l'addon, si une version autogérée de l'addon existe déjà sur le cluster, vous pouvez choisir comment les `configMap` conflits potentiels doivent être résolus en définissant une `resolveConflicts` option via le fichier de configuration, par ex.

```
addons:
- name: vpc-cni
  attachPolicyARNs:
    - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
  resolveConflicts: overwrite
```

Pour la création d'un addon, le `resolveConflicts` champ prend en charge trois valeurs distinctes :
+  `none`- EKS ne modifie pas la valeur. La création risque d'échouer.
+  `overwrite`- EKS remplace toutes les modifications de configuration aux valeurs par défaut d'EKS.
+  `preserve`- EKS ne modifie pas la valeur. La création risque d'échouer. (Identique`none`, mais différent de la [mise `preserve` à jour des addons](#update-addons)).

## Répertorier les addons activés
<a name="_listing_enabled_addons"></a>

Vous pouvez voir quels modules complémentaires sont activés dans votre cluster en exécutant :

```
eksctl get addons --cluster <cluster-name>
```

or

```
eksctl get addons -f config.yaml
```

## Configuration de la version de l'addon
<a name="_setting_the_addons_version"></a>

La définition de la version de l'addon est facultative. Si le `version` champ est laissé vide, la version par défaut de l'addon `eksctl` sera résolue. Vous trouverez plus d'informations sur la version par défaut pour des modules complémentaires spécifiques dans la documentation AWS relative à EKS. Notez que la version par défaut n'est pas nécessairement la dernière version disponible.

La version de l'addon peut être définie sur. `latest` La version peut également être définie avec la balise de construction EKS spécifiée, telle que `v1.7.5-eksbuild.1` ou`v1.7.5-eksbuild.2`. Il peut également être défini sur la version finale de l'addon, telle que `v1.7.5` ou`1.7.5`, et la balise de `eksbuild` suffixe sera découverte et définie pour vous.

Consultez la section ci-dessous pour savoir comment découvrir les extensions disponibles et leurs versions.

## Découvrir les addons
<a name="_discovering_addons"></a>

Vous pouvez découvrir quels modules complémentaires peuvent être installés sur votre cluster en exécutant :

```
eksctl utils describe-addon-versions --cluster <cluster-name>
```

Cela permettra de découvrir la version de Kubernetes de votre cluster et de filtrer en fonction de celle-ci. Sinon, si vous voulez voir quels addons sont disponibles pour une version particulière de Kubernetes, vous pouvez exécuter :

```
eksctl utils describe-addon-versions --kubernetes-version <version>
```

Vous pouvez également découvrir des addons en filtrant sur leur`type`, `owner` and/or `publisher`. Par exemple, pour voir les addons pour un propriétaire et un type particuliers, vous pouvez exécuter :

```
eksctl utils describe-addon-versions --kubernetes-version 1.22 --types "infra-management, policy-management" --owners "aws-marketplace"
```

Les `types` `publishers` indicateurs `owners` et sont facultatifs et peuvent être spécifiés ensemble ou individuellement pour filtrer les résultats.

## Découverte du schéma de configuration des addons
<a name="_discovering_the_configuration_schema_for_addons"></a>

Après avoir découvert l'addon et la version, vous pouvez consulter les options de personnalisation en récupérant son schéma de configuration JSON.

```
eksctl utils describe-addon-configuration --name vpc-cni --version v1.12.0-eksbuild.1
```

Cela renvoie un schéma JSON des différentes options disponibles pour cet addon.

## Utilisation des valeurs de configuration
<a name="_working_with_configuration_values"></a>

 `ConfigurationValues`peuvent être fournis dans le fichier de configuration lors de la création ou de la mise à jour des addons. Seuls les formats JSON et YAML sont pris en charge.

Pour, par exemple. ,

```
addons:
- name: coredns
  configurationValues: |-
    replicaCount: 2
```

```
addons:
- name: coredns
  version: latest
  configurationValues: "{\"replicaCount\":3}"
  resolveConflicts: overwrite
```

**Note**  
N'oubliez pas que lorsque les valeurs de configuration des modules complémentaires sont modifiées, des conflits de configuration peuvent survenir.

```
Thus, we need to specify how to deal with those by setting the `resolveConflicts` field accordingly.
As in this scenario we want to modify these values, we'd set `resolveConflicts: overwrite`.
```

De plus, la commande get sera désormais également récupérée `ConfigurationValues` pour l'addon. par exemple

```
eksctl get addon --cluster my-cluster --output yaml
```

```
- ConfigurationValues: '{"replicaCount":3}'
  IAMRole: ""
  Issues: null
  Name: coredns
  NewerVersion: ""
  Status: ACTIVE
  Version: v1.8.7-eksbuild.3
```

## Utilisation d'un espace de noms personnalisé
<a name="_using_custom_namespace"></a>

Un espace de noms personnalisé peut être fourni dans le fichier de configuration lors de la création des addons. Un espace de noms ne peut pas être mis à jour une fois qu'un addon est créé.

### Utilisation du fichier de configuration
<a name="_using_config_file"></a>

```
addons:
  - name: aws-ebs-csi-driver
    version: latest
    namespaceConfig:
      namespace: custom-namespace
```

### Utilisation de l'indicateur CLI
<a name="_using_cli_flag"></a>

Vous pouvez également spécifier un espace de noms personnalisé à l'aide de l'`--namespace-config`indicateur :

```
eksctl create addon --cluster my-cluster --name aws-ebs-csi-driver --namespace-config 'namespace=custom-namespace'
```

La commande get récupérera également la valeur de l'espace de noms pour l'addon

```
- ConfigurationValues: ""
  IAMRole: ""
  Issues: null
  Name: aws-ebs-csi-driver
  NamespaceConfig:
    namespace: custom-namespace
  NewerVersion: ""
  PodIdentityAssociations: null
  Status: ACTIVE
  Version: v1.47.0-eksbuild.1
```

## Mise à jour des addons
<a name="update-addons"></a>

Vous pouvez mettre à jour vos modules complémentaires vers des versions plus récentes et modifier les politiques associées en exécutant :

```
eksctl update addon -f config.yaml
```

```
eksctl update addon --name vpc-cni --version 1.8.0 --service-account-role-arn <new-role>
```

**Note**  
La configuration de l'espace de noms ne peut pas être mise à jour une fois qu'un addon est créé. Le `--namespace-config` drapeau n'est disponible que lors de la création de l'addon.

Comme pour la création d'un addon, lors de la mise à jour d'un addon, vous avez un contrôle total sur les modifications de configuration que vous avez peut-être appliquées précédemment à ce module complémentaire. `configMap` Plus précisément, vous pouvez les conserver ou les remplacer. Cette fonctionnalité optionnelle est disponible via le même champ du fichier de configuration`resolveConflicts`. Par exemple,

```
addons:
- name: vpc-cni
  attachPolicyARNs:
    - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
  resolveConflicts: preserve
```

Pour la mise à jour de l'addon, le `resolveConflicts` champ accepte trois valeurs distinctes :
+  `none`- EKS ne modifie pas la valeur. La mise à jour risque d'échouer.
+  `overwrite`- EKS remplace toutes les modifications de configuration aux valeurs par défaut d'EKS.
+  `preserve`- EKS préserve la valeur. Si vous choisissez cette option, nous vous recommandons de tester les modifications de champ et de valeur sur un cluster hors production avant de mettre à jour le module complémentaire sur votre cluster de production.

## Supprimer des addons
<a name="_deleting_addons"></a>

Vous pouvez supprimer un addon en exécutant :

```
eksctl delete addon --cluster <cluster-name> --name <addon-name>
```

Cela supprimera l'addon et tous les rôles IAM qui lui sont associés.

Lorsque vous supprimez votre cluster, tous les rôles IAM associés aux addons sont également supprimés.

## Flexibilité de création de clusters pour les extensions réseau par défaut
<a name="barecluster"></a>

Lorsqu'un cluster est créé, EKS installe automatiquement VPC CNI, CoreDNS et kube-proxy en tant qu'addons autogérés. Pour désactiver ce comportement afin d'utiliser d'autres plugins CNI tels que Cilium et Calico, eksctl prend désormais en charge la création d'un cluster sans aucun addon réseau par défaut. Pour créer un tel cluster, définissez`addonsConfig.disableDefaultAddons`, comme dans :

```
addonsConfig:
  disableDefaultAddons: true
```

```
eksctl create cluster -f cluster.yaml
```

Pour créer un cluster avec uniquement CoreDNS et kube-proxy et non VPC CNI, spécifiez les addons explicitement et définissez-les, comme dans : `addons` `addonsConfig.disableDefaultAddons`

```
addonsConfig:
  disableDefaultAddons: true
addons:
  - name: kube-proxy
  - name: coredns
```

```
eksctl create cluster -f cluster.yaml
```

Dans le cadre de cette modification, eksctl installe désormais des addons par défaut en tant qu'addons EKS au lieu d'addons autogérés lors de la création du cluster s'il n'`addonsConfig.disableDefaultAddons`est pas explicitement défini sur true. Ainsi, `eksctl utils update-*` les commandes ne peuvent plus être utilisées pour mettre à jour les addons pour les clusters créés avec eksctl v0.184.0 et versions ultérieures :
+  `eksctl utils update-aws-node` 
+  `eksctl utils update-coredns` 
+  `eksctl utils update-kube-proxy` 

Au lieu de cela, `eksctl update addon` devrait être utilisé maintenant.

Pour en savoir plus, consultez [Amazon EKS qui introduit la flexibilité de création de clusters pour les extensions réseau](https://aws.amazon.com/about-aws/whats-new/2024/06/amazon-eks-cluster-creation-flexibility-networking-add-ons/).