Clean up self-set node labels

[liggitt]

What type of PR is this?
/kind cleanup

What this PR does / why we need it:
Starts to clean up self-set kubelet labels under k8s.io prefixes:

• removes fluentd node selector to complete migration to daemonset
• starts the process of switching the beta.kubernetes.io/metadata-proxy-ready label to a cloud.google.com/metadata-proxy-ready label by adding the label to new nodes and labeling existing nodes on upgrade
• starts the process of switching the beta.kubernetes.io/kube-proxy-ds-ready label to a node.kubernetes.io/kube-proxy-ds-ready label by adding the label to new nodes and labeling existing nodes on upgrade
• starts the process of switching the beta.kubernetes.io/masq-agent-ds-ready label to a node.kubernetes.io/masq-agent-ds-ready label by adding the label to new nodes and labeling existing nodes on upgrade

This is related to https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/0000-20170814-bounding-self-labeling-kubelets.md#implementation-timeline

Does this PR introduce a user-facing change?:

* the fluentd addon daemonset will now target all nodes.
* setting `ENABLE_METADATA_CONCEALMENT=true` in kube-up will now set a `cloud.google.com/metadata-proxy-ready=true` label on new nodes. In v1.16, the metadata proxy add-on will switch to using that label as a node selector.
* setting `KUBE_PROXY_DAEMONSET=true` in kube-up will now set a `node.kubernetes.io/kube-proxy-ds-ready=true` label on new nodes. In v1.16, the kube-proxy daemonset add-on will switch to using that label as a node selector.
* In 1.16, the masq-agent daemonset add-on will switch to using `node.kubernetes.io/masq-agent-ds-ready` as a node selector.

/cc @piosz
for fluentd cleanup

/cc @dekkagaijin
for metadata proxy label

/sig cluster-lifecycle
/sig gcp

[k8s-ci-robot]

@liggitt: GitHub didn't allow me to request PR reviews from the following users: dekkagaijin.

Note that only kubernetes members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

What type of PR is this?
/kind cleanup

What this PR does / why we need it:
Starts to clean up self-set kubelet labels under k8s.io prefixes:

• removes fluentd node selector to complete migration to daemonset
• starts the process of switching the beta.kubernetes.io/metadata-proxy-ready label to a cloud.google.com/metadata-proxy-ready label by adding the label to new nodes

Does this PR introduce a user-facing change?:

* the fluentd addon daemonset will now target all nodes.
* setting `ENABLE_METADATA_CONCEALMENT=true` in kube-up will now set a `cloud.google.com/metadata-proxy-ready=true` label on new nodes. In a future release, the metadata add-on will switch to using that label as a node selector.

/cc @piosz
for fluentd cleanup

/cc @dekkagaijin
for metadata proxy label

/sig cluster-lifecycle
/sig gcp

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.

[liggitt]

/cc @MrHohn
for kube-proxy daemonset labeling

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: liggitt

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/fluentd-elasticsearch/OWNERS [liggitt]
• cluster/addons/fluentd-gcp/OWNERS [liggitt]
• cluster/addons/ip-masq-agent/OWNERS [liggitt]
• cluster/addons/kube-proxy/OWNERS [liggitt]
• cluster/addons/metadata-proxy/OWNERS [liggitt]
• cluster/gce/OWNERS [liggitt]
• cmd/kubelet/OWNERS [liggitt]

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

[MrHohn]

LGTM for kube-proxy and ip-masq-agent

[liggitt]

/retest

[soggiest]

/lgtm

[liggitt]

/hold

would like @dekkagaijin to weigh in on the metadata proxy change

[soggiest]

@dekkagaijin please review per @liggitt's comment above. Code freeze for 1.14 is in 3 days, this will need to be merged within the week.

[liggitt]

also want @thockin's thoughts on the cloud.google.com/metadata-proxy-ready label. That was intended to match things like cloud.google.com/gke-accelerator, but I'm not sure if that matches current thinking

/assign @thockin

[thockin]

I have precious little knowledge of the metadata proxy stuff. All of these make me want to hurt myself. Thanks for cleaning up. Do we have a plan as to when we can actually get rid of them? I know proxy daemonset work stalled..

[thockin]

@mikedanese for metdata viz, too

[dekkagaijin]

/lgtm

[k8s-ci-robot]

@dekkagaijin: changing LGTM is restricted to assignees, and only kubernetes/kubernetes repo collaborators may be assigned issues.

In response to this:

/lgtm

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.

[thockin]

/lgtm on Jake's behalf

…

On Tue, Mar 5, 2019 at 11:36 AM Kubernetes Prow Robot ***@***.***> wrote: @dekkagaijin: changing LGTM is restricted to assignees, and only kubernetes/kubernetes repo collaborators may be assigned issues. In response to this: /lgtm 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. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or mute the thread.

[liggitt]

/hold cancel

Do we have a plan as to when we can actually get rid of them? I know proxy daemonset work stalled..

we will need to keep selectors long term for the things that legitimately may not want to run on every node (masq-agent and metadata-proxy)

I don't know if there were blockers to kube-proxy progressing to run as a DS or if that work just got preempted