Chapter 8: Application Configuration Management

Application Configuration Management

This lesson points

1. Creating and using ConfigMaps Secret and resources;
2. Pod authentication implementations and principles;
3. Container resources, security, and other pre-check configure and use.

Subdivided into the following eight areas:

Demand Source

Background Questions

First look together at the sources of demand. We should have had this experience, it is to use a container mirror to start a container. To start the container, there are many issues to be addressed needs for support:

• First, for example, some variable configuration. Because we can not put some variable configuration mirror written inside, when the configuration needs change, we may need to recompile a mirror, this certainly is not acceptable;
• The second is the storage and use of sensitive information. For example, the application needs to use some passwords, or use some token;
• The third container is what we want to access the cluster itself. For example, I want to access kube-apiserver, then the authentication itself is a problem;
• The fourth is the container after running on the node, its resource requirements;
• The fifth is the container on the nodes that are shared kernel, then it's a safe control how to do?
• The last thing we talk about a pre-condition before the start of the test container. For example, a container before the start, I may have to confirm the DNS service is not easy to use? Or confirm Unicom's network is not? Then the fact that some of the front of the check.

Pod Configuration Management

In Kubernetes inside, it is how do these configuration managed it? As shown below:

• The ConfigMap configured to use the variable;
• Sensitive information is Secret;
• Authentication is ServiceAccount these independent resources to achieve;
• The allocation of resources is Resources;
• Security control is the SecurityContext;
• Pre-check these spec configuration management in which added with InitContainers these fields, to achieve.

ConfigMap

ConfigMap Introduction

Let's review the first part, is ConfigMap. Let's start with ConfigMap it is used to do, and one of the benefits it brings. In fact, it is mainly manage some variable configuration information, such as some of our application configuration files, or it inside some environment variables, or some command-line arguments.

Its advantage is that it allows a number of variable configuration mirror and container decoupling, which would also ensure the portability of the container. Look at the file layout screenshot to the right of the figure below.

The required configuration files, environment variables, command-line parameters variable configuration management major container runtime. Decoupling mirror for the container and a variable configuration, in order to protect the workload portability (Pod) of.

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    app: flannel
    tier: node
  name: kube-flannel-cfg
  namespace: kube-system
data:
  cni-conf.json: |
    {
      "name": "cbr0",
      "type": "flannel",
      "delegate":{
        "isDefaultGateway": true
      }
    }
  net-conf.json: |
  {
    "Network": "172.27.0.0/16".
    "Backend": {
      "Type": "vxlan"
    }
  }
   

This is a definition ConfigMap itself, which consists of two parts: a meta-information is ConfigMap, we are concerned about both the name and namespace information. Next, the data inside, you can see it manage two profiles. In fact, its structure is this: from the name to see ConfigMap contains the word Map, Map is actually key: value, key is a file name, value is the contents of the file.

Creating ConfigMap

After reading the introduction, more specific look at how it was created. We recommend using kubectl this command to create, with the argument that there are two: one is the designated name, the second is DATA. DATA can specify which file or directory is specified, as well as directly specifying key-value pairs, you can look at the example below.

Create a command:kubectl create configmap [NAME] [DATA]

Which DATA:

• Specified file or directory

Specify the file to create the sample:

kubectl create configmap kube-flannel-cfg --from-file=configure-pod-container/configmap/cni-conf.json -n kube-system

kubectl get configmap kube-flannel-cfg -o yaml
apiVersion：v1
kind: ConfigMap
metadata:
  labels:
    app: flannel
    tier: node
  name: kube-flannel-cfg
  namespace: kube-system
data: 
  cni-conf.json: |  # 文件名字作为key
    {  # 文件内容作为value
      "name": "cbr0",
      "type": "flannel",
      "delegate": {
        "isDefaultGateway": true
      }
    }

Specify key-value pairs created

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

kubectl get configmap special-config -o yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:  # 输入的键值对
  special.how: very
  special.type: charm

If the specified file, the file name is the Map key, the file content is the Map of value. And then specify the key-value pair is key to the specified data, namely: key: value form, mapped directly to the Map key: value.

ConfigMap use

