kubeadm: CoreDNS version is hardcoded to a single constant instead of resolved per Kubernetes version

[yashsingh74]

Issue

kubeadm pins the CoreDNS version to be deployed to a single flat constant (constants.CoreDNSVersion, currently v1.14.4), used regardless of which Kubernetes version is being installed or upgraded to. Users can already override the deployed CoreDNS tag via ClusterConfiguration.dns.imageTag, but several code paths reference the raw constant directly instead of the resolved/overridden value, so the override doesn't fully propagate everywhere it should:

• Corefile migration logic (phases/addons/dns/dns.go) migrates toward the hardcoded constant rather than the actually-deployed/overridden tag.
• The CoreDNS upgrade preflight checks (phases/upgrade/preflight.go) validate migration compatibility against the hardcoded constant.
• The suggested DNSVersion shown by kubeadm upgrade plan (phases/upgrade/compute.go) is a flat constant instead of being computed per target Kubernetes version, unlike the sibling EtcdVersion on the same lines.

There's also a maintenance-side problem: the upstream CoreDNS version does not get updated once a Kubernetes release branch is cut, which forces kubeadm to keep carrying the same pinned CoreDNS dependency for the lifetime of that branch. Combined with the hardcoded constant, this means there is no supported way to move off an older CoreDNS build on an existing release branch even when upstream ships a newer one.

This matters beyond consistency: newer CoreDNS releases are rebuilt against newer Go toolchain versions, which routinely carry Go CVE fixes. Because the override doesn't propagate everywhere today, a user who explicitly sets dns.imageTag to a newer CoreDNS build to pick up those fixes doesn't get consistent behavior across kubeadm. The migration/preflight/upgrade-plan logic still reasons about the old hardcoded version instead of the version the user actually asked to run. Users should be able to opt into a newer, more secure CoreDNS build without kubeadm second-guessing that choice in some code paths but not others.

What did you expect to happen?

CoreDNS should follow the same override model that etcd already has:

