The author | KanJunBao Ali cloud technology experts

Introduction: This article will discuss the new opportunities and challenges of cloud native storage technology from the aspects of the concept, characteristics, requirements, principles, use and cases of cloud native storage service. This is the second article in a series that covers container storage concepts. Please join us in the comments section.

Related articles recommended:

Cloud native storage: the cornerstone of cloud native applications Cloud native storage: container storage and K8s storage volumes

Two key areas of cloud native storage: Docker storage volume, K8s storage volume;

  • Docker storage volume: a storage organization form of container service in a single node, focusing on data storage and related technologies of container operation;
  • K8s storage volume: focuses on storage orchestration of container clusters and storage services from the perspective of applications using storage.

Docker storage

One of the advantages of container services’ popularity is the organization of container images when they are run. Container By using the container image technology, multiple containers on the same node share an image resource (more specifically, share an image layer), avoiding the need to copy and load the image file every time the container is started. This method not only saves the storage space of the host, but also improves the startup efficiency of the container.

1. Container read/write layer

In order to improve the efficiency of node storage, containers not only share image resources among different containers, but also share data among different mirrors. The realization principle of shared mirror data is as follows: An image is composed by layers. That is, a complete image contains multiple data layers, and each layer of data is overlaid to form a complete image.

To enable mirroring data to be shared between multiple containers, each layer of the container image is read-only. In practice, we know that when using an image to start a container, you can actually read and write in the container. How does this work?

When a container uses images, a read and write layer is added on top of multiple image layers. At runtime, a read-write layer is mounted on the top layer of each container based on the current image. All user operations against the container are performed in the read-write layer. Once the container is destroyed, the read-write layer is also destroyed.

As shown in the example above, there are three containers on a node, each running on two images.

The image storage layer is described as follows:

This node contains six mirroring layers: Layer 1 to Layer 6.

  • Image 1 consists of Layer 1, 3, 4 and 5.
  • Image 2 consists of layers 2, 3, 5, and 6.

Therefore, the two mirrors share Layer 3 and Layer 5.

Container storage instructions:

  • Container 1: Starts with image 1
  • Container 2: Starts with image 1
  • Container 3: Starts with image 2

Containers 1 and 2 share image 1, and each container has its own writable layer; Container 1 (2) and container 3 share image 2 layers (Layer3, 5);

The preceding example shows that data sharing by hierarchical container images can greatly reduce the resource requirements of container services on host storage.

The structure of container read and write layer is given above, and the principle of read and write is as follows:

For read: the container is composed of so many layers of data. When the data of different layers is repeated, the principle of reading is that the data of the upper layer overwrites the data of the lower layer. For write: When a container changes a file, it does so in the uppermost read/write layer. The main implementation technologies are: write copy, time configuration.

1) Copy while writing

Copy-on-write (CoW: copy-on-write) indicates that replication is performed only when data needs to be written. It is used for modifying existing files. CoW technology allows all containers to share the file system of the image, and all data is read from the image. Only when a file is written, the file to be written is copied from the image to the uppermost read/write layer for modification. So no matter how many containers are sharing the same image, the write operation is copied from the image on the copy, do not modify the image of the source files, and multiple containers use the same file, can be in each container file system to generate a copy, each container is its own copy of the modified, isolated, They don’t affect each other.

2) Time configuration

Time allocation: In a scenario where there is no file in the mirror, space is allocated only when a new file is written to improve storage resource utilization. For example, starting a container does not preallocate some disk space for the container, but allocates new space as needed when new files are written.

2. Storage drivers

Storage driver refers to how to manage the data at each layer of a container to achieve the above shared, read and write effect. That is, the container storage driver realizes the storage and management of the container read/write layer data. Common storage drivers:

  • AUFS
  • OverlayFS
  • Devicemapper
  • Btrfs
  • ZFS

Using AUFS as an example, let’s talk about how the storage driver works:

AUFS is a joint file system (UFS) that is a file-level storage driver.

