Through previous study, I learned that Pod is the smallest operating unit in k8s, and each container is run in the Pod, but the life cycle of the container may be very short, and it is frequently created and destroyed .

When learning docker, create a container. If the data volume of the container is not specified, the files in the container are usually stored temporarily on the disk, which brings some problems to important applications running in the container, such as the following scene:

When the container crashes and the file is lost, kubelet will restart the container, but the container will restart in a clean state, and the data previously saved in the container will also be cleared;
When running multiple containers concurrently in a Pod, it is often necessary to share files between these containers;

Based on these problems, the "volume" component appeared in k8s to solve

The abstract concept of Kubernetes volume (Volume) can solve these two problems. At the core of the volume is a directory containing some data, which can be accessed by the containers in the Pod.

2. Volume in k8s

Summary of volumes in k8s:

Volume is an object abstracted by k8s. It is defined on a Pod, and then mounted to a specific file directory by multiple containers in a Pod;
Kubernetes implements data sharing between different containers in the same Pod and persistent storage of data through Volume;
The life cycle of a Volume is not related to the life cycle of a single container in the Pod. When the container is terminated or restarted, the data in the Volume will not be lost;
K8S can support many types of volumes, and Pod can also use any number of volumes at the same time;

3. Common Volume types in k8s

There are many types of volumes provided in k8s, some commonly used types are listed below:

Conventional storage: EmptyDir, HostPath;
Advanced storage: PV, PVC;
Configuration storage: ConfigMap, Secret;
Others: network storage systems NFS, CIFS, including local and distributed ones provided by cloud service providers;

Next, for the volumes that are used more in daily business, demonstrate their use one by one through examples.

4. EmptyDir of Volume

4.1 Features of EmptyDir

When a Pod is assigned to a node, a volume is created first emptyDir, and the volume will always exist as long as the Pod runs on the node;
When the Pod is deleted from the node for some reason, emptyDirthe data in the volume will also be permanently deleted;
A container crash does not cause the Pod to be removed from the node, so emptyDirthe data in the volume is safe when the container crashes;

Usage scenario: temporary cache space to store some relay logs during operation;

4.2 EmptyDir for file sharing

As shown in the figure, our requirement is to create a Volume of type EmptyDir to share the logs of two containers;

4.2.1 About busybox

1. It is a software that integrates more than 300 most commonly used Linux commands and tools;

2. Contains simple tools, such as ls, cat and echo, etc., and also contains some more complex tools, such as grep, find, telnet, etc.;

4.3 Operation steps

The following steps are used in the case demonstration

4.3.1 Create configuration template file yaml

Create a volume-emptydir.yaml file in the current directory, and configure the following content:

    apiVersion: v1kind: Podmetadata:  name: test-volume-emptydir  namespace: defaultspec:  containers:  - name: test-nginx    image: nginx:1.20    ports:    - containerPort: 80    volumeMounts:  # 将nginx-log-volume挂在到nginx容器中，对应的目录为 /var/log/nginx    - name: test-log-volume      mountPath: /var/log/nginx   - name: test-busybox    image: busybox:1.35.0     command: ["/bin/sh","-c","tail -f /usr/local/test/access.log"] # 容器启动后初始命令，读取指定文件中内容    volumeMounts:  # 将nginx-log-volume挂在到busybox容器中，对应的目录为 /logs    - name: test-log-volume      mountPath: /usr/local/test   volumes: # 这里声明volume存储劵， name为nginx-log-volume，类型是emptyDir  - name: test-log-volume    emptyDir: {}

The key positions in the configuration are as follows:

4.3.2 Creating Pods

Use the apply command to create a pod. After the creation is successful, you can see that 2 containers are running in the pod test-volume-emptydir;

4.3.3 Access nginx to generate access logs

Random access to generate some logs in nginx

4.3.4 View container logs

Use the following command to view the access.log log generated by the container

kubectl logs -f test-volume-emptydir -n default -c test-busybox

5. HostPath of Volume

