Automatically add node labels beta.kubernetes.io/{os,arch}

[luxas]

Proposal: #17981
As discussed in #22623:

@davidopp: #9044 says cloud provider but can also cover platform stuff.

Adds a label beta.kubernetes.io/platform to kubelet that informs about the os/arch it's running on.
Makes it easy to specify nodeSelectors for different arches in multi-arch clusters.

$ kubectl get no --show-labels
NAME        STATUS    AGE       LABELS
127.0.0.1   Ready     1m        beta.kubernetes.io/platform=linux-amd64,kubernetes.io/hostname=127.0.0.1
$ kubectl describe no
Name:           127.0.0.1
Labels:         beta.kubernetes.io/platform=linux-amd64,kubernetes.io/hostname=127.0.0.1
CreationTimestamp:  Thu, 31 Mar 2016 20:39:15 +0300

@davidopp @vishh @fgrzadkowski @thockin @wojtek-t @ixdy @bgrant0607 @dchen1107 @preillyme

[davidopp]

Would it be better to split it into two labels, one for OS and one for arch?

[luxas]

Do you have a specific case where it would be useful?
To me, it doesn't matter so much, but I think we're fine with one, cause in most cases, you must specify both os and arch

[luxas]

@davidopp Is it ok as-is or should I change something?
I would like to hear what you think.

I lean towards just one label as implemented here.
It would make less noise, and it's only one label to specify in nodeSelector
And I honestly can't come up with a case where you only would specify os or arch.

WDYT about os-arch vs os_arch then?
os/arch (which I would have preferred) wasn't allowed as a value.

[vishh]

I have a preference for separating OS from Arch as well. Depending on the use case this PR is trying to address, I guess the value of the split might not be obvious.

[ixdy]

Note prior art: with #19905, the server version string includes a field "platform" which is fmt.Sprintf("%s/%s", runtime.GOOS, runtime.GOARCH).

[luxas]

@davidopp @vishh Updated to two labels for reasons no one knows today but may prove useful in the future.
PTAL

[davidopp]

LGTM

[vishh]

@davidopp @dchen1107 @bgrant0607 What is the purpose of NodeStatus.NodeSystemInfo? Is that supposed to be a super set of all the node related labels that are exposed by the kubelet? Will users be able to use the fields in NodeSystemInfo for scheduling in the future?

[vishh]

@davidopp can we hold on to this PR until #23684 (comment) is resolved?

[luxas]

ping @davidopp @lavalamp
I think it'll pass now
PTAL

[davidopp]

LGTM

[luxas]

@k8s-bot unit test this please github issue: #IGNORE

[luxas]

@davidopp Any clue what's failing in integration?
FAIL k8s.io/kubernetes/pkg/kubelet 0.768s

Removing ok-to-merge as it isn't needed anymore

[luxas]

Adding LGTM back now when the rebase/flake is fixed.

[luxas]

@david-mcmahon FYI, I'd really like this to get merged before v1.3.0-alpha.4 so we can test the changes out.
But I don't know if I should add priority just for that (right now 7th in the queue)
Please keep in mind before cutting the release :)

[luxas]

@jlowdermilk FYI, this has been ín the queue now three times when the submit-queue stopped and started again. Now it got kicked out of the queue because of what I think is a flake:

FAIL    k8s.io/kubernetes/contrib/mesos/pkg/offers  5.889s

That hasn't showed up earlier when these commits have been tested, so it have to be a flake.
Will retest unit.

[luxas]

@k8s-bot unit test this please github issue: #IGNORE

[luxas]

Adding P1 given that we want it merged before v1.3.0-alpha.4 and because it was on the top of the queue some hours ago but was kicked out due to flakes/unstable queue

[k8s-github-robot]

@k8s-bot test this [submit-queue is verifying that this PR is safe to merge]

[k8s-bot]

GCE e2e build/test passed for commit 0b6b723.

• Build Log
• Test Artifacts
• Internal Jenkins Results

[k8s-github-robot]

Automatic merge from submit-queue

[davidopp]

@luxas if you want these also published as labels, you're running low on time to send a PR, as the code freeze for 1.3 is this Friday.

[luxas]

@davidopp I do not really understand what you mean, os/arch is already exposed as labels on every node:

$ hack/local-up-cluster.sh
...
$ _output/local/bin/linux/amd64/kubectl describe no
Name:           127.0.0.1
Labels:         beta.kubernetes.io/arch=amd64
            beta.kubernetes.io/os=linux
            kubernetes.io/hostname=127.0.0.1
CreationTimestamp:  Mon, 16 May 2016 08:56:22 +0300
Phase:          
Conditions:
  Type      Status  LastHeartbeatTime           LastTransitionTime          Reason              Message
  ----      ------  -----------------           ------------------          ------              -------
  OutOfDisk     False   Mon, 16 May 2016 08:57:26 +0300     Mon, 16 May 2016 08:56:22 +0300     KubeletHasSufficientDisk    kubelet has sufficient disk space available
  Ready     True    Mon, 16 May 2016 08:57:26 +0300     Mon, 16 May 2016 08:56:23 +0300     KubeletReady            kubelet is posting ready status
Addresses:  127.0.0.1,127.0.0.1
Capacity:
 alpha.kubernetes.io/nvidia-gpu:    0
 cpu:                   4
 memory:                16359708Ki
 pods:                  110
System Info:
 Machine ID:            dce29be2dcd94c1b958052dc77e08e6f
 System UUID:           3C4DC303-9C6C-11E4-A26A-F0761C62F136
 Boot ID:           5d120efb-67d6-4e91-9ae7-4c666fa4ab42
 Kernel Version:        4.2.0-25-generic
 OS Image:          Ubuntu 15.10
 Operating System:      linux
 Architecture:          amd64
 Container Runtime Version: docker://1.9.1
 Kubelet Version:       v1.3.0-alpha.1.1829+aada051b20c9e4-dirty
 Kube-Proxy Version:        v1.3.0-alpha.1.1829+aada051b20c9e4-dirty
ExternalID:         127.0.0.1
Non-terminated Pods:        (0 in total)
...

But thanks for notifying anyway, I'll have to be quick with some other things