After you create finished, should be how to use it?

Pod ConfigMap mainly used, is generally used to mount a Pod configuration file, environment variables, command-line parameters.

Example 1] by ConfigMap configuration environment variable)

apiVersion:
kind: Pod
metadata:
  namp: cm-env-test
spec:
  containers:
    - name: test-container
      iamge: k8s.gcr.io/busybox
      command: ["/bin/sh","-c","env"]
      env:
        # 用apecial-config中的specila.how定义环境变量
        - name: SPECILA_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.how
  restartPolicy: Never
  

Example 2 :( line configuration parameters configMap control command)

apiVersion: v1
kind: Pod
metadata:
  name: cm-cmd-test
spec:
  containers:
    - name: test-container
      iamge: k8s.gcr.io/busybox
      command: ["/bin/sh","-c","echo ${SPECILA_LEVEL_KEY}"]
      env:
        - name: SPECILA_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: SPECIAL_LEVEL
  restartPolicy: Never
  

Example 3: Mounting profile with ConfigMap

apiVersion: v1
kind: Pod
metadata:
  name: cm-value-test
spec:
  containers:
    - name: test-container
      image: k8s.gcr.io/busybox
      command: ["/bin/sh","-c","ls /etc/config"]
      valumeMonuts:
        - name: config-value
          mountPath: /etc/config
  valumes:
    - name: config-valume
      configMap:
        name: special-config
  restartPolicy: Never        

It is shown, mainly in the pod used in the above FIG ConfigMap:

• The first is the environment variable. Environment variables, then by valueFrom, then ConfigMapKeyRef this field, the following name is specified ConfigMap name, key is ConfigMap.data inside the key. In this case, after the start busybox container vessel performed env will see a SPECIAL the LEVEL KEY environment variables;
• The second is the command-line parameters. Command line parameters is actually the first line of environmental variables directly cmd get inside this field to use;
• The last one is a directory under volume loading directly linked to the way to the container. The above example is that the special-config ConfigMap linked to the contents inside the / etc / config directory inside the container, this is also a way to use.

ConfigMap points to note

Now the use of ConfigMap do a summary, as well as some of its attention to the point, pay attention to the following five-point total listed:

1. ConfigMap file size. Although ConfigMap file no size limit, but in ETCD inside, write data is limited in size and is now limited to less than 1MB;
2. Note that when the second point is introduced ConfigMap pod must be the same in ConfigMap Namespace, the front can in fact be seen, ConfigMap.metadata which are namespace field;
3. The third is the pod cited ConfigMap. If this ConfigMap does not exist, then the pod is unable to create successful, in fact, this also means that before you create a pod, must first be referenced ConfigMap created;
4. The fourth point is to use envFrom way. When the import all the information ConfigMap inside into the environment variable, if ConfigMap in some key is not valid, such as key names with numbers inside, then this environment variable is not actually injected into the container, it will be ignored. But the pod itself can create. And the third point is not the same manner, on the basis of a file exists ConfigMap, introduced into a whole form the environment variable;
5. The last point is: What kind of pod to use ConfigMap? There is only pod to api created by K8s ConfigMap use, for example by using the command line kubectl pod to create, you can certainly use ConfigMap, but the pod created in other ways, for example by static pod manifest kubelet created, it is You can not use the ConfigMap.

Secret

Secret Introduction

Now we talk about Secret, Secret is a major target for resource sensitive information stored password token and so on. Wherein the sensitive information is saved using the base-64 encoded, we look at the definition of the Secret Data FIG.

apiVersion: v1
kind: Secret # Secret元数据
metadata: 
  name: mysecret
  namespace: kube-system
type: Opaque
data:
  username: YYUYYYLKSD
  password: sjdfksdklflkll=

Metadata, then, which is mainly name, namespace two fields; followed by type, it is a very important field, it refers to a type of Secret. Secret type more species, listed the following four common types:

• The first is Opaque, it is common Secret documents;
• The second is service-account-token, a Secret for service-account authentication used;
• The third is dockerconfigjson, which is a private Secret by pulling warehouse mirror;
• The fourth is bootstrap.token, Secret is an access node for the cluster with the check.

