- Newest
- Most votes
- Most comments
Additional Technical Context for EKS 1.33
Since the error specifically highlights the conflict in ConfigMap coredns - .data.Corefile, here are two specific tips to ensure a smooth transition:
Direct ConfigMap Backup: Before applying any changes, back up the actual configuration where the conflict resides:
kubectl get configmap coredns -n kube-system -o yaml > coredns-cm-backup.yaml
Crucial Check for 'PRESERVE' Mode: If you choose --resolve-conflicts PRESERVE to keep your custom settings, verify that your Corefile includes the ready plugin. Newer EKS versions (including 1.33) rely on a readiness probe that will fail if this plugin is missing from the configuration:
.:53 {
errors
health
ready # <--- Required for the pod to pass the readiness probe
kubernetes cluster.local in-addr.arpa ip6.arpa {
...
}
}
This prevents your CoreDNS pods from getting stuck in an Unready state after the update.
The error you're encountering indicates a configuration conflict with your CoreDNS ConfigMap during the update process. Here's how to resolve this issue:
Before Applying the Update:
- Back up your current configuration: Save your existing CoreDNS deployment configuration by running:
kubectl get deployment coredns -n kube-system -o yaml > aws-k8s-coredns-old.yaml
- Save your current ConfigMap: You should also back up your CoreDNS ConfigMap to preserve your custom Corefile settings.
Resolving the Conflict:
You have several options to resolve the configuration conflict:
-
Override existing settings: When updating the Amazon EKS add-on, choose to override the existing settings as your conflict resolution option. Use the
--resolve-conflicts OVERWRITEparameter, which will change all settings to Amazon EKS default values. Note that if you've set custom values for any settings, they will be overwritten with Amazon EKS default values. -
Preserve existing settings: Use the
--resolve-conflicts PRESERVEoption to maintain your existing configuration values. However, if you use this option, it's recommended to test any field and value changes on a non-production cluster before updating the add-on on your production cluster. -
Manual resolution: If you have custom Corefile configurations, you may need to manually merge your custom settings with the new version requirements. For example, in newer EKS add-on versions, the CoreDNS Deployment uses the
/readyendpoint for the readinessProbe. If you use a custom Corefile, you must add thereadyplugin to the config so that the/readyendpoint is active in CoreDNS.
Restoring Configuration:
If you need to restore your configuration after the update, you can reapply your custom settings from the backup file you created. Make sure to review and merge any necessary changes required by the new CoreDNS version with your custom configuration.
Best Practice:
It's strongly recommended to test the upgrade process in a non-production environment first to identify and resolve any conflicts before applying changes to your production cluster.
Sources
Manage CoreDNS for DNS in Amazon EKS clusters - Amazon EKS
Update the CoreDNS Amazon EKS add-on - Amazon EKS
Upgrade Amazon EKS add-ons | AWS re:Post
Update an Amazon EKS add-on - Amazon EKS
Relevant content
- asked 2 years ago
- asked 2 years ago
- asked 4 years ago
- AWS OFFICIALUpdated 10 months ago
- AWS OFFICIALUpdated a year ago

Thanks for the reply, I will try first.
Done it today and everything works fine. Thanks