Issue 1:
Learning more Kubernetes, I wanted to follow the documentation through "Securing the Service". This example references another and opaquely, this second reference references code that is broken :-(

http://kubernetes.io/v1.1/docs/user-guide/connecting-applications.html#securing-the-service

https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/connecting-applications.md#securing-the-service

The page references "Nginx https service":

http://kubernetes.io/v1.1/examples/https-nginx/README.html

https://github.com/kubernetes/kubernetes/blob/release-1.1/examples/https-nginx/README.md

Which provides instructions on generating the secret. It was not immediately obvious from the page that there's an assumption that the reader will have downloaded Kubernetes/examples sources.

make keys secret KEY=/tmp/nginx.key CERT=/tmp/nginx.crt SECRET=/tmp/secret.json

After attempting and failing to download/build the sources, I believe that this script no longer works:

#14558

I'll break the issue into separate issues, since, by fixing the make, the "Nginx https service" will be fixed (#21633). However, I wasted quite some (free time) to realize this mistake and was blocked for some time.

Ironically, I found generate-secrets-from-file on the following page and, through grokking this and the make_secret.go file, I was able to muddle through and create a secret.json file for Kubernetes.

https://tectonic.com/enterprise/docs/latest/deployer/tls.html

Recommend:

Add documentation that explicitly documents (separately) how to generate a Kubernetes secret from self-signed certificates.

Please add (if there's not already) an easier way to submit bugs against kubernetes.io by helping the reader reference the github source directly. I googled for duplicates to find the correct github page.

It's challenging in documentation but please be mindful of introducing nested assumptions to do this, do this, which requires doing this..... as, if any part of the chain fails...

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

Yes

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

I am aware of similar

issue #29166 which was fixed in #36616 and v1.4.6. However, I can

still reproduce as of v1.4.6.

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

Bug Report

Kubernetes version (use kubectl version):

v1.4.6

Environment:

Cloud provider or hardware configuration: AWS

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

Kernel (e.g. uname -a): 4.7.3-coreos-r2

Install tools: kube-aws v0.9.1

What happened:

Periodically, petsets will drop below the number of desired replicas

and be unable to restore themselves.

The petset shows the following error:

Unable to mount volumes for pod "petset-min-repro-0_default(xxx...)": timeout expired waiting for volumes to attach/mount for pod "petset-min-repro-0"/"default". list of unattached/unmounted volumes=[storage]
Error syncing pod, skipping: timeout expired waiting for volumes to attach/mount for pod "petset-min-repro-0"/"default". list of unattached/unmounted volumes=[storage]

What you expected to happen:

I expect EBS volumes to reattach to the correct pod automatically

following node failure.

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

Apply the below YAML to bring up the test PetSet

# Define storage class first so it can be used later
kind: StorageClass
apiVersion: storage.k8s.io/v1beta1
metadata:
name: ebs-encrypted-storage

# Launch in AWS
provisioner: kubernetes.io/aws-ebs

# EBS-specific settings
# http://kubernetes.io/docs/user-guide/persistent-volumes/#aws
parameters:
type: io1
encrypted: "true"
zone: us-west-1b
iopsPerGB: "10"

---

# PetSet boilerplate
apiVersion: apps/v1alpha1
kind: PetSet
metadata:
name: petset-min-repro
labels:
component: test
role: reprpoduce

spec:
serviceName: petset-min-repro
replicas: 2

template:
metadata:
labels:
component: test
role: reprpoduce
annotations:
pod.alpha.kubernetes.io/initialized: "true"

spec:

# One container with an image that does nothing
containers:
- name: es-data
image: alpine:latest
command:
- tail
- -f
- /dev/null

# Attach persistent storage
volumeMounts:
- name: storage
mountPath: /data

volumeClaimTemplates:
- metadata:
name: storage
annotations:
# The storage should use the below defined storage class
# Use both alpha and beta annotations for compatibility
# http://blog.kubernetes.io/2016/10/dynamic-provisioning-and-storage-in-kubernetes.html
volume.alpha.kubernetes.io/storage-class: ebs-encrypted-storage
volume.beta.kubernetes.io/storage-class: ebs-encrypted-storage

spec:
# Volume should only be mountable to one pod at a time
accessModes:
- ReadWriteOnce
resources:
requests:
# Smallest allowed io1 volume size
storage: 4Gi

Identify the EBS volume bound to one of the pods

PVC=$(kubectl describe pvc storage-petset-min-repro-0 | grep Volume | awk '{ print $2 }')
VOLUME_ID=$(kubectl describe pv $PVC | grep VolumeID | awk -F '/' '{ print $NF }')

Detach the EBS volume from the node. One may reasonably ask why this would

happen at all, but this is the most reliable way I've found

to reproduce. It has also occurred randomly.

aws ec2 detach-volume --volume-id=$VOLUME_ID

Observe that the pod does not successfully restart and

remains stuck in state ContainerCreating.

kubectl get pod petset-min-repro-0

Anything else do we need to know:

I have been able to so far work around this issue by terminating the node

the pod is attempting to attach onto.