Bump CoreDNS version to 1.5.0 and update manifest

[rajansandeep]

What type of PR is this?

/kind bug

What this PR does / why we need it:
Updates the version of CoreDNS to 1.5.0 and also updates the manifests.

Which issue(s) this PR fixes:

Fixes #78003

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

CoreDNS is now version 1.5.0
    - A `ready` plugin has been included to report pod readiness
    - The `proxy` plugin has been deprecated. The `forward` plugin is to be used instead.
    - CoreDNS fixes the logging now that kubernetes’ client lib switched to klog from glog.

[rajansandeep]

/cc @chrisohaver

[neolit123]

thanks @rajansandeep
/approve
cc @kubernetes/sig-cluster-lifecycle-pr-reviews

[neolit123]

/retest

[neolit123]

/test pull-kubernetes-e2e-kind

[MrHohn]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: MrHohn, neolit123, rajansandeep

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• cluster/addons/dns/OWNERS [MrHohn]
• cmd/kubeadm/OWNERS [neolit123]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[rajansandeep]

/test pull-kubernetes-e2e-gce-100-performance

[rosti]

/test pull-kubernetes-e2e-gce-100-performance

[neolit123]

@rajansandeep
looks like the bump broke kubeadm upgrade e2e:
https://k8s-testgrid.appspot.com/sig-cluster-lifecycle-kubeadm#kubeadm-kinder-upgrade-stable-master
72f6954...a67f128

i will have a look, but we might have to revert if there is no apparent solution
cc @fabriziopandini

[neolit123]

creating a cluster from the master k/k branch works fine with the new coredns version.
however, creating an older k/k version cluster and upgrading it to master causes the coredns pods to not ready-up.

nothing apparent in the container logs:
https://storage.googleapis.com/kubernetes-jenkins/logs/ci-kubernetes-e2e-kubeadm-kinder-upgrade-stable-master/1129638974428549121/artifacts/kinder-upgrade-control-plane/containers/coredns-fb8b8dccf-v9qj7_kube-system_coredns-2b0e095354f65aab8941d4a50b23ec24e86ec441395edeae5a7a318ac948c4bf.log
https://gcsweb.k8s.io/gcs/kubernetes-jenkins/logs/ci-kubernetes-e2e-kubeadm-kinder-upgrade-stable-master/1129638974428549121/artifacts/kinder-upgrade-control-plane/containers/

[rajansandeep]

@neolit123 I believe this is due to the CoreDNS ConfigMap retained during upgrade and the ‘ready’ plugin not included in the upgraded version. This causes the coredns pods to report as not-ready.

This is one of the reasons why #78033 is important.

[neolit123]

ok, understood
it would have been better to get #78033 in first to have the migrate logic in place before the version bump.

[chrisohaver]

Can the failing upgrade tests be run ad-hoc in a PR?

[neolit123]

No. Not on a pr remotelly but locally yes using the tool kinder. However i think the failure is reproducible with a regular 1.14 - master upgrade