AUFS is a layered file system that transparently superimposes one or more existing file systems, combining multiple file systems into a single layer representation. That is, different directories can be mounted to the same virtual file system. Files can be modified layer by layer, the bottom layer is read-only, only the top layer of the file system is writable. When a file needs to be modified, AUFS creates a copy of the file, uses CoW to copy the file from the read-only layer to the writable layer for modification, and the result is also stored in the writable layer. In Docker, the bottom read-only layer is the Image, and the writable layer is the Container runtime.

Other kinds of storage drivers are not detailed here, interested students can go to the online information.

3. Introduction to Docker data volumes

Applications in a container read/write data at the read/write layer. The image layer and the read/write layer map to the internal file system of the container and the underlying architecture responsible for storage inside the container. When we need internal container applications to interact with external storage, we need an external storage similar to computer USB flash drive, container data volume provides this function.

On the other hand: the data stored in the container itself is temporary storage and will be deleted when the container is destroyed. By mounting external storage to container file systems through data volumes, applications can reference external data or persist their own data into data volumes. Therefore, container data volumes are the implementation method for container data persistence.

Container storage composition: read-only layer (container image) + read/write layer + external storage (data volume)Copy the code

Container data volumes are classified into standalone data volumes and cluster data volumes. Single-node data volume refers to the data volume mounting capability of container services on a node. Docker Volume is the representative implementation of single-node data volume. Cluster data volume focuses on the data volume orchestration capability at the cluster level, and K8s data volume is the main application mode of cluster data volume.

Docker Volume is a directory that can be used by multiple containers, bypassing UFS and containing the following features:

  • Data volumes can be shared and reused between containers;
  • Compared with the storage-driven writable layer, data volume reads and writes directly to external storage, which is more efficient.
  • Data volume update is external storage read/write, does not affect the image and container read/write layer.
  • Data volumes can persist until no container is available to use them.

1) Docker data volume type

Bind: mount the host directory/file directly into the container.

  • You need to use the absolute path on the host, and can automatically create a host directory.
  • Containers can modify any file in the mount directory, which makes applications more convenient, but also brings security risks.

Volume: This mode is used when a third-party data Volume is used.

  • Volume command: docker Volume (create/rm);
  • Docker is a function provided by Docker, so it cannot be used in a non-Docker environment;
  • It is divided into named data volume and anonymous data volume, whose implementation is the same, the difference is that the name of anonymous data volume is random code;
  • Supports data volume-driven expansion, enabling access of more external storage types.

Tmpfs: non-persistent volume type, stored in memory.

Data is easily lost.

2) Bind mount syntax

-v: SRC: DST: OPTS supports only standalone versions.

  • Src: indicates the volume mapping source, host directory or file. The value must be an absolute address.
  • Dst: the target mount address in the container.
  • Opts: Optional, mount properties: RO, consistent, delegated, cached, Z, Z.
  • Consistent, delegated, cached: Configure shared transmission attributes for MAC systems.
  • Z, Z: Selinux label for the host directory.

Example:

$ docker run -d --name devtest -v /home:/data:ro,rslave nginx
$ docker run -d --name devtest --mount type=bind.source=/home,target=/data,readonly.bind-propagation=rslave nginx
$ docker run -d --name devtest -v /home:/data:z nginx
Copy the code

3) Syntax of Volume mount mode

-v: SRC: DST: OPTS supports only standalone versions.

  • Src: indicates the volume mapping source. The data volume name is empty.
  • Dst: the destination directory in the container.
  • Opts: Optional. Mount property: ro (read-only).

Example:

$ docker run -d --name devtest -v myvol:/app:ro nginx
$ docker run -d --name devtest --mount source=myvol2,target=/app,readonly nginx
Copy the code

4. Docker data volume usage

Docker data volume usage:

1) Volume type

  • Docker run — d -v /data3 nginx;
  • The /var/lib/docker/volumes/{volume-id}/_data directory is created on the host by default.
  • Docker run — d -v nas1:/data3 nginx;
  • If the NAS1 volume is not currently found, a volume of the default type (local) is created.

2) Bind

Docker run -d -v /test:/data nginx If there is no /test directory on the host, this directory is created by default.

3) Data volume container

