Utilisation du module complémentaire CoreDNS Amazon EKS - Amazon EKS

Aidez à améliorer cette page

Vous souhaitez contribuer à ce guide de l'utilisateur ? Faites défiler cette page vers le bas et sélectionnez Modifier cette page sur GitHub. 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.

Utilisation du module complémentaire CoreDNS Amazon EKS

CoreDNS est un serveur DNS flexible et extensible qui peut servir de DNS de cluster Kubernetes. Lorsque vous lancez un cluster Amazon EKS avec au moins un nœud, deux réplicas de l'image CoreDNS sont déployés par défaut, quel que soit le nombre de nœuds déployés dans votre cluster. Les Pods CoreDNS fournissent une résolution de noms pour tous les Pods du cluster. Les Pods CoreDNS peuvent être déployés sur les nœuds Fargate si votre cluster inclut un Définissez quelle Pods utilisation AWS Fargate lors du lancement avec un espace de noms qui correspond à l'espace de noms pour le CoreDNS deployment. Pour plus d'informations sur CoreDNS, consultez Utilisation de CoreDNS pour la découverte des services dans la documentation Kubernetes.

Le tableau suivant répertorie la dernière version du module complémentaire Amazon EKS pour chaque version de Kubernetes.

Version de Kubernetes 1.30 1.29 1.28 1.27 1.26 1.25 1.24 1.23
v1.11.1-eksbuild.9 v1.11.1-eksbuild.9 v1.10.1-eksbuild.11 v1.10.1-eksbuild.11 v1.9.3-eksbuild.15 v1.9.3-eksbuild.15 v1.9.3-eksbuild.15 v1.8.7-eksbuild.10
Important

Si vous gérez vous-même ce module complémentaire, les versions répertoriées dans le tableau peuvent ne pas être les mêmes que les versions autogérées disponibles. Pour plus d'informations sur la mise à jour du type autogéré de ce module complémentaire, consultez la rubrique Mise à jour du module complémentaire autogéré.

