Categories
Uncategorized

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 specify the docker run , 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:

description

Container run the executable file

Parameters passed to the executable file

Docker kubernetes
ENTRYPOINT command
CMD args

 

 

 

 

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"   //最终变量值为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, you 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  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
metadata:
  name: fortune-env-from-configmap
spec:
  containers:
  - image: luksa/fortune:env
    env:
    - name: INTERVAL                  //设置环境变量
      valueFrom:
        configMapkeyRef:
          name: fortune-configmap     
          key: sleep-interval         //变量的值取自fortune-configmap的slee-interval对应的值

  

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

apiVersion: v1
kind: pod
metadata:
  name: fortune-env-from-configmap
spec:
  containers:
  - image: luksa/fortune:env
    envFrom:
    - prefix: CONFIG_
      confgMapRef:
        name: my-confg-map    //引用my-config-map的ConfigMap并在变量前面都加上CONFIG_

  

7.4.5 Using ConfigMap volumes will be exposed as a file entry

apiVersion: v1
kind: pod
metadata:
  name: configmap-volume-yh
spec:
  containers:
  - image: nginx:aplin
    name: web-server
    volumeMounts:
    ...
    - name: config
defaultMode: "6600" //设置文件的权限为rw-rw mountPath: /etc/nginx/con.conf
subPath: my.conf //subPath字段可以用于挂载卷中某个独立的文件或者文件夹,而且不覆盖该卷下其他文件 ... volume: ... - name: config configMap: name: fortune-config //引用fortune-config configMap的卷,然后挂载在/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 Secret

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:       
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

    Modify the definition of Pod in spec.volumes [] plus a volume, the volume to a name, spec.volumes []. Secret.secretName record is a reference to the name of Secret

    Added to each container requires the use of a Secret spec.containers []. VolumeMounts [], specifies spec.containers []. VolumeMounts []. ReadOnly = true, spec.containers []. VolumeMounts []. MountPath to point an unused system path.

    Mirroring or modify the exercise of command system can find the path specified in the previous step. In each case a key Secret data field is following a path specified 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 must be defined in spec.volumes

If the Pod is more containers must reference the Secret then defined for each container must specify your own volumeMounts, but Pod definition statement once spec.volumes enough.

Secret key mapped to the specified path

Secret key may be mapped to the control path in the container, using spec.volumes []. Secret.items modify particular path is 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 the file / etc / foo / my-group / my-username instead of / 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 the default permissions are 0644, -rw-r equivalent to linux files – 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 / foo path, each derived key file permission bits will be 0400

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: loading into the container will not be automatically updated to secret form subPath

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, define the environment variable and env []. ValueFrom.secretKeyRef designated 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, detailed description of 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,

 

Leave a Reply