Core DNS Upgrades with Cluster API

[cprivitere]

This was discussed at the 3/16 cluster-api meeting and I was asked to open an issue to foster discussion on this topic.

• Currently, kcp does not upgrade coreDNS unless you explicitly pass it a version to upgrade to.
• Should this be changed? It’s very much unexpected for users. For example users using kubeadm upgrade would not see this as kubeadm would upgrade it for them.
• Currently, there is no documentation on a minimum or target version of CoreDNS to have for a particular version of K8S, only a MAXIMUM version. So even if providers wanted to manually handle this somehow, they don’t have guidance on what to enforce.
• Should management of CoreDNS be explicitly added to the provider contract?

[cprivitere]

My opinion is that at minimum we should clearly document the minimum versions required. Though I would prefer kcp just handled this automatically.

[fabriziopandini]

/milestone v1.2

Some comments to help to start the discussion

• I'm not aware of the reason behind current approach in KCP (the proposal just suggest user to change the version); however making CoreDNS upgrade automatic is a change of behavior we should properly document and advertise, and ideally it should be deployed when bumping an API version(under which conditions it happens etc. etc.)
• Documenting which version of CoreDNS should be used for each Kubernetes version (including the minimum version required) should be a responsibility of the CoreDNS project, we can eventually link to such documentation.
• AFAIK kubeadm has a notion of CoreDNS version tested with each Kubernetes version, which I expect to match with the above documentation. Not 100% sure what we should use as a source of truth between the two docs.
• We are currently documenting the maximum supported Kubernetes version in KCP, given the dependency on the CoreDNS migration library, but this is not really related to the Kubernetes version in the Cluster

[kfox1111]

This issue and kubernetes/kubeadm#2318 are related I think. Might be good to widen the conversation.

[neolit123]

I guess one way for kubeadm users to find what version of corends will be deployed for a k8s version is to use 'kubeadm confug images list' command. It will give them the corends image version which is the same as the corends version.

[sbueringer]

I think we should use Kubernetes as source of truth. IIRC there is a bunch of testing done in k/k when they upgrade to a new CoreDNS version. I don't want to duplicate their efforts and I think it's a good signal for us when they think a CoreDNS version is ready to be used / tested / ... .

E.g. here we found a bug in CoreDNS v1.8.3 which resulted in v1.8.4 being used instead: kubernetes/kubernetes#99751

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[killianmuldoon]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[cprivitere]

/remove-lifecycle stale

[fabriziopandini]

/lifecycle frozen
/area controlplane
/area bootstrap
/triage accepted

if we can figure out a nice and clean transition from current to the new behaviour this could be a nice UX improvement at the cost of maintaining a version map between Kubernetes version and CoreDns version.
It probably qualifiies as API change given we are changing behaviour when fields are not explicitly set, which could be breaking for people intentially willing to stick to a specific CoreDNS version
/kind api-change
/help

[k8s-ci-robot]

@fabriziopandini:
This request has been marked as needing help from a contributor.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• Does this issue have zero to low barrier of entry?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/lifecycle frozen
/area controlplane
/area bootstrap
/triage accepted

if we can figure out a nice and clean transition from current to the new behaviour this could be a nice UX improvement at the cost of maintaining a version map between Kubernetes version and CoreDns version.
It probably qualifiies as API change given we are changing behaviour when fields are not explicitly set
/kind api-change
/help

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-ci-robot]

@fabriziopandini: The label(s) area/controlplane cannot be applied, because the repository doesn't have them.

In response to this:

/lifecycle frozen
/area controlplane
/area bootstrap
/triage accepted

if we can figure out a nice and clean transition from current to the new behaviour this could be a nice UX improvement at the cost of maintaining a version map between Kubernetes version and CoreDns version.
It probably qualifiies as API change given we are changing behaviour when fields are not explicitly set
/kind api-change
/help

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

[fabriziopandini]

/priority backlog

[fabriziopandini]

The Cluster API project currently lacks enough active contributors to adequately respond to all issues and PRs.

This issue is not updated since 2022, and I'm not aware of folks still interested around this topic/volunteering to do the design + implementation work

[fabriziopandini]

/close

[k8s-ci-robot]

@fabriziopandini: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.