Issue 1:
Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see http://kubernetes.io/docs/troubleshooting/.):

No

What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.):

'<node/discovery> failed to parse response as JWS object [square/go-jose: compact JWS format must have three parts]'

Is this a BUG REPORT or FEATURE REQUEST? (choose one):

BUG REPORT

Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.4", GitCommit:"3b417cc4ccd1b8f38ff9ec96bb50a81ca0ea9d56", GitTreeState:"clean", BuildDate:"2016-10-21T02:48:38Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}

Environment:

Cloud provider or hardware configuration:

OS (e.g. from /etc/os-release): Centos 7.1

Kernel (e.g. uname -a): 4.1.12-37.5.1.el7uek.x86_64 #2 SMP Thu Jun 9 16:01:20 PDT 2016 x86_64 x86_64 x86_64 GNU/Linux

Install tools:

Others:

What happened:

Failed with error:

<node/discovery> failed to parse response as JWS object [square/go-jose: compact JWS format must have three parts]

What you expected to happen:

The cluster should be able to join the master node

How to reproduce it (as minimally and precisely as possible):

kubeadm init on master

kubeadm join on cluster

Anything else do we need to know:

kubeadm version: version.Info{Major:"1", Minor:"5+", GitVersion:"v1.5.0-alpha.2.380+85fe0f1aadf91e", GitCommit:"85fe0f1aadf91e134102cf3c01a9eed11a7e257f", GitTreeState:"clean", BuildDate:"2016-11-02T14:58:17Z", GoVersion:"go1.7.1", Compiler:"gc", Platform:"linux/amd64"}

For kube-discovery image

docker inspect

[root@ovm21 ~]# docker inspect c5e0c9a457fc

[

{

"Id": "sha256:c5e0c9a457fcb53ac5c564656f3fabba733ab1e8187e98d095c88356b9245de8",

"RepoTags": [

"gcr.io/google_containers/kube-discovery-amd64:1.0"

],

"RepoDigests": [

"gcr.io/google_containers/kube-discovery-amd64@sha256:7ebce8129c41bf64053f56a4f4418e198265b104b17f3f2d5b61667e208528f4"

],

"Parent": "",

"Comment": "",

"Created": "2016-09-24T17:16:49.942311731Z",

"Container": "5581c81bd1defe34d67a2c267841bc164e0decd53b1a9114b745585e628de106",

"ContainerConfig": {

"Hostname": "6250540837a8",

"Domainname": "",

"User": "",

"AttachStdin": false,

"AttachStdout": false,

"AttachStderr": false,

"Tty": false,

"OpenStdin": false,

"StdinOnce": false,

"Env": [

"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

],

"Cmd": [

"/bin/sh",

"-c",

"#(nop) ENTRYPOINT \u0026{["/bin/sh" "-c" "\"/usr/local/bin/kube-discovery\""]}"

],

"Image": "2b3aeb5c0ccc7b85afa3c110b8b6fc3698f1da723f4845cd4250895c599393e1",

"Volumes": null,

"WorkingDir": "",

"Entrypoint": [

"/bin/sh",

"-c",

""/usr/local/bin/kube-discovery""

],

"OnBuild": [],

"Labels": {}

},

"DockerVersion": "1.9.1",

"Author": "",

"Config": {

"Hostname": "6250540837a8",

"Domainname": "",

"User": "",

"AttachStdin": false,

"AttachStdout": false,

"AttachStderr": false,

"Tty": false,

"OpenStdin": false,

"StdinOnce": false,

"Env": [

"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

],

"Cmd": null,

"Image": "2b3aeb5c0ccc7b85afa3c110b8b6fc3698f1da723f4845cd4250895c599393e1",

"Volumes": null,

"WorkingDir": "",

"Entrypoint": [

"/bin/sh",

"-c",

""/usr/local/bin/kube-discovery""

],

"OnBuild": [],

"Labels": {}

},

"Architecture": "amd64",

"Os": "linux",

"Size": 134164555,

"VirtualSize": 134164555,

"GraphDriver": {

"Name": "btrfs",

"Data": null

},

"RootFS": {

"Type": "layers",

"Layers": [

"sha256:42755cf4ee95900a105b4e33452e787026ecdefffcc1992f961aa286dc3f7f95",

"sha256:7815ca90458efad6a994cbe56b123737a3b92c472493d5581fb960821680a338",

"sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef"

]

}

}

]

