Shulou(Shulou.com)06/01 Report--

This article mainly introduces the use of Kubernetes volumes, the article is very detailed, has a certain reference value, interested friends must read it!

The life cycle of disk files in containers is relatively short, which will cause some problems in some complex container applications. 1. After the container crash, kubelet will restart the container, but these files will be lost. Second, multiple containers in pod often need to share files. Therefore, the Volume of Kubernetes should be created to solve these problems.

Background

In Docker, there is also the concept of volumes, volume is just a simple directory on disk, or volume in other containers. Lifecycles are also unmanaged, and until recently they were based on local backend storage. Docker also provides volume driver, but now it is also weak (such as the Ceph volume driver mentioned on the official website, which is no longer maintained).

Kubernetes's volume has an obvious life cycle-- consistent with the pod life cycle that uses it. As a result, the volume life cycle is longer than the container running in pod, and even if the container is restarted, the data on the volume is still preserved. Of course, when pod no longer exists, volume disappears. More importantly, Kubernetes supports multiple types of volume, and pod can use multiple types of volume at the same time.

In the internal implementation, volume is just a directory, and there may be some data in the directory that can be accessed by pod's container. How this directory is created, what storage medium its back end is based on, and what data content is in it, are determined by the specific volume type used.

To use volume,pod, you need to specify the type and content of the volume (the spec.volumes field) and the location mapped to the container (the spec.containers.volumeMounts field).

The processes in the container can see the file system made up of Docker image and volumes. Docker image is in the root of the file system architecture, and any volume is mapped on a specific path to the mirror. Volume cannot be mapped to other volume or hard-linked to another volume. Each container in the container must be blocked to specify the volume they want to map.

Volume Typ

Kubernetes supports many kinds of volume, including emptyDir, hostPath, gcePersistentDisk, awsElasticBlockStore, nfs, iscsi, flocker, glusterfs, rbd, cephfs, gitRepo, secret, persistentVolumeClaim, downwardAPI, azureFileVolume, azureDisk, vsphereVolume, Quobyte, PortworxVolume, ScaleIO.

EmptyDir

When a Pod is assigned to a Node, the emptyDir volume is created for the first time, and the volume exists as long as the Pod is running on that Node. As described in its name, it is empty when initialized. Containers in pod can fully read and write to the same file in emptyDir volume, even though volume may be mapped to a different path in each container. In any case, once the pod is removed from the Node, the data in the emptyDir volume is permanently deleted. Note: container crash does not delete pod on Node, so the data in emptyDir volume is still secure.

The usage scenarios of emptyDir volume are:

1) temporary space, such as disk-based sorting scenarios, etc.

2) recover from crash through checkpointing for a long time

By default, emptyDir volume can be stored on any back-end media-regular disk, ssd, or network storage, depending on your environment. However, you can also set the emptyDir.medium field to Memory and tell Kubernetes to map tmpfs (a RAM-based file system). Tmpfs is very fast, but be careful that it is different from disk, tmpfs will be emptied once the machine is rebooted, and writing files on tmpfs will be limited by container memory.

Pod example:

ApiVersion: v1kind: Podmetadata: name: test-pdspec: containers:-image: gcr.io/google_containers/test-webserver name: test-container volumeMounts:-mountPath: / cache name: cache-volume volumes:-name: cache-volume emptyDir: {} hostPath

HostPath volume maps files or directories in the node file system to pod. Most Pod don't need this feature, but it can be useful for certain scenarios. These scenarios include:

1) the running container needs to access the internal structure of Docker: use hostPath mapping / var/lib/docker

2) run cAdvisor in the container, using hostPath mapping / dev/cgroups

However, you should be careful when using this volume, because:

1) the same pod (such as created through podTemplate) may behave differently on different Node, because the contents of the files mapped on different nodes are different.

2) when Kubernetes adds a resource-sensitive scheduler, the resources used by hostPath will not be counted

3) only root has write permission for directories created under the host. You need to make your program run on privileged container, or change the file permissions on the host.

Pod example:

ApiVersion: v1kind: Podmetadata: name: test-pdspec: containers:-image: gcr.io/google_containers/test-webserver name: test-container volumeMounts:-mountPath: / test-pd name: test-volume volumes:-name: test-volume hostPath: # directory location on host path: / datarbd

Rbd volumes can map Rados Block Device devices to pod. When Pod is removed, the contents of the emptyDir volume are emptied. Unlike emptyDir, the contents of the rbd volume still exist, but the volume is unmounted. That is, the data on the rbd volume can be mapped again, and the data can be passed between pod.

Important: you must install the Ceph environment before using rbd volumes.

One of the features of RBD is that it can be mapped to multiple users simultaneously in a read-only manner. Unfortunately, rbd volumes can only be mapped by a schema that is already readable and writable by one user-- multiple writable users cannot be allowed to use at the same time.

Check RBD example for more details.

Cephfs

Cephfs volumes can map existing CephFS volumes to pod. Like the rbd volume, when the pod is removed, the contents of the cephfs volume still exist, but the volume is unmounted. Another difference is that CephFS can be mapped to multiple users in a read-write manner at the same time.

Check CephFS example for more details.

Use subPath

Sometimes, the same volume can be shared in a pod, making it useful for multiple purposes. The volumeMounts.subPath feature can be used to specify a subdirectory in a volume instead of directly using the root directory of the volume.

Here is an example of pod using the LAMP stack (Linux Apache Mysql PHP), which uses a shared volume. The HTML content is mapped in its HTML subdirectory, while the database is stored in its mysql directory.

ApiVersion: v1kind: Podmetadata: name: my-lamp-sitespec: containers:-name: mysql image: mysql volumeMounts:-mountPath: / var/lib/mysql name: site-data subPath: mysql-name: php image: php volumeMounts:-mountPath: / var/www/html name: site-data subPath: html volumes:-name: site-data persistentVolumeClaim: ClaimName: my-lamp-site-data resource

The storage media of emptyDir or hostPath volumes (disks, SSD, etc.) depends on the storage media of the file system where the kubelet root directory (for example, / var/lib/kubelet) resides. There is no limit on the amount of space that can be used by emptyDir or hostPath volumes, and there is no resource isolation for containers or pod.

In the future, we expect emptyDir or hostPath volumes to request a specified size of space and select a storage media type through the resource attribute.

The above is all the content of this article "what's the use of Kubernetes volumes?" Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.