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.):

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:

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-45-51-248 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 vm:

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 --cloud-provider=aws

Output was as follows:

Running pre-flight checks
cloud provider "aws" initialized for the control plane. Remember to set the same cloud provider flag on the kubelet.
<master/tokens> generated token: "a57da0.0787c7da23cded2a"
<master/pki> generated Certificate Authority key and certificate:
Issuer: CN=kubernetes | Subject: CN=kubernetes | CA: true
Not before: 2016-11-18 13:36:38 +0000 UTC Not After: 2026-11-16 13:36:38 +0000 UTC
Public: /etc/kubernetes/pki/ca-pub.pem
Private: /etc/kubernetes/pki/ca-key.pem
Cert: /etc/kubernetes/pki/ca.pem
<master/pki> generated API Server key and certificate:
Issuer: CN=kubernetes | Subject: CN=kube-apiserver | CA: false
Not before: 2016-11-18 13:36:38 +0000 UTC Not After: 2017-11-18 13:36:39 +0000 UTC
Alternate Names: [10.45.51.248 10.96.0.1 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local]
Public: /etc/kubernetes/pki/apiserver-pub.pem
Private: /etc/kubernetes/pki/apiserver-key.pem
Cert: /etc/kubernetes/pki/apiserver.pem
<master/pki> generated Service Account Signing keys:
Public: /etc/kubernetes/pki/sa-pub.pem
Private: /etc/kubernetes/pki/sa-key.pem
<master/pki> created keys and certificates in "/etc/kubernetes/pki"
<util/kubeconfig> created "/etc/kubernetes/kubelet.conf"
<util/kubeconfig> created "/etc/kubernetes/admin.conf"
<master/apiclient> created API client configuration
<master/apiclient> created API client, waiting for the control plane to become ready
<master/apiclient> all control plane components are healthy after 26.051640 seconds
<master/apiclient> waiting for at least one node to register and become ready
<master/apiclient> first node is ready after 2.502080 seconds
<master/apiclient> attempting a test deployment

After outputting the last line (attempting a test deployment) it doesn't do anything. Ever. I've tried this several times (on newly provisioned VMs each time), and the same thing happens every time.

What you expected to happen:

Either complete the test deployment and move on, or show some sort of error indicating what went wrong and ideally a reference to some documentation on how to fix/workaround/do whatever it was I didn't do and was supposed to.

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

Create two 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.

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/.):

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

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

Kubernetes version (use kubectl version):

Environment:

Cloud provider or hardware configuration:

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

Kernel (e.g. uname -a):

Install tools:

Others:

What happened:

kubectl get cs

NAME STATUS MESSAGE ERROR

etcd-1 Unhealthy Get https://10.37.116.32:2379/health: remote error: bad certificate

scheduler Healthy ok

controller-manager Healthy ok

etcd-0 Unhealthy Get https://10.37.116.31:2379/health: remote error: bad certificate

What you expected to happen:

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

Anything else do we need to know: