Pod挂载(ConfigMap,Downward API,Server Account)

到目前为止，Kubernetes 支持的 Projected Volume 一共有四种：
1.Secret(存放数据库的 Credential 信息)
2.ConfigMap(ConfigMap 保存的是不需要加密的,应用所需的配置信息)
3.Downward API(让 Pod 里的容器能够直接获取到这个 Pod API 对象本身的信息)
4.Server Account(定义授权信息，特殊的Secret)

ConfigMap

与 Secret 类似的是 ConfigMap，它与 Secret 的区别在于，ConfigMap 保存的是不需要加密的、应用所需的配置信息。而 ConfigMap 的用法几乎与 Secret 完全相同：你可以使用 kubectl createconfigmap 从文件或者目录创建 ConfigMap，也可以直接ConfigMap 对象的 YAML

--from-file=map-key=./file.name

动态更新

   更新etcd
Pod（格式） 用
volumeMount:
  - name: conf-name
    mountPath: /挂载在容器的目录/容器中的具体文件名


volumes:
  - name: conf-name
    configMap:
         - name: cfmap-name
           items:
           - key: 创建ocnfigmap 对象时指定的key
             path: 容器中的具体文件名

静态不更新

volumeMount:
  - name: conf-name
    mountPath: /挂载在容器的目录/容器中的具体文件名
    subPath:容器中的具体文件名

volumes:
  - name: conf-name
    configMap:
         - name: cfmap-name
           items:
           - key: 创建ocnfigmap 对象时指定的key
             path: 容器中的具体文件名

Downward API

让 Pod 里的容器能够直接获取到这个 Pod API 对象本身的信息,Downward API 能够获取到的信息，一定是 Pod 里的容器进程启动之前就能够确定下来的信息。
dapi.yaml

apiVersion: v1
kind: Pod
metadata:
  name: test-downwardapi-volume
  labels:
    zone: us-est-coast
    cluster: test-cluster1
    rack: rack-22
spec:
  containers:
    - name: client-container
      image: busybox
      command: ["sh", "-c"]
      args:
      - while true;
        do
          if [[ -e /etc/podinfo/labels ]]; then
            echo -en '\n\n'; cat /etc/podinfo/labels;
            echo -en '\n'; cat /etc/podinfo/name; 
          fi;
          sleep 5;
        done;
      volumeMounts:
        - name: podinfo
          mountPath: /etc/podinfo
          readOnly: false
  volumes:
    - name: podinfo
      projected:
        sources:
        - downwardAPI:
            items:
              - path: "labels"
                fieldRef:
                  fieldPath: metadata.labels
              - path: "name"
                fieldRef:
                  fieldPath: metadata.name

查看容器内的信息

kubectl logs -f test-downwardapi-volume

cluster="test-cluster1"
rack="rack-22"
zone="us-est-coas

其实，Secret、ConfigMap，以及 Downward API 这三种 Projected Volume 定义的信息，大多还可以通过环境变量的方式出现在容器里。但是，通过环境变量获取这些信息的方式，不具备自动更新的能力。所以，一般情况下，我都建议你使用 Volume 文件的方式获取这些信息

Service Account

Service Account 对象的作用，就是 Kubernetes 系统内置的一种“服务账户”，它是 Kubernetes进行权限分配的对象。比如，Service Account A，可以只被允许Kubernetes API 进行 GET 操作，而 Service Account B，则可以有 Kubernetes API 的所有操作的权限。像这样的 Service Account 的授权信息和文件，实际上保存在它所绑定的一个特殊的 Secret 对象里的。这个特殊的 Secret 对象，就叫作ServiceAccountToken。
任何运行在 Kubernetes 集群上的应用，都必须使用这个 ServiceAccountToken 里保存的授权信息，也就是 Token，才可以合法地访问 API Server。
所以说，Kubernetes 项目的 Projected Volume 其实只有三种，因为第四种 ServiceAccountToken，只是一种特殊的 Secret ，另外，为了方便使用，Kubernetes 已经为你提供了一个的默认“服务账户”（default ServiceAccount）。并且，任何一个运行在 Kubernetes 里的 Pod，都可以直接使用这个默认的 ServiceAccount，而无需显示地声明挂载它

我们设置一个my.cnf文件，挂载到容器里面去

echo "user=mysql " >> my.cnf
echo "passwd=123456" >>my.cnf

创建 configmap 对象和key(命令行创建)

kubectl  create  configmap mysql-cnf   --from-file=my-cnf=./my.cnf

2 从 yaml 文件创建

# ./kustomization.yaml
configMapGenerator:
- name:  mysql-cnf
  files:
  - my-cnf=./my.cnf

kubectl apply -f ./kustomization.yaml

mysql-test.yml

apiVersion: v1
kind: Pod
metadata:
  name: test-configmap
spec:
  containers:
  - name: test-configmap-volume
    image: busybox
    args:
    - sleep
    - "86400"
    volumeMounts:
    - name: mysqlcfmap
      mountPath: "/etc/my.cnf"     # 挂载到容器中目录，这个目录会自动创建
      subPath: my.cnf                #如果容器目录中有此文件，则覆盖，没有此文件，删除其他的，创建此文件
  volumes:
  - name: mysqlcfmap
    configMap:
       name:   mysql-cnf   # 创建 configmap 对象的名称
       items:
       - key: my-cnf          #创建  configmap 对象时指定的 key
         path: my.cnf              # 容器 /etc/my.cnf 目录中的文件名

启动进入容器查看

kubectl create -f mysql-test.yml 
kubectl exec -it test-configmap -c test-configmap-volume sh
ls /etc /my.cnf