Manage CoreDNS for DNS in Amazon EKS clusters - Amazon EKS
CoreDNS versionsImportant CoreDNS upgrade considerations
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Help improve this page

To contribute to this user guide, choose the Edit this page on GitHub link that is located in the right pane of every page.

Manage CoreDNS for DNS in Amazon EKS clusters

Tip

With Amazon EKS Auto Mode, you don’t need to install or upgrade networking add-ons. Auto Mode includes pod networking and load balancing capabilities.

For more information, see Automate cluster infrastructure with EKS Auto Mode.

CoreDNS is a flexible, extensible DNS server that can serve as the Kubernetes cluster DNS. When you launch an Amazon EKS cluster with at least one node, two replicas of the CoreDNS image are deployed by default, regardless of the number of nodes deployed in your cluster. The CoreDNS Pods provide name resolution for all Pods in the cluster. The CoreDNS Pods can be deployed to Fargate nodes if your cluster includes a Fargate Profile with a namespace that matches the namespace for the CoreDNS deployment. For more information on Fargate Profiles, see Define which Pods use Amazon Fargate when launched. For more information about CoreDNS, see Using CoreDNS for Service Discovery in the Kubernetes documentation.

CoreDNS versions

The following table lists the latest version of the Amazon EKS add-on type for each Kubernetes version.

Kubernetes version CoreDNS version

1.32

v1.11.4-eksbuild.2

1.31

v1.11.4-eksbuild.2

1.30

v1.11.4-eksbuild.2

1.29

v1.11.4-eksbuild.2

1.28

v1.10.1-eksbuild.18

1.27

v1.10.1-eksbuild.18

1.26

v1.9.3-eksbuild.22

1.25

v1.9.3-eksbuild.22
Important

If you’re self-managing this add-on, the versions in the table might not be the same as the available self-managed versions. For more information about updating the self-managed type of this add-on, see Update the CoreDNS Amazon EKS self-managed add-on.

Important CoreDNS upgrade considerations

  • To improve the stability and availability of the CoreDNS Deployment, versions v1.9.3-eksbuild.6 and later and v1.10.1-eksbuild.3 are deployed with a PodDisruptionBudget. If you’ve deployed an existing PodDisruptionBudget, your upgrade to these versions might fail. If the upgrade fails, completing one of the following tasks should resolve the issue:

    • When doing the upgrade of the Amazon EKS add-on, choose to override the existing settings as your conflict resolution option. If you’ve made other custom settings to the Deployment, make sure to back up your settings before upgrading so that you can reapply your other custom settings after the upgrade.

    • Remove your existing PodDisruptionBudget and try the upgrade again.

  • In EKS add-on versions v1.9.3-eksbuild.3 and later and v1.10.1-eksbuild.6 and later, the CoreDNS Deployment sets the readinessProbe to use the /ready endpoint. This endpoint is enabled in the Corefile configuration file for CoreDNS.

    If you use a custom Corefile, you must add the ready plugin to the config, so that the /ready endpoint is active in CoreDNS for the probe to use.

  • In EKS add-on versions v1.9.3-eksbuild.7 and later and v1.10.1-eksbuild.4 and later, you can change the PodDisruptionBudget. You can edit the add-on and change these settings in the Optional configuration settings using the fields in the following example. This example shows the default PodDisruptionBudget.

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

    You can set maxUnavailable or minAvailable, but you can’t set both in a single PodDisruptionBudget. For more information about PodDisruptionBudgets, see Specifying a PodDisruptionBudget in the Kubernetes documentation.

    Note that if you set enabled to false, the PodDisruptionBudget isn’t removed. After you set this field to false, you must delete the PodDisruptionBudget object. Similarly, if you edit the add-on to use an older version of the add-on (downgrade the add-on) after upgrading to a version with a PodDisruptionBudget, the PodDisruptionBudget isn’t removed. To delete the PodDisruptionBudget, you can run the following command:

    kubectl delete poddisruptionbudget coredns -n kube-system

  • In EKS add-on versions v1.10.1-eksbuild.5 and later, change the default toleration from node-role.kubernetes.io/master:NoSchedule to node-role.kubernetes.io/control-plane:NoSchedule to comply with KEP 2067. For more information about KEP 2067, see KEP-2067: Rename the kubeadm "master" label and taint in the Kubernetes Enhancement Proposals (KEPs) on GitHub.

    In EKS add-on versions v1.8.7-eksbuild.8 and later and v1.9.3-eksbuild.9 and later, both tolerations are set to be compatible with every Kubernetes version.

  • In EKS add-on versions v1.9.3-eksbuild.11 and v1.10.1-eksbuild.7 and later, the CoreDNS Deployment sets a default value for topologySpreadConstraints. The default value ensures that the CoreDNS Pods are spread across the Availability Zones if there are nodes in multiple Availability Zones available. You can set a custom value that will be used instead of the default value. The default value follows:

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

CoreDNS v1.11 upgrade considerations

  • In EKS add-on versions v1.11.1-eksbuild.4 and later, the container image is based on a minimal base image maintained by Amazon EKS Distro, which contains minimal packages and doesn’t have shells. For more information, see Amazon EKS Distro. The usage and troubleshooting of the CoreDNS image remains the same.