Issue 2:
Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see http://kubernetes.io/docs/troubleshooting/.):

No.

What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.):

kubectl join

preflight

kubelet is not empty

Is this a BUG REPORT or FEATURE REQUEST? (choose one):

BUG REPORT

Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.4", GitCommit:"3b417cc4ccd1b8f38ff9ec96bb50a81ca0ea9d56", GitTreeState:"clean", BuildDate:"2016-10-21T02:48:38Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.4", GitCommit:"3b417cc4ccd1b8f38ff9ec96bb50a81ca0ea9d56", GitTreeState:"clean", BuildDate:"2016-10-21T02:42:39Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}

Environment:

Cloud provider or hardware configuration:

AWS EC2 Classic ami-45b69e52 m3.2xlarge instance type in us-east-1 region.

OS (e.g. from /etc/os-release):

NAME="Ubuntu"
VERSION="16.04.1 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.1 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial

Kernel (e.g. uname -a):

Linux ip-10-159-146-253 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:39:52 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Install tools:

N/A

Others:

N/A

What happened:

I was standing up a 3-node cluster following the instructions here: http://kubernetes.io/docs/getting-started-guides/kubeadm/

Commands I ran on each slave:

sudo su -
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
cat <<EOF > /etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial main
EOF
apt-get update
apt-get install -y docker.io
apt-get install -y kubelet kubeadm kubectl kubernetes-cni

Additional commands run on the master:

kubeadm init --pod-network-cidr=10.244.0.0/16
kubectl apply -f flannel.yml

flannel.yml:

---
kind: ConfigMap
apiVersion: v1
metadata:
name: kube-flannel-cfg
namespace: kube-system
labels:
tier: node
app: flannel
data:
cni-conf.json: |
{
"name": "cbr0",
"type": "flannel",
"delegate": {
"isDefaultGateway": true
}
}
net-conf.json: |
{
"Network": "10.244.0.0/16",
"Backend": {
"Type": "vxlan"
}
}
---
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
name: kube-flannel-ds
namespace: kube-system
labels:
tier: node
app: flannel
spec:
template:
metadata:
labels:
tier: node
app: flannel
spec:
hostNetwork: true
nodeSelector:
beta.kubernetes.io/arch: amd64
containers:
- name: kube-flannel
image: quay.io/coreos/flannel-git:v0.6.1-28-g5dde68d-amd64
command: [ "/opt/bin/flanneld", "--ip-masq", "--kube-subnet-mgr" ]
securityContext:
privileged: true
env:
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
volumeMounts:
- name: run
mountPath: /run
- name: flannel-cfg
mountPath: /etc/kube-flannel/
- name: install-cni
image: quay.io/coreos/flannel-git:v0.6.1-28-g5dde68d-amd64
command: [ "/bin/sh", "-c", "set -e -x; cp -f /etc/kube-flannel/cni-conf.json /etc/cni/net.d/10-flannel.conf; while true; do sleep 3600; done" ]
volumeMounts:
- name: cni
mountPath: /etc/cni/net.d
- name: flannel-cfg
mountPath: /etc/kube-flannel/
volumes:
- name: run
hostPath:
path: /run
- name: cni
hostPath:
path: /etc/cni/net.d
- name: flannel-cfg
configMap:
name: kube-flannel-cfg

ssh-d onto slave node and ran - as per the documentation - (anonymised to protect the not-so-innocent):

sudo su -
kubeadm join --token=[TOKEN] [MASTER IP]

Output was:

Running pre-flight checks
preflight check errors:
/var/lib/kubelet is not empty

What you expected to happen:

I expected the node to join the cluster and output data according to the docs: http://kubernetes.io/docs/getting-started-guides/kubeadm/

As I understand the architecture, each node has to have a kubelet on it. I have a feeling that some preflight checks have been added for something else, reused for this and aren't quite appropriate. I may be wrong, though!

How to reproduce it (as minimally and precisely as possible):

Create three AWS EC2 Classic ami-45b69e52 m3.2xlarge instance type in us-east-1 region.

Run the commands as I did.

Anything else do we need to know:

No.