**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éterminez les champs que vous pouvez personnaliser pour les modules complémentaires Amazon EKS
<a name="kubernetes-field-management"></a>

Les modules complémentaires Amazon EKS sont installés sur votre cluster à l'aide des configurations standard de bonnes pratiques. Pour plus d'informations sur l'ajout d'un module complémentaire Amazon EKS à votre cluster, consultez [Modules complémentaires Amazon EKS](eks-add-ons.md).

Vous voudrez peut-être personnaliser la configuration d'un module complémentaire Amazon EKS pour activer les fonctions avancées. Amazon EKS utilise la fonction apply côté serveur de Kubernetes pour permettre la gestion d’un module complémentaire par Amazon EKS sans écraser votre configuration pour les paramètres qui ne sont pas gérés par Amazon EKS. Pour plus d'informations, consultez [apply côté serveur](https://kubernetes.io/docs/reference/using-api/server-side-apply/) dans la documentation Kubernetes. Pour ce faire, Amazon EKS gère un ensemble minimal de champs pour chaque module complémentaire qu'il installe. Vous pouvez, sans problème, modifier tous les champs qui ne sont pas gérés par Amazon EKS ou un autre processus de plan de contrôle Kubernetes tel que `kube-controller-manager`.

**Important**  
La modification d'un champ géré par Amazon EKS empêche Amazon EKS de gérer le module complémentaire. Ce processus peut entraîner l'écrasement de vos modifications lors de la mise à jour d'un module complémentaire.

## Syntaxe de gestion de champs
<a name="add-on-config-management-understanding-field-management"></a>

Lorsque vous affichez les détails d'un objet Kubernetes, les champs gérés et non gérés sont renvoyés en sortie. Les champs gérés peuvent être l'un des types suivants :
+  **Entièrement géré** : toutes les clés du champ sont gérées par Amazon EKS. Les modifications apportées à une valeur provoquent un conflit.
+  **Partiellement géré** : certaines clés du champ sont gérées par Amazon EKS. Seules les modifications apportées aux clés explicitement gérées par Amazon EKS provoquent un conflit.

Les deux types de champs sont étiquetés avec `manager: eks`.

Chaque clé est soit un `.` représentant le champ lui-même, qui correspond toujours à un ensemble vide, soit une chaîne qui représente un sous-champ ou un élément. La sortie pour la gestion des champs comprend les types de déclarations suivants :
+  `f:name `, où *name* est le nom d'un champ d'une liste.
+  `k:keys `, où se *keys* trouve une carte des champs d'un élément de liste.
+  `v:value `, où *value* est la valeur exacte au format JSON formaté de l'élément d'une liste.
+  `i:index `, où *index* est la position d'un élément dans la liste.

Les parties de sortie suivantes pour le module complémentaire CoreDNS illustrent les déclarations précédentes :
+  **Champs entièrement gérés** : si un champ géré possède un (champ) `f:` spécifié, mais aucune (clé) `k:`, alors le champ entier est géré. Les modifications apportées aux valeurs de ce champ provoquent un conflit.

  Dans la sortie suivante, vous pouvez voir que le conteneur nommé `coredns` est géré par `eks`. Les sous-champs `args`, `image` et `imagePullPolicy` sont également gérés par `eks`. Les modifications apportées aux valeurs de ces champs provoquent un conflit.

  ```
  [...]
  f:containers:
    k:{"name":"coredns"}:
    .: {}
    f:args: {}
    f:image: {}
    f:imagePullPolicy: {}
  [...]
  manager: eks
  [...]
  ```
+  **Champs partiellement gérés** : si une clé gérée a une valeur spécifiée, les clés déclarées sont gérées pour ce champ. La modification des clés spécifiées provoque un conflit.

  Dans la sortie suivante, vous pouvez voir que `eks` gère les volumes `config-volume` et `tmp` définis à l'aide de la clé `name`.

  ```
  [...]
  f:volumes:
    k:{"name":"config-volume"}:
      .: {}
      f:configMap:
        f:items: {}
        f:name: {}
      f:name: {}
    k:{"name":"tmp"}:
      .: {}
      f:name: {}
  [...]
  manager: eks
  [...]
  ```
+  **Ajout de clés à des champs partiellement gérés** : si seule une valeur de clé spécifique est gérée, vous pouvez ajouter en toute sécurité des clés supplémentaires, telles que des arguments, à un champ sans provoquer de conflit. Si vous ajoutez des clés supplémentaires, assurez-vous d’abord que le champ n’est pas géré. L'ajout ou la modification d'une valeur gérée provoque un conflit.

  Dans la sortie suivante, vous pouvez voir que la clé `name` et le champ `name` sont gérés. L'ajout ou la modification d'un nom de conteneur provoque un conflit avec cette clé gérée.

  ```
  [...]
  f:containers:
    k:{"name":"coredns"}:
  [...]
      f:name: {}
  [...]
  manager: eks
  [...]
  ```

## Procédure
<a name="view-field-management"></a>

Vous pouvez utiliser `kubectl` pour voir quels champs sont gérés par Amazon EKS pour tout module complémentaire Amazon EKS.

Vous pouvez, sans problème, modifier tous les champs qui ne sont pas gérés par Amazon EKS ou un autre processus de plan de contrôle Kubernetes tel que `kube-controller-manager`.

1. Déterminez le module complémentaire que vous souhaitez examiner. Pour voir l'ensemble du `deployments` terrain DaemonSets déployé sur votre cluster, consultez[Consultez les ressources Kubernetes dans le AWS Management Console](view-kubernetes-resources.md).

1. Pour afficher les champs gérés d'un module complémentaire, exécutez la commande suivante :

   ```
   kubectl get type/add-on-name -n add-on-namespace -o yaml
   ```

   Par exemple, vous pouvez voir les champs gérés pour le module complémentaire CoreDNS avec la commande suivante.

   ```
   kubectl get deployment/coredns -n kube-system -o yaml
   ```

   La gestion des champs est répertoriée dans la section suivante dans la sortie renvoyée.

   ```
   [...]
   managedFields:
     - apiVersion: apps/v1
       fieldsType: FieldsV1
       fieldsV1:
   [...]
   ```
**Note**  
Si vous ne voyez pas `managedFields` en sortie, ajoutez `--show-managed-fields` à la commande et exécutez-la à nouveau. La version de `kubectl` que vous utilisez détermine si les champs gérés sont retournés par défaut.

## Étapes suivantes
<a name="view-field-management-next-steps"></a>

Personnalisez les champs qui ne sont pas détenus par AWS le module complémentaire for you.