• A SupportedCoreDNSVersion map (keyed by Kubernetes minor version) with a resolver function
• GetDNSImage a new GetDNSImageTag helper should resolve the default from that map (falling back to the nearest version with a warning if the target Kubernetes version isn't covered yet), then apply cfg.DNS.ImageTag on top if set.
• Corefile migration, the CoreDNS upgrade preflight checks, and the kubeadm upgrade plan suggested DNSVersion should all consult the resolved/overridden version instead of the raw constant, so a user's override — including overriding to a newer CoreDNS build for CVE/security reasons — is honored consistently everywhere, not just in the deployed manifest.

This does not require any new API field — ClusterConfiguration.dns.imageTag dns.imageRepository already exist and already provide the override surface.

Created a PR addressing the changes -

• kubeadm: propagate resolved CoreDNS version override to migration, preflight, and upgrade plan kubernetes#140280

[neolit123]

This matters beyond consistency: newer CoreDNS releases are rebuilt against newer Go toolchain versions, which routinely carry Go CVE fixes. Because the override doesn't propagate everywhere today, a user who explicitly sets dns.imageTag to a newer CoreDNS build to pick up those fixes doesn't get consistent behavior across kubeadm. The migration/preflight/upgrade-plan logic still reasons about the old hardcoded version instead of the version the user actually asked to run. Users should be able to opt into a newer, more secure CoreDNS build without kubeadm second-guessing that choice in some code paths but not others.

i think the CVE argument is weak, the image override does work, that doesn't work is the validation and migration.
that is worth fixing as a bug without much discussion.

There's also a maintenance-side problem: the upstream CoreDNS version does not get updated once a Kubernetes release branch is cut, which forces kubeadm to keep carrying the same pinned CoreDNS dependency for the lifetime of that branch. Combined with the hardcoded constant, this means there is no supported way to move off an older CoreDNS build on an existing release branch even when upstream ships a newer one.

for that the override does work.

A SupportedCoreDNSVersion map (keyed by Kubernetes minor version) with a resolver function

what should be discussed is whether we need this or not.
historically i was a bit concerned that we only had such a map for etcd and not for coredns, but these dependencies are different...
etcd often breaks in ways that a certain k8s version needs exactly a certain etcd version.
that has not been the case for coredns; its kubernetes plugin is stable and the k8s APIs that it cares about are also stable. if there are Corefile changes we can gate them on k8s version in the manifest template.

a few problems with the PR:

• build/dependencies.yaml needs to be updated to use the renamed constant
• renaming constants in constants.go actually breaks users who copy the kubeadm constants.go as kubernetes is not importable as a module. one of our own tests breaks too https://github.com/kubernetes/kubeadm/blob/main/tests/e2e/manifests/verify_manifest_lists.go#L355 . but we are allowed to break the constants file as its not an API.
• you have clearly used AI but as a contributor you are required to understand what is being changed. your usage of AI must be disclosed and you must agree that you understand the changes.

if you split this work into two PRs:

• bug fix: to propagate the image tag override
• feature: expose the k8s/coredns version mapping

that might be the better approach.

in the meantime let's see what the others think
cc @SataQiu @pacoxu @carlory @HirazawaUi

for the bug i'm +1, for the feature i'm on the fence, get's a +0.5 from me.

[HirazawaUi]

There's also a maintenance-side problem: the upstream CoreDNS version does not get updated once a Kubernetes release branch is cut, which forces kubeadm to keep carrying the same pinned CoreDNS dependency for the lifetime of that branch. Combined with the hardcoded constant, this means there is no supported way to move off an older CoreDNS build on an existing release branch even when upstream ships a newer one.

That's not accurate. If CoreDNS has an intolerable CVE vulnerability, we can still update the CoreDNS version and backport it to the versions that are still supported.

[HirazawaUi]

I'm very curious to know whether you have encountered any real-world issues that urgently require this solution, because no one has ever complained before about the inability to update the CoreDNS version.

[yashsingh74]

Thanks for the detailed review, @neolit123 and @HirazawaUi.

On the CVE point its fair. The image does deploy correctly when you override the tag. But I don't think that makes the rest of the issue go away. The problem is that once you override dns.imageTag, the manifest respects it but migration and preflight don't. They still check against the hardcoded constant. So the override kind of half-works and it changes what gets deployed but not what kubeadm validates against. That inconsistency is the actual bug, separate from any CVE angle.

Second on the version map, I get the etcd comparison and agree CoreDNS isn't nearly as fragile version-to-version. But that's a compatibility argument, and what I'm pointing at is more of a consistency thing like EtcdVersion in compute.go is computed per target k8s version on literally the same lines where DNSVersion is just the flat constant. That's the asymmetry I want fixed, not a claim that CoreDNS needs the same compatibility risk treatment as etcd. Also, corefile changes solves migration, but it doesn't touch upgrade plan showing a static version regardless of target.

@HirazawaUi it's less an incident and more something I ran into while actually maintaining dependencies.yaml. Looking at how rarely the pinned CoreDNS version gets bumped across older release branches, versus how far the Go toolchain in those same branches has moved on, the two are clearly drifting out of sync. That's also the motivation when we're planning a patch or minor release, CoreDNS should be part of the set of components we're keeping in sync, not something that just sits there because nothing forces it to move. Making it easier to bump would nudge the community toward running current CoreDNS builds by default, which means fewer lingering CVEs rather than relying on someone noticing and backporting after the fact.

On we can backport it if there's an intolerable CVE I agree that's technically possible, but in practice I don't see it happening much. I don't see many CoreDNS bumps landing even on 1.32.x, 1.33.x and so on. So I'd rather make this user-centric and let consumers plan and move their own CoreDNS version, instead of it being tied to a hardcoded dependency that only moves when someone backports it.

Either way, here's what I'll do:

• split into two PRs: bug fix (migration/preflight/upgrade plan all read the resolved tag) and feature (the version map), so the bug fix isn't blocked by the feature debate
• fix build/dependencies.yaml and the vendored constants.go and run the compatibility break checks.

I used AI assistance drafting parts of #140280, but I've gone through myself and understand it.

[SataQiu]

@yashsingh74 thanks for your feedback.

I'm +1 for fixing the CoreDNS preflight and migration logic to respect the user‑specified version instead of a hardcoded constant.

But I doubt whether we need to maintain a CoreDNS version mapping. CoreDNS is already very compatible – as your PR demonstrates, K8s 1.34–1.36 all work with CoreDNS 1.14.4. And since kubeadm bumps the CoreDNS version promptly and users who upgrade step by step will naturally get the latest supported CoreDNS version, I personally don't see much need to retain mappings for older Kubernetes releases.

[HirazawaUi]

@yashsingh74 thanks, that context helps.

I think the concern about CoreDNS not being bumped often enough is more about release/dependency maintenance policy than about needing a k8s minor -> CoreDNS version map.

Even with a map, someone still has to decide to bump CoreDNS, update dependencies.yaml, verify the behavior, and backport the change. The map would mostly record that decision; it does not by itself make CoreDNS updates safer or more automatic.

For patch releases, I would still expect CoreDNS bumps to be handled deliberately, especially because it is on the cluster DNS path. If there is a concrete security issue or important bugfix, we can bump and backport the pinned version for supported branches.

So I remain +1 on fixing the dns.imageTag propagation bug, but I'm not convinced that an etcd-like CoreDNS version map is needed for this.

[yashsingh74]

Thanks all for converging on this. I've will update the PR #140280 to be bug-fix only:

• Update the Corefile migration, upgrade preflight, and kubeadm upgrade plan's DNSVersion to read the dns.imageTag instead of the hardcoded constant.
• Dropped the SupportedCoreDNSVersion map and the CoreDNSVersion rename entirely.