Considérations importantes concernant la mise à niveau de CoreDNS

  • Pour améliorer la stabilité et la disponibilité de CoreDNSDeployment, des versions v1.9.3-eksbuild.6 et des versions ultérieures et, v1.10.1-eksbuild.3 elles sont déployées avec un PodDisruptionBudget. Si vous avez déployé une version existante PodDisruptionBudget, la mise à niveau vers ces versions risque d'échouer. Si la mise à niveau échoue, l'exécution de l'une des tâches suivantes devrait résoudre le problème :

    • Lors de la mise à niveau du module complémentaire Amazon EKS, choisissez de remplacer les paramètres existants comme option de résolution des conflits. Si vous avez défini d'autres paramètres personnalisés pour le Deployment, assurez-vous de les sauvegarder avant de procéder à la mise à niveau afin de pouvoir réappliquer vos autres paramètres personnalisés après la mise à niveau.

    • Supprimez votre version existante PodDisruptionBudget et réessayez d'effectuer la mise à niveau.

  • Dans les versions v1.9.3-eksbuild.3 et ultérieures, et v1.10.1-eksbuild.6 et ultérieures des modules complémentaires EKS, le Deployment CoreDNS définit readinessProbe pour utiliser le point de terminaison /ready. Ce point de terminaison est activé dans le fichier de configuration Corefile pour CoreDNS.

    Si vous utilisez un Corefile personnalisé, vous devez ajouter le plug-in ready à la configuration, afin que le point de terminaison /ready soit actif dans CoreDNS pour que la sonde puisse l'utiliser.

  • Dans les versions v1.9.3-eksbuild.7 et ultérieures, et v1.10.1-eksbuild.4 et ultérieures des modules complémentaires EKS, vous pouvez modifier le PodDisruptionBudget. Vous pouvez modifier le module complémentaire et modifier ces paramètres dans les paramètres de configuration facultatifs à l'aide des champs de l'exemple suivant. Cet exemple montre la valeur PodDisruptionBudget par défaut.

    { "podDisruptionBudget": { "enabled": true, "maxUnavailable": 1 } }

    Vous pouvez définir maxUnavailable ou minAvailable, mais vous ne pouvez pas définir les deux dans un même PodDisruptionBudget. Pour plus d'informations sur PodDisruptionBudgets, consultez la rubrique Spécification d'un PodDisruptionBudget de la documentation Kubernetes.

    Notez que si vous définissez enabled sur false, le PodDisruptionBudget n'est pas supprimé. Après avoir défini ce champ sur false, vous devez supprimer l'objet PodDisruptionBudget. De même, si vous modifiez le module complémentaire pour utiliser une ancienne version du module complémentaire (rétrogradage) après la mise à niveau vers une version avec un PodDisruptionBudget, le PodDisruptionBudget n'est pas supprimé. Pour supprimer le PodDisruptionBudget, exécutez la commande suivante :

    kubectl delete poddisruptionbudget coredns -n kube-system
  • Dans les versions complémentaires d'EKS v1.10.1-eksbuild.5 et versions ultérieures, modifiez la tolérance par défaut de node-role.kubernetes.io/master:NoSchedule à pour vous conformer node-role.kubernetes.io/control-plane:NoSchedule à KEP 2067. Pour plus d’informations sur KEP 2067, consultez KEP-2067: Reame the kubeadm "master" label and taint dans Kubernetes Enhancement Proposals (KEPs) sur GitHub.

    Dans les versions v1.8.7-eksbuild.8 complémentaires d'EKS v1.9.3-eksbuild.9 et les versions ultérieures, les deux tolérances sont définies pour être compatibles avec chaque Kubernetes version.

  • Dans les versions complémentaires d'EKS v1.9.3-eksbuild.11 v1.10.1-eksbuild.7 et versions ultérieures, CoreDNS Deployment définit une valeur par défaut pourtopologySpreadConstraints. La valeur par défaut garantit qu'CoreDNSPodsils sont répartis entre les zones de disponibilité s'il existe des nœuds disponibles dans plusieurs zones de disponibilité. Vous pouvez définir une valeur personnalisée qui sera utilisée à la place de la valeur par défaut. La valeur par défaut est la suivante :

    topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway labelSelector: matchLabels: k8s-app: kube-dns

CoreDNSconsidérations relatives 1.11 à la mise à niveau

  • Dans les versions complémentaires d'EKS v1.11.1-eksbuild.4 et versions ultérieures, l'image du conteneur est basée sur une image de base minimale gérée par Amazon EKS Distro, qui contient un minimum de packages et ne possède pas de shell. Pour plus d'informations, consultez Amazon EKS Distro. L'utilisation et le dépannage de l'CoreDNSimage restent les mêmes.

Création du module complémentaire Amazon EKS

Créez le type Amazon EKS du module complémentaire. Check

