CoreDNS addon uses « wrong » kubeadm default config

[moh2a]

Description

When the CoreDNS addon configuration is left empty, Kamaji automatically creates the CoreDNS Deployment using the default kubeadm configuration. To do so, Kamaji relies on an embedded Go dependency on kubeadm.

The issue is that this kubeadm Go dependency is not necessarily aligned with the Kubernetes / kubeadm version of the managed cluster. For example:

• Kamaji may embed kubeadm v1.35
• The managed cluster may actually run Kubernetes v1.32

Because the CoreDNS version is directly tied to the kubeadm version
(see https://github.com/coredns/deployment/blob/master/kubernetes/CoreDNS-k8s_version.md),
this can result in Kamaji deploying a CoreDNS version that does not match the cluster Kubernetes version.

Why this is problematic

This behavior is particularly problematic in the following scenarios:

• Air-gapped environments, where container images are preloaded and strictly controlled

• Kamaji upgrades, which may unexpectedly change the CoreDNS version

Since the kubeadm Go dependency may change between Kamaji releases, upgrading Kamaji can trigger a CoreDNS rollout even though the cluster Kubernetes version has not changed.

This makes CoreDNS upgrades:

• Implicit
• Hard to predict
• Decoupled from the cluster lifecycle

As a result, Kamaji may attempt to deploy a CoreDNS image that:

• Is not available in the configured or preloaded registry
• Is incompatible with the cluster Kubernetes version
• Was not intentionally upgraded by the operator

Current workaround

The only reliable workaround today is to explicitly configure:

• The CoreDNS image tag
• The CoreDNS image registry

This prevents Kamaji from falling back to kubeadm defaults coming from a different kubeadm version than the one used by the cluster.

Expected behavior

Ideally, the following improvement would be desirable:

• Derive the CoreDNS version from the actual Kubernetes version of the managed cluster, rather than from Kamaji’s embedded kubeadm dependency

Thanks for your work on Kamaji. We hope this feedback helps improve the predictability and safety of CoreDNS addon management. Please let us know if further details or examples are required.

[prometherion]

It's doable as we did with the Konnectivity server/agent by inflecting the version from the deployed Control Plane version: with CoreDNS, is way harder since there's no parity in terms of version.

I wouldn't define this as a bug, but rather as a feature request: we have our roadmap and are happy to receive external contributions, or a commercial engagement to get this delivered.