Kubernetes Leverages Volume to Mount ConfigMap with Secret

1. Overview

In Kubernetes clusters, configuration management of applications is a critical and complex task. With the expansion of applications and the popularity of microservice architectures, the traditional configuration file management approach has been difficult to meet the demand for dynamic and flexible configuration. Fortunately, Kubernetes provides powerful configuration management capabilities, of which ConfigMap and Secret combined with Volume mounting is an important means to achieve this goal.

1.1 ConfigMap

ConfigMap is an API object in Kubernetes for storing non-sensitive configuration information such as application configuration parameters, environment variables, and so on. It allows you to decouple configuration information from your application's container image, making it easier to manage and update configurations.

1.2 Secret

Similar to ConfigMap, Secret is an API object in Kubernetes, but it is used to store sensitive information such as database passwords, OAuth tokens, etc. Secret stores data via Base64 encoding, but Kubernetes automatically decodes Secret when it is mounted in a Pod to ensure data security. For a detailed explanation of Secret resources, see theKubernetes Objects - Secret" This blog post.

2, the use of Volume mounted ConfigMap and Secret

Kubernetes allows you to mount ConfigMap and Secret as a Volume in a Pod so that containers have direct access to this configuration information or sensitive data.The advantage of this approach is thatSupports dynamic updating. when ConfigMap and Secret are updated, the data in the container is also updated.

The following is an example of a nginx container image demonstrating the use of Volume to mount ConfigMap and Secret.

2.1 NoMount any storage volume

(1) A sample workload using an Nginx container image is as follows, without any type of storage volume mounted.

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) Going inside the container, you can see that there are data files in the /etc/ssl directory after starting the nginx container using the nginx container image.

2.2 Mount ConfigMap

Create a configmap for testing.

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 Mounting the entire configmap resource object inside the container

Update the nginx-v1 workload configuration file to mount the configmap resource object for testing to the nginx container /etc/ssl directory.

kind: Deployment
apiVersion: apps/v1
metadata:
  name: nginx-v1
  namespace: test-configmap-volume
  labels:
    app: nginx-v1
  annotations:
    /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

Going into the container /etc/ssl directory again results in the following.

When a ConfigMap is mounted as a volume to a specified path in a container, if the target path does not exist in the container, Kubernetes automatically creates this path when the container starts.If the target path already exists in the container, the ConfigMap overwrites the contents of the original directory by default (unless a subpath is used), and each key of the ConfigMap is created as a new file (with the same name as the key) in that directory.

2.2.2 Mounting the configmap resource object with the specified key inside the container

Update the nginx-v1 workload configuration file to mount the key specified in the configmap resource object for testing to the nginx container /etc/ssl directory. (Mount keys a and b in the container /etc/ssl path and change the filename of a to haa and the filename of b to 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
    .......

The results are as follows:

When ConfigMap mounts the specified key as a volume to the specified path in the container, if the target path does not exist in the container, Kubernetes automatically creates this path when the container starts.If the target path already exists in the container, the ConfigMap overwrites the contents of the original directory by default (unless subpaths are used), and the keys are created as a new file in the directory (with the same filename as path).

2.2.3 Mounting configmap resource objects inside the container via subpaths

Whether you mount the entire configmap resource object inside the container or mount the configmap resource object with a specified key inside the container, if the target path already exists in the container, ConfigMap will overwrite the contents of the original directory by default. Sometimes we want to overwrite the specified file in the original directory, then we need to use theSubpath, using subpath to select the specified key-value of configMap to mount in the container, will not overwrite other files in the original directory.

Update the nginx-v1 workload configuration file to overwrite the container /etc/ssl/ file with the key a specified for the configmap resource object for testing via a subpath.

.......
    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/
              subPath: a
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File
          imagePullPolicy: IfNotPresent
      .......

The results are as follows:

The specified key-value of the configMap selected by using subpath is mounted in the container without overwriting other files in the original directory.

2.3 Mount Secret

For detailed steps see theKubernetes Objects - Secret" this blog post, this article will not repeat, the use of the same way and mount ConfigMap.

3. Summary

(1) mount the entire ConfigMap/Secret resource object inside the container

When ConfigMap/Secret is mounted as a Volume to a specified path in a container, if the target path does not exist in the container, Kubernetes will automatically create it when the container starts. If the target path already exists in the container, the ConfigMap overwrites the contents of the original directory by default, and each key of the ConfigMap is created as a new file (with the same name as the key) in that directory.

(2) Mount the ConfigMap/Secret resource object with the specified key inside the container.

When ConfigMap/Secret mounts a specified key as a volume to a specified path in a container, if the target path does not exist in the container, Kubernetes automatically creates the path when the container starts. If the target path already exists in the container, ConfigMap overwrites the contents of the original directory by default, and the keys are created as a new file (with the same name as the path) in that directory.

(3) Mount the ConfigMap/Secret resource object inside the container via a sub-path

If the mount path is an existing directory, the contents under the directory will not be overwritten. Directly mounting ConfigMap/Secret in the container's path will overwrite the original files under the container's path. Using subpath to select the specified key-value of ConfigMap/Secret to be mounted in the container will not overwrite other files under the original directory.