Prérequis
  1. Déterminez la version du module complémentaire actuellement installée sur votre cluster.

    kubectl describe deployment coredns --namespace kube-system | grep coredns: | cut -d : -f 3

    L'exemple qui suit illustre un résultat.

    v1.10.1-eksbuild.11
  2. Déterminez le type de module complémentaire installé sur votre cluster. Selon l'outil avec lequel vous avez créé votre cluster, le type de module complémentaire Amazon EKS peut ne pas être actuellement installé sur votre cluster. Remplacez my-cluster par le nom de votre cluster.

    aws eks describe-addon --cluster-name my-cluster --addon-name coredns --query addon.addonVersion --output text

    Si un numéro de version est renvoyé, le type de module complémentaire Amazon EKS est installé sur votre cluster, et vous n'avez donc pas besoin de suivre les étapes restantes de cette procédure. Si une erreur est renvoyée, cela signifie que le type de module complémentaire Amazon EKS n'est pas installé sur votre cluster. Suivez les étapes restantes de cette procédure pour l'installer.

  3. Enregistrez la configuration du module complémentaire actuellement installé.

    kubectl get deployment coredns -n kube-system -o yaml > aws-k8s-coredns-old.yaml
  4. Créez le module complémentaire à l'aide de la AWS CLI. Si vous souhaitez utiliser le AWS Management Console ou eksctl pour créer le module complémentaire, consultez Création d'un EKS module complémentaire Amazon et spécifiez coredns le nom du module complémentaire. Copiez la commande qui suit sur votre appareil. Si nécessaire, apportez les modifications suivantes à la commande, puis exécutez la commande modifiée.

    aws eks create-addon --cluster-name my-cluster --addon-name coredns --addon-version v1.11.1-eksbuild.9

    Si vous avez appliqué à votre module complémentaire actuel des paramètres personnalisés qui entrent en conflit avec les paramètres par défaut du module complémentaire Amazon EKS, la création peut échouer. Si la création échoue, vous recevez un message d'erreur qui peut vous aider à résoudre le problème. Vous pouvez également ajouter --resolve-conflicts OVERWRITE à la commande précédente. Cela permet au module complémentaire de remplacer les paramètres personnalisés existants. Une fois que vous avez créé le module complémentaire, vous pouvez le mettre à jour avec vos paramètres personnalisés.

  5. Assurez-vous que la dernière version du module complémentaire correspondant à la version de Kubernetes de votre cluster a été ajoutée à votre cluster. Remplacez my-cluster par le nom de votre cluster.

    aws eks describe-addon --cluster-name my-cluster --addon-name coredns --query addon.addonVersion --output text

    La création du module complémentaire peut prendre plusieurs secondes.

    L'exemple qui suit illustre un résultat.

    v1.11.1-eksbuild.9
  6. Si vous avez personnalisé les paramètres du module complémentaire, avant de créer le module complémentaire Amazon EKS, utilisez la configuration que vous avez enregistrée lors d'une étape précédente pour mettre à jour le module complémentaire Amazon EKS avec vos paramètres personnalisés.

Mise à jour du module complémentaire Amazon EKS

