**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.
# Gestion de CoreDNS pour DNS dans les clusters Amazon EKS
**Astuce**
Avec le mode automatique Amazon EKS, il n’est pas nécessaire d’installer ou de mettre à niveau de modules complémentaires de mise en réseau. Le mode automatique inclut des fonctionnalités de mise en réseau des pods et d’équilibrage de charge.
Pour de plus amples informations, veuillez consulter [Automatisation de l’infrastructure du cluster avec le mode automatique EKS](automode.md).
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 des nœuds Fargate si votre cluster comprend un [profil Fargate](fargate-profile.md) avec un espace de noms qui correspond à l’espace de noms de CoreDNS `deployment`. Pour plus d'informations sur CoreDNS, consultez [Utilisation de CoreDNS pour la découverte des services](https://kubernetes.io/docs/tasks/administer-cluster/coredns/) dans la documentation Kubernetes.
## Versions de CoreDNS
Le tableau suivant répertorie la dernière version du type d’add-on Amazon EKS pour chaque version de Kubernetes.
| Version de Kubernetes | Version de CoreDNS |
| --- | --- |
| 1,35 | v1.14.2-eksbuild.4 |
| 1,34 | v1.13.2-eksbuild.7 |
| 1,33 | v1.13.2-eksbuild.7 |
| 1,32 | v1.11.4-eksbuild.33 |
| 1,31 | v1.11.4-eksbuild.33 |
| 1,30 | v1.11.4-eksbuild.33 |
**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 [Mettre à jour le module complémentaire CoreDNS Amazon EKS autogéré](coredns-add-on-self-managed-update.md).
## Considérations importantes concernant la mise à niveau de CoreDNS
+ Les mises à jour CoreDNS utilisent PodDisruptionBudget un pour maintenir la disponibilité du service DNS pendant le processus de mise à jour.
+ Afin d’améliorer la stabilité et la disponibilité du déploiement CoreDNS, les versions `v1.9.3-eksbuild.6` et ultérieures ainsi que `v1.10.1-eksbuild.3` 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 déploiement, veillez à sauvegarder vos paramètres avant la mise à niveau afin de pouvoir les réappliquer après la mise à niveau.
+ Supprimez votre version existante `PodDisruptionBudget` et réessayez d'effectuer la mise à niveau.
+ Dans les versions EKS add-on `v1.9.3-eksbuild.3` et ultérieures ainsi que `v1.10.1-eksbuild.6` et ultérieures, le déploiement CoreDNS configure `readinessProbe` pour qu’il utilise le point de terminaison `/ready`. Ce point de terminaison est activé dans le fichier de configuration `Corefile` de 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`PodDisruptionBudgets`, consultez la section [Spécifier un PodDisruptionBudget](https://kubernetes.io/docs/tasks/run-application/configure-pdb/#specifying-a-poddisruptionbudget) dans la documentation de *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 du module complémentaire EKS et `v1.10.1-eksbuild.5` et ultérieures, modifiez la tolérance par défaut de `node-role.kubernetes.io/master:NoSchedule` à `node-role.kubernetes.io/control-plane:NoSchedule` pour vous conformer au KEP 2067. Pour plus d'informations sur KEP 2067, voir [KEP-2067: Renommer l'étiquette « master » de kubeadm et altérer les propositions d'amélioration de *Kubernetes* (](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cluster-lifecycle/kubeadm/2067-rename-master-label-taint#renaming-the-node-rolekubernetesiomaster-node-taint)KEP) sur. GitHub
Dans les versions du module complémentaire EKS `v1.8.7-eksbuild.8` et ultérieures ainsi que `v1.9.3-eksbuild.9` et ultérieures, les deux tolérances sont définies pour être compatibles avec toutes les versions de Kubernetes.
+ Dans les versions du module complémentaire EKS `v1.9.3-eksbuild.11` et `v1.10.1-eksbuild.7` et ultérieures, le déploiement CoreDNS définit une valeur par défaut pour `topologySpreadConstraints`. La valeur par défaut garantit que les pods CoreDNS sont répartis entre les zones de disponibilité si des nœuds sont 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
```
### Considérations relatives à la mise à niveau de CoreDNS `v1.11`
+ Dans les versions du module complémentaire EKS `v1.11.1-eksbuild.4` et ultérieures, l’image du conteneur est basée sur une [image de base minimale](https://gallery.ecr.aws/eks-distro-build-tooling/eks-distro-minimal-base) gérée par Amazon EKS Distro, qui contient un nombre minimal de paquets et ne dispose pas de shells. Pour plus d'informations, consultez [Amazon EKS Distro](https://distro.eks.amazonaws.com/). L’utilisation et le dépannage de l’image CoreDNS restent les mêmes.