A data volume container is a running container. Other containers can inherit mounted data volumes from this container, so all mount of this container is represented in the reference container.

Docker run -d –volumes-from nginx1 -v /test1:/data1 Nginx inherited all the data volumes from the configuration container.

4) Mounting and propagation of data volumes

Docker Volume supports mount Propagation.

  • Private: Mounts are not propagated. Mounts in the source directory and destination directory are not displayed on the other side.
  • Shared: The mount is propagated between the source and destination.
  • Slave: The mount of the source object can be propagated to the destination object, but not vice versa.
  • Rprivate: recursive Private, default;
  • Rshared: recursive Shared;
  • Rslave: recursive Slave.

Example:

$docker run -- d -v /home:/data:shared nginx: $docker run -- d -v /home:/data:shared $docker run -- d -v /home:/data:slave nginx $docker run -- d -v /home:/data:slaveCopy the code

5) Visibility of mounting data volumes

Volume Mount visibility:

  • Local empty directory, mirror empty directory: no special processing.
  • Local empty directory, mirror non-empty directory: The contents of the mirror directory are copied to the host. (Copy, not map; The contents are saved even if the container deletes them);
  • Local non-empty directory, mirror empty directory: the contents of the local directory are mapped to containers.
  • Local non-empty directory, mirror non-empty directory: The contents of the local directory are mapped to the container, and the contents of the container directory are hidden.

Bind Mount visibility: Based on the host directory.

  • Local empty directory, mirror empty directory: no special processing.
  • Local empty directory, mirror non-empty directory: the container directory becomes empty.
  • Local non-empty directory, mirror empty directory: the contents of the local directory are mapped to containers.
  • Local non-empty directory, mirror non-empty directory: The contents of the local directory are mapped to the container, and the contents of the container directory are hidden.

Docker data volume plug-in

Docker data volumes implement a way to mount container external storage to the container file system. In order to expand the container’s requirements for external storage types, Docker proposed to mount different types of storage services through storage plug-ins. The Volume Driver is a storage plug-in for each storage type.

  • Multiple storage plug-ins can be deployed on a single node.
  • A storage plug-in is responsible for mounting services for a storage type.

The Docker Daemon communicates with Volume driver in the following ways:

  • Sock files: Linux is installed in /run/docker/plugins
  • Spec file: / etc/docker/plugins/subsequent acquisition. The class definition
  • Json file: / usr/lib/docker/plugins/infinit. Json definition

Implementation interface:

Create, Remove, Mount, Path, Umount, Get, List, Capabilities;

Example:

$ docker volume create --driver nas -o diskid="" -o host="10.46.225.247"-o path = "/ nas1" -o mode="" --name nas1
Copy the code

Docker VolumeDriver Docker VolumeDriver is suitable for data Volume management in single-machine container environment or swarm platform. With the popularity of K8s, there are fewer and fewer scenarios for using VolumeDriver. Docs.docker.com/engine/exte…

K8s storage volume

1. Basic concepts

According to the previous description, in order to implement the container data persistence we need to use the data volume function, in K8s orchestration system how to define the storage for the running payload (Pod)? K8s is a container orchestration system, which focuses on the management and deployment of container applications in the whole cluster. Therefore, the K8s application storage needs to be considered from the perspective of the cluster. The K8s storage volume defines the relationship between applications and storage in the K8s system. It contains the following concepts:

1) Volume Data Volume

The data volume defines the details of the external storage and is embedded in the Pod as part of the Pod. Its essence is a record object stored externally in the K8s system, when the load needs to use external storage, from the data volume to check the relevant information and storage mount operation.

  • The Pod life cycle is the same as Pod, that is, when Pod is deleted, the data volume also disappears (note that it is not deleted).
  • The storage details are defined in the choreographer template, and the choreographer awareness is applied to store the details.
  • Multiple volumes can be defined in a payload (Pod), which can be of the same type or different types of storage.
  • Each Pod Container can reference one or more volumes, and different Containers can use the same volume at the same time.

