Gérer CoreDNS pour DNS dans les clusters Amazon EKS

Les mises à jour CoreDNS utilisent un PodDisruptionBudget pour aider à 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 :

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 sur PodDisruptionBudgets, consultez la section Spécification d’un PodDisruptionBudget dans 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 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, consultez KEP-2067 : Renommer le label « master » et le rejet kubeadm dans les propositions d’amélioration Kubernetes (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

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 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. L’utilisation et le dépannage de l’image CoreDNS restent les mêmes.