Gérer Core DNS for DNS dans les EKS clusters Amazon

Pour améliorer la stabilité et la disponibilité du CoreDNS Deployment, versions v1.9.3-eksbuild.6 et versions ultérieures et v1.10.1-eksbuild.3 sont déployés avec unPodDisruptionBudget. Si vous avez déployé une version existantePodDisruptionBudget, votre 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 complémentaires v1.9.3-eksbuild.3 et ultérieures v1.10.1-eksbuild.6 et ultérieures, le CoreDNS Deployment définit le readinessProbe pour utiliser le /ready point de terminaison. Ce point de terminaison est activé dans le fichier Corefile de configuration pour CoreDNS.

Si vous utilisez un plugin personnaliséCorefile, vous devez ajouter le ready plugin à la configuration, afin que le /ready point de terminaison soit actif dans CoreDNS pour que la sonde soit utilisée.

Dans les versions EKS complémentaires v1.9.3-eksbuild.7 v1.10.1-eksbuild.4 et ultérieures, vous pouvez modifier lePodDisruptionBudget. 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 ouminAvailable, mais vous ne pouvez pas définir les deux en une seule foisPodDisruptionBudget. Pour plus d'informationsPodDisruptionBudgets, consultez la section Spécifier un PodDisruptionBudget dans la documentation de Kubernetes.

Notez que si vous définissez sur enabledfalse, 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étrogradez le module complémentaire) après la mise à niveau vers une version avec unPodDisruptionBudget, celui-ci PodDisruptionBudget n'est pas supprimé. Pour supprimer le PodDisruptionBudget, exécutez la commande suivante :

kubectl delete poddisruptionbudget coredns -n kube-system

Dans les versions EKS complémentaires v1.10.1-eksbuild.5 et 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, voir KEP-2067 : Renommer l'étiquette « master » de kubeadm et altérer les propositions d'amélioration de Kubernetes () sur KEPs GitHub.

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

Dans les versions EKS complémentaires v1.9.3-eksbuild.11 v1.10.1-eksbuild.7 et ultérieures, le CoreDNS Deployment définit une valeur par défaut pourtopologySpreadConstraints. La valeur par défaut garantit que CoreDNS Pods 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 EKS complémentaires 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 minimum de packages et ne possède pas de shell. Pour plus d'informations, consultez Amazon EKS Distro. L'utilisation et le dépannage du CoreDNS l'image reste la même.