Table of contents
1.2.2 Create secret based on parameters
1.2.3 How to use secret resources
2.2.2 Based on variable parameter form
Preface: Principles of Configuration Management
When you need to modify many configuration files, create a configuration resource, mount the configuration resource to each pod, and use it for the pod, so that you only need to modify the configuration resource
One: Secret
1.1 Introduction to Secret
Secret solves the problem of configuring sensitive data such as passwords, tokens, and secret keys without exposing these sensitive data to images or Pod Specs. Secret can be used as Volume or environment variable.
Secret: Save encrypted files; encrypt data and store it in Etcd, so that Pod containers can be accessed by mounting Volume
There are three optional parameters for secret:
- generic: Generic type, usually used to store password data.
- tls: This type is only used to store private keys and certificates.
- docker-registry: If you want to save the authentication information of the docker warehouse, you must use this type to create it.
Secret type:
- Service Account: Used to be referenced by service account. When the service accout is created, Kubernetes will create the corresponding secret by default. If the Pod uses serviceaccount, the corresponding secret will be automatically mounted to the /run/secrets/kubernetes.io/serviceaccount directory of the Pod.
- Opaque: Secret in base64 encoding format, used to store passwords, secret keys, etc. The original data can be obtained through base64 --decode decoding, so the security is weak.
- kubernetes.io/dockerconfigjson: used to store authentication information for private docker registries
A Pod needs to be referenced before it can use a secret. There are three ways for a Pod to use a secret:
- As a file in a volume mounted on one or more containers.
- As an environment variable for the container.
- Used by the kubelet when pulling images for pods.
Application Scenario: Credentials
Official website:
1.2 Creation and use
1.2.1 Based on file format
1. Create a username and password file
[root@master ~]# echo -n 'admin' > username.txt ##创建username文件存放用户名admin；-n:不转行输出
[root@master ~]# echo -n '123456' > password.txt ##创建password文件存放密码123456
2. View resources
[root@master ~]# kubectl create secret generic db-user-pass --from-file=username.txt --from-file=password.txt ##创以数据库形式的资源，以文件形式导入凭据存放
secret/db-user-pass created
[root@master ~]# kubectl get secret ##查看secret资源
[root@master ~]# kubectl describe secret db-user-pass
##查看资源详细信息
1.2.2 Create secret based on parameters
1. Create variable parameters, first pass the 64-bit encoding method, and convert plaintext to ciphertext
[root@master ~]# echo -n 'admin' | base64 ##基于用户名生成64位编码
YWRtaW4= ##生成的编码
[root@master ~]# echo -n '123456' | base64 ##基于密码生成64位编码
MTIzNDU2 ##生成的编码2. Write a yaml file and create a secret by quoting the ciphertext
[root@master ~]# cd demo/
[root@master demo]# vim secret.yaml
apiVersion: v1
kind: Secret ##资源格式
metadata:
name: mysecret ##资源名称
type: Opaque ##opa凭证类型
data:
username: YWRtaW4= ##复制生成的用户名编码
password: MTIzNDU2 ##复制生成的密码编码3. Create secret resources and view information
[root@master demo]# kubectl create -f secret.yaml ##创建了配置资源
secret/mysecret created
[root@master demo]# kubectl get secret
1.2.3 How to use secret resources
1. Use the variables in the secret to import into the pod
Example: reassign username and password in the secret resource above
key:username to SECRET_USERNAME
key:password to SECRET_PASSWORD
[root@master demo]# vim secret-var.yaml
apiVersion: v1
kind: Pod ##类型为pod
metadata:
name: mypod
spec:
containers:
- name: nginx ##名字为nginx
image: nginx ##镜像为nginx
env: ##环境代理
- name: SECRET_USERNAME ##username赋值给SECRET_USERNAME
valueFrom: ##值来自于谁
secretKeyRef:
name: mysecret ##值来自于mysecret资源
key: username ##资源的值：username
- name: SECRET_PASSWORD ##password 赋值给SECRET_PASSWORD
valueFrom:
secretKeyRef:
name: mysecret
key: password
[root@master demo]# kubectl apply -f secret-var.yaml ##创建资源
pod/mypod created
[root@master demo]# kubectl get pods ##查看pod资源
NAME READY STATUS RESTARTS AGE
mypod 1/1 Running 0 29s
[root@master demo]# kubectl exec -it mypod bash ##进入资源
root@mypod:/# echo $SECRET_USERNAME ##输出username变量
admin
root@mypod:/# echo $SECRET_PASSWORD ##输出PASSWORD变量
123456Enter the pod to view the value of the environment variable SECRET_PASSWORD as password
2. Mount it as a volume to a certain directory of the pod
[root@master demo]# vim secret-vol.yaml ##编写secret-vol文件
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: nginx
image: nginx
volumeMounts: ##容器卷挂载
- name: foo ##指明挂载卷的名称
mountPath: "/etc/foo" ##挂载的路径在容器中的/etc/foo
readOnly: true ##设置权限为只读模式
volumes: ##被挂载的外部资源
- name: foo ##创建挂载卷名称
secret:
secretName: mysecret ## secret资源
[root@master demo]# kubectl delete -f secret-var.yaml ##删除之前的secret资源
pod "mypod" deleted
[root@master demo]# kubectl create -f secret-vol.yaml ##创建资源
pod/mypod created
[root@master demo]# kubectl get pods ##查看资源
NAME READY STATUS RESTARTS AGE
mypod 1/1 Running 0 50s ##创建成功
[root@master ~]# kubectl exec -it mypod bash ##进入mypod资源
root@mypod:/# ls /etc/foo
password username ##挂载成功
root@mypod:/# cat /etc/foo/password
123456 ##看到password对应的值
root@mypod:/etc/foo# cat username
admin ##看到username对应的值Two: configmap
2.1 Introduction to configmap
Configmap is a resource object in k8s, which is used to save non-confidential configuration . The data can be saved in the form of key/value key-value pairs
, or in the form of files .
Function:
When we deploy services, each service has its own configuration file. If multiple services are deployed on one server: nginx, tomcat, apache, etc., then these configurations all exist on this node. If a server cannot To meet the requirements of high online concurrency, the server needs to be expanded. After the expansion, the server still needs to deploy multiple services: nginx, tomcat, and apache. The configuration of these services still needs to be managed on the newly added server. If there is a problem with one of the services, The configuration file needs to be modified, and the configuration on each physical node needs to be modified. This method certainly cannot meet the requirements of large-scale online configuration changes. Therefore, k8s introduces the Configmap resource object, which can be used as a volume and mounted to the pod to achieve unified configuration management.The main function of ConfigMap is to decouple images from configuration files so as to achieve portability and reusability of images.
Features:
Configmap is a resource in k8s, which is equivalent to a configuration file. There can be one or more Configmaps;
Configmap can be made into a Volume. After the k8s pod is started, it is mapped to the specified directory inside the container in the form of a volume; the
application in the container follows the original method Read the configuration file on the specific directory of the container;
from the perspective of the container, the configuration file is like being packaged in a specific directory inside the container, and the whole process has no intrusion on the application.
Application Scenario: Application Configuration
Restrictions on using ConfigMap:
- ConfigMap needs to be created before Pod starts;
- And only when ConfigMap and Pod are in the same namespace, can it be referenced by Pod;
- When the Pod mounts the directory bound to the ConfigMap, the directory under the directory will not be mounted into the Pod, only the files under the directory will be mounted.
Knowledge structure diagram:
2.2 Create ConfigMap
2.2.1 Based on kubectl form
[root@master demo]# vim redis.properties ##创建redis的配置文件中需要的参数文件
redis.host=127.0.0.1 ##主机地址
redis.port=6379 ##端口
redis.password=123456 ##密钥
[root@master demo]# kubectl create configmap redis-config --from-file=redis.properties ##创建configmap资源,名称为redis-config文件来自于redis.properties文件
configmap/redis-config created
[root@master demo]# kubectl get configmap ##查看资源
NAME DATA AGE
redis-config 1 69s
[root@master demo]# kubectl get cm ##缩写查看资源
NAME DATA AGE
redis-config 1 95s
[root@master demo]# kubectl describe cm redis-config ##查看参数信息
--from-file: All the files in the specified directory will be used to create a key-value pair in the ConfigMap. The name of the key is the file name, and the value is the content in the file.
Create mypod resource view file import
[root@master demo]# kubectl delete pod/mypod ##先将原先创建的mypod资源删除
pod "mypod" deleted
[root@master demo]# vim cm.yaml
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: busybox
image: busybox ##镜像为linux最小内核
command: [ "/bin/sh","-c","cat /etc/config/redis.properties" ] ##执行在pod中查看 /etc/config/redis.properties文件中的数据信息
volumeMounts:
- name: config-volume ##使用指定资源的标签
mountPath: /etc/config ##挂载点
volumes:
- name: config-volume ##指定资源标签
configMap:
name: redis-config ##指定的资源名称
restartPolicy: Never
[root@master demo]# kubectl apply -f cm.yaml ##创建资源
pod/mypod created
[root@master demo]# kubectl get pods ##查看pod资源
NAME READY STATUS RESTARTS AGE
mypod 0/1 Completed 0 25s ##执行完任务状态就为Completed
[root@master demo]# kubectl logs mypod ##查看mypod的日志信息
redis.host=127.0.0.1
redis.port=6379
redis.password=1234562.2.2 Based on variable parameter form
[root@master demo]# vim myconfig.yaml ##创建变量资源
apiVersion: v1
kind: ConfigMap
metadata:
name: myconfig
namespace: default
data:
special.level: info ##定义两个键值
special.type: hello
[root@master demo]# kubectl create -f myconfig.yaml ##创建资源
configmap/myconfig createdCreate mypod using configmap resource output variable parameters
[root@master demo]# vim config-var.yaml
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: busybox
image: busybox
command: [ "/bin/sh", "-c", "echo $(LEVEL) $(TYPE)" ] ##输出LEVEL和TYPE两个变量
env: ##定义环境变量
- name: LEVEL ##定义LEVEL变量
valueFrom: ##值来自于
configMapKeyRef: ##来自于configMap类型资源
name: myconfig ##创建的configMap的资源
key: special.level ##key来自于configMap中的special.level
- name: TYPE ##定义TYPE变量
valueFrom:
configMapKeyRef:
name: myconfig
key: special.type
restartPolicy: Never
[root@master demo]# kubectl delete pod mypod ##删除重复的名称的资源
pod "mypod" deleted
[root@master demo]# kubectl apply -f config-var.yaml ##创建mypod资源
pod/mypod created
[root@master demo]# kubectl logs mypod ##通过查看日志查看变量的输出
info helloAfter the K8s 1.6 version, a new field envFrom is introduced, so that all key:values in the ConfigMap can be automatically generated as environment variables.
The difference between env and envFrom: the former can customize the variable name, but requires repetitive operations; the latter cannot customize the variable name, but it is very convenient.
The difference between configMapKeyRef and configMapRef: the former needs to specify key and configmap, while the latter only needs to specify configMap.