Data is then followed, Secret is stored data, it is also the form of key-value store.

Create a Secret

Next we look at the creation of the Secret.

There are two ways to create:

• The system creates: for example K8s for each namespace of the default user (default ServiceAccount) Create a Secret;
• Users manually create: command to manually create, recommend kubectl this command-line tool, it is relatively ConfigMap will be one more type parameters. Where the data is the same, it is also possible to specify files and key-value pairs. type, then, if you do not specify, the default is Opaque type.

Secret can create user-created, there is a system to automatically create Secret

• For example: K8S the default namespace of each user (default ServiceAccount) created Secret

Create a command manually: kubectl create secrt generic [NAME] [DATA] [TYPE]

Wherein DATA: can specify the file / value pairs

In addition TYPE: Opaque default

Specify the file creation:

kubectl create secret generic myregistrykey --from-file=.dockerconfigjson=/root/.docker/config.json –type=kubernetes.io/dockerconfigjson

apiVersion: V1
kind: Secret
metadata:
  name: myregistrykey
  namespace: default
data: 
  .dockerconfigjson: jflsdkjfklsdjflksdjflksjdfkjsdklfjalkqqqqqqqqqqqqqqqqqqqqqqqkljdflksjdfdsf
type: kubernetes.io/dockerconfigjson

Specify key-value pairs:

kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11

apiVersion: v1
data: 
  password: tttttslejkljlk
  username: ChjsldfiwenkHH
kind: Secret
meatdata:
  name: prod-db-secret
  namespace: default
type: Opaque

Figure above two examples. The first is by specifying the file, create a pull Secret private warehouse mirroring, the specified file is /root/.docker/config.json. if the specified type is dockerconfigjson, we specify another key-value pairs, we type is not specified, the default is Opaque. Key-value pair is key: in the form of value, where the value of the content base64 encryption. Secret is to create such a situation.

Secret Use

After creating the Secret, then look at how to use it. It is mainly used by pod, usually mounted by volume to form the container specified directory, then the container business processes and then to read the Secret catalog to use. Also in the mirror need access to private warehouses, but also by reference Secret to achieve.

Example 1: (Sectet mounted at user specified directory)

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts: # secret以文件形式挂载在/etc/foo下
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo  
    secret:  # 指定要挂载的secret
      secrteName: mysecret

Example 2: (SeviceAccount automatically mounted using a fixed secret directory (ca.crt generation token and two files))

apiVersion: v1
kind: Pod
metadata: 
  name: nginx-sjdlrkj325-mdfp5
  namespace: default
spec:
  containers:
  - iamge: nginx: 1-alpine
    name: nginx
    - volumeMounts: # 固定挂载到容器中的/var/run/secret/kubernetes.io/serviceaccount目录下 /var/run/secret/kubernetes.io/serviceaccount
      name: default-token-666i8
      readonly: true
  serviceAccount: default
  serviceAccountName: default # 使用namespace默认的serviceaccount
  volumes:
  - name: default-token-6lsdkjf
    secret:
      defaultMode: 420  # 挂载namespace默认的secret
      secretName: default-token-6fjsi

Let's look at a user-specified directory to mount the way:

• The first embodiment: As shown in FIG left, the user directly specify, to mount the container mysecret / etc / foo directory;
• The second embodiment: As shown in FIG right, the system automatically generates, the serviceaccount-secret automatically mounted on the lower container /var/run/secrets/kubernetes.io/serviceaccount directory, it generates two files, one ca .crt, it is a token. These are two saved the certificate file authentication information.

Use private image library

Secret used by private warehouse following look at the mirror. First, the private information is stored in image repository Secret inside (created specifically referring to the section of the Secret), and then pull the mirror private repository, then the image below can be configured in two ways:

• The first embodiment: as shown on the left side, directly inside the pod, configured by imagePullSecrets field;
• The second way is automatically injected. User configuration imagePullSecrets in advance will be used in serviceaccount pod, Pod create the system automatically inject the imagePullSecrets.

Designated imagePullSecret

apiVersion: v1
kind: Pod
metadata:
  name: private-reg
