This is the 14th day of my participation in Gwen Challenge
11 Containerizing configuration information
K8s provides two special types of storage volumes, configMap and Secret. In most cases, instead of providing storage space for PODS, k8S provides users with a way to inject configuration information from outside the cluster to inside the POD.
- How to container configuration information
- Customize command line parameters, such as command and args, to run the container as a feature based on the parameters passed by args
- The configuration information is made directly into the image, but this method is very inflexible, the image can only be used in one scenario, over-coupling
- Environment variables. Cloud Native supports loading configuration through environment variables, or using ENTRYPOINT scripts to preprocess environment variables into configuration information
- A storage volume, mounted at container startup, or a dedicated configuration volume, mounted to the application’s configuration file directory
- Secret Compares this parameter with ConfigMap
Similarities: - Form of key/value - Belonging to a specific namespace - Can be exported to environment variables - Can be mounted by directory/file (all keys and some keys are supported) Differences: - Secret can be associated with the ServerAccount. - Secret can store register authentication information in the ImagePullSecret parameter. Private warehouse to pull the mirror - Secret support Base64 encryption - Secret into kubernetes. IO/Service Account, kubernetes. IO/dockerconfigjson, Configmap indicates Opaque. - Secret The Secret file is stored in the TMPFS file system. After Pod is deleted, the Secret file is also deleted.Copy the code11.1 POD Obtaining Environment Variables
- Env, see: kubectl explain Pods.spec.containers.env
name <string> # variable name
value <string> # The value of the variable
valueFrom <Object> # Reference values, such as a key in configMap, and field names in POD definitions, such as metadata.labels
resourceFieldRef <Object> # reference the value in the resource limit
secretKeyRef <Object> # reference secretKey
Copy the code11.2 configMap
If we want to start a POD that needs to read different configuration information, we can do it in two ways:
- The configMap resource can be associated with the current POD, and the POD reads a data from the configMap and passes it to a variable in the POD’s internal container. Once the variable is injected, the container can be restarted.
- ConfigMap resources can be mounted to the current POD as a file system path. This directory is exactly where the application reads the configuration file. The container can read the configuration information, and when configMap changes, the POD is notified and can reload the configuration.
All configuration information in each configMap is stored as key-value configurations.
- For details, see Kubectl Explain configMap
apiVersion <string> # version number
binaryData <map[string]string> # Binary data
data <map[string]string> # Key-value pair data
kind <string> # Object type
metadata <Object> Object metadata
Copy the code- Command line interface (CLI)
Create a configMap named my-config with data from a file in the directory, key as filename, and value as file content
kubectl create configmap my-config --from-file=path/to/dir
Create a configMap named my-config with data from key-value pairs in the file
kubectl create configmap my-config --from-file=path/to/file
Create a configMap named my-config. You can also manually specify the name of the key
kubectl create configmap my-config --from-file=key1=/path/to/bar/file1.txt --from-file=key2=/path/to/bar/file2.txt
# create from a literal
kubectl create configmap my-config --from-literal=key1=config1 --from-literal=key2=config2
# Name my-config from env
kubectl create configmap my-config --from-env-file=path/to/bar.env
Copy the code11.2.1 Injecting POD ENV
- Create ConfigMap and use it in POD ENV
apiVersion: v1
kind: ConfigMap Create a ConfigMap object
metadata:
name: nginx-config
namespace: default
data:
server_name: myapp.kaliarch.com Key value pair data
nginx_port: | # key/value pair data, this is the nginx configuration file, need to pay attention to the newline
server {
server_name myapp.kaliarch.com;
listen 80;
root /data/web/html;
}
---
apiVersion: v1
kind: Pod
metadata:
name: pod-configmap-demo
namespace: default
labels:
app: myapp
tier: frontend
annotations:
kaliarch.com/created-by: "cluster amdin"
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
ports:
- name: http
containerPort: 80
env:
- name: NGINX_SERVER_PORT The container needs to use the ENTRYPOINT script at startup to convert the environment variables into the application configuration file
valueFrom: The # value comes from the configMap object
configMapKeyRef: # reference the configMap object
name: nginx-config The name of the configMap object
key: nginx_port Which key in configMap is referenced
optional: true # Relative POD startup is optional. If this value is not present in configMap, true does not block POD startup
- name: NGINX_SERVER_NAME If you use exec to enter the container, you will find that the variables are already injected into the container before starting the container.
valueFrom:
configMapKeyRef:
name: nginx-config
key: server_name
Copy the code11.2.2 Mounting a POD Volume
- Data in configMap can be mounted as files in the container, and when data in configMap changes, the files in the container also change without reloading the processes in the container.
apiVersion: v1
kind: ConfigMap # to create ConfigMap
metadata:
name: nginx-config-volumes
namespace: default
data: There are two data stores in ConfigMap.
index: | # data 1, which can be used to inject environment variables in a container using ENV, or mounted as files using volumeMounts in a container
<h1>this is a test page<h1>
vhost: | # data 2, which can either inject environment variables in a container using ENV, or mount them as files using volumeMounts in a container
server {
listen 80;
server_name localhost;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
location = /hostname.html {
alias /etc/hostname;}}server {
server_name myapp.kaliarch.com;
listen 80;
root /data/web/html;
}
---
apiVersion: v1
kind: Pod
metadata:
name: pod-configmap-volumes-demo
namespace: default
labels:
app: myapp
tier: frontend
annotations:
kaliarch.com/created-by: "cluster amdin"
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
ports:
- name: http
containerPort: 80
volumeMounts:
- name: nginx-conf
mountPath: /etc/nginx/conf.d
readOnly: true
- name: nginx-page
mountPath: /data/web/html/
readOnly: true
volumes: # define the volume
- name: nginx-conf Define the volume name
configMap: The volume type is configMap
name: nginx-config-volumes Read configMap of which name from the namespace
items: The configMap data is mapped to the file. If not, use the configMap key as the file name and the value as the file content
- key: vhost Which key to use configMap
path: www.conf Map the data in configMap to the name of the file in the container
mode: 644 # specify file permissions
- name: nginx-page
configMap:
name: nginx-config-volumes
items:
- key: index
path: index.html
mode: 644
Copy the code- After the startup, enter the container to check whether the file is properly mounted
kubectl exec -it pod-configmap-volumes-demo -c myapp -- /bin/sh
Copy the code- Run the curl command to check whether the curl command can be used normally
$curl 10.244.2.104 Hello MyApp | Version: v1 | < a href ="hostname.html">Pod Name</a>
$ curl -H "Host:myapp.kaliarch.com"10.244.2.104 < h1 > this is atest page<h1>
Copy the code11.3 secret
The configMap stores data in plaintext. If sensitive data needs to be stored, you need to use secret. Secret and The configMap store data in Base64 encoding instead of plaintext.
- Secret type
docker-registry Create a secret that Docker Registry uses
generic Create a secret from a local file, directory, or literal
tls Create a TLS secret
Copy the code- List format, see kubectl Explain Secret
apiVersion <string> # API version
data <map[string]string> The data is listed as key-value pairs. The values need to be base64 encrypted
kind <string> # Object type
metadata <Object> # metadata
stringData <map[string]string> # plaintext data
type <string> # data type
Copy the code11.3.1 Private Warehouse Authentication 1
- Start by creating secret from the command line
kubectl create secret docker-registry regsecret --docker-server=registry-vpc.cn-hangzhou.aliyuncs.com --docker-username=admin --docker-password=123456 [email protected]
Copy the code- You can save it as a file if you want
kubectl get secret regsecret -o yaml
Copy the code- When POD is created, pull the username and password used by the image from the Docker hub, kubectl explain Pods.spec imagePullSecrets field
apiVersion: v1
kind: Pod
metadata:
name: secret-file-pod
spec:
containers:
- name: mypod
image: redis
imagePullSecrets: Obtain the username and password required by the image
- name: regsecret # secret object
Copy the code11.3.2 Private Warehouse Authentication 2
- Start by creating secret from the command line
kubectl create secret docker-registry regsecret --docker-server=registry-vpc.cn-hangzhou.aliyuncs.com --docker-username=admin --docker-password=123456 [email protected]
Copy the code- Create a customized ServiceAccount object and define image pull Secrets on the ServiceAccount object
apiVersion: v1
kind: ServiceAccount
metadata:
name: admin
namespace: default
imagePullSecrets:
- name: regsecret # specified secret
Copy the code- Create POD using the specified ServiceAccount object
apiVersion: v1
kind: Pod
metadata:
name: pod-serviceaccount-demo
namespace: default
labels:
app: myapp
tier: frontend
spec:
containers:
- name: nginx
image: ikubernetes/myapp:v1
ports:
- name: http
containerPort: 80
serviceAccountName: admin Use serviceAccount to authenticate the pull image, which is more secure
Copy the code11.3.3 Creating a TLS Certificate
- It is first created from the command line
kubectl create secret tls nginx-secret --cert=tls.crt --key=tls.key
Copy the code- The data in Secret can be mounted as a file within the container and then used as a certificate file within the nginx container
apiVersion: v1
kind: Pod
metadata:
name: pod-configmap-volumes-demo
namespace: default
labels:
app: myapp
tier: frontend
annotations:
kaliarch.com/created-by: "cluster amdin"
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
ports:
- name: http
containerPort: 80
volumeMounts:
- name: nginx-conf
mountPath: /etc/nginx/secret
readOnly: true
volumes: # define the volume
- name: nginx-conf Define the volume name
configMap: # The volume type is secret
name: nginx-secret Which name secret is read from the namespace
items: Define the mapping of secret data to the file. If not, use the key in secret as the file name and the value as the file content
- key: tls.key # which key to use secret
path: www.conf Map the data in secret to the file name in the container
mode: 644 # specify file permissions
- key: tls.crt
path: index.html
mode: 644
Copy the codeother
Send your notes to: github.com/redhatxl/aw… Welcome one button three links