Shulou(Shulou.com)06/02 Report--

Preface

There are two kinds of resource objects, Secret and configMap, in K8s, which is also a way to achieve data persistence, which is slightly different from the previously written PV or mount directory.

Secret resource object: you can store lightweight sensitive information, such as the user name and password of the database or the authentication key. The data it stores is stored in secret text.

ConfigMap resource objects: like Secret, they share most of the common features, but the difference is that configMap holds some less important information, and the data it holds is stored in clear text.

When we create the above two resource objects, we actually write the information stored by these two resource objects to the etcd data center in the K8s cluster.

1. The similarities and differences between secret and configMap:

Both are used to store lightweight information and can be mounted by other resource objects (Deployment, RC, RS, and POd).

The creation methods (4) and reference methods (2) of the two resource objects are the same and are stored in the form of key-value pairs.

Differences:

Secret is used to store sensitive information, while configMap is used to save some less important data, specifically when we execute "kubectl describe." Command, Secret this type of resource object can not view its specific information, while configMap can view the specific content of its storage.

2. Four creation methods of Secret resource object 1 (through-- from-literal)

Suppose the data to be stored is:

Name:zhangsan

Tel:15888888888

[root@master ~] # kubectl create secret generic secret1-- from-literal=name=zhangsan-- from-literal=tel=1588888888 [root@master ~] # kubectl get secrets secret1 # View the created secret1NAME TYPE DATA AGEsecret1 Opaque 289s [root@master ~] # kubectl describe secrets secret1Name: secret1Namespace: defaultLabels: Annotations: Type: OpaqueData====name: 8 bytes # you can see only the contents of the key. Can not see the key corresponding to the value tel: 10 bytes creation method 2 (through-- from-file way)

This method is more troublesome than method 1 and is not recommended.

# you need to write the stored key-value pairs to a file first, and each file can only write one value [root@master ~] # echo zhangsan > name [root@master ~] # echo 15888888888 > tel [root@master ~] # cat name telzhangsan15888888888 [root@master ~] # kubectl create secret generic secret2-- from-file=name-- from-file=tel # execute the above command to create Then use the command of method 1 to view it yourself to create method 3 (through-- from-env-file)

This method can write multiple key-value pairs in the same file, which is recommended.

[root@master ~] # cat > env.txt tel=15888888888 > EOF [root@master ~] # kubectl create secret generic secert3-- from-env-file=env.txt # execute the above command to create data centers stored in k8s by key values in env.txt # check whether to create them by yourself (via yaml configuration file) # you can encrypt the values to be stored [root@master ~] # echo zhangsan | base64emhhbmdzYW4K [root@master ~] # echo 1588888888 | | base64MTU4ODg4ODg4OAo= [root@master ~] # vim secret.yaml # write yaml file apiVersion: v1kind: Secretmetadata: name: secret4data: # the following values are encrypted on the command line name: emhhbmdzYW4K tel: MTU4ODg4ODg4OAo= [root@master ~] # kubectl apply-f secret.yaml # execute yaml file # you can use the following command to decrypt encrypted characters [root@master ~] # echo-n MTU4ODg4ODg4OAo= | base64-- decode 1588888888 III. " Two ways of using Secret

Since this storage method of secret cannot be viewed from the command line, another is, what is the meaning of this storage method? Through the following usage, you should be able to understand its usage scenario.

Use method 1 (using secret as volume mount) [root@master ~] # vim secret-pod.yaml # to write a yaml file and run a podapiVersion: v1kind: Podmetadata: name: secret-podspec: containers:-name: secret-pod image: busybox args:-/ bin/sh-- c-sleep 10; touch / tmp/healthy The fields above sleep 30000 # have nothing to do with using secret:-name: test mountPath: / etc/test # specify the directory to be mounted into the container readOnly: true # it is decided here that volumes:-name: test secret: secretName: secret4 # is mounted as read-only, and the name of secret is specified here That is, we use the secret [root@master ~] # kubectl apply-f secret-pod.yaml # created by the fourth method to execute the yaml file [root@master ~] # kubectl exec-it secret-pod / bin/sh # into the created container / # cat / etc/test/name / etc/test/tel # to see the zhangsan1588888888# under the mounted directory, and we can find that it has been decrypted automatically.

Now, we can verify that if we change the contents of the secret4 at this time, will the contents of the corresponding mount directory in the container change?

[root@master ~] # echo lisi | base64bGlzaQo= [root@master ~] # echo 1599999999 | base64MTU5OTk5OTk5OQo= [root@master ~] # vim secret.yaml # modify its contents apiVersion: v1kind: Secretmetadata: name: secret4data: name: bGlzaQo= tel: MTU5OTk5OTk5OQo= [root@master ~] # kubectl apply-f secret.yaml # re-execute yaml file [root@master ~] # kubectl exec-it secret-pod / bin/sh # enter container / # cat / etc/test/name again / etc/test/tel # you can see that the data in the container has also changed with it. 2 (using secret as environment variables) [root@master ~] # vim secret-pod.yaml # write the yaml file apiVersion: v1kind: Podmetadata: name: secret-podspec: containers:-name: secret-pod image: busybox args:-/ bin/sh-- c-sleep 10 Touch / tmp/healthy Sleep 30000 env: # set environment variables Here, call the value stored in secert3-name: SECRET_NAME # container's variable name valueFrom: secretKeyRef: name: secert3 # specifies that secert3 key: name # calls the corresponding value of secert3's name-name: SECRET_TEL # where SECRET_TEL is the same as valueFrom: SecretKeyRef: name: secert3 key: tel [root@master ~] # kubectl delete-f secret-pod.yaml # Delete the previous pod [root@master ~] # kubectl apply-f secret-pod.yaml # regenerate pod# into the container Output the corresponding variable [root@master ~] # kubectl exec-it secret-pod / bin/sh/ # echo $SECRET_NAMEzhangsan/ # echo $SECRET_TEL15888888888

