kubernetes ConfigMap and Secret: configure the application

7.1 Configuration of the container application

7.2. Passing command line parameters to the vessel

7.2.1. Docker commands and parameters to be defined

1. Understand ENTRYPOINT and CMD

　　ENTRYPOINT definition can execute the program is called when the container starts

　　CMD designated parameter passed to ENTRYP

dockerfile follows

FROM daocloud.io/centos:latest

ADD aaa /usr/local/aaa

CMD ["-f","/var/log/aa.log"]
ENTRYPOINT ["tail"]

When the boot image, run the following command to start the container: tail -f /var/log/aa.log

Or <arguments> specify the docker run <images>, arguments CMD content overwrites

7.2.2 covering the command line parameters and the kubernetes

When defining the container, and CMD ENTRYPOINT mirror can be covered k8s, the only familiar with the command and set values vessel args definition

The corresponding parameters are as follows:

Docker	kubernetes	description
ENTRYPOINT	command	Container run the executable file
CMD	args	Parameters passed to the executable file

Related yml code is as follows:

kind: pod
spec:
  containers:
  - image: some/image
    command: ["/bin/command"]
    args: ["args1","args2","args3"]

7.3. Set the environment variable container

7.3.1. Specify environment variables in the definition of container

The same set of commands and parameters of the container, can not create a list of environment variables that were modified in the pod.

The container is provided in the environment variables following code file yml pod of:

kind: pod
spec:
  containers:
  - image: luksa/fortune:env
    env:
    - name: INTERVAL
      value: "30"
    name: value-test-yh

7.3.2. References to other environment variables in the environment variable value

Use $ (VAR) reference environment variables,

Related ym code is as follows:

env: 
- name: FIRST_VAR 
  value: "foo" 
- name: SECOND_VAR 
  value: "$ (FIRST_VAR) bar" The final variable is foobar //

7.4. ConfigMap decoupling configuration using

7.4.1.ConfigMap Introduction

kubernetes allows separate configuration to a separate resource objects ConfigMap option, in essence, is a key / value pairs mapping, variable values can be a short literal, it can be a complete configuration file.

Applications need not be read directly ConfigMap, do not even need to know whether it exists.

Content mapping the environment variable transmitted in the form of a file or volume to the container, rather than transmitted directly to the container, the command line parameters defined by $ is (ENV_VAR) variable Syntax

7.4.2. Creating ConfigMap

Creating Intermediate ConfigMap not add -f use kubectl creat configmap.

1. instructions used to create ConfigMap

#kubectl creat configmap configmap-yaohong --from-literal=foo=bar --from-literal=sleep-interval=25

2. Create ConfigMap entries from the contents of the file

#kubectl create configmap my-conf-yh --from-file=config-file.conf

Use the command, the custom entry is stored in the file content. With the same literal

#kubectl create configmap my-conf-yh --from-file=customkey=config-file.conf

3. Create a folder from ConfigMap

#kubectl create configmap my-conf-yh --from-file=/path/to/dir

4. Merge different options

#kubectl create configmap my-conf-yh 
  --from-file=/path/to/dir/
  --from-file=bar=foobar.conf
  --from-literal=some=thing

5. Obtain ConfigMap

#kubectl -n <namespace> get configmap

7.4.3. ConfigMap passed to container entry as environment variables

Parameter values referenced environment variable to the current variable

apiVersion: v1 
kind: POD 
the Metadata: 
  name: Fortune-env-from-ConfigMap 
spec: 
  Containers: 
  - Image: Luksa / Fortune: env 
    env: 
    - name: INTERVAL // set the environment variable 
      the valueFrom: 
        configMapkeyRef: 
          name: Fortune-ConfigMap      
          Key : sleep-interval // value of the variable from the fortune-configmap slee-interval corresponding to the value of

7.4.4. A one-time transfer of all entries ConfigMap as environment variables

