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.): various combinations of EBS/volume/deleted/wiped/1.3

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

Kubernetes version (use kubectl version): 1.3.5

Environment:

Cloud provider or hardware configuration: AWS

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

Kernel (e.g. uname -a): Linux ip-10-20-8-136.ec2.internal 4.3.3-coreos #2 SMP Thu Dec 17 23:57:55 UTC 2015 x86_64 Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz GenuineIntel GNU/Linux

Install tools: CloudFormation + Ansible

Others:

What happened:

After the upgrade to 1.3.5, EBS volumes no longer get detached after their parent pods move to different nodes. Worse still, the volumes get wiped clean.

What you expected to happen:

EBS volumes should get detached/attached as pods move and their content should never be wiped.

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

Starting from a cluster running 1.2.4

Create a deployment of size 1 with an EBS volume, and write some data to the volume

Upgrade the cluster to 1.3.5. Following the instructions at https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md/#v130-beta1, under the bullet point "In order to safely upgrade an existing Kubernetes cluster without interruption of volume attach/detach logic:"

Upgrade master to 1.3.5

Upgrade nodes to 1.3.5

Trigger a move for the pod created in step 1, for example by specifying a different node in spec.nodeName

Anything else do we need to know:

First, I think volume attach/detach stopped working after the upgrade because kubelet can't add the volumes.kubernetes.io/controller-managed-attach-detach annotation to existing nodes. New nodes do come up with this annotation.

Second, the volumes get wiped because kubelet tries to recursively delete the pod directory before the volumes are unmounted, which, because of the first problem, never happens.

cc @thomaso-mirodin

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

skydns, dns, docs

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

BUG REPORT -- Documentation

Kubernetes version (use kubectl version):

master branch

Environment:

Cloud provider or hardware configuration:

None, local setup via vagrant

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

CoreOS 1122.0.233

Kernel (e.g. uname -a):

Linux c40 4.7.0-coreos-r1

Install tools:

Vagrant + Ansible running on a container that provisions each host to a given state (master or minion)

Kubernetes running using hyperkube in a container

Others:

What happened:

There is no way to run SkyDNS that I can find in the docs to specify an IP address or host of the API server that would work if the API server goes away and it started up on another host.

The documentation has a couple issues.

The broken link in https://github.com/kubernetes/kubernetes/tree/master/build/kube-dns:

"See the example files (ReplicationController and Service),"

The hyperlink to "ReplicationController" is broken and goes to https://github.com/kubernetes/kubernetes/blob/master/cluster/addns/dns/skydns-rc.yaml.in

And should go to ("addons" instead of "addns").

https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/skydns-rc.yaml.in

I tried to fix this in the source but can't find where "addns" is coming from in the markdown conversion.

Secondly, in the section "How Does it work", starting with "SkyDNS depends on etcd for what to serv", the paragraph is lined out.

I now understand after looking at the 1.4 branch that DNS has been completely reworked to not use kube2sky, however, this is confusing if someone is just using the master branch.

What you expected to happen:

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

view https://github.com/kubernetes/kubernetes/tree/master/build/kube-dns

Anything else do we need to know:

master branch.