原文地址:http://kubernetes.io/v1.0/docs/user-guide/secrets.html

刚说了想要使用secrets，必须要先创建它，因为磁盘会取检测这个对象是否是一个secret对象并且存在。Secrets和namespace密切相关，他们只能被相同namespace下的pod使用

单独的secrets的大小被限制为1M，这是为了防止创建打的secrets会造成api的崩溃和内存的耗尽，然后，创建很多个个小的secrets仍然会导致内存耗尽，所以对于secrets的内存更加综合负载的控制和管理将会出现在将来

Kubelet 仅仅支持从API获取到的secret,这包含所有的kubelet以及replication controller创建的所有pod,但是不包含带有–manifest-url的创建出来的Pod，以及那些非常规创建的pod（its –config flag, or its REST API (these are not common ways to create pods.)

使用Secrets的值

在挂载了secrets的container中，Secrets以文件的形式存在，并且这些值是基于 base-64 加密之后的，下面是容器中执行命令的例子


$ ls /etc/foo/
username
password
$ cat /etc/foo/username
value-1
$ cat /etc/foo/password
value-2


容器中的程序负责从加密的文件中提取具体的值，现在的情况是，如果有程序需要在环境变量中使用secret的值，那么用户就需要修改镜像文件，就类似在加载这个镜像之前增加一步来读取secret文件，并放到环境变量中。在将来会提供更加方便的方式来实现类似的功能。

Secret和Pod的交互的生命周期

当一个pod被API创建之后，这个时候，不会有任何的检查这个pod挂载的secret是否存在，一旦这个Pod被安排，kubelet就会取尝试获取secret的值，如果它获取不到，它就会不停的重试，它会发出一个报告，告诉说为什么没有启动，一旦获取成功，kubelet就会挂载secret,然后启动，注意，Pod中的容器在所有的磁盘被挂载之前是不会启动的

一旦kubelet启动了容器，它的secret就不会再改变了，即使secret的源被修改了。如果想修改这个值，必须删除原来的容器，重新创建，所有，一个secret的更新和更新一个容器镜像的流程类似（增加一个，删除一个）

resourceVersion的值在创建的时候并没有指定，所以，如果一个secret被更新了，在同时，一个pod被创建，我们就不知道pod中使用的是哪个版本的secret,通过检查的方式是不可能知道使用的是哪个版本，但是我们可以通过pod来查看使用的到底是什么，然后replacation controller重启那些旧版本的以更新到最新版本，所以，强烈建议通过创建一个新的secret的方式来更新secret而不是更新原来的secret