configMap和secret

给容器内应用程序传递参数的实现方式:
　　1. 将配置文件直接打包到镜像中，但这种方式不推荐使用，因为修改配置不够灵活。
　　2. 通过定义Pod清单时，指定自定义命令行参数，即设定 args:["命令参数"]，这种也
　　    可在启动Pod时，传参来修改Pod的应用程序的配置文件.
　　3. 使用环境变量来给Pod中应用传参修改配置
　　   但要使用此种方式，必须符合以下前提之一:
　　    1) Pod中的应用程序必须是Cloud Native的应用程序，即支持直接通过环境变量来加载配置信息。
　　    2) 通过定义Entrypoint脚本的预处理变量来修改Pod中应用程序的配置文件，这些Entrypoint脚本
　　　    可以使用set，sed，grep等工具来实现修改，但也要确保容器中有这些工具。
　　4.存储卷: 我们可将配置信息直接放到存储卷中，如PV中,Pod启动时，自动挂载存储卷到配置文件目录，
　　    来实现给Pod中应用提供不同的配置。
　　5. configMap 或 secret　　　

configMap的主要作用:
　　就是为了让镜像 和 配置文件解耦，以便实现镜像的可移植性和可复用性，因为一个configMap其实就是一系列配置信息的集合，将来可直接注入到Pod中的容器使用，而注入方式有两种，一种将configMap做为存储卷，一种是将configMap通过env中configMapKeyRef注入到容器中； configMap是KeyValve形式来保存数据的，如: name=zhangsan 或 nginx.conf="http{server{...}}" 对于configMap的Value的长度是没有限制的，所以它可以是一整个配置文件的信息。
configMap: 它是K8s中的标准组件,它通过两种方式实现给Pod传递配置参数:
　　A. 将环境变量直接定义在configMap中，当Pod启动时,通过env来引用configMap中定义的环境变量。
　　B. 将一个完整配置文件封装到configMap中,然后通过共享卷的方式挂载到Pod中,实现给应用传参。secret: 它时一种相对安全的configMap，因为它将configMap通过base64做了编码, 让数据不是明文直接存储在configMap中，起到了一定的保护作用，但对Base64进行反编码，对专业人士来说，没有任何难度，因此它只是相对安全。
对于configMap中第一种，让Pod引用configMap中的环境变量的方式:
　　kubectl explain pods.spec.containers.env 　　 #env也可直接定义传递给Pod中容器的环境变量，这点需要记住。
　　　　env.valueFrom
　　　　   configMapKeyRef： 可用于定义Pod启动时引用的configMapKey是哪个。
　　　　   fieldRef: 也可引用一个字段，为Pod中容器内应用程序的每个环境变量值,如:
　　　　   metadata.name: 引用Pod的名称
　　　　   metadata.namespace: 引用Pod所在的名称空间名
　　　　   metadata.labels: 引用Pod的标签
　　　　   status.hostIP: 引用Pod所在节点的IP
　　　　   status.podIP: 引用Pod的IP
　　　　   resourceFieldRef: 引用一个资源需求 或 资源限制
　　　　   secretKeyRef: 引用一个secretKey来为Pod传参
在定义configMap时，通常仅需要定义它的data 或 binaryData(二进制数据)，它俩都是map[string]类型的，
所以它们的值都是以hash列表方式存储的，即key和value没有直接关系，key就是hash码。
创建configmap示例:

　#命令创建:
　　kubectl create configmap nginx-config --from-literal=nginx_port=80 --from-literal=server_name=myapp.test.com
　　kubectl get configmap
　　kubectl describe cm nginx-config
　　#使用文件内容来做key的值
　　vim w3c.conf
　　　　server {
　　　　    server_name bbs.test.com;
　　　　    listen 80;
　　　　　root /data/nginx/bbs/
　　　}

#注意：configmap的名称中不支持下划线！
　　#这个是定义了一个key叫www, 其值为www.conf的内容.
　　kubectl create configmap nginx-www --from-file=www=./www.conf 

　　#这是定义了一个key叫www.conf,其值为www.conf的内容
　　kubectl create configmap nginx-www --from-file=./www.conf
　　kubectl get cm nginx-www -o yaml
　　kubectl describe cm nginx-www

#给Pod中的容器传递configMap定义的变量的示例:
vim  pod-configmap.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-cm-1
  namespace: default
  labels:
     app: myapp
     tier: frontend
  annotations:
     test.com/created-by: “cluster admin”
spec:
  containers:
  -  name: myapp
     image: ikubernetes/myapp:v1
     ports:
     -   name: http
         containerPort:80
     env:
     - name: NGINX_SERVER_PORT
       valueFrom:
         configMapKeyRef:
            name: nginx-config
            key: nginx_port
     -  name:NGINX_SERVER_NAME
        valueFrom:
          configMapKeyRef:
            name: nginx-config
            key: server_name