K8S Volume Common types:

  • Local storage: For example, HostPath and emptyDir, data of these storage volumes is stored on specific nodes of the cluster and cannot be used when the node is down.
  • Network storage: Ceph, Glusterfs, NFS, and Iscsi. Data on these volumes is stored on remote storage services instead of on a node in a cluster. To use a volume, you need to mount the storage services to a local host.
  • Secret/ConfigMap: The data of these storage volumes is information about objects in the cluster and does not belong to a node. The object data is mounted to the node as a volume for application use.
  • CSI/Flexvolume: These two data volume expansion methods can be regarded as abstract data volume types. Each extension can be further refined into a different storage type;
  • PVC: A data volume definition method that abstracts a data volume into a POD independent object. The storage information of this object definition (association) is the real storage information corresponding to the storage volume for K8s load mount.

The following are some examples of volume templates:

volumes:
  - name: hostpath
    hostPath:
      path: /data
      type: Directory
---
  volumes:
  - name: disk-ssd
    persistentVolumeClaim:
      claimName: disk-ssd-web-0
  - name: default-token-krggw
    secret:
      defaultMode: 420
      secretName: default-token-krggw
---
  volumes:
    - name: "oss1"
      flexVolume:
        driver: "alicloud/oss"
        options:
          bucket: "docker"
          url: "oss-cn-hangzhou.aliyuncs.com"
Copy the code

2) PVC and PV

  • K8s storage volume is a cluster-level concept, and its object scope is the entire K8s cluster, not just a node.
  • The K8s storage volume contains objects (PVC, PV, SC) that are independent of the application payload (Pod) and associated with the choreographer template.
  • The K8s storage volume can have its own independent life cycle that is not attached to a Pod.

PVC PersistentVolumeClaim PVC is an abstract storage volume type in K8s and represents a volume representation of data stored for a specific type. The design intention is: storage and application choreography are separated, storage details are abstracted out and storage choreography (storage volume) is implemented. In this way, the storage volume object in K8s exists independently of the application orchestration, which decouples the application and storage at the orchestration level.

PV PersistentVolume PV represents a volume of a specific storage type in K8s. The specific storage type and volume parameters are defined in the object. That is, all information about the target storage service is stored in the PV. The K8s uses the storage information in the PV to mount the storage service.

The relationship between application load, PVC, and PV is as follows:

From the point of view of implementation, as long as there is PV can realize the separation of storage and application choreography, but also can realize the mount of data volume, why use PVC + PV two objects? K8s is designed to perform secondary abstraction of storage volumes from the perspective of application. PV describes specific storage types and requires defining detailed storage information. However, users at the application layer do not want to know too much about the underlying details when consuming storage services. Therefore, it is not friendly for the application orchestration layer to define specific storage services. At this time, the storage service is abstracted again, only the user relationship parameters are extracted, and the PVCS are used to abstract the lower level PV. Therefore, PVC and PV focus on different objects. PVC focuses on users’ storage needs and provides users with a unified storage definition method. PV focuses on the details of storage, which can define specific storage types and detailed parameters used for storage mount.

When used, the application layer declares a storage requirement (PVC), and K8s selects and binds a PV that meets the PVC requirement in a best match manner. So PVC is technically the storage object required by the application, which belongs to the application scope (and the application is in a noun space); PV is a storage object of the storage plane and belongs to the entire storage domain (not a noun space).

Some properties of PVC and PV are given below:

  • PVC and PV always come in pairs, PVC must be bound to PV before it can be consumed by application (Pod);
  • PVC and PV are one-to-one bound. There is no case where one PV is bound by multiple PVCS or one PVC is bound by multiple PVS.
  • PVC is the storage concept of the application layer, which belongs to the specific noun space.
  • PV is a storage concept at the storage level. It is clustered and does not belong to a noun space. PV is often managed by specialized storage operation and maintenance personnel;
  • Consumption relation: Pod consumes PVC, PVC consumes PV, and PV defines the specific storage medium.

3) Detailed definition of PVC

The templates defined by PVC are as follows:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: disk-ssd-web-0
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  storageClassName: alicloud-disk-available
  volumeMode: Filesystem
Copy the code

