Blog|ETJava Beta

搜索：

Kubernetes利用Volume挂载ConfigMap与Secret

发表于阅读(1) 博客类别：Crawler 转自：https://www.cnblogs.com/zhangmingcheng/p/18391460
如有侵权请联系我们删除 (页面底部联系我们)
1、概述

　　在Kubernetes集群中，应用的配置管理是一个关键且复杂的任务。随着应用的扩展和微服务架构的普及，传统的配置文件管理方式已经难以满足动态、灵活的配置需求。幸运的是，Kubernetes提供了强大的配置管理能力，其中ConfigMap和Secret结合Volume挂载的方式是实现这一目标的重要手段。

1.1 ConfigMap

　　ConfigMap是Kubernetes中的一个API对象，用于存储非敏感的配置信息，如应用的配置参数、环境变量等。它允许你将配置信息与应用的容器镜像解耦，从而更容易地管理和更新配置。

1.2 Secret

　　与ConfigMap类似，Secret也是Kubernetes中的一个API对象，但它用于存储敏感信息，如数据库密码、OAuth令牌等。Secret通过Base64编码存储数据，但Kubernetes在将Secret挂载到Pod中时会自动进行解码，以确保数据的安全性。详细Secret资源讲解请参见《Kubernetes对象——Secret 》这篇博文。

2、利用Volume挂载ConfigMap与Secret

　　Kubernetes允许你将ConfigMap和Secret作为Volume挂载到Pod中，这样容器就可以直接访问到这些配置信息或敏感数据了。这种方式的好处是，支持动态更新。ConfigMap和Secret更新后，容器中的数据也会更新。

　　下面以nginx容器镜像为例演示，利用Volume挂载ConfigMap与Secret。

2.1 不挂载任何存储卷

（1）使用Nginx容器镜像的工作负载示例如下，没有挂载任何类型存储卷。

apiVersion: apps/v1 kind: Deployment metadata: namespace: test-configmap-volume labels: app: nginx-v1 name: nginx-v1 spec: replicas: 1 selector: matchLabels: app: nginx-v1 template: metadata: labels: app: nginx-v1 spec: containers: - name: container-jzx3ih imagePullPolicy: IfNotPresent image: 'nginx' ports: - name: tcp-80 protocol: TCP containerPort: 80 serviceAccount: default affinity: {} initContainers: [] volumes: [] strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 25% maxSurge: 25%

（2）进入容器内部，可以看到使用nginx容器镜像启动nginx容器后，/etc/ssl目录下是存在数据文件的。

2.2 挂载ConfigMap

创建测试用的configmap。

apiVersion: v1 kind: ConfigMap metadata: namespace: test-configmap-volume labels: {} name: test-configmap-volume1 spec: template: metadata: labels: {} data: a: aa b: bb c: cc

2.2.1 将整个configmap资源对象挂载到容器内部

更新nginx-v1工作负载配置文件，将测试用的configmap资源对象挂载到nginx容器/etc/ssl目录下。

kind: Deployment apiVersion: apps/v1 metadata: name: nginx-v1 namespace: test-configmap-volume labels: app: nginx-v1 annotations: deployment.kubernetes.io/revision: '2' spec: replicas: 1 selector: matchLabels: app: nginx-v1 template: metadata: creationTimestamp: null labels: app: nginx-v1 spec: volumes: - name: volume-pikzy0 configMap: name: test-configmap-volume1 defaultMode: 420 containers: - name: container-jzx3ih image: 'nginx' ports: - name: tcp-80 containerPort: 80 protocol: TCP resources: {} volumeMounts: - name: volume-pikzy0 readOnly: true mountPath: /etc/ssl terminationMessagePath: /dev/termination-log terminationMessagePolicy: File imagePullPolicy: IfNotPresent restartPolicy: Always terminationGracePeriodSeconds: 30 dnsPolicy: ClusterFirst serviceAccountName: default serviceAccount: default securityContext: {} affinity: {} schedulerName: default-scheduler strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 25% maxSurge: 25% revisionHistoryLimit: 10 progressDeadlineSeconds: 600

再次进入容器/etc/ssl目录下，结果如下。

当ConfigMap以volume的形式挂载到容器中的指定路径时，如果目标路径在容器中不存在，Kubernetes会在容器启动时自动创建这个路径。如果目标路径已经存在于容器中，ConfigMap默认会会覆盖原先目录下的内容（除非使用子路径），并且ConfigMap的每个key都会被创建为该目录下的一个新文件（文件名与key相同）。