#应用这个使用configMap的Pod：　kubectl apply -f pod-configmap.yaml
#进入Pod查看configMap传入的变量
　　kubectl exec -it pod-cm-1 -- /bin/sh
　　/ # printenv　　 #查看我们定义的变量有没有传递进来.
#接着我们来修改configmap中可以的值，看能否在Pod马上生效:
　　kubectl edit cm nginx-config 　　   #将nginx-config这个configmap中的值修改一下.
　　kubectl describe cm nginx-config   #确认edit已经修改了configmap中key的值.
#接着在登陆pod-cm-1 这个Pod中，查看容器中变量的值是否改变了。
#可以看到值是不会改变的，它仅会在创建Pod时，加载一次configmap中的数据.

#通过共享卷的方式来挂载configmap:
vim  pod-configmap-2.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-cm-2
  namespace: default
  labels:
    app: myapp
    tier: frontend
  annotations:
    test.com/created-by: “cluster admin”
spec:
 containers:
 - name: myapp
   image: ikubernetes/myapp:v1
   ports:
   - name: http
     containerPort: 80
   volumeMounts:
   - name: nginxconf
     mountPath: /etc/nginx/config.d/   #挂载点不存在,Pod会自动创建.
     readOnly: true       #不能让容器修改配置的内容。
volumes:
-  name: nginxconf        #定义存储卷的名字为nginxconf
   configMap:
     name: nginx-config   #要挂载nginx-config这个configMap

 #创建Pod

　kubectl apply -f pod-configmap-2.yaml
　　kubectl exec -it pod-cm-2 -- /bin/sh
　　/ # ls -l /etc/nginx/config.d/
　　　　total 0
　　　　lrwxrwxrwx 1 root root 17 Jul 21 13:48 nginx_port -> ..data/nginx_port
　　　　lrwxrwxrwx 1 root root 18 Jul 21 13:48 server_name -> ..data/server_name

注: 你将可以看到config.d下面创建了两个连接文件，它们的内容就时nginx-config这个configMap中定义的变量值，连接文件名为key的名字， 连接文件指向的文件其实是新版本的configmap文件，即当configmap文件被修改时，它就会将改变同步到API Server，APIServer在将改变通告给所有引用者，之后引用者的内容也将变成新版本的内容，这样就可以实现动态更新配置文件了。

#测试动态更新configmap的变量值
　　kubectl edit cm nginx-config 　　
　　　　 #修改nginx-config的中server_port为8888 查看Pod中的变化.
　　　　  不过要有点耐心，因为APIServer通告完成是需要时间的。
通常若非敏感数据，均可使用明文存储的configMap来做，若涉及到密码，私钥等数据时,一定要使用secret类型.

secret有三种类型：

　　1、Opaque：base64 编码格式的 Secret，用来存储密码、密钥等；但数据也可以通过base64 –decode解码得到原始数据，所有加密性很弱。

　　2、kubernetes.io/dockerconfigjson：用来存储私有docker registry的认证信息。

　　3、kubernetes.io/service-account-token：用于被serviceaccount引用，serviceaccout 创建时Kubernetes会默认创建对应的secret。Pod如果使用了serviceaccount，对应的secret会自动挂载到Pod目录/run/secrets/kubernetes.io/serviceaccount中。

#创建一个mysql-root-password的secret:

kubectl create secret generic mysql-root-password --from-literal=password=MyP@ss.8*9
　　　　注: 这就定义了一个generic类型的secret, 名字是mysql-root-password, key是password,值是MyP@ss.8*9
　　kubectl get secret
　　kubectl describe secret mysql-root-password
　　kubectl get secret mysql-root-password -o yaml 　　 #可看到password这个key的值是加密的. 

#但secret的加密是一种伪加密，它仅仅是将数据做了base64的编码.　echo  password这个Key的值  | base64 -d 　　 #-d:是解码, 这样就可以看到base64加码后的明文密码了。

#创建一个引用secret的Pod清单:
vim  pod-secret-1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-secret-1
  namespace: default
  labels:
     app: myapp
     tier: frontend
 annotations:
     test.com/created-by: “cluster admin”
spec:
  containers:
  -  name: myapp
     image: ikubernetes/myapp:v1
     ports:
     -  name: http
        containerPort:80
     env:
     -  name: MYSQL_ROOT_PASSWORD   #它是Pod启动成功后,Pod中容器的环境变量名.
        valueFrom:
          secretKeyRef:
            name: mysql-root-password  #这是secret的对象名
            key: password      #它是secret中的key名

 #创建导入secret内容的Pod:
