Table of contents
1. ConfigMaps
One of the best practices in application deployment is to separate the configuration information required by the application from the program, so that the application can be reused better and more flexible functions can be realized through different configurations.
After the application is packaged as a container image, configuration injection can be performed when creating a container through environment variables or plug-in files. However, in a large-scale container cluster environment, it will become very complicated to configure multiple containers differently.
Starting from Kubernetes v1.2, a unified application configuration management solution - ConfigMap is provided.
After the ConfigMap is created, the data will actually be stored in Etcd in K8s, and then the data will be referenced when Pod is created.
Application Scenario: Application Configuration
Pod uses configmap data in two ways:
• Variable injection , get ConfigMap through environment variables
• Data volume mount , mount the content in ConfigMap as a file or directory inside the container by means of Volume mount
Create configMap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
abc: "123"
cde: "456"
redis.properties: |
port: 6379
host: 192.168.2.117View the created configMap
Create configMap-deploy.yaml
apiVersion: v1
kind: Pod
metadata:
name: app-config-demo
spec:
containers:
- name: demo
image: nginx
env:
- name: ABCD
valueFrom:
configMapKeyRef:
name: app-config
key: abc
- name: CDEF
valueFrom:
configMapKeyRef:
name: app-config
key: cde
volumeMounts:
- name: config
mountPath: "/config" # 配置文件挂载在容器中的位置
readOnly: true
volumes: # 数据卷挂载
- name: config
configMap:
name: app-config
items:
- key: "redis.properties"
path: "redis.properties"Verify that the variable injection is successful, and the redis.properties configuration file is also mounted to the /config path.
ConfigMap points to note
Now make a summary of the use of ConfigMap, as well as some of its attention points. The following five points are listed in total:
- The first point is the size of the ConfigMap file . Although there is no size limit for the ConfigMap file, there is a size limit for writing data in ETCD, and now it is limited to within 1MB;
- The second point to note is that when a pod imports a ConfigMap, it must be a ConfigMap in the same Namespace . As you can see earlier, there is a namespace field in ConfigMap.metadata;
- The third point is the ConfigMap referenced by the pod. If the ConfigMap does not exist, the pod cannot be created successfully. In fact, this also means that the ConfigMap to be referenced must be created before creating the pod;
- The fourth point is the way to use envFrom. When importing all the information in the ConfigMap into environment variables, if some keys in the ConfigMap are invalid, for example, the key names contain numbers, then this environment variable will not be injected into the container, and it will be ignored. But the pod itself can be created. This is different from the third point. It is based on the existence of the ConfigMap file and is imported as an environment variable as a whole;
- The last point is: what kind of pod can use ConfigMap? Here, only pods created through K8s api can use ConfigMap. For example, pods created by using the command line kubectl can definitely use ConfigMap, but pods created by other methods, such as static pods created by kubelet through manifest, are Cannot use ConfigMap.
Two, Secret
k8s secrets are used to store and manage some sensitive data, such as passwords, tokens, keys and other sensitive information. It stores the encrypted data that Pod wants to access in Etcd . Then users can access the information stored in these Secrets by mounting Volumes or environment variables in Pod containers . Similar to ConfigMap, the difference is that Secret mainly stores sensitive data, and all data must be base64 encoded.
Application Scenario: Credentials
kubectl create secret supports three data types:
• docker-registry (kubernetes.io/dockerconfigjson): store image warehouse authentication information
• generic (Opaque): store passwords, keys, etc.
• tls (kubernetes.io/tls): stores TLS certificates
We can execute the following command in the linux command line break to encrypt:
echo -n 'admin' | base64
echo -n '1f2d1e2e67df' | base64Create secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: db-user-pass
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2RmCreate secret-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: secret-demo-pod
spec:
containers:
- name: demo
image: nginx
env:
- name: USER
valueFrom:
secretKeyRef:
name: db-user-pass
key: username
- name: PASS
valueFrom:
secretKeyRef:
name: db-user-pass
key: password
volumeMounts:
- name: config
mountPath: "/config"
readOnly: true
volumes:
- name: config
secret:
secretName: db-user-pass
items:
- key: username
path: my-usernameSuccessfully read the username and password
Some points for attention in the use of Secret, the following three points are listed:
- The first point is the file size limit of Secret. This is the same as ConfigMap, which is also 1MB;
- The second point is that Secret uses base-64 encoding, but it is not much different from plaintext. Therefore, if there is some confidential information to be stored in Secret, it should be carefully considered. That is to say, who will visit your cluster and who will use your Secret should be carefully considered, because if they can access the cluster, they can get the Secret;
- The third point is the best practice for reading Secrets. It is recommended not to use list/watch. If you use list/watch to operate, all Secrets under the namespace will be pulled down, which actually exposes more information. It is recommended to use the GET method, so that you only get the Secret you need.
Reference link to the original text: K8S series (seven) application configuration management_Lin Musen^~^'s blog-CSDN blog_k8s application configuration file