Storage interfaces defined by PVC include read/write mode, resource capacity, and volume mode. The main parameters are described as follows:

AccessModes: storage volume accessModes, including ReadWriteOnce, ReadWriteMany, and ReadOnlyMany.

  • ReadWriteOnce: PVC can only be consumed by one POD simultaneously in read/write mode.
  • ReadWriteMany can be consumed by multiple pods simultaneously in read/write mode;
  • ReadOnlyMany indicates that multiple pods can be consumed in read-only mode at the same time.

Note: The access mode defined here is only a declaration at the choreography level. It is up to the storage plug-in implementation to determine whether the application is readable or writable when reading or writing storage files.

Storage: Defines the storage capacity this PVC object is expected to provide. Again, the data size here is only the value declared by the choreographer. The storage capacity depends on the underlying storage service type.

VolumeMode: indicates the mounting mode of a storage volume. FileSystem and Block are supported.

FileSystem: mounts a data volume to a FileSystem for use. Block: Attaching a data volume to a Block device for use.

4) PV detailed definition

The following is an example of arranging PV objects for cloud disk data volumes:

apiVersion: v1
kind: PersistentVolume
metadata:
  labels:
    failure-domain.beta.kubernetes.io/region: cn-shenzhen
    failure-domain.beta.kubernetes.io/zone: cn-shenzhen-e
  name: d-wz9g2j5qbo37r2lamkg4
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 30Gi
  flexVolume:
    driver: alicloud/disk
    fsType: ext4
    options:
      VolumeId: d-wz9g2j5qbo37r2lamkg4
  persistentVolumeReclaimPolicy: Delete
  storageClassName: alicloud-disk-available
  volumeMode: Filesystem
Copy the code
  • AccessModes: storage volume accessModes, including ReadWriteOnce, ReadWriteMany, and ReadOnlyMany. The specific meaning is the same as the PVC field;
  • Capacity: defines the capacity of a storage volume.
  • PersistentVolumeReclaimPolicy: define recycling strategies that how to deal with PV; remove PVC Delete and Retain are supported. This parameter is described in the dynamic data volume section.
  • StorageClassName: indicates the name of the storage class used by the storage volume. This parameter is described in the dynamic data volume section.
  • VolumeMode: same as the definition of volumeMode in PVC;
  • Flexvolume: Indicates a specific storage type. Flexvolume is an abstract storage type, and the specific storage type and storage parameters are defined in the subconfiguration items of Flexvolume.

5) PVC/PV binding

PVC can only be used by Pod after it is bound to PV, and the process of PVC binding PV is the process of PV consumption. This process has certain rules, and PV that meets the following rules can only be bound by PVC:

  • VolumeMode: VolumeMode of the consumed PV needs to be consistent with PVC;
  • AccessMode: The AccessMode of the consumed PV must be the same as that of the PVC.
  • StorageClassName: If PVC defines this parameter, PV must have related parameter definition before binding.
  • LabelSelector: Selects the appropriate PV binding from the PV list by label matching;
  • Storage: A PV can be bound only when the capacity of the consumed PV is greater than or equal to the storage capacity requirement of the PVC.

PVS that meet all of the above requirements can be bound by PVC.

If multiple PVS meet the requirements at the same time, select a more suitable ONE from the PVS for binding. Usually, select the one with the smallest capacity. If there are more than one with the smallest capacity, select it randomly. If there is no PV storage that meets the above requirements, the PVC will be in the Pending state, waiting for a suitable PV to appear before binding.

2. Static and dynamic storage volumes

From the discussion above, we know that PVC is a secondary abstraction of storage for application services, with a concise storage definition interface. PV is a storage abstraction with complicated storage details. It is generally defined and maintained by a dedicated cluster manager.

Based on the PV creation method, storage volumes can be divided into dynamic storage and static storage:

  • Static storage volume: PV created by an administrator
  • Dynamic storage volume: PV created by the Provisioner plug-in

1) Static storage volume

The cluster administrator analyzes the storage requirements of the cluster, allocates some storage media in advance, and creates PV objects. The CREATED PV objects are consumed by the PVC. If a PVC requirement is defined in the load, K8s will bind the PVC to the matching PV through relevant rules, thus enabling the application to access the storage service.

