一、ConfigMap

应用部署的一个最佳实践是将应用所需的配置信息与程序进行分离，这样可以使得应用程序被更好地复用，通过不同的配置也能实现更灵活的功能。
将应用打包为容器镜像后，可以通过环境变量或者外挂文件的方式在创建容器时进行配置注入，但在大规模容器集群的环境中，对多个容器进行不同的配置将变得非常复杂。
从Kubernetes v1.2开始提供了一种统一的应用配置管理方案——ConfigMap。

创建ConfigMap后，数据实际会存储在K8s中Etcd，然后通过创建Pod时引用该数据。

应用场景：应用程序配置

Pod使用configmap数据有两种方式：

• 变量注入，通过环境变量获取ConfigMap

• 数据卷挂载，通过Volume挂载的方式将ConfigMap中的内容挂载为容器内部的文件或目录

创建configMap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  abc: "123"
  cde: "456"

  redis.properties: |
    port: 6379
    host: 192.168.2.117

查看创建的configMap

创建configMap-deploy.yaml

apiVersion: v1
kind: Pod
metadata:
  name: app-config-demo
spec:
  containers:
    - name: demo 
      image: nginx 
      env:
        - name: ABCD 
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: abc
        - name: CDEF
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: cde
      volumeMounts:
      - name: config             
        mountPath: "/config"  # 配置文件挂载在容器中的位置
        readOnly: true
  volumes:            # 数据卷挂载
    - name: config 
      configMap:
        name: app-config
        items:
        - key: "redis.properties"
          path: "redis.properties"

验证变量注入成功，redis.properties 配置文件也挂载到了 /config 路径下。

ConfigMap 注意要点

现在对 ConfigMap 的使用做一个总结，以及它的一些注意点，注意点一共列了以下五条：

第一点 ConfigMap 文件的大小。虽然说 ConfigMap 文件没有大小限制，但是在 ETCD 里面，数据的写入是有大小限制的，现在是限制在 1MB 以内；
第二点注意点是 pod 引入 ConfigMap 的时候，必须是相同的 Namespace 中的 ConfigMap，前面其实可以看到，ConfigMap.metadata 里面是有 namespace 字段的；
第三点是 pod 引用的 ConfigMap。假如这个 ConfigMap 不存在，那么这个 pod 是无法创建成功的，其实这也表示在创建 pod 前，必须先把要引用的 ConfigMap 创建好；
第四点就是使用 envFrom 的方式。把 ConfigMap 里面所有的信息导入成环境变量时，如果 ConfigMap 里有些 key 是无效的，比如 key 的名字里面带有数字，那么这个环境变量其实是不会注入容器的，它会被忽略。但是这个 pod 本身是可以创建的。这个和第三点是不一样的方式，是 ConfigMap 文件存在基础上，整体导入成环境变量的一种形式；
最后一点是：什么样的 pod 才能使用 ConfigMap？这里只有通过 K8s api 创建的 pod 才能使用 ConfigMap，比如说通过用命令行 kubectl 来创建的 pod，肯定是可以使用 ConfigMap 的，但其他方式创建的 pod，比如说 kubelet 通过 manifest 创建的 static pod，它是不能使用 ConfigMap 的。

二、Secret

k8s secrets用于存储和管理一些敏感数据，比如密码，token，密钥等敏感信息。它把 Pod 想要访问的加密数据存放到 Etcd 中。然后用户就可以通过在 Pod 的容器里挂载 Volume 的方式或者环境变量的方式访问到这些 Secret 里保存的信息了。与ConfigMap类似，区别在于Secret主要存储敏感数据，所有的数据要经过base64编码。

应用场景： 凭据

kubectl create secret 支持三种数据类型：

• docker-registry (kubernetes.io/dockerconfigjson)：存储镜像仓库认证信息

• generic (Opaque)：存储密码、密钥等

• tls (kubernetes.io/tls)：存储TLS证书

我们可以在 linux 命令换行执行如下的命令进行加密：

echo -n 'admin' | base64
echo -n '1f2d1e2e67df' | base64

创建secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: db-user-pass
type: Opaque
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm

创建 secret-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: secret-demo-pod
spec:
  containers:
  - name: demo 
    image: nginx 
    env:
      - name: USER 
        valueFrom:
          secretKeyRef:
            name: db-user-pass
            key: username
      - name: PASS
        valueFrom:
          secretKeyRef:
            name: db-user-pass
            key: password
    volumeMounts:
    - name: config
      mountPath: "/config"
      readOnly: true
  volumes:
    - name: config 
      secret:
        secretName: db-user-pass
        items:
        - key: username
          path: my-username

成功读取到用户名和密码

Secret 使用的一些注意点，下面列了三点：

第一点 Secret 的文件大小限制。这个跟 ConfigMap 一样，也是 1MB；
第二点是 Secret 采用了 base-64 编码，但是它跟明文也没有太大区别。所以说，如果有一些机密信息要用 Secret 来存储的话，还是要很慎重考虑。也就是说谁会来访问你这个集群，谁会来用你这个 Secret，还是要慎重考虑，因为它如果能够访问这个集群，就能拿到这个 Secret；
第三点就是 Secret 读取的最佳实践，建议不要用 list/watch，如果用 list/watch 操作的话，会把 namespace 下的所有 Secret 全部拉取下来，这样其实暴露了更多的信息。推荐使用 GET 的方法，这样只获取你自己需要的那个 Secret。