kubernetes / Best practice to inject values to con

Question

I'm new at kubernetes, and Im wondering the best way to inject values to ConfigMap.

for now, I defined Deployment object which takes the relevant values from ConfigMap file. I wish to use the same .yml file for my production and staging environments. so only the values in the configMap will be changed, while the file itself will be the same.

Is there any way to do it built-in in kubernetes, without using configuration management tools (like Ansible, puppet, etc.)?

Answer 1

You also create configmap

kubectl create configmap special-config \
    --from-env-file=configure-pod-container/configmap/kubectl/game-env-file.properties

and access it in the container

apiVersion: v1
kind: Pod
metadata:
   name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: k8s.gcr.io/busybox
      command: [ "/bin/sh", "-c", "env" ]
      envFrom:
      - configMapRef:
          name: special-config
  restartPolicy: Never

Answer 2

You can find the links to the quoted text in the end of the answer.

A good practice when writing applications is to separate application code from configuration. We want to enable application authors to easily employ this pattern within Kubernetes. While the Secrets API allows separating information like credentials and keys from an application, no object existed in the past for ordinary, non-secret configuration. In Kubernetes 1.2, we’ve added a new API resource called ConfigMap to handle this type of configuration data.

Besides, Secrets data will be stored in a base64 encoded form, which is also suitable for binary data such as keys, whereas ConfigMaps data will be stored in plain text format, which is fine for text files.

The ConfigMap API is simple conceptually. From a data perspective, the ConfigMap type is just a set of key-value pairs.

There are several ways you can create config maps:

• Using list of values in the command line

  $ kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm
  

• Using a file on the disk as a source of data

  $ kubectl create configmap game-config-2 --from-file=docs/user-guide/configmap/kubectl/game.properties --from-file=docs/user-guide/configmap/kubectl/ui.properties
  $ kubectl create configmap game-config-3 --from-file=game-special-key=docs/user-guide/configmap/kubectl/game.properties
  

• Using directory with files as a source of data

  $ kubectl create configmap game-config --from-file=configure-pod-container/configmap/kubectl/
  

• Combining all three previously mentioned methods

There are several ways to consume a ConfigMap data in Pods

• Use values in ConfigMap as environment variables

  spec:
    containers:
      - name: test-container
        image: k8s.gcr.io/busybox
        command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY)" ]
        env:
          - name: SPECIAL_LEVEL_KEY
            valueFrom:
              configMapKeyRef:
                name: special-config
                key: SPECIAL_LEVEL
  

• Use data in ConfigMap as files on the volume

  spec:
    containers:
      - name: test-container
        image: k8s.gcr.io/busybox
        command: [ "/bin/sh", "-c", "ls /etc/config/" ]
        volumeMounts:
        - name: config-volume
          mountPath: /etc/config
    volumes:
      - name: config-volume
        configMap:
          # ConfigMap containing the files
          name: special-config
  

Only changes in ConfigMaps that are consumed in a volume will be visible inside the running pod. Kubelet is checking whether the mounted ConfigMap is fresh on every periodic sync. However, it is using its local ttl-based cache for getting the current value of the ConfigMap. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod can be as long as kubelet sync period + ttl of ConfigMaps cache in kubelet.

Pod that contains in specification any references to non-existent ConfigMap or Secrets won't start.

Consider to read official documentation and other good articles for even more details:

• Configuration management with Containers
• Configure a Pod to Use a ConfigMap
• Using ConfigMap
• Kubernetes ConfigMaps and Secrets
• Managing Pod configuration using ConfigMaps and Secrets in Kubernetes

Answer 3

If you're thinking of ansible then I suspect you'll want to look at helm for this. I don't think it is a concern that kubernetes itself would address but helm is a kubernetes project.

If I understand correctly you've got a configmap yaml file and you want to deploy it with one set of values for staging and one for production.

A natural way to do this would be to keep two copies of the file with '-staging' and '-prod' appended on the name and have your CI choose the one for the environment it is deploying to. Or you could have a shell script in your CI that does a sed/replace on the particular values you want to switch for the environment.

Using helm you could pass in command-line parameters at deploy time or via a parameter-file (the values.yaml).