　　kubectl apply -f pod-secret.yaml
　　kubectl exec pod-secret-1 -- printenv |grep ‘MYSQL_ROOT_PASSWORD’ 　　 #可以看到注入到容器中的secret是明文存储的.

Opaque Secret

Opaque 类型的数据是一个 map 类型，要求value是base64编码格式，比如我们来创建一个用户名为 admin，密码为 admin321 的 Secret 对象，首先我们先把这用户名和密码做 base64 编码，

$ echo -n "admin" | base64
YWRtaW4=
$ echo -n "admin321" | base64
YWRtaW4zMjE=

然后我们就可以利用上面编码过后的数据来编写一个YAML文件：(secret-demo.yaml)

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
  password: YWRtaW4zMjE=

然后同样的我们就可以使用kubectl命令来创建了：

$ kubectl create -f secret-demo.yaml
secret "mysecret" created

利用get secret命令查看：

其中default-token-cty7pdefault-token-n9w2d

使用describe命令，查看详情：

$ kubectl describe secret mysecret
Name:         mysecret
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
password:  8 bytes
username:  5 bytes

我们可以看到利用describe命令查看到的Data没有直接显示出来，如果想看到Data里面的详细信息，同样我们可以输出成YAML文件进行查看：

$ kubectl get secret mysecret -o yaml
apiVersion: v1
data:
  password: YWRtaW4zMjE=
  username: YWRtaW4=
kind: Secret
metadata:
  creationTimestamp: 2018-06-19T15:27:06Z
  name: mysecret
  namespace: default
  resourceVersion: "3694084"
  selfLink: /api/v1/namespaces/default/secrets/mysecret
  uid: 39c139f5-73d5-11e8-a101-525400db4df7
type: Opaque

创建好Secret对象后，有两种方式来使用它：

• 以环境变量的形式
• 以Volume的形式挂载

环境变量

首先我们来测试下环境变量的方式，同样的，我们来使用一个简单的busybox镜像来测试下:(secret1-pod.yaml)

apiVersion: v1
kind: Pod
metadata:
  name: secret1-pod
spec:
  containers:
  - name: secret1
    image: busybox
    command: [ "/bin/sh", "-c", "env" ]
    env:
    - name: USERNAME
      valueFrom:
        secretKeyRef:
          name: mysecret
          key: username
    - name: PASSWORD
      valueFrom:
        secretKeyRef:
          name: mysecret
          key: password

主要上面环境变量中定义的secretKeyRef关键字，和我们上节课的configMapKeyRef是不是比较类似，一个是从Secret对象中获取，一个是从ConfigMap对象中获取，创建上面的Pod：

$ kubectl create -f secret1-pod.yaml
pod "secret1-pod" created

然后我们查看Pod的日志输出：

$ kubectl logs secret1-pod
...
USERNAME=admin
PASSWORD=admin321
...

可以看到有 USERNAME 和 PASSWORD 两个环境变量输出出来。

Volume 挂载

同样的我们用一个Pod来验证下Volume挂载，创建一个Pod文件：(secret2-pod.yaml)

apiVersion: v1
kind: Pod
metadata:
  name: secret2-pod
spec:
  containers:
  - name: secret2
    image: busybox
    command: ["/bin/sh", "-c", "ls /etc/secrets"]
    volumeMounts:
    - name: secrets
      mountPath: /etc/secrets
  volumes:
  - name: secrets
    secret:
     secretName: mysecret

创建Pod:

$ kubectl create -f secret-pod2.yaml
pod "secret2-pod" created

然后我们查看输出日志：

$ kubectl logs secret2-pod
password
username

可以看到secret把两个key挂载成了两个对应的文件。当然如果想要挂载到指定的文件上面，是不是也可以使用上一节课的方法：在secretName下面添加items指定 key 和 path，这个大家可以参考上节课ConfigMap中的方法去测试下。

kubernetes.io/dockerconfigjson

除了上面的Opaque这种类型外，我们还可以来创建用户docker registry认证的Secret，直接使用kubectl create命令创建即可，如下：

$ kubectl create secret docker-registry myregistry --docker-server=DOCKER_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
secret "myregistry" created

然后查看Secret列表：

$ kubectl get secret
NAME                  TYPE                                  DATA      AGE
default-token-n9w2d   kubernetes.io/service-account-token   3         33d
myregistry            kubernetes.io/dockerconfigjson        1         15s
mysecret              Opaque                                2         34m

注意看上面的TYPE类型，myregistry是不是对应的kubernetes.io/dockerconfigjson，同样的可以使用describe命令来查看详细信息：

