Déterminez les champs que vous pouvez personnaliser pour les modules complémentaires Amazon EKS - Amazon EKS
Syntaxe de gestion de champsProcédureÉtapes suivantes

Aidez à améliorer cette page

Pour contribuer à ce guide de l’utilisateur, cliquez sur le lien Modifier cette page sur GitHub qui se trouve dans le volet droit de chaque page.

Déterminez les champs que vous pouvez personnaliser pour les modules complémentaires Amazon EKS

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.

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 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

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ù keys est une carte des champs de l’élément d’une 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

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 tous les deployments et DaemonSets déployés sur votre cluster, consultez Affichage des ressources Kubernetes dans la AWS Management Console.

  2. 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

Personnalisez les champs qui n’appartiennent pas à AWS pour votre module complémentaire.