spec:
  containers:
  - name: private-reg-container
    image: <你的镜像>
  imagePullSecret：
  - name: regcred
  

Secret use of points to note

Finally, take a look at some of the attention points Secret used, the three points listed below:

1. The first is the Secret file size limit. Like this ConfigMap, it is 1MB;
2. The second is the Secret uses base-64 encoding, but it is not much difference with the plaintext. So, if there is some use of confidential information Secret store, then it must be very carefully considered. That is who is going to visit you this cluster, who will be with you this Secret, still have to be carefully considered, because if it can access the cluster, you can get the Secret.

If sensitive information is Secret demanding, there is a strong demand for this encryption is recommended and can be used Kubernetes do a vault open source solutions to address rights management and encryption of sensitive information.

1. The third best practice is to read the Secret, is not recommended list / watch, if a list / watch operation, then all Secret under the namespace will pull down all, this is actually exposed to more information. GET recommended methods, so you only get the Secret own needs.

ServiceAccount

Introduction ServiceAccount

Next, we talk about ServiceAccount. ServiceAccount The first is used to solve the authentication problem in a cluster inside the pod, authentication information is present in the Secret inside.

Look at the left side of the screenshot above, you can see the bottom of the red box, there is a Secret field that specifies which ServiceAccount with a Secret, this is K8s automatically add the ServiceAccount. Then look at the right side of the figure above theme, Secret data of its corresponding data, there are two, one is in ca.crt, is a token. ca.crt for checking the service end, Pod token for authentication, they are encoded in a base64. Then you can see the metadata that is meta information, in fact, there is a link ServiceAccount information (the secret being used by which ServiceAccount). Finally, we note type, this is the service-account-token of this type.

For example: Pod in application access K8s cluster to which it belongs

After the introduction to its corresponding ServiceAccount and secret, we look at, pod is how to use it ServiceAccount or use secret is how to access your K8s cluster.

In fact, when the pod is created, it will first of all the secret to a fixed mount directory container, which is implemented on K8s function. It put this ca.crt and token these two files to a fixed mount directory.

To access the cluster when the pod, it is how to use this file it? We look at the code below screenshot:

When we realize Pod access K8s cluster Go inside, the general will be transferred directly to a InClusterConfig way to generate some of this information to access the service Client. You can then look at this last Config there are two pieces of information:

• Is a tlsClientConfig, this is mainly used ca.crt verification server;
• The second is the Bearer Token, this is the pod authentication. On the server side of the pod will be a use authentication token.

Back again on the left side. pod after the completion of the identity authentication information will have two parts: one is the Group, is a User. Identity authentication is that two pieces of information. Then you can use RBAC capabilities to carry out a pod authorization management.

If RBAC is not configured, the default permissions of the pod has a resource GET, is that you can get data from K8s belongs in the cluster. If it requires more permissions, you will need to configure their own RBAC. RBAC-related knowledge, which we will detail in a later lesson, we can look at.

Resource

Container resource management with

Here are some Resource, namely: a resource configuration management container.

Currently, there are three types of internal support: CPU, memory, and temporary storage. When you think of these three is not enough, there are some of their own resources, such as GPU, or other resources, you can also define your own, but when you configure the number specified must be an integer. At present the allocation of resources and limit request is divided into two types, one is the amount needed is a limit of resources. CPU, memory and storage are carried out temporarily in a statement Resource field under the container inside.

Support Resource type:

• CPU: Unit: millicore (1 Core = 1000millicore)
• Memory: Unit: Byte
• ephemeral storage (temporary storage): Unit: Byte
• Custom Resources: When you configure must be an integer

Configuration:

The allocation of resources into request / limit of two types

• CPU
  • spec.containers[].resources.limits.cpu
  • spec.containers[].resources.request.cpu
• Memory
  • spec.containers[].resources.limits.memory
  • spec.containers[].resources.request.memory
• ephemeral storage (temporary storage)
  • spec.containers[].resources.limit.epherneral-storage
  • spec.containers[].resources.request.epherneral-storage

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: wp
    iamge: wordpress
    resources:  # 申明需要的资源
      request：
        memory: "64Mi"
        cpu: "250m"
        ephemeral-storage: "2Gi"
      limits:
        memory: "128Mi"
        cpu: "500m"
        ephemeral-storage: "4Gi"
        