$ kubectl describe secret myregistry
Name:         myregistry
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  kubernetes.io/dockerconfigjson

Data
====
.dockerconfigjson:  152 bytes

同样的可以看到Data区域没有直接展示出来，如果想查看的话可以使用-o yaml来输出展示出来：

$ kubectl get secret myregistry -o yaml
apiVersion: v1
data:
  .dockerconfigjson: eyJhdXRocyI6eyJET0NLRVJfU0VSVkVSIjp7InVzZXJuYW1lIjoiRE9DS0VSX1VTRVIiLCJwYXNzd29yZCI6IkRPQ0tFUl9QQVNTV09SRCIsImVtYWlsIjoiRE9DS0VSX0VNQUlMIiwiYXV0aCI6IlJFOURTMFZTWDFWVFJWSTZSRTlEUzBWU1gxQkJVMU5YVDFKRSJ9fX0=
kind: Secret
metadata:
  creationTimestamp: 2018-06-19T16:01:05Z
  name: myregistry
  namespace: default
  resourceVersion: "3696966"
  selfLink: /api/v1/namespaces/default/secrets/myregistry
  uid: f91db707-73d9-11e8-a101-525400db4df7
type: kubernetes.io/dockerconfigjson

可以把上面的data.dockerconfigjson下面的数据做一个base64解码，看看里面的数据是怎样的呢？

$ echo eyJhdXRocyI6eyJET0NLRVJfU0VSVkVSIjp7InVzZXJuYW1lIjoiRE9DS0VSX1VTRVIiLCJwYXNzd29yZCI6IkRPQ0tFUl9QQVNTV09SRCIsImVtYWlsIjoiRE9DS0VSX0VNQUlMIiwiYXV0aCI6IlJFOURTMFZTWDFWVFJWSTZSRTlEUzBWU1gxQkJVMU5YVDFKRSJ9fX0= | base64 -d
{"auths":{"DOCKER_SERVER":{"username":"DOCKER_USER","password":"DOCKER_PASSWORD","email":"DOCKER_EMAIL","auth":"RE9DS0VSX1VTRVI6RE9DS0VSX1BBU1NXT1JE"}}}

如果我们需要拉取私有仓库中的docker镜像的话就需要使用到上面的myregistry这个Secret：

apiVersion: v1
kind: Pod
metadata:
  name: foo
spec:
  containers:
  - name: foo
    image: 192.168.1.100:5000/test:v1
  imagePullSecrets:
  - name: myregistrykey

我们需要拉取私有仓库镜像192.168.1.100:5000/test:v1，我们就需要针对该私有仓库来创建一个如上的Secret，然后在Pod的 YAML 文件中指定imagePullSecrets，我们会在后面的私有仓库搭建的课程中跟大家详细说明的。

kubernetes.io/service-account-token

另外一种Secret类型就是kubernetes.io/service-account-token，用于被serviceaccount引用。serviceaccout 创建时 Kubernetes 会默认创建对应的 secret。Pod 如果使用了 serviceaccount，对应的secret会自动挂载到Pod的/run/secrets/kubernetes.io/serviceaccount目录中。

这里我们使用一个nginx镜像来验证一下，大家想一想为什么不是呀busybox镜像来验证？当然也是可以的，但是我们就不能在command里面来验证了，因为token是需要Pod运行起来过后才会被挂载上去的，直接在command命令中去查看肯定是还没有 token 文件的。

$ kubectl run secret-pod3 --image nginx:1.7.9
deployment.apps "secret-pod3" created
$ kubectl get pods
NAME                           READY     STATUS    RESTARTS   AGE
...
secret-pod3-78c8c76db8-7zmqm   1/1       Running   0          13s
...
$ kubectl exec secret-pod3-78c8c76db8-7zmqm ls /run/secrets/kubernetes.io/serviceaccount
ca.crt
namespace
token
$ kubectl exec secret-pod3-78c8c76db8-7zmqm cat /run/secrets/kubernetes.io/serviceaccount/token
eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2U

 Secret 与 ConfigMap 对比

最后我们来对比下Secret和ConfigMap这两种资源对象的异同点：

相同点：

• key/value的形式
• 属于某个特定的namespace
• 可以导出到环境变量
• 可以通过目录/文件形式挂载
• 通过 volume 挂载的配置信息均可热更新

不同点：

• Secret 可以被 ServerAccount 关联
• Secret 可以存储 docker register 的鉴权信息，用在 ImagePullSecret 参数中，用于拉取私有仓库的镜像
• Secret 支持 Base64 加密
• Secret 分为 kubernetes.io/service-account-token、kubernetes.io/dockerconfigjson、Opaque 三种类型，而 Configmap 不区分类型