We talked about the use of EmptyDir above. I believe students after the actual operation should be able to see that the volume created by EmptyDir is a virtual path, so when it is destroyed, the data generated by the container in the pod will also be destroyed. That is, it is impossible to truly realize the persistence of data placement, so we are thinking, is it possible to do the following?

Of course it is possible, this is another kind of Volume that I will talk about next: hostPath;

5.1 Overview of hostPath

The data in emptyDir is not persisted, and will be destroyed with the end of the Pod. If it needs to be persisted to disk, choose another method;
A disk of hostPath type is a file or directory attached to the host;
Some applications need to use the internal files of docker, and then only need to hang /var/lib/docker on the local machine as the hostPath;

5.2 hostPath type

According to different usage scenarios, it can be subdivided into multiple types

Directory The given directory path must exist;
DirectoryOrCreate If the given path does not exist, an empty directory will be created there as needed;
File The corresponding file must exist on the given path;
FileOrCreate If the given path does not exist, an empty file will be created there as needed;

5.3 hostPath operation demonstration

5.3.1 Create a template configuration file

Create a configuration file named volume-hostpath.yaml in the current directory with the following content:

apiVersion: v1kind: Podmetadata:  name: hostpath-volume-test  namespace: defaultspec:  containers:  - name: test-nginx    image: nginx:1.20    ports:    - containerPort: 80    volumeMounts:  # 将nginx-log-volume挂在到nginx容器中，对应的目录为 /var/log/nginx    - name: test-log-volume      mountPath: /var/log/nginx   - name: test-busybox    image: busybox:1.35.0     command: ["/bin/sh","-c","tail -f /usr/local/test/access.log"] # 容器启动后初始命令，读取指定文件中内容    volumeMounts:  # 将nginx-log-volume挂在到busybox容器中，对应的目录为 /logs    - name: test-log-volume      mountPath: /usr/local/test   volumes: # 这里声明volume存储劵， name为test-log-volume，类型是hostPath  - name: test-log-volume    hostPath:        path: /usr/local/test        type: DirectoryOrCreate #如果给定路径不存在，将根据需要在那里创建一个空目录

The main configuration is similar to that in the emptyDir case above, and the final volumes type is changed to hostPath related parameters;

5.3.2 Use the apply command to create a pod

After the creation is successful, you can see that a Pod starting with a hostpath is generated, which contains two containers;

5.3.3 Access nginx to generate access logs

5.3.4 View container output logs

Pay attention here to use the name you defined yourself

kubectl logs -f hostpath-volume-test -n default -c test-busybox

5.3.5 View the log file of the mounted directory

The working node checks the log file of the corresponding mounting directory, logs in to the server of the working node, and you can see that the corresponding nginx log file is also in it;

5.3.6 Delete the current pod

After deleting the pod, it is found that the log files in the working node directory still exist

5.4 Comparison between emptyDir and hostPath

Through the above demonstration, let's compare the similarities and differences between emptyDir and hostPath:

Both are local storage volume methods;
emptyDir is a temporary storage space and does not provide persistence support at all;
The volume data of hostPath is persisted in the file system of the node node. Even if the pod has been deleted, the data in the volume volume still remains on the node node;

6. ConfigMap of Volume

6.1 ConfigMap requirement scenario

Many applications rely on some configuration information during their initialization or running, and most of the time, there is a need to adjust the values set by configuration parameters, and ConfigMap is a method used by Kubernetes to inject configuration data into application Pods;

6.2 Introduction to ConfigMaps

It is an API object of K8S, which is used to save [non-encrypted data] into key-value pairs, such as etcd;
It can be used as environment variables, command line parameters, etc., to decouple environment variables, configuration information and container images, and facilitate modification of application configurations;

How to use

The kubectl create configmap command creates a ConfigMap based on a directory, file, or key-value pair

For example:

kubectl create configmap NAME --from-literal=key1=value1 --from-literal=key2=value2

6.3 ConfigMap creation operation demo

