Cut v2.1.0-rc.0

[mrueg]

What this PR does / why we need it:

## v2.1.0-rc.0 / 2021-05-20
  
* [FEATURE] Add support for native TLS #1354
* [FEATURE] Add wildcard option to metric-labels-allowlist #1403
* [FEATURE] Add build info metric #1332
* [CHANGE] Add "uid" label to every pod metric #1304
* [CHANGE] Add resourceVersion to CronJob metrics #1447
* [CHANGE] Update go version and dependencies #1474
* [CHANGE] Bump client-go and friends to v0.21 (Kubernetes v1.21) #1463
* [CHANGE] Replace deprecated use of ioutil #1458
* [BUGFIX] Fix builder.Builder WithMetrics signature #1455
* [BUGFIX] Fix pod-metric missing reasons #1287
* [BUGFIX] Fix multiListWatch resourceVersion mismatch if watch reconnected #1377

@lilic @tariq1890 @brancz

[lilic]

Thank you!

[lilic]

I don't think we need an rc, we can go straight to the release of v2.1, we mainly did this for 2.0 due to so many breaking changes. What do you think?

[mrueg]

This works for me as well, I did it as the release process suggested to start with an rc. I don't mind going straight to 2.1.0 and branch off then. the risk should be rather low.

[tariq1890]

I think we should still follow the documented release process.

But having said that, if we want to retire the rc builds, I am okay with amending the release process in another PR and going forward with this approach

[lilic]

As mentioned I am happy with going with releases candidates 👍

error: pathspec 'release-2.1' did not match any file(s) known to git

You need to create a new release branch, do you have permissions for it?

[mrueg]

As mentioned I am happy with going with releases candidates +1

error: pathspec 'release-2.1' did not match any file(s) known to git

You need to create a new release branch, do you have permissions for it?

I was following the release steps (to ensure they are correct). I can create a branch here for the release from master. I assume we need to do that first then?

[lilic]

Yeah, it's not a common step, but the benchmark test requires it.

Cut the new release branch, e.g. release-1.2, or merge/cherry-pick changes onto the minor release branch you intend to tag the release on

guess it's an odd ordering but its in the release docs.

[mrueg]

I pushed the release-2.1 branch and switched this PR to point to it

[tariq1890]

/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: lilic, mrueg, tariq1890

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 [lilic,tariq1890]

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