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

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.

Vous souhaitez contribuer à ce guide de l'utilisateur ? Choisissez le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page. Vos contributions aideront à améliorer notre guide de l'utilisateur pour tout le monde.

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

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 le Kubernetes fonctionnalité d'application côté serveur pour permettre la gestion d'un module complémentaire par Amazon EKS sans remplacer votre configuration par des paramètres qui ne sont pas gérés par Amazon EKS. Pour plus d'informations, consultez la section Application côté serveur dans le Kubernetes . Pour ce faire, Amazon EKS gère un ensemble minimal de champs pour chaque module complémentaire qu'il installe. Vous pouvez modifier tous les champs qui ne sont pas gérés par Amazon EKS ou un autre Kubernetes processus du plan de contrôle tel quekube-controller-manager, sans problème.

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

Lorsque vous consultez les détails d'un Kubernetes objet, les champs gérés et non gérés sont renvoyés dans la 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 CoreDNS le module complémentaire illustre 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 modifier tous les champs qui ne sont pas gérés par Amazon EKS ou un autre Kubernetes processus du plan de contrôle tel quekube-controller-manager, sans problème.

  1. Déterminez le module complémentaire que vous souhaitez examiner. Pour voir tous les deployments et DaemonSets déployé sur votre cluster, voirVue Kubernetes ressources dans le 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 CoreDNS module complémentaire 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 le voyez pas managedFields dans le résultat, ajoutez-le --show-managed-fields à la commande et exécutez-la à nouveau. La version kubectl que vous utilisez détermine si les champs gérés sont renvoyés par défaut.

Étapes suivantes

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