ConfigMap and Secret are Kubernetes in two special types of storage volumes, ConfigMap such resources is primarily used to provide configuration data to customize program behavior, but some sensitive configuration information, such as user names, passwords, keys, etc. are usually Secret be configured by such resource objects, their corresponding configuration information stored in the object, and then stored in the form of its volume and mount disposed on Pod obtain the corresponding resources to decouple the configuration and image files .
A, Secret resource object
1) Secret Overview
Secret way to target resources to store data by way of key-value pairs are stored in the Pod Secret way resources are carried out by environmental variables or storage volumes of data access, to solve the passwords, sensitive data token, key, etc. configuration problems, without the need to expose the sensitive data to the spec of Pod or the mirror field. Further, the object Secret store and print data format Base64 encoded string, the user when creating Secret objects also need to have this type of data encoding formats. When access to the environment variable storage volume or container in a manner, automatically decoded to plain text format. Note that, if it is on the Master node, Secret objects to store non-encrypted format in etcd in, so the need for strict control of etcd management and permissions.
2) the type of resources Secret
Secret There are four types:
. 1) the Account-Service: Access to Kubernetes API, automatically created by Kubernetes, and automatically mounts the Pod in the directory /run/secrets/kubernetes.io/serviceaccount;
2) of Opaque: Base64 encoded format the Secret, for storing passwords, keys, information, certificate, type identifier of Generic;
. 3) kubernetes.io/dockerconfigjson: storing authentication information for the private docker registry, Registry-type identifier for the Docker;
. 4) Kubernetes .io / tls: SSL communication mode is used to store certificates and private key file type identifier is imperative to create TLS;
3) Create a Secret fashion
Data storage is the assumption that:
username: root
password: 123.com
following storage is to store this information!
1) mode using --from-literal (text) of
[root@master ~]# kubectl create secret generic mysecret01 --from-literal=username=root --from-literal=password=123.com
#创建一个secret资源对象，名称为mysecret01，采用的加密方式是generic（通用的、一般的加密方式）
#注意：这种方式每一条只能保存一条信息
[root@master ~]# kubectl get secrets mysecret01
NAME TYPE DATA AGE
mysecret01 Opaque 2 25s
[root@master ~]# kubectl describe secrets mysecret01 #查看该资源的详细信息
Name: mysecret01
Namespace: default
Labels: <none>
Annotations: <none>
Type: Opaque #不透明的，看不到的
Data
====
password: 7 bytes #只能查看键的名称，无法查看到键对应的值
username: 4 bytes
[root@master ~]# kubectl get secrets mysecret01 -o yaml
#将该资源以yaml文件的方式进行显示
apiVersion: v1
data:
password: MTIzLmNvbQ== #键对应的值都是乱码，加密使用的是base64编码格式
username: cm9vdA==
kind: Secret
metadata:
creationTimestamp: "2020-02-14T10:08:21Z"
name: mysecret01
namespace: default
resourceVersion: "2474"
selfLink: /api/v1/namespaces/default/secrets/mysecret01
uid: 1aee0635-7bfb-4e8a-a21e-be993e534156
type: Opaque
[root@master ~]# echo -n cm9vdAo= | base64 --d #将乱码解码后的结果
root
[root@master ~]# echo -n MTIzLmNvbQ== | base64 --d
123.com2) way to use --from-file (file)
This method is more similar to the first approach, it may seem a little trickier!
[root@master ~]# echo root > username
[root@master ~]# echo 123.com > password
#需要先将要存储的键值对写入到文件中，并且每个文件只能写入一个值
[root@master ~]# kubectl create secret generic mysecret02 --from-file=username --from-file=password
[root@master ~]# rm -rf username password
#即使文件删除之后，该资源键对应的值依然也是存在的
[root@master ~]# kubectl get secrets mysecret02
NAME TYPE DATA AGE
mysecret02 Opaque 2 58s
[root@master ~]# kubectl describe secrets mysecret02
Name: mysecret02
Namespace: default
Labels: <none>
Annotations: <none>
Type: Opaque
Data
====
password: 8 bytes
username: 5 bytes3) --from-env-file (environment variable) manner
This way you can write multiple key-value pairs in the same file, it is recommended to use!
[root@master ~]# tee env.txt <<EOF #将多个需要存储的键值写入同一个文件中
username=root
password=123.com
EOF
[root@master ~]# kubectl create secret generic mysecret03 --from-env-file=env.txt
secret/mysecret03 created
[root@master ~]# kubectl get secrets mysecret03
NAME TYPE DATA AGE
mysecret03 Opaque 2 19s
[root@master ~]# kubectl describe secrets mysecret03
Name: mysecret03
Namespace: default
Labels: <none>
Annotations: <none>
Type: Opaque
Data
====
username: 4 bytes
password: 7 bytes4) by way of yaml file
[root@master ~]# echo root | base64 #需要将键对应的值进行加密
cm9vdAo=
[root@master ~]# echo 123.com | base64
MTIzLmNvbQo=
[root@master ~]# vim secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: mysecret04
data:
username: cm9vdAo= #将加密后的值写到配置文件中
password: MTIzLmNvbQo=
[root@master ~]# kubectl apply -f secret.yaml
[root@master ~]# kubectl get secrets mysecret04
NAME TYPE DATA AGE
mysecret04 Opaque 2 118s
[root@master ~]# kubectl describe secrets mysecret04
Name: mysecret04
Namespace: default
Labels: <none>
Annotations:
Type: Opaque
Data
====
password: 8 bytes
username: 5 bytes4) use of resources Secret
1) mounted in a way to use volume
[root@master ~]# vim secret-pod01.yaml
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mypod
image: busybox
args:
- /bin/sh
- -c
- sleep 3000000 #以上字段仅仅是创建一个容器
volumeMounts:
- name: secret-test
mountPath: "/etc/secret-test" #指定容器中的目录
readOnly: true #以只读的方式挂载
volumes:
- name: secret-test
secret:
secretName: mysecret04 #指定的是已有的secret资源的名称
[root@master ~]# kubectl apply -f secret-pod01.yaml
[root@master ~]# kubectl exec -it mypod /bin/sh #进入容器
/ # cat -n /etc/secret-test/username /etc/secret-test/password #查看对应的目录是否存在数据
1 root
2 123.com
#而且是已经解密后的数据
/ # echo 12324235532 > /etc/secret-test/username
/bin/sh: can't create /etc/secret-test/username: Read-only file systemNow, we can verify that, if at this time to change the content secret04, then mount the directory contents of the container corresponding to whether the change?
[root@master ~]# echo zhangsan | base64
emhhbmdzYW4K
[root@master ~]# echo 123456 | base64
MTIzNDU2Cg==
[root@master ~]# vim secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: mysecret04
data:
username: emhhbmdzYW4K
password: MTIzNDU2Cg==
[root@master ~]# kubectl apply -f secret.yaml
[root@master ~]# kubectl exec -it mypod /bin/sh
/ # cat -n /etc/secret-test/username /etc/secret-test/password
1 zhangsan
2 123456
#再次查看容器中数据，发现已经发生了变化！ Note: If using volume mount invoke secert stored value, the value of the container will change with the change in the value of secert store!
2) Run by the way environment variables
[root@master ~]# vim secret-pod02.yaml
apiVersion: v1
kind: Pod
metadata:
name: mypod2
spec:
containers:
- name: mypod
image: busybox
args:
- /bin/sh
- -c
- sleep 3000000
env: #设置环境变量
- name: SECRET_USERNAME #指容器中的变量名称
valueFrom:
secretKeyRef:
name: mysecret02 #调用的是mysecret02
key: username #对应的是mysecret02中username对应的值
- name: SECRET_PASSWORD #同上
valueFrom:
secretKeyRef:
name: mysecret02
key: password
[root@master ~]# kubectl apply -f secret-pod02.yaml
[root@master ~]# kubectl exec -it mypod2 /bin/sh
/ # echo ${SECRET_USERNAME}
root
/ # echo ${SECRET_PASSWORD}
123.com
#进入容器之后，查看变量对应的值Note: If the variable invoke secert stored values, variables in the container and does not change with the value stored secert occur unless rebuild the pod.
Two, ConfigMap resource object
1) ConfigMap Overview
We know that in almost all applications development, will involve changing the configuration file, such as in web programming, you need to connect to the database, caching and even queue and so on. And we write an application from the first line of code starts to undergo development environment, test environment, the environment only to the final pre-release online environment. And every environment must define its stand-alone configurations. If we are not well manage these profiles, your operation and maintenance work will suddenly become very tedious. For this reason some of the biggest specialized industry has developed its own set of configuration management centers such as 360 Qcon, Baidu's disconf and so on. kubernetes also provides its own set of programs that ConfigMap. kubernetes configuration management is achieved through the application container ConfigMap.
2) ConfigMap way to create
In fact, the way to create configMap and secert resource objects exactly the same!
1) by way --from-literal
[root@master ~]# kubectl create configmap configmap01 --from-literal=username=root --from-literal=password=123.com
#创建一个configmap资源，名称为configmap01
[root@master ~]# kubectl describe configmaps configmap01
Name: configmap01
Namespace: default
Labels: <none>
Annotations: <none>
Data #可以很明确的看出存储的键对应的值，所以一般用于存储配置文件信息
====
password:
----
123.com
username:
----
root
Events: <none>2) by way of --from-file
[root@master ~]# echo root > username
[root@master ~]# echo 123.com > password
[root@master ~]# kubectl create configmap configmap02 --from-file=username --from-file=password
configmap/configmap02 created
[root@master ~]# kubectl describe configmaps configmap02
Name: configmap02
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
password:
----
123.com
username:
----
root
Events: <none>3) --from-env-file manner
[root@master ~]# tee 123.txt <<EOF
> username=root
> password=123.com
> EOF
[root@master ~]# kubectl create configmap configmap03 --from-env-file=123.txt
configmap/configmap03 created
[root@master ~]# kubectl describe configmaps configmap03
Name: configmap03
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
username:
----
root
password:
----
123.com
Events: <none>4) by way of yaml file
[root@master ~]# vim configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: configmap04
data:
username: root #configmap使用yaml文件进行创建时，键对应的值无需事先加密
password: 123.com #对应的值如果是数字，则需要单引号引起
[root@master ~]# kubectl apply -f configmap.yaml
[root@master ~]# kubectl describe configmaps configmap04
Name: configmap04
Namespace: default
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","data":{"password":"123.com","username":"root"},"kind":"ConfigMap","metadata":{"annotations":{},"name":"configmap04","n...
Data
====
password:
----
123.com
username:
----
root
Events: <none>3) ConfigMap of use
1) mounted in a way to use volume
[root@master ~]# vim configmap-pod01.yaml
apiVersion: v1
kind: Pod
metadata:
name: configmap-pod01
spec:
containers:
- name: configmap-pod01
image: busybox
args:
- /bin/sh
- -c
- sleep 3000000
volumeMounts:
- name: configmap-test
mountPath: "/etc/configmap-test"
readOnly: true
volumes:
- name: configmap-test
configMap:
name: configmap01
[root@master ~]# kubectl apply -f configmap-pod01.yaml
[root@master ~]# kubectl exec -it configmap-pod01 /bin/sh
/ # cat -n /etc/configmap-test/username /etc/configmap-test/password
1 root
2 123.comConfigMap resources using volume mount the way, almost the same as the use of the resource volume mount Secret way, it will change the source data changes!
2) Run by the way environment variables
[root@master ~]# vim configmap-pod02.yaml
apiVersion: v1
kind: Pod
metadata:
name: configmap-pod02
spec:
containers:
- name: configmap-pod02
image: busybox
args:
- /bin/sh
- -c
- sleep 3000000
env:
- name: CONFIGMAP_USERNAME
valueFrom:
configMapKeyRef:
name: configmap04
key: username #调用的是configmap04中username的值
- name: CONFIGMAP_PASSWORD
valueFrom:
configMapKeyRef:
name: configmap04
key: password
[root@master ~]# kubectl apply -f configmap-pod02.yaml
[root@master ~]# kubectl exec -it configmap-pod02 /bin/sh
/ # echo ${CONFIGMAP_USERNAME}
root
/ # echo ${CONFIGMAP_PASSWORD}
123.comConfigMap resources using environment variables the way, almost the same as the use of resources and Secret Variables way, will not change with the source data!
Three, Secret of the similarities and differences with ConfigMap
1) the same point
Are used to store information in a lightweight, it can be used for other resource objects (Deployment, RC, RS and POd) to mount use.
Both methods create a resource object (four kinds) and reference method (two kinds) are the same, are a way of storing key-value pairs.
2) difference
Secret is used to store sensitive information, and configMap is used to save some of the less important data, specifically in command, Secret resource objects of this type do not see when we execute "kubectl describe ...." to their specific information, and configMap can view the details of their preserved.
3) Notes
1) Secret, ConfigMap must be created before Pod;
2) only with the current Secret, ConfigMap pod in the same namespace to use this Secret, ConfigMap, in other words, Secret, ConfigMap not cross namespace called.
---------- article. Thank reading ------------