2.2.2 将configmap资源对象指定key挂载到容器内部

更新nginx-v1工作负载配置文件，将测试用的configmap资源对象指定key挂载到nginx容器/etc/ssl目录下。（将key a、b挂载到容器/etc/ssl路径下并且a的文件名改为haa，b的文件名改成hbb）

...... spec: volumes: - name: volume-pikzy0 configMap: name: test-configmap-volume1 items: - key: a path: haa - key: b path: hbb defaultMode: 420 containers: - name: container-jzx3ih image: 'nginx' ports: - name: tcp-80 containerPort: 80 protocol: TCP resources: {} volumeMounts: - name: volume-pikzy0 readOnly: true mountPath: /etc/ssl terminationMessagePath: /dev/termination-log terminationMessagePolicy: File imagePullPolicy: IfNotPresent restartPolicy: Always .......

结果如下：

当ConfigMap将指定key以volume的形式挂载到容器中的指定路径时，如果目标路径在容器中不存在，Kubernetes会在容器启动时自动创建这个路径。如果目标路径已经存在于容器中，ConfigMap默认会会覆盖原先目录下的内容（除非使用子路径），这些key都会被创建为该目录下的一个新文件（文件名与path相同）。

2.2.3 将configmap资源对象通过子路径挂载到容器内部

不管是将整个configmap资源对象挂载到容器内部，还是将configmap资源对象指定key挂载到容器内部，如果目标路径已经存在于容器中，ConfigMap默认会会覆盖原先目录下的内容。有时候我们就想覆盖原先目录下指定文件，这时候就需要使用子路径，使用subpath选定configMap的指定的key-value挂载在容器中，不会覆盖掉原目录下的其他文件。

更新nginx-v1工作负载配置文件，将测试用的configmap资源对象指定key a通过子路径覆盖容器/etc/ssl/openssl.cnf文件。

....... spec: volumes: - name: volume-pikzy0 configMap: name: test-configmap-volume1 defaultMode: 420 containers: - name: container-jzx3ih image: 'nginx' ports: - name: tcp-80 containerPort: 80 protocol: TCP resources: {} volumeMounts: - name: volume-pikzy0 readOnly: true mountPath: /etc/ssl/openssl.cnf subPath: a terminationMessagePath: /dev/termination-log terminationMessagePolicy: File imagePullPolicy: IfNotPresent .......

结果如下：

通过使用subpath选定configMap的指定的key-value挂载在容器中，不会覆盖掉原目录下的其他文件。

2.3 挂载Secret

详细步骤参见《Kubernetes对象——Secret 》这篇博文，本文不再赘余，使用方式和挂载ConfigMap一致。

3、总结

　　Kubernetes允许你将ConfigMap和Secret作为Volume挂载到Pod中，这样容器就可以直接访问到这些配置信息或敏感数据了。这种方式的好处是，支持动态更新。ConfigMap和Secret更新后，容器中的数据也会更新。

（1）将整个ConfigMap/Secret资源对象挂载到容器内部

　　当ConfigMap/Secret以Volume的形式挂载到容器中的指定路径时，如果目标路径在容器中不存在，Kubernetes会在容器启动时自动创建这个路径。如果目标路径已经存在于容器中，ConfigMap默认会会覆盖原先目录下的内容，并且ConfigMap的每个key都会被创建为该目录下的一个新文件（文件名与key相同）。

（2）将ConfigMap/Secret资源对象指定key挂载到容器内部

　　当ConfigMap/Secret将指定key以Volume的形式挂载到容器中的指定路径时，如果目标路径在容器中不存在，Kubernetes会在容器启动时自动创建这个路径。如果目标路径已经存在于容器中，ConfigMap默认会会覆盖原先目录下的内容，这些key都会被创建为该目录下的一个新文件（文件名与path相同）。

（3）将ConfigMap/Secret资源对象通过子路径挂载到容器内部

　　如果挂载路径是一个已存在的目录，则目录下的内容不会被覆盖。直接将ConfigMap/Secret挂载在容器的路径，会覆盖掉容器路径下原有的文件，使用subpath选定ConfigMap/Secret的指定的key-value挂载在容器中，则不会覆盖掉原目录下的其他文件。