2) Dynamic storage volume

The cluster administrator configures the back-end storage pool and creates the corresponding template (Storageclass). When PVC needs to consume PV, the storage details of storageclass are referred to according to the requirements defined by PVC. Dynamically create a PV from the Provisioner plug-in.

Comparison of the two volumes:

  • The final effect of dynamic storage volume and static storage volume is Pod -> PVC -> PV link, and the object template definition is the same.
  • The difference between a dynamic volume and a static volume is that a dynamic volume is automatically created by a plug-in while a static volume is manually created by a cluster administrator.

Provides the advantages of dynamic storage volumes:

  • Dynamic volume enables K8s to implement automatic PV lifecycle management. PV creation and deletion are completed through Provisioner;
  • Automatic PV object creation reduces configuration complexity and system administrator workload.
  • The dynamic volume ensures that the storage capacity required by the PVC is consistent with the PV capacity provided by the Provision, optimizing the storage capacity planning.

3) Dynamic volume implementation process

When the user declares a PVC, if the StorageClassName field is added to the PVC, it means: When the PVC cannot find a matching PV in the cluster, the corresponding Provisioner plug-in is triggered to create an appropriate PV for binding according to the StorageClassName definition, that is, to create a dynamic data volume. Dynamic data volumes are created by the Provisioner plug-in and are associated with the PVC through the StorageClassName.

StorageClass can be translated into a StorageClass, representing a template for creating PV storage volumes. When the PVC triggers automatic PV creation, the content of the StorageClass object is used to create the PV. This includes: target Provisioner name, detailed parameters for creating PV, reclaim mode, and configuration.

The StorageClasss template is defined as follows:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: alicloud-disk-topology
parameters:
  type: cloud_ssd
provisioner: diskplugin.csi.alibabacloud.com
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer
Copy the code
  • Provisioner: The name of a registered plug-in that implements the functionality of creating a PV; A StorageClass can define only one Provisioner;
  • Parameters: indicates the specific parameters for creating a data volume. For example, create an SSD cloud disk.
  • ReclaimPolicy: used to specify to create PV persistentVolumeReclaimPolicy field values, supports the Delete/Retain; Delete indicates that a DYNAMICALLY created PV is automatically destroyed when it is destroyed. Retain represents a dynamically created PV that is not automatically destroyed and is handled by the administrator.
  • AllowVolumeExpansion: defines whether the PVS created by this storage class run dynamic expansion. The default value is false. Whether the dynamic capacity expansion is realized by the underlying storage plug-in, here is just a switch;
  • VolumeBindingMode: say dynamic creation of PV time, support the Immediate/WaitForFirstConsumer; Indicates immediate creation and delayed creation respectively.

When a user creates a PVC declaration, it looks for an appropriate PV to bind to in the cluster. If there is no suitable PV to bind to, the following process is triggered:

  • The Volume Provisioner will watch the existence of the PVC if the PVC defines the StorageClassName and the StorageClass object defines its own Provisioner plug-in. Provisioner triggers the process of creating the PV;
  • Provisioner Performs PV creation based on the Parameters defined by the PVC (Size, VolumeMode, and AccessModes) and the Parameters defined by the StorageClass (ReclaimPolicy, Parameters);
  • Provisioner creates the data volume on the storage side (through API calls, or otherwise) and creates the PV object when it is finished;
  • After PV is created, it is bound to PVC. To meet the subsequent Pod startup process.

4) Delay binding dynamic data volumes

A certain type of storage (Ali Cloud disk) has restrictions on the mount properties. Data volumes and Node nodes can only be mounted in the same availability zone, but cannot be mounted in different availability zones. This type of storage volume usually encounters the following problems:

  • A data volume is created in the availability zone A, but the node resources in the availability zone A are exhausted, resulting in the failure of Pod startup to complete mount.
  • When planning PVCS and PVS, the cluster administrator cannot determine which available areas to create multiple PVS for backup.

