By building MySQL environment to learn important concepts k8s, including persistent volumes, and network configuration parameters. This is Part II, devoted parameter configuration. If you can not fully understand some places, please fancy piece " master important concepts k8s (Kubernetes) (a) through to build MySQL: network and persistent volumes ."
Configuration parameters:
Configuration parameters are more important K8s in a concept, it includes the following three parts:
- ConfigMap : is used to save the shared configuration data. When you need to share data between different profiles, you can store these data in the form of key-value pairs in the configMap. For details, see " the Configure A Pod to the Use A ConfigMap "
- Secret : It is very similar with the role configMap, but used to store confidential information such as passwords database. For details, see " Secrets "
- Variable Environment : it is what we are familiar with the environment variable, usually defined by the system. Different systems such as Linux and Windows have their own ways to define an environment variable. k8s environment variable is mainly used to transmit data to the container. For details, see " Container Environment the Variables "
configMap:
Here is configMap (mysql-config.yaml) profile. Its structure is simple, the most important part is the data, which is the key, the list of values. This is a relatively simple example, the complex may also contain files and keys, the combined value of the list. You can put a configMap placed in a separate file, so it was easier to debug, and it is also possible to deploy (Deployment) put together, so it was easier to run.
apiVersion: v1
kind: ConfigMap
metadata:
name: mysql-config # name of ConfigMap, referenced in other files
data:
db-host: mysql # host address of mysql server
db-name: service_config # name of the databaseconfigMap run command is different from other objects, such as general operating command is "kubectl apply -f mysql-volume.yaml" or "kubectl create -f mysql-volume.yaml", as long as you give the profile name on the list, no need to give the object to be created category (it is automatically recognized) and the name, because in the configuration file has been (eg. "kind: ConfigMap", it means that the object type is "ConfigMap" "name: mysql-config "says configMap name to be created is" mysql-config "). But configMap create command is "kubectl create configmap [map-name] [data-source]", object classes and names should be given a clear command line, [map-name] is the name of configMap to be created. "[Data-source]" is the file name of the data source file (the file name is not a configuration file), we mentioned above, configMap may contain other documents in the key, the list of values, "[data-source]" is "other files" in the file name. Note that this command where they did not mention the profile. I do not like this way, because when you deploy configuration in reference to the key, value pair, configMap need to give the name, if it is not a file exists, but typing when creating, so it is prone to error.
So I created using a common command "kubectl apply -f mysql-config.yaml" to create configMap, in this way in the official document k8s's is not, but it is also feasible. But the drawback is can not contain other files.
Type "kubectl get configMap" has been created to show good configMap.
vagrant@ubuntu-xenial:/var/log$ kubectl get configMap
NAME DATA AGE
mysql-config 2 11hType "kubectl describe configMap" to show the details of configMap.
vagrant@ubuntu-xenial:/var/log$ kubectl describe configMap
Name: mysql-config
Namespace: default
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","data":{"db-host":"mysql","db-name":"service_config"},"kind":"ConfigMap","metadata":{"annotations":{},"name":"mysql-con...
Data
====
db-host:
----
mysql
db-name:
----
service_config
Events: <none>secret：
Here is the secret configuration file (mysql-secret.yaml), it configMap like, the "data" Here is the key, the list of values, but the value of the key is inside the through base64 encoded (e.g. "cm9vdA ==
" ). You can run on Linux, the command "echo -n dbuser | base64" get "dbuser" coding, the output is "ZGJ1c2Vy", then go write it secret. In the following file in a database which stores the user name and password.
apiVersion: v1
kind: Secret
metadata:
name: mysql-secret
data:
mysql-user-root-pwd: cm9vdA== # database password for "root"
mysql-user-dbuser-name: ZGJ1c2Vy # database user name for "dbuser"
mysql-user-dbuser-pwd: ZGJ1c2Vy # database password for "dbuser"secret mode of operation is the same as with other objects, then you can create detailed secret information display "kubectl describe secret mysql-secret" command, where "mysql-secret" is the secret name. Because the value is the base64 encoded, here only it shows the number of bytes, without showing values.
vagrant@ubuntu-xenial:/var/log$ kubectl describe secret mysql-secret
Name: mysql-secret
Namespace: default
Labels: <none>
Annotations:
Type: Opaque
Data
====
mysql-user-dbuser-name: 6 bytes
mysql-user-dbuser-pwd: 6 bytes
mysql-user-root-pwd: 4 bytesIt is noteworthy that secret but the data is encoded and not encrypted. So you can get the original value by the anti-coding, so it is not secure. If you want security, you have additional encryption for him.
Environment Variable：
Environment variable is usually defined in the deployment, there's no separate configuration file. The following is a fragment deployment configuration file in the environment variable. "MYSQL_ROOT_PASSWORD" is the environment variable name, "secretKeyRef" explained its value comes from secret, "name: mysql-secret" is the secret name, "key: mysql-user-root-pwd" is a secret in the keys, it the final value is the meaning of "MYSQL_ROOT_PASSWORD" environment variable is defined by "mysql-user-root-pwd", and "mysql-user-root-pwd" is a secret key inside.
env:
- name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-secret
key: mysql-user-root-pwdThe following is a definition of another fragment environment variable, similar to the above, except that it comes from configMap keys, instead of secret.
env:
- name: MYSQL_DATABASE
valueFrom:
configMapKeyRef:
name: mysql-config
key: db-nameDeployment file:
The following is quoted configMap and secret deployment files, the deployment file it with the previously mentioned very similar, but the sharing of data extracted out into the configMap and secret inside.
apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql-deployment
labels:
app: mysql
spec:
selector:
matchLabels:
app: mysql
strategy:
type: Recreate
template:
metadata:
labels:
app: mysql
spec:
containers:
- image: mysql:5.7
name: mysql-con
imagePullPolicy: Never
env:
- name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-secret
key: mysql-user-root-pwd
- name: MYSQL_USER_NAME
valueFrom:
secretKeyRef:
name: mysql-secret
key: mysql-user-dbuser-name
- name: MYSQL_USER_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-secret
key: mysql-user-dbuser-pwd
- name: MYSQL_DATABASE
valueFrom:
configMapKeyRef:
name: mysql-config
key: db-name
args: ["--default-authentication-plugin=mysql_native_password"]
ports:
- containerPort: 3306
name: mysql
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
volumes:
- name: mysql-persistent-storage
persistentVolumeClaim:
claimName: mysql-pv-claimindex
- Secrets
- Configure a Pod to Use a ConfigMap
Expose Pod Information to Containers Through Files
This article from the blog article multiple platforms OpenWrite release!