Mettez à jour le type de module complémentaire Amazon EKS. Si vous n'avez pas ajouté le type de module complémentaire Amazon EKS à votre cluster, ajoutez-le ou consultez la rubrique Mise à jour du module complémentaire autogéré au lieu de terminer cette procédure.

  1. Déterminez la version du module complémentaire actuellement installée sur votre cluster. Remplacez my-cluster par le nom de votre cluster.

    aws eks describe-addon --cluster-name my-cluster --addon-name coredns --query "addon.addonVersion" --output text

    L'exemple qui suit illustre un résultat.

    v1.10.1-eksbuild.11

    Si la version renvoyée est identique à la version de Kubernetes de votre cluster dans le tableau des dernières versions, cela signifie que la dernière version est déjà installée sur votre cluster, et vous n'avez donc pas besoin de terminer cette procédure. Si vous recevez une erreur au lieu d'un numéro de version dans votre sortie, cela signifie que le type de module complémentaire Amazon EKS n'est pas installé sur votre cluster. Vous devez créer le module complémentaire avant de pouvoir le mettre à jour à l'aide de cette procédure.

  2. Enregistrez la configuration du module complémentaire actuellement installé.

    kubectl get deployment coredns -n kube-system -o yaml > aws-k8s-coredns-old.yaml
  3. Mettez à jour votre module complémentaire à l'aide de la AWS CLI. Si vous souhaitez utiliser AWS Management Console ou mettre eksctl à jour le module complémentaire, consultezMettre à jour un EKS module complémentaire Amazon. Copiez la commande qui suit sur votre appareil. Si nécessaire, apportez les modifications suivantes à la commande, puis exécutez la commande modifiée.

    • Remplacez my-cluster par le nom de votre cluster.

    • Remplacez v1.11.1-eksbuild.9 par la dernière version répertoriée dans le tableau des dernières versions pour la version de votre cluster.

    • L'option --resolve-conflicts PRESERVE conserve les valeurs de configuration existantes pour le module complémentaire. Si vous avez défini des valeurs personnalisées pour les paramètres des modules complémentaires et que vous n'utilisez pas cette option, Amazon EKS remplace vos valeurs par ses valeurs par défaut. Si vous utilisez 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. Si vous remplacez cette valeur par OVERWRITE, tous les paramètres sont remplacés par les valeurs par défaut d'Amazon EKS. Si vous avez défini des valeurs personnalisées pour certains paramètres, il est possible qu'elles soient remplacées par les valeurs par défaut d'Amazon EKS. Si vous remplacez cette valeur par none, Amazon EKS ne modifie la valeur d'aucun paramètre, mais la mise à jour risque d'échouer. Si la mise à jour échoue, vous recevez un message d'erreur pour vous aider à résoudre le conflit.

    • Si vous ne mettez à jour aucun paramètre de configuration, supprimez --configuration-values '{"replicaCount":3}' de la commande. Si vous mettez à jour un paramètre de configuration, remplacez "replicaCount":3 par le paramètre que vous voulez définir. Dans cet exemple, le nombre de réplicas de CoreDNS est défini sur 3. La valeur que vous spécifiez doit être valide pour le schéma de configuration. Si vous ne connaissez pas le schéma de configurationaws eks describe-addon-configuration --addon-name coredns --addon-version v1.11.1-eksbuild.9, lancez-le en remplaçant v1.11.1-eksbuild.9 par le numéro de version du module complémentaire dont vous souhaitez consulter la configuration. Le schéma est renvoyé dans la sortie. Si vous disposez déjà d'une configuration personnalisée et vous voulez la supprimer et rétablir les valeurs par défaut d'Amazon EKS pour tous les paramètres, supprimez "replicaCount":3 de la commande, de sorte que le champ {} soit vide. Pour plus d'informations sur les paramètres CoreDNS, consultez la section Personnalisation du service DNS (français non garanti) dans la documentation Kubernetes.

      aws eks update-addon --cluster-name my-cluster --addon-name coredns --addon-version v1.11.1-eksbuild.9 \ --resolve-conflicts PRESERVE --configuration-values '{"replicaCount":3}'

      La mise à jour peut prendre plusieurs secondes.

  4. Assurez-vous que la version du module complémentaire a été mise à jour. Remplacez my-cluster par le nom de votre cluster.

    aws eks describe-addon --cluster-name my-cluster --addon-name coredns

    La mise à jour peut prendre plusieurs secondes.

    L'exemple qui suit illustre un résultat.

    { "addon": { "addonName": "coredns", "clusterName": "my-cluster", "status": "ACTIVE", "addonVersion": "v1.11.1-eksbuild.9", "health": { "issues": [] }, "addonArn": "arn:aws:eks:region:111122223333:addon/my-cluster/coredns/d2c34f06-1111-2222-1eb0-24f64ce37fa4", "createdAt": "2023-03-01T16:41:32.442000+00:00", "modifiedAt": "2023-03-01T18:16:54.332000+00:00", "tags": {}, "configurationValues": "{\"replicaCount\":3}" } }

Mise à jour du module complémentaire autogéré

Important