apiVersion: v1 
kind: POD 
the Metadata: 
  name: Fortune-env-from-ConfigMap 
spec: 
  Containers: 
  - Image: Luksa / Fortune: env 
    envFrom: 
    - prefix: CONFIG_ 
      confgMapRef: 
        name: My-confg-references the Map // my-config -map of ConfigMap and in front of the variables plus CONFIG_

7.4.5 Using ConfigMap volumes will be exposed as a file entry

apiVersion: v1 
kind: POD 
the Metadata: 
  name: ConfigMap YH-Volume- 
spec: 
  Containers: 
  - Image: nginx: Aplin 
    name: Web-Server 
    volumeMounts: 
    ... 
    - name: config 
      the DefaultMode: "6600" // set file permissions is-RW RW 
      MountPath: /etc/nginx/con.conf 
      subPath: // subPath my.conf field may be used to mount the volume in a separate file or folder, and does not cover the other files in the volume 
    ... 
  volume: 
  ... 
  - name: config 
    configMap: 
      name: Fortune-config // references fortune-config configMap volume, and then mount /etc/nginx/conf.d

　　Can use the following command to view /etc/nginx/conf.d file contains the following fortune-config

#kubectl exec config-volume-yh -c web-server ls /etc/nginx/conf.d

7.5. Secert using sensitive data transferred to the container

7.5.1. Introduction Secert

Secret ConfigMap structure and the like, are key / value mappings.

Using the same methods and ConfigMap, you can:

　　Secret 1. The entry to the container is passed as an environment variable,

　　2. Secret entry exposed to the volume file

ConfigMap insensitive text stored configuration data, use data stored inherently sensitive Secret

7.5.2. The default token Secret

1. Review the secret

# kubectl get secrets 
NAME                  TYPE                                  DATA   AGE
default-token-x9cjb   kubernetes.io/service-account-token   3      78d

2. Describe the secret

# kubectl describe secrets default-token-x9cjb 
Name:         default-token-x9cjb
Namespace:    default
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: default
              kubernetes.io/service-account.uid: 64a41a09-98ce-11e9-9fa5-fa163e6fdb6b

Type:  kubernetes.io/service-account-token

Data
====
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5lduaW8vc2VydmljZTxCv6HdtP-ZW3ZC2IKKR5YBhaokFIl35mix79pU4Ia2pJ_fuPTBGNyrCHyNQYH4ex5DhND3_b2puQmn8RSErQ
ca.crt:     1298 bytes
namespace:  7 bytes

7.5.3. Create a Secret

1. Create a generic secret is called https-yh

#kubectl create secret generic https-yh --from-file=https.key  --from-file=https.cert  --from-file=foo

2. Create a secret.yaml file, content encoded in base64

$ echo -n 'admin' | base64
YWRtaW4=
$ echo -n '1f2d1e2e67df' | base64
MWYyZDFlMmU2N2Rm

yaml contents of the file:

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

create:

$ kubectl create -f ./secret.yaml
secret "mysecret" created

Secret parsing content

$ kubectl get secret mysecret -o yaml
apiVersion: v1
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm
kind: Secret
metadata:
  creationTimestamp: 2016-01-22T18:41:56Z
  name: mysecret
  namespace: default
  resourceVersion: "164619"
  selfLink: /api/v1/namespaces/default/secrets/mysecret
  uid: cfee02d6-c137-11e5-8d73-42010af00002
type: Opaque

base64 decoded:

$ echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
1f2d1e2e67df

7.5.4. Comparison with the Secret ConfigMap

Secret of contents entries will be Base64 encoded format, and ConfigMap directly in plain text display.

1. Create a Secret binary data

　　Base64 binary data can be converted to plain text, and displayed in a format YAML or Json

　　But pay attention to the size limit is 1MB Secret

2.stringDate field Introduction

　　Secret entries may be provided by a plain text field StringDate

kind: Secret
apiVersion: v1
stringDate:
  foo: plain txt
