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

Les EKS modules complémentaires Amazon sont installés sur votre cluster à l'aide de configurations standard conformes aux meilleures pratiques. Pour plus d'informations sur l'ajout d'un EKS module complémentaire Amazon à votre cluster, consultezEKSModules complémentaires Amazon.

Vous souhaiterez peut-être personnaliser la configuration d'un EKS module complémentaire Amazon pour activer des fonctionnalités avancées. Amazon EKS utilise la fonctionnalité d'application Kubernetes côté serveur pour permettre à Amazon de gérer un module complémentaire EKS sans remplacer votre configuration par des paramètres qui ne sont pas gérés par Amazon. EKS Pour plus d'informations, consultez Server-Side Apply dans la documentation Kubernetes. Pour ce faire, Amazon EKS gère un ensemble minimal de champs pour chaque module complémentaire installé. Vous pouvez modifier tous les champs qui ne sont pas gérés par AmazonEKS, ou par un autre processus du plan de Kubernetes contrôle tel quekube-controller-manager, sans problème.

Important

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

Syntaxe de gestion des champs

Lorsque vous affichez les détails d'un objet Kubernetes, 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 AmazonEKS. Les modifications apportées à une valeur provoquent un conflit.

• Gestion partielle — Certaines clés du champ sont gérées par AmazonEKS. Seules les modifications apportées aux clés explicitement gérées par Amazon sont à l'EKSorigine d'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 JSON formatée exacte d'un élément de 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 l'utiliser kubectl pour voir quels champs sont gérés par Amazon EKS pour n'importe quel EKS module complémentaire Amazon.

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

1. Déterminez le module complémentaire que vous souhaitez examiner. Pour afficher tous les deployments et DaemonSets déployés sur votre cluster, consultez Consultez Kubernetes les 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 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 ne sont pas détenus par AWS le module complémentaire for you.