6.3.1 Create using the command line

Use the following command to create a ConfigMap

kubectl create configmap test-config --from-literal=account=test --from-literal=password=123456

6.3.2 View the created configmap

kubectl get configmap test-config -o yaml

6.3.3 Create using yaml configuration file

Create a test-configmap.yaml file in the current directory. The core configuration content is as follows:

apiVersion: v1kind: ConfigMapmetadata:  name: congge-configmap  namespace: defaultdata:  info:     username:congge    password:123456

Use the apply command to execute the creation

6.3.4 View configmap details

kubectl describe cm congge-configmap -n default

6.4 ConfigMap operation demo

The above demonstrates two ways to create a configmap. How to use the configmap after it is created? To put it simply, you only need to open a pod and mount the configmap into it for use;

6.4.1 Create a pod using a configuration file

Note that the Volume inside uses the name of the configmap created in the yaml above:

apiVersion: v1kind: Podmetadata:  name: pod-configmap  namespace: defaultspec:  containers:  - name: nginx    image: nginx:1.20    volumeMounts: # configmap挂载的目录    - name: config      mountPath: /config   volumes: # 声明configmap  - name: config    configMap:      name: congge-configmap

Execute the apply command to create, and then check whether the creation is successful;

6.4.2 Verify the value configured in configmap

Enter the pod container

kubectl exec -it pod-configmap -n default – /bin/sh

Enter the mount directory/config in the configuration file to view the configuration information

7. Secret of Volume

Some configurations require encrypted storage, and ConfigMap can only be saved in plain text, so ConfigMap is not suitable;

7.1 Introduction to Secret

Secret role

Used to save sensitive information, such as passwords, secret keys, certificates, OAuth tokens and ssh keys, etc.;
There is no need to expose these sensitive data to mirrors or Pods;

No matter what kind of Volume it is, it is ultimately for Pods. For Pods, Secret can be used in one of three ways:

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;

7.2 common types of secret

The following lists several types commonly used in secret

7.2.1 dockerconfigjson

Used to store authentication information for private docker registries

7.2.2 Service Account

1. As long as the Pod interacts with the Kubernetes API, it will automatically have this type of Secret;

2. K8S is automatically created and mounted to the Pod's /run/secrets/kubernetes.io/serviceaccount directory;

7.2.3 Opaque

The encryption type is base64, which is characterized by changing plaintext to ciphertext

7.3 Using Secret Opaque

The following uses the Opaque type in Secret to illustrate. First, use a string to do the test. Simply put, it is to base64 encode the string to get a string similar to ciphertext;

7.3.1 Create a template configuration file

Create a secret.yaml configuration file in the current directory, the content is as follows, where the username and password are the ones seen in the above test:

apiVersion: v1kind: Secretmetadata:  name: my-secrettype: Opaquedata:  username: YWRtaW4=  password: MTIzNDU2

7.3.2 Use the apply command to create a secret

After the creation is successful, you can use get to view the created secret by the way;

7.3.3 Check my-secret details

Use the following command to view

kubectl get secret my-secret -o yaml

7.3.4 Create pods

Create a new pod and use the above secret. In the current directory, create a configuration file named pod-secret-volume.yaml with the following content:

apiVersion: v1kind: Podmetadata:  name: pod-secretspec:  containers:  - name: nginx    image: nginx:1.20    volumeMounts: # secret挂载    - name: congge-config      mountPath: /etc/secret  volumes:  - name: congge-config    secret:      secretName: my-secret

Use the apply command to execute and create a pod

7.3.5 View secret information

The secret information in the pod has actually been decrypted, use the following command to enter the pod

kubectl exec -it pod-secret -- /bin/sh

Check the username and password configured in the secret in the specified directory, and you can see that in the pod, the encrypted information has been decrypted;

Turn: https://blog.csdn.net/zhangcongyi420/article/details/128433221

[Cloud native kubernetes] Detailed explanation of Volume usage of k8s data storage [Transfer]

1. What is Volume