date:
  https.cert: HGIOPUPSDF63456BJ3BBJL34563456BLKJBK634563456BLBKJBLKJ63456BLK3456LK
  http.key: OHOPGPIU42342345OIVBGOI3456345OVB6O3456BIPO435B6IPU345UI

7.5.5 Using Secret in the pod

secret data volume as a mount and exposed to the environment variable Pod in containers, can also be used other resources in the system. For example, you can use the certificate to import files secret interact with external systems needed.

Pod used in the form of a secret file

Create a Secret, you can reference the same multiple Pod Secret
Pod modify the definition in spec.volumes[]plus a volume, the volume to a name, spec.volumes[].secret.secretNamethe record is a reference to the name of Secret
Add in each container requires the use of a Secret spec.containers[].volumeMounts[], specify spec.containers[].volumeMounts[].readOnly = true, spec.containers[].volumeMounts[].mountPathto a path pointing to the system is not in use.
Mirroring or modify the exercise of command system can find the path specified in the previous step. At this point in the Secret dataEach key is specified field following the path of a file name

Here is referenced in a Pod Secret Liezi:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo
    secret:
      secretName: mysecret

Each referenced Secret in every spec.volumesdefinition

If multiple containers in a Pod Secret should reference the definition of a container, then each must specify your own volumeMounts, but declared in a Pod define spec.volumesjust fine.

Secret key mapped to the specified path

You may control the secret key is mapped to a path in the container, using a spec.volumes[].secret.itemsmodified specific path mapped

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo
    secret:
      secretName: mysecret
      items:
      - key: username
        path: my-group/my-username

What happened?

username is mapped to a file /etc/foo/my-group/my-usernameinstead/etc/foo/username
password has not changed

Secret File Permissions

Permissions can specify the secret file, similar to the linux system file permissions, if you do not specify a default permissions are 0644equivalent to the linux file -rw-r--r--permissions

Set the default permission bits

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
  volumes:
  - name: foo
    secret:
      secretName: mysecret
      defaultMode: 256

Above shows a secret file to mount the container /etc/foopath, each derived key file permission bits will be0400

Since JSON does not support octal, decimal number 256 and therefore represent 0400, if yaml format files then it is natural to use the octal

Similarly you can specify that a key individual rights

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
  volumes:
  - name: foo
    secret:
      secretName: mysecret
      items:
      - key: username
        path: my-group/my-username
        mode: 511

Reading the secret value from the volume

A point worth noting is mounted to the container in the form of secret documents, their value is already after base64 decoding, and can be read out directly use.

$ ls /etc/foo/
username
password
$ cat /etc/foo/username
admin
$ cat /etc/foo/password
1f2d1e2e67df

The secret is mounted automatically updated content

That is, if you modify the contents of a Secret, then mount the Secret of the container will also take to the updated value, but this interval is determined by the synchronization of the time kubelet. The longest period of time will be a plus synchronous cache life cycle (period + ttl)

Exception: In subPath mounted to the vessel will not automatically updated secret form

Use Secret in the form of environment variables

Create a Secret, you can reference the same multiple Pod Secret
Modify the definition of the pod, and define the environment variable using env[].valueFrom.secretKeyRefthe specified secret key and the corresponding
Mirroring or modify the command line, so that they can read the 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
            key: username
      - name: SECRET_PASSWORD
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: password
  restartPolicy: Never

Reading the container environment variable is a value already after base64 decoding of:

$ echo $SECRET_USERNAME
admin
$ echo $SECRET_PASSWORD
1f2d1e2e67df

Use imagePullSecrets

Create a special secret access to mirrored repository when accessing the mirror repository created by the Pod's kubelet and pulled the mirror, described in detail in the document here

Auto Import Set imagePullSecrets

You can create a manual, and then refer to it in serviceAccount in. All through this imagePullSecrets Pod will be created with the default serviceAccount associated to pull the mirror,