Kubernetes ConfigMap vs Secret

scene comparison

• Secret: Use Secret when you want to store some sensitive data, such as (passwords, OAuth tokens, ssh keys, credentials, etc.)
• ConfigMap : ConfigMap can be used when you need to store some non-sensitive configuration data, such as the application's ini, json and other configuration files.

ConfigMap：

Create ConfigMap

kind: ConfigMap
apiVersion: v1
metadata:
  name: example-config
  namespace: default
data:
  example.property.1: hello        #key-value形式，key规则必须满足dns域名规则。value为字符串。
  example.property.2: world
  example.property.file: |-        #配置文件使用方式，直接把文件内容放入value即可
    property.1=value-1
    property.2=value-2
    property.3=value-3

How to use:

1. Fill in the environment variables

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "env" ]
      env:
        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: example-config     #需要使用的ConfigMap名称，必须已经存在
              key: example.property.1  #对应ConfigMap data 的key
  restartPolicy: Never

set result

SPECIAL_LEVEL_KEY=hello

2. Set the container startup command line parameters

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ]
      env:
        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: example-config
              key: example.property.1
        - name: SPECIAL_TYPE_KEY
          valueFrom:
            configMapKeyRef:
              name: example-config
              key: example.property.2
  restartPolicy: Never

operation result:

hello world

3. Mount the ConfigMap to the file

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh","-c","ls -l /etc/config/path/" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: example-config
        items:
        - key: example.property.1
          path: path/one/example.property.1
        - key: example.property.2
          path: path/two/example.property.2
        - key: example.property.file
          path: path/file/example.property.file
  restartPolicy: Never

The files created are as follows:

└── path
    ├── file
    │   └── example.property.file
    ├── one
    │   └── example.property.1
    └── two
        └── example.property.2
        
#cat example.property.1          hello
#cat example.property.2          world
#cat example.property.file  
    property.1=value-1
    property.2=value-2
    property.3=value-3    

Notice:

• ConfigMap must be created before use. If a non-existing configMap is referenced, the Pod will fail to start
• ConfigMap can only be used by applications within the same namespace.

3.1 Mount ConfigMap to a single file:

Suppose my project structure is as follows (project path is /usr/local):

.
├── Dockerfile
├── Makefile
├── app.conf
├── controllers
│   └── pod.go
└── main.go

I just want to mount the app.conf file from the ConfigMap, the other files remain unchanged, what should I do now? OK, here we go.

Suppose my ConfigMap is as follows:

apiVersion: v1
kind: ConfigMap
metadata:
  name: test-cfgmap
data:
  app.conf: file data

• The first way:

A ConfigMap can be used using the following definition file:

apiVersion: v1
kind: Pod
metadata:
  name: test-pd-plus-cfgmap
spec:
  containers:
  - image: ubuntu
    name: bash
    volumeMounts:
    - mountPath: /usr/local/app.conf
      name: cfgmap
      subPath: app.conf
  volumes:
  - name: cfgmap
    configMap:
      name: test-cfgmap

Note that when using ConfigMap in this way, the key, volumeMounts.mountPath and volumeMounts.subPath names of ConfigMap must be consistent, otherwise the mount will fail.

• The second way:

apiVersion: v1
kind: Pod
metadata:
  name: test-pd-plus-cfgmap
spec:
  containers:
  - image: ubuntu
    name: bash
    volumeMounts:
    - mountPath: /usr/local/app.conf
      name: cfgmap
      subPath: app.conf
  volumes:
  - name: cfgmap
    configMap:
      name: test-cfgmap
      items:
      - key: app.conf
        path: app.conf

Note that when using ConfigMap in this way, it is no longer required that the key of ConfigMap must be the same as the mounted file name, but the corresponding relationship between key and path needs to be specified in items.

• Other ways:

Of course, if you want, you can also mount the ConfigMap to a different path , and then link to the files you need through a soft link.

Actual usage example (Redis configuration):

For example, when we need to start Redis with the following configuration

maxmemory 2mb
maxmemory-policy allkeys-lru

First, let's create a ConfigMap:

apiVersion: v1
data:
  redis-config: |
    maxmemory 2mb
    maxmemory-policy allkeys-lru
kind: ConfigMap
metadata:
  name: example-redis-config
  namespace: default

Let's create a Pod to use it:

apiVersion: v1
kind: Pod
metadata:
  name: redis
spec:
  containers:
  - name: redis
    image: kubernetes/redis:v1
    env:
    - name: MASTER
      value: "true"
    ports:
    - containerPort: 6379
    volumeMounts:
    - mountPath: /redis-master
      name: config
  volumes:
    - name: config
      configMap:
        name: example-redis-config
        items:
        - key: redis-config
          path: redis.conf     #指定生成的配置文件名称

