Issue 1:
Had started on a page that references this page. Have filed an issue against the parent but part of its resolution involves fixing this page too:

#21631

The page:

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

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

Provides instructions on generating a secret. It was not immediately obvious from this page (I linked directly to it to a 1. Download/build the code, 2. You should have a "make" command....) that there's an assumption that the reader will have downloaded Kubernetes/examples sources. The make command obviously won't work as the correct "make" command won't exist:

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

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 Kuberenetes 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.

Issue 2:
Forked from the discussion in #30083 for implementing against CRI. I remember there is an old issue for this, but couldn't find it anyway.

It's worth noted that changing the container naming format is likely to cause one-time backward compatibility issues during upgrades, and may need non-trivial effort to ensure nothing would break. We'll need to determine whether it's worth the efforts to overhaul the naming logic right now. However, it shouldn't be a blocker for the ongoing kuberuntime implementation. We can use this issue to discuss what naming format to use and whether we want to make the change and/or make it backward compatible.

Kubelet embeds a lot of information in the (docker) container name itself so that it can retrieve the information easily. The current format:

k8s_<container_name>.<hash_of_container>_<pod_name>_<pod_namespace>_<pod_UID>_<random_ID>

kubelet detects whether a container meets the desired spec by checking the hash of the container.

As for the random ID, it's used to ensure each name is unique since kubelet creates a new instance of the container every time a container terminates (i.e., restarting).

The "k8s_" prefix is used to detect whether this container is managed by kubelet or not.

E.g.,

pod name: heapster-v1.1.0-527143062-67der
pod namespace: kube-system
container name: heapster-nanny

The docker container name:
k8s_heapster-nanny.1a2e29e8_heapster-v1.1.0-527143062-67der_kube-system_b288c37f-58d9-11e6-a5b5-42010af00002_d4cdbac9

With CRI, there is no need to construct a super long container name. We could either rely more on the labels, or potentially rely on the runtime to provide more information.

However, we still need to 1) make container name meaningful and user-friendly, and 2) generate unique name

IMO, we can write the <hash_of_container> as a label and remove it from the name. The pod UID, though useful in some cases (when pods get recreated), is too long and should be omitted. The new name will look like:

k8s_<container_name>_<pod_name>_<pod_namespace>_<random_ID>

@kubernetes/sig-node @thockin @dchen1107