[Kubeadm]:Bump CoreDNS to v1.7.0

[rajansandeep]

What type of PR is this?
/kind bug

What this PR does / why we need it:
Updates CoreDNS to v1.7.0. The default Corefile now includes the max_concurrent option, which sets the maximum number of concurrent upstream queries allowed by the forward plugin.

Also updates the migration library to 1.0.10 which supports coredns v1.7.0

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

ACTION REQUIRED : In CoreDNS v1.7.0, [metrics names have been changed](https://github.com/coredns/coredns/blob/master/notes/coredns-1.7.0.md#metric-changes) which will be backward incompatible with existing reporting formulas that use the old metrics' names. Adjust your formulas to the new names before upgrading. 

Kubeadm now includes CoreDNS version v1.7.0. Some of the major changes include:
-  Fixed a bug that could cause CoreDNS to stop updating service records.
-  Fixed a bug in the forward plugin where only the first upstream server is always selected no matter which policy is set.
-  Remove already deprecated options `resyncperiod` and `upstream` in the Kubernetes plugin.
-  Includes Prometheus metrics name changes (to bring them in line with standard Prometheus metrics naming convention). They will be backward incompatible with existing reporting formulas that use the old metrics' names.
-  The federation plugin (allows for v1 Kubernetes federation) has been removed.
More details are available in https://coredns.io/2020/06/15/coredns-1.7.0-release/

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

[rajansandeep]

/cc @chrisohaver

[BenTheElder]

https://prow.k8s.io/view/gcs/kubernetes-jenkins/pr-logs/pull/92651/pull-kubernetes-dependencies/1277983325801156608 is a real failure

[neolit123]

should we also mention this change in the release note? i don't have good statistical context on how breaking it is, but i'm going to assume it affects larger clusters with a lot of queries?

[chrisohaver]

The limit is per instance. The larger a cluster the more CoreDNS instances... So it should not change drastically at scale in theory. For comparison, kube-dns (via it's default dnsmasq behavior), had a limit of 150 concurrent queries. More details here. CoreDNS never had a limit before this, it would just OOM if too many queries came in.

[neolit123]

ok, thanks for the details.

[chrisohaver]

Regarding release notes: CoreDNS 1.7.0 does introduce some backward incompatible changes. Notably, it makes many Prometheus metrics name changes (to bring them in line with standard Prometheus metrics naming convention). They will be backward incompatible with existing reporting formulas that use the old metrics names. Less critically, 1.7.0 drops support for a couple of kubernetes plugin options which had already been deprecated and ignored by CoreDNS for several releases (i.e. now instead of ignoring them, CoreDNS will exit with an unknown directive error).

[neolit123]

i think we should briefly mention that in the k8s release note and even link to the coredns release notes.

[rajansandeep]

Yes, I’ll update the release notes.

[neolit123]

last time i've checked, feature freeze was on the 9th of July.
/milestone v1.19
/approve

[neolit123]

/kind feature

[rajansandeep]

@neolit123, I updated the release notes with "action required" for the metrics changes.
Would it be appropriate to include the workaround example in coredns/coredns#3671 (comment) in the notes?

[neolit123]

or just link to the example github comment - e.g. "A workaround can be found here - LINK".
@rosti WDYT?

[neolit123]

/lgtm
/approve
/retest

i unblocked this PR, but hoping we will not get many user complains about the breaking changes.

[neolit123]

/milestone v1.19
/priority important-soon

[rajansandeep]

/assign @liggitt
/retest

[liggitt]

cc @johnbelamaric for coredns breaking changes

/approve
for vendor bump

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: liggitt, 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:

• OWNERS [liggitt]

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

[chrisohaver]

/lgtm

[rajansandeep]

/retest

[rajansandeep]

/retest

[fejta-bot]

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to fejta).

Review the full test history for this PR.

Silence the bot with an /lgtm cancel or /hold comment for consistent failures.