After we have created the Pod, enter it: The generated configuration file is as follows:

redis-master
`-- redis.conf -> ..data/redis.conf

We found that a file redis.conf was generated in the redis-master directory, corresponding to the file name defined by our path above. Output the content of redis.conf:

maxmemory 2mb
maxmemory-policy allkeys-lru

Let's take a look at the configuration of redis:

$ kubectl exec -it redis redis-cli
127.0.0.1:6379> CONFIG GET maxmemory
1) "maxmemory"
2) "2097152"
127.0.0.1:6379> CONFIG GET maxmemory-policy
1) "maxmemory-policy"
2) "allkeys-lru"

In line with our expectations.

Note: Although using configMap can easily put our configuration file into the container, we must pay attention to the size of the configuration file, (try to control it within 1M) and do not abuse ConfigMap, otherwise it may cause greater pressure on apiserver and etcd , which affects the entire cluster.

Secret:

When you need to use some sensitive configuration, such as passwords, certificates and other information, it is recommended to use Secret.

Create Secret

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

Note: The value of Secret must go through base64. The above plaintext is: username: admin password: 1f2d1e2e67df , you can directly use echo -n "1f2d1e2e67df" | base64 to perform base64, or you can perform base64 encryption and decryption here

How to use:

1. Mount to file

apiVersion: v1
kind: Pod
metadata:
  name: mypod
  namespace: default
spec:
  containers:
  - image: redis
    name: mypod
    volumeMounts:
    - mountPath: /etc/foo
      name: foo
      readOnly: true
  volumes:
  - name: foo
    secret:
      defaultMode: 420      #0644默认文件权限，由于json文件不支持八进制，使用json时应使用十进制
      secretName: mysecret

Running result: Two files username and password are generated in the /etc/foo/ directory

foo/
|-- password -> ..data/password
`-- username -> ..data/username
#cat username       admin
#cat password      1f2d1e2e67df

Note: Automatic update: When Secrets are updated, the mounted pods will not be updated immediately, but wait for the kubelete check cycle, kubelet will periodically check for secret changes and update it.

2. Use through environment variables

apiVersion: v1
kind: Pod
metadata:
  name: secret-env-pod
spec:
  containers:
    - name: mycontainer
      image: redis
      env:
        - name: SECRET_USERNAME
          valueFrom:
            secretKeyRef:
              name: mysecret   #指定secret名称
              key: username    #要使用的key
        - name: SECRET_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: password

$ echo $SECRET_USERNAME
admin
$ echo $SECRET_PASSWORD
1f2d1e2e67df

3. Pull the image

apiVersion: v1
kind: Secret
metadata:
  name: image-test-secret
  namespace: default
type: kubernetes.io/dockerconfigjson
data:
  .dockerconfigjson: ew0KCSJhdXRocyI6IHsNCgkJImltYWdlLXRlc3QiOiB7DQoJCQkiYXV0aCI6ICJjbTl2ZERweWIyOTAiLA0KCQkJImVtYWlsIjogIiINCgkJfQ0KCX0NCn0=

The plaintext of the encrypted part is:

{
	"auths": {
		"image-test": {
			"auth": "cm9vdDpyb290",   #  密文为"root:rootbase64"的结果
			"email": ""
		}
	}
}

The deployment file is used as follows:

apiVersion: v1
kind: Pod
metadata:
  name: foo
  namespace: default
spec:
  containers:
    - name: foo
      image: janedoe/awesomeapp:v1
  imagePullSecrets:
    - name: image-test-secret

Actual usage example (mounting certificate file):

kind: Secret
apiVersion: v1
metadata:
  name: client-certs
  namespace: default
data:
  ca.pem: *** #实际使用请替换成经过base64加密后的内容
  kubernetes.pem: ***
  kubernetes-key.pem: ***

Deploy with deployment:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: redis
spec:
  replicas: 1
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
      - name: redis
        image: redis
        ports:
          - containerPort: 8080
        volumeMounts:
        - mountPath: /etc/kubernetes/certs
          name: my-certs
      volumes:
        - name: my-certs
          secret:
            secretName: client-certs
            items:
            - key: ca.pem
              path: ca.pem
            - key: kubernetes.pem
              path: kubernetes.pem
            - key: kubernetes-key.pem
              path: kubernetes-key.pem
      imagePullSecrets:
        - name: image-test-secret

{{o.name}}

{{m.name}}