Nous recommandons d'ajouter le type Amazon EKS du module complémentaire à votre cluster au lieu d'utiliser le type autogéré du module complémentaire. Si la différence entre les types ne vous est pas familière, consultez EKSModules complémentaires Amazon. Pour plus d'informations sur l'ajout d'un module complémentaire Amazon EKS à votre cluster, consultez Création d'un EKS module complémentaire Amazon. Si vous ne parvenez pas à utiliser le module complémentaire Amazon EKS, nous vous encourageons à signaler les raisons pour lesquelles vous ne pouvez pas utiliser le module complémentaire Amazon EKS dans le GitHub référentiel de feuilles de route pour les conteneurs.

  1. Vérifiez que le type autogéré du module complémentaire est installé sur votre cluster. Remplacez my-cluster par le nom de votre cluster.

    aws eks describe-addon --cluster-name my-cluster --addon-name coredns --query addon.addonVersion --output text

    Si un message d'erreur est renvoyé, le type autogéré du module complémentaire est installé sur votre cluster. Suivez les étapes restantes de cette procédure. Si un numéro de version est renvoyé, le type de module complémentaire Amazon EKS est installé sur votre cluster. Pour mettre à jour le type Amazon EKS du module complémentaire, suivez la procédure décrite dans la rubrique Mise à jour du module complémentaire Amazon EKS plutôt que cette procédure. Si les différences entre les types de modules complémentaires ne vous sont pas familières, consultez EKSModules complémentaires Amazon.

  2. Découvrez quelle version de l'image de conteneur est actuellement installée sur votre cluster.

    kubectl describe deployment coredns -n kube-system | grep Image | cut -d ":" -f 3

    L'exemple qui suit illustre un résultat.

    v1.8.7-eksbuild.2
  3. Si votre version actuelle de CoreDNS est v1.5.0 ou ultérieure, mais qu'elle est antérieure à la version répertoriée dans le tableau Versions de CoreDNS, ignorez cette étape. Si votre version actuelle est antérieure à la version 1.5.0, vous devez modifier la ConfigMap pour que CoreDNS utilise le module complémentaire, plutôt que le module complémentaire proxy.

    1. Ouvrez la carte de configuration avec la commande suivante.

      kubectl edit configmap coredns -n kube-system
    2. Remplacez proxy dans la ligne suivante par forward. Enregistrez le fichier et quittez l'éditeur.

      proxy . /etc/resolv.conf
  4. Si vous avez initialement déployé votre cluster sur Kubernetes version 1.17 ou antérieure, vous devrez peut-être supprimer une ligne abandonnée de votre manifeste CoreDNS.

    Important

    Vous devez effectuer cette étape avant la mise à jour vers la version 1.7.0 de CoreDNS, mais il est recommandé d'effectuer cette étape même en cas de mise à jour vers une version antérieure.

    1. Vérifiez si votre manifeste CoreDNS possède la ligne.

      kubectl get configmap coredns -n kube-system -o jsonpath='{$.data.Corefile}' | grep upstream

      Si aucune sortie n'est renvoyée, votre manifeste ne dispose pas de la ligne et vous pouvez passer à l'étape suivante pour mettre à jour CoreDNS. Si la sortie est renvoyée, vous devez supprimer la ligne.

    2. Modifiez la ConfigMap en utilisant la commande suivante, en supprimant la ligne dans le fichier contenant le mot upstream. Ne modifiez rien d'autre dans le fichier. Une fois la ligne supprimée, enregistrez les modifications.

      kubectl edit configmap coredns -n kube-system -o yaml
  5. Récupérez la version de votre image CoreDNS actuelle :

    kubectl describe deployment coredns -n kube-system | grep Image

    L'exemple qui suit illustre un résultat.

    602401143452.dkr.ecr.region-code.amazonaws.com/eks/coredns:v1.8.7-eksbuild.2
  6. Si vous effectuez une mise à jour vers de CoreDNS vers la version 1.8.3 ou une version ultérieure, vous devez ajouter l'autorisation endpointslices au system:coredns Kubernetes clusterrole.

    kubectl edit clusterrole system:coredns -n kube-system

    Ajoutez les lignes suivantes sous les lignes d'autorisation existantes dans la section rules du fichier.

    [...] - apiGroups: - discovery.k8s.io resources: - endpointslices verbs: - list - watch [...]
  7. Mettez à jour le module complémentaire CoreDNS en remplaçant 602401143452 et region-code par les valeurs obtenues à l'étape précédente. Remplacez v1.11.1-eksbuild.9 par la version de CoreDNS répertoriée dans le tableau des dernières versions pour votre version de Kubernetes.

    kubectl set image deployment.apps/coredns -n kube-system coredns=602401143452.dkr.ecr.region-code.amazonaws.com/eks/coredns:v1.11.1-eksbuild.9

    L'exemple qui suit illustre un résultat.

    deployment.apps/coredns image updated
  8. Vérifiez à nouveau la version d'image de conteneur pour confirmer qu'elle a été mise à jour vers la version que vous avez spécifiée à l'étape précédente.

    kubectl describe deployment coredns -n kube-system | grep Image | cut -d ":" -f 3

    L'exemple qui suit illustre un résultat.

    v1.11.1-eksbuild.9