Spike: Understand CoreDNS upgrades for an existing cluster

[eak13]

Problem Statement
We need to get a better understanding of the implications of upgrading the CoreDNS component in a brownfield scenario.

https://coredns.io/
https://coredns.io/2021/05/28/coredns-1.8.4-release/ < latest release notes

Proposed Change

• Can you upgrade CoreDNS independent of a kubernetes upgrade via CAPI?
• How disruptive is an upgrade? (i.e. no-op vs. reboot cluster?)
• Can you deploy an explicit version vs. the k8s default?
• Any other pertinent information for a CoreDNS upgrade

[SaurabhArora86]

I can work on it, please assign it to me.

[SaurabhArora86]

@ak3216 What are we thinking for the outcome of this Issue. Hackmd link or some kind of document

[eak13]

@SaurabhArora86 that would be great, or you can just update in the comments here. Would also ask that you add a topic to the design call agenda so we can review with the broader team.

[SaurabhArora86]

coreDNS.docx
This is a WIP copy

[SaurabhArora86]

As per what was discussed in Design call, it is best to upgrade CoreDNS as a part of Kubernetes upgrade in CAPI rather than upgrading CoreDNS individually.

Majorly because:

1. CAPI has feature of handling Corefile upgrade along with CoreDNS rather than manually updating Corefile (in case of Only CoreDNS upgrade).

2. Updating only CoreDNS image in KCP spec, causes entire CAPI to reconcile and spin up a new machine rather than just updating CoreDNS deployment.

3. KCP needs to be annotated to exclude CoreDNS from its scope.

All this has been described as a part of Hackmd link Spike: Understand CoreDNS upgrades for an existing cluster - HackMD.0

[lb4368]

https://hackmd.io/iogRxOGfSZWu7ypHq-w9mw?view