For example, the resource requirements wordpress container, one request, one limits, which are critical for resources and resources needed to conduct a statement.

Pod Quality of Service (QoS) configuration

CPU memory according to the demand for container resources, we conducted a classification for quality of service pod, are Guaranteed, Burstable and BestEffort.

• Guaranteed: pod inside each container must have memory and CPU request and a statement of the limit, and request and limit must be the same, this is Guaranteed;
• Burstable: Burstable presence of a container having at least a CPU and a memory request;
• BestEffort: As long as the Guaranteed and Burstable, that is BestEffort.

Well, this is what kind of quality of service it? After the allocation of resources is good, when running on this node pod container, such as lack of memory on a node quota resources, kubelet put some low-priority, or less demanding quality of service (such as: BestEffort, Burstable) pod expelled out. They are in accordance with the first removal BestEffort, then remove a Burstable order to expel the pod.

SecurityContext

Introduction SecurityContext

SecurityContext behavior is mainly used to limit a container, it can ensure security, and other containers. This ability is not Kubernetes or container runtime capability piece itself, but Kubernetes and runtime configuration by the user, and finally reached under the kernel, and then through the mechanism of the kernel so that SecurityContext to take effect. So here was talking about, it would be more simple or a little more abstract.

SecurityContext divided into three levels:

• The first level is a container, the container only take effect;
• The second level is the pod, for pod in all containers into force;
• The third is the cluster level, is the PSP, all pod cluster effect.

Permissions and access control settings, now lists a total of seven (the number of follow-up may vary):

1. The first Discretionary Access Control is to control file access through a user ID and group ID;
2. The second is SELinux, it is to control user access control to files or processes through policy configuration;
3. The third is the prerogative of privileged container;
4. The fourth is the Linux Capabilities, it is also a privileged ability to configure to a specific process;
5. The fifth is the AppArmor, it also controls an access control rights of the executable file through some configuration files, such as reading and writing some of the ports;
6. The sixth Seccomp is control of one of the system call;
7. The seventh AllowPrivilegeEscalation is a child process can obtain a more restrictive than the father's permission.

In fact, last fall are the core to control some of its authority.

The figure is an example of the configuration of the pod SecurityContext level and container level, if you have more demand for content, you can learn this information to search for more in-depth information.

InitContainer

InitContainer Introduction

Then look at the InitContainer, first introduced the distinction InitContainer and ordinary container, the following three points:

1. InitContainer is first started before the ordinary container, and until all InitContainer after successful execution, ordinary container will be activated;
2. Between InitContainer is defined in the order to start the execution performed again after the successful implementation of a second, while ordinary container is started concurrently;
3. InitContainer executed after the successful conclusion of the exit, while the ordinary container may have been executed. It may be a longtime, or that fails will restart, and this is different from ordinary container InitContainer place.

According to the above three points, we look at a use of InitContainer. In fact, it is mainly ordinary container service, for example, it can do a initialized before starting an ordinary container, or for it to prepare some configuration files, configuration files may be some things change. Another example is to do some pre-conditions of verification, such as whether the Unicom network.

The screenshot above is a configuration InitContainer of flannel components, it is mainly to prepare some of InitContainer network profile for this before kube-flannel ordinary container starts.

Conclusion

• ConfigMap and Secret: Secret introduces ConfigMap and methods of creation and usage scenarios, and then use common point ConfigMap attention and were classified Secret and finishing. Finally, the private warehouse mirroring use and configuration;
• Pod Authentication: first introduced and Secret ServiceAccount relationship, and then the Pod authentication process and analyze implementation details from the perspective of the source, while the leads Pod rights management (i.e. RBAC configuration management);
• Container resources and security: first introduced the common container resource types (CPU / Memory) configuration, and then the quality of service for Pod classification detail. Meanwhile SecurityContext effective hierarchical authority and a brief description of the configuration item;
• InitContainer: first it introduced the use of the difference between InitContainer and ordinary container and InitContainer of. Then based on the actual use of the embodiment has been described InitContainer use.