Configmap and Secret in Kubernetes

The test environment of this article is CentOS 7.3, Kubernetes cluster is 1.11.2, see kubeadm installation Kubernetes V1.11.1 cluster

In order to facilitate everyone to learn Kubernetes system, I organized a Kubernetes learning series of articles, covering the basic knowledge of Kubernetes, installation steps and the related content of the whole Kubernetes system, I believe we read this series, To have a deeper understanding of Kubernetes.

Application Scenarios: Kubernetes provides Configmap to provide configuration files or environment variables to the container to implement different configurations. This decouples the image configuration from the image itself, making the container application independent of the environment configuration.

Pass parameters to the container

Docker	Kubernetes	describe
ENTRYPOINT	command	An executable file in a container
CMD	args	Parameters that need to be passed to the executable

If you need to pass parameters to the container, you can do so in a Yaml file, either through command and args or environment variables.

kind: Pod
spec:
  containers:
  - image: docker.io/nginx
    command: ["/bin/command"]
    args: ["arg1"."arg2"."arg3"]
    env:
    - name: INTERVAL
      value: "30"
    - name: FIRST_VAR
      value: "foo"
    - name: SECOND_VAR
      value: "$(FIRST_VAR)bar"
Copy the code

As you can see, we can use the env tag to pass environment variables into the container and reference each other. The problem with this approach is that the configuration file is bound to the deployment. Therefore, for the same application, the parameters of the test environment and the production environment are different. This requires two deployment files, which is not very convenient to manage.

What is a ConfigMap

In the preceding example, ConfigMap can be used to decouple deployment and configuration. For the same application deployment file, you can use the valueFrom field to reference a ConfigMap that exists in both the test and production environments (the configuration content is different, but the name is the same). You can reduce the complexity of environment management and deployment.

ConfigMap can be used in three ways:

Generates environment variables in the container
Sets the parameters of the container start command
Mount as a file or directory inside the container

The disadvantage of ConfigMap

ConfigMap must be created before Pod
ConfigMap belongs to a NameSpace and can only be applied to pods in the same NameSpace
Quota management in ConfigMap is not implemented
If a volume is mounted to a container, the volume can only be mounted to a certain directory, and the original files in the directory will be overwritten
Static pods cannot use ConfigMap

The creation of ConfigMap

$ kubectl create configmap <map-name> --from-literal=<parameter-name>=<parameter-value>
$ kubectl create configmap <map-name> --from-literal=<parameter1>=<parameter1-value> --from-literal=<parameter2>=<parameter2-value> --from-literal=<parameter3>=<parameter3-value>
$ kubectl create configmap <map-name> --from-file=<file-path>
$ kubectl apply -f <configmap-file.yaml>
You can also create configMap from a folder
$ kubectl create configmap <map-name> --from-file=/path/to/dir
Copy the code

Declaration of Yaml

apiVersion: v1
data:
  my-nginx-config.conf: |
    server {
      listen              80;
      server_name         www.kubia-example.com;

      gzip on;
      gzip_types text/plain application/xml;

	  location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;}}sleep-interval: |
    25
kind: ConfigMap		
Copy the code

ConfigMap calls

Environment variables

apiVersion: v1
kind: Pod
metadata:
  name: env-configmap
spec:
  containers:
  - image: nginx
    env:
    - name: INTERVAL
      valueFrom:
        configMapKeyRef:
          name: <map-name>
          key: sleep-interval
Copy the code

If a nonexistent ConfigMap is referenced, an error will be reported when the Pod is created until the ConfigMap can be read properly.

Pass all environment variables at once

spec:
  containers:
  - image: nginx
    envFrom:
    - prefix: CONFIG_
      configMapRef:
        name: <map-name>
Copy the code

Command line argument

apiVersion: v1
kind: Pod
metadata:
  name: env-configmap
spec:
  containers:
  - image: nginx
    env:
    - name: INTERVAL
      valueFrom:
        configMapKeyRef:
          name: <map-name>
          key: sleep-interval
    args: ["$(INTERVAL)"]
Copy the code

As a configuration file

apiVersion: v1
kind: Pod
metadata:
  name: nginx-test
spec:
  containers:
  - image: nginx
    name: web-server
    volumeMounts:
    - name: config
      mountPath: /etc/nginx/conf.d
      readOnly: true
  volumes:
  - name: config
    configMap:
      name: <map-name>
Copy the code

When Configmap is mounted as a folder, the contents of the folder in the image are invisible. How does this work? This is because the contents of the original folder cannot be accessed and therefore cannot be displayed. To prevent this mode from affecting application running, you can mount the ConfigMap as a configuration file.

spec:
  containers:
  - image: nginx
    volumeMounts:
    - name: config
      mountPath: /etc/someconfig.conf
      subPath: myconfig.conf
Copy the code

The renewal of the Configmap

$ kubectl edit configmap <map-name>
Copy the code

After confGiMap is updated, if the confGiMap is mounted as a folder, the mounted Volume is automatically updated. If it is mounted as a file, it will not be updated automatically. But for most applications, the easiest way to restart the Pod (kill it and pull it up again) after the configuration file is updated. If the configuration file is mounted as a folder, you can restart the application in the container to make the configuration file update take effect. Even if you restart the application in the container, note that the configMap update is not synchronized with the update of the mounted file in the container and there may be a delay. Therefore, make sure that the configuration in the container has been updated to the latest version before reloading the application.

What is the Secret

Secret is similar to ConfigMap, but is used to store sensitive information. On the Master node, secret is stored in unencrypted form (meaning we have to manage the Master very tightly). Since Kubernets 1.7, ETCD stores Secret in encrypted form. Secret is limited to 1MB in size. When Secret is mounted to a Pod, it is mounted as TMPFS, meaning that the content is kept in the node’s memory rather than written to disk to ensure that the information is secure.

Kubernetes helps keep your Secrets safe by making sure each Secret is only distributed to the nodes that run the pods that need access to the Secret. Also, on the nodes themselves, Secrets are always stored in memory and never written to physical storage, which would require wiping the disks after deleting the Secrets from them.

Every Kubernetes cluster has a default secrets

The creation and invocation process is much the same as configMap, which I won’t go into here.

The resources

Kubernetes Pod in-depth understanding and practice
Configmap