At this point, the call is completed by referring to the key-value pair stored in secert in the form of variables. You can also test and modify the values stored in secert to see whether the variables in the pod container will change accordingly. The answer is no. If the values stored in secert are called in the way of variables, the values of variables in the container will not change with the values stored in secert, unless the pod is regenerated.

4. Four ways to create configMap resource objects

In fact, configMap and secert resource object creation method is exactly the same, here write down "--from-literal", "--from-env-file" and "yaml file" these three creation methods, as for the "--from-file" creation method, refer to the secert creation method.

Creation method 1 (through-- from-literal) [root@master ~] # kubectl create configmap config1-- from-literal=name=lisi-- from-literal=age=18# stores a key named config1 pair [root@master ~] # kubectl describe configmaps config1 # View the created config1Name: config1Namespace: defaultLabels: Annotations: # you can clearly see the data stored in it So it is used to store some less important data Data====age:----18name:----lisiEvents: creation method 2 (through-- from-env-file) [root@master ~] # cat > config.txt age=18 > EOF [root@master ~] # kubectl create configmap configmap2-- from-env-file=config.txt # execute command creation method 3 (via yaml configuration file) [root@master ~] # vim configmap3.yaml # write Yaml file apiVersion: v1kind: ConfigMapmetadata: name: configmap3data: name: lisi age: '18' # if the value is a number Then [root@master] # kubectl apply-f configmap3.yaml # must be quoted in single quotation marks to execute the yaml file. Fifth, there are two ways to reference configMap data.

The way it is applied is similar to that of secert resource objects, which are mounted by volume or referenced as variables, except that some keywords in some yaml files are different.

Reference method 1 (mount via volume) [root@master ~] # kubectl delete-f secret-pod.yaml # Delete the previously created pod [root@master ~] # vim secret-pod.yaml # modify the yaml file apiVersion: v1kind: Podmetadata: name: secret-podspec: containers:-name: secret-pod image: busybox args:-/ bin/sh-- c-sleep 10; touch / tmp/healthy Sleep 30000 # this does not change volumeMounts:-name: test mountPath: / mnt # Mount to the container's mnt directory readOnly: true volumes:-name: test configMap: # the keywords here are different name: configmap3 # Mount configmap3 [root@master ~] # kubectl apply-f secret-pod.yaml # execute yaml file [root@master ~] # kubectl exec-it secret-pod / bin/sh # enter the container / # cat / mnt/name / mnt/age # to view the mounted content lisi18/ # (due to the special container used So the output format is not very intuitive, but the data is correct)

Similarly, in this way of volume mounting, the data in the pod container changes as the data in the configmap3 changes, and they share the same file.

Reference method 2 (by configuring the env environment variable) [root@master ~] # kubectl delete-f secret-pod.yaml # Delete the previously created pod [root@master ~] # vim secret-pod.yaml # modify the yaml file apiVersion: v1kind: Podmetadata: name: secret-podspec: containers:-name: secret-pod image: busybox args:-/ bin/sh-- c-sleep 10; touch / tmp/healthy Sleep 30000 env: # define environment variables Here you use the key-value pair of the created configmap2-name: USER_NAME valueFrom: configMapKeyRef: name: configmap2 key: name # call the value of name in configmap2-name: USER_AGE valueFrom: configMapKeyRef: name: configmap2 key: age # call the value of age in configmap2 [root@master ~] # kubectl apply-f secret-pod.yaml [root@master ~] # kubectl exec-it secret-pod / bin/sh # enter the container output environment variable / # echo $USER_NAMElisi/ # echo $USER_AGE18

Here's a test. If you change the key-value pair of configmap2, will the environment variables in the container change?

[root@master ~] # vim config.txt # modify the value of configmap2 name=wangwuage=28 [root@master ~] # kubectl delete configmaps # you need to delete [root@master ~] # kubectl create configmap configmap2-- from-env-file=config.txt # and then create [root@master ~] # kubectl exec-it secret-pod / bin/sh # to enter the container output variable. You can see that the variable has not changed / # echo $USER_AGE18/ # echo $USER_NAMElisi

So, now regenerate the pod to see if its environment variables will change (and certainly will)?

[root@master ~] # kubectl delete-f secret-pod.yaml # Delete pod [root@master ~] # kubectl apply-f secret-pod.yaml # regenerate pod [root@master ~] # kubectl exec-it secret-pod / bin/sh # enter the container to view the environment variables and find that it has changed / # echo $USER_NAMEwangwu/ # echo $USER_AGE28

At this point, the verification is complete.

-this is the end of this article. Thank you for reading-

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.