Improve CoreDNS support and validation in KubeadmControlPlane

[wfernandes]

User Story

As part of issue #2545, we added a dependency on github.com/coredns/migration. It was added in PR: #2574.

This library needs to be kept up to date if we are to support future coredns version upgrades so we will need automation to check for upgrades in this library and update our modules.
OR
We decouple ourselves from this library somehow. 🙂

See comment below from @detiber:

I'm wondering if we should think about some type of automated checking to see if it is out of date, since the current implementation will require us to cut a new release if a newer version of CoreDNS is released prior to us being able to support it (based on the version comparison check)

https://github.com/kubernetes-sigs/cluster-api/pull/2574/files/9cb95d52d539b8b3109951909588388781ba7acd#r389755735

/cc @vincepri @ncdc
/kind feature

[ncdc]

We should look into switching over to using the CoreDNS operator as soon as it's mature and stable.

[timothysc]

@stealthybox @neolit123 - What's the state of the addons, and the latest CoreDNS operator?

[neolit123]

The CoreDNS operator needs a controller runtime v2 update, but it should be available in the near future. This will help us extract the migration logic out of capi and kubeadm. But the version binding would remain in any form, since consumers would need to track operator versioning. Benefits would come if A) we can track the latest version of the operator B) old versions of the operator can install and migrate newer CoreDNS.

[vincepri]

Where is the coredns operator code hosted today?

[neolit123]

there is a coredns operator here:
https://github.com/kubernetes-sigs/cluster-addons/tree/master/coredns
but AFAIK this is not the operator that the coredns maintainers created.

i also see there is a related GSoC task for this opened 5 days ago that includes ConfigMap updates:
kubernetes-sigs/cluster-addons#47
cc @johnsonj

@rajansandeep mentioned to me that he is personally working on the operator, so i do not know how/if this intersects with GSoC and if there is source code in another repository.

is the GSoC task supposed to be completed by a student or is this adjacent work? my personal preference would be to delegate the main body of work away from GSoC - i.e. have a working version with CRv2 ideally sooner than end-of-GSoC.

[wfernandes]

A couple of questions I had:

• Will this CoreDNS Operator be installed and/or managed by clusterctl?
• What is GSoC?

[vincepri]

For v0.3.x we might need a different issue to add a verification script to update to the latest version of the module, if it's available

[neolit123]

Will this CoreDNS Operator be installed and/or managed by clusterctl?

unclear to me. would make sense to install it in an "addons phase" of sorts.

What is GSoC?

google summer of code.

[johnsonj]

Thanks for the cc @neolit123 - I'll discuss this in cluster-addons and with @rajansandeep

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[vincepri]

/lifecycle frozen

[vincepri]

/milestone v0.4.x

[vincepri]

/milestone Next

[vincepri]

/milestone v1.2
/retitle Improve CoreDNS support and validation in KubeadmControlPlane
/assign @sbueringer

• Automate the version bump of the coredns migration library (somehow)
• Validate that users won't be able to set a version higher than the maximum supported within the library
• Validate that the version has a prefix (v)

[sbueringer]

xref: #4463
(there's a bunch of information in this issue)

[sbueringer]

• we should double-check if migration.ValidUpMigration actually works as expected. In our upgrade tests there seem to be cases where we migrate from v1.8.0 => v1.8.4 which should not be supported according to ValidUpMigration

[killianmuldoon]

@sbueringer I'll take a look at this. - In which case shouldn't we be allowed to go to v1.8.4 ?

[sbueringer]

@killianmuldoon I think we kind of should, but it looks like the migration might have a problem migrating the CoreDNS config then. (based on ValidUpMigration it seems to migrate from one version to another, so we would need v1.8.0=>v1.8.1=>v1.8.2=>v1.8.3=>v1.8.4)

There's an error somewhere in those assumptions, but I don't know where and we should find it out :)

[killianmuldoon]

/assign

[sbueringer]

We realized that I misread ValidUpMigration

[killianmuldoon]

@vincepri #6406 is a solution to the first item on your list:

• Automate the version bump of the coredns migration library (somehow)
• Validate that users won't be able to set a version higher than the maximum supported within the library
• Validate that the version has a prefix (v)

[fabriziopandini]

/triage accepted

[fabriziopandini]

/help
/unassign @killianmuldoon

[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:

/help
/unassign @killianmuldoon

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.

[fabriziopandini]

(doing some cleanup on old issues without updates)
/close
we now have dependabot helping us in keeping up with this dependency, and I'm not aware of issues about recent version validation so I'm closing this for now

[k8s-ci-robot]

@fabriziopandini: Closing this issue.

In response to this:

(doing some cleanup on old issues without updates)
/close
we now have dependabot helping us in keeping up with this dependency, and I'm not aware of issues about recent version validation so I'm closing this for now

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.