The volumeBindingMode field in StorageClass is used to solve this problem. If the volumeBindingMode is set to WaitForFirstConsumer, The Provisioner does not immediately create the data volume when it receives the PVC Pending, but waits for the PVC to be consumed by the Pod before executing the create process.

Its realization principle is as follows:

  • Provisioner does not immediately create a data volume when it receives the PVC Pending state, but waits for the PVC to be consumed by the Pod.
  • If a Pod consumes this PVC and the scheduler finds that the PVC is delayed binding, pv continues to complete the scheduling function (more on storage scheduling later); And the scheduler will patch the scheduling results into the PVC metadata;
  • If the Provisioner discovers that scheduling information is written to the Provisioner PVC, it obtains the location information (zone, Node) for creating the target data volume based on the scheduling information and triggers the PV creation process.

As can be seen from the above process, delayed binding allows the application load to be scheduled (to ensure that sufficient resources are available for POD use), and then triggers the creation process of dynamic volumes. In this way, the problem of no resources in the available area of data volumes and inaccurate storage planning are avoided.

In a multi-availability zone cluster environment, the deferred binding dynamic volume solution is recommended. The Aliyun ACK cluster already supports the preceding configuration solution.

3. Example

The following is an example of PVC and PV consumption by POD:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nas-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi
  selector:
    matchLabels:
      alicloud-pvname: nas-csi-pv
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nas-csi-pv
  labels:
    alicloud-pvname: nas-csi-pv
spec:
  capacity:
    storage: 50Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  flexVolume:
    driver: "alicloud/nas"
    options:
      server: "***-42ad.cn-shenzhen.extreme.nas.aliyuncs.com"
      path: "/share/nas"--- apiVersion: apps/v1 kind: Deployment metadata: name: deployment-nas labels: app: nginx spec: selector: matchLabels: App: nginx template: metadata: labels: app: nginx spec: containers: -name: nginx1 image: nginx: 1.8-name: Nginx2 image: nginx:1.7.9 volumeMounts: -name: NAS-PVC mountPath: nginx2 image: nginx:1.7.9 volumeMounts: -name: NAS-PVC mountPath:"/data"
      volumes:
        - name: nas-pvc
          persistentVolumeClaim:
            claimName: nas-pvc
Copy the code

Template parsing:

  • This application is an Nginx service orchestrated in Deployment mode. Each POD contains 2 containers: nginx1 and nginX2.
  • The Volumes field defined in the template indicates that you want to mount data Volumes to applications. In this example, PVC is used to define data Volumes.
  • Internal application: mount data volume NAS-PVC to /data directory of nginx2 container; Nginx1 container is not mounted;
  • PVC (NAS-PVC) is defined as a storage volume with a capacity of not less than 50 GB and the read/write mode of the volume is ReadWriteOnce. It requires PVCS to be labeled.
  • A NS-CSI-PV (PV) is defined as a storage volume with a capacity of 50 GB, read/write mode of ReadWriteOnce, reclaim mode of Retain, abstract type of Flexvolume, and Label configuration.

According to the binding logic of PVC and PV, if the PV meets PVC consumption requirements, the PVC will be bound with the PV and used for POD mounting.

conclusion

This article describes in detail the overall appearance of container storage, including Docker data volumes in the range of standalone and clustered K8s data volumes. K8s data volume pays more attention to the storage choreography capability at the cluster level, and also realizes the specific data volume mounting process on the node. In order to achieve the above complex storage volume orchestration capability, K8s has a complex implementation architecture. The next section will introduce the storage architecture and implementation process of K8s.

Course recommended

In order for more developers to enjoy the dividends brought by Serverless, this time, we gathered 10+ Technical experts in the field of Serverless from Alibaba to create the most suitable Serverless open course for developers to learn and use immediately. Easily embrace the new paradigm of cloud computing – Serverless.

Click to free courses: developer.aliyun.com/learning/ro…

“Alibaba Cloud originator focuses on micro-service, Serverless, container, Service Mesh and other technical fields, focuses on the trend of cloud native popular technology, large-scale implementation of cloud native practice, and becomes the public account that most understands cloud native developers.”