github/kubernetes
1
0
Fork 0
mirror of https://github.com/k3s-io/kubernetes.git synced 2025-09-10 21:50:05 +00:00
Code Issues Projects Releases Wiki Activity

Qualified all references to "controller" so that references to "replication controller" are clear. fixes #9404

Browse Source 
Also ran hacks/run-gendocs.sh
This commit is contained in:
RichieEscarez
2015-06-16 14:48:51 -07:00
parent 43889c612c
commit eb44b3c830
12 changed files with 53 additions and 52 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
docs/secrets.md
View File

@@ -103,17 +103,17 @@ start until all the pod's volumes are mounted.
Once the kubelet has started a pod's containers, its secret volumes will not
change, even if the secret resource is modified. To change the secret used,
the original pod must be deleted, and a new pod (perhaps with an identical
PodSpec) must be created. Therefore, updating a secret follows the same
`PodSpec`) must be created. Therefore, updating a secret follows the same
workflow as deploying a new container image. The `kubectl rolling-update`
command can be used ([man page](kubectl_rolling-update.md)).
The resourceVersion of the secret is not specified when it is referenced.
The `resourceVersion` of the secret is not specified when it is referenced.
Therefore, if a secret is updated at about the same time as pods are starting,
then it is not defined which version of the secret will be used for the pod. It
is not possible currently to check what resource version of a secret object was
used when a pod was created. It is planned that pods will report this
information, so that a controller could restart ones using a old
resourceVersion. In the interim, if this is a concern, it is recommended to not
information, so that a replication controller restarts ones using an old
`resourceVersion`. In the interim, if this is a concern, it is recommended to not
update the data of existing secrets, but to create new ones with distinct names.
## Use cases