Shulou(Shulou.com)05/31 Report--

How to analyze the volume clone Alpha of Kubernetes, in view of this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

What is cloning?

Many storage systems provide the "clone" function of creating volumes. A clone is a copy of an existing volume that is the only volume of its own on the system, but the data on the source is replicated to the destination (clone). A clone is similar to a snapshot in that it is a point-in-time copy of a volume, but instead of creating a new snapshot object from the volume, we create a new independent volume, which is sometimes thought of as prepopulating the newly created volume.

Why add cloning technology to Kubernetes

The Kubernetes volume plug-in system already provides a powerful abstraction that automatically provides, appends, and mounts blocks and file stores. Kubernetes v1.15 introduced alpha support for volume cloning. This feature allows you to use Kubernetes API to create new volumes using the contents of existing volumes in the user namespace.

The goal of all these features is to support portability of Kubernetes workloads: the goal of Kubernetes is to create an abstraction layer between distributed system applications and the underlying cluster, so that applications do not know the details of the cluster they are running on, and application deployment does not require specific storage device knowledge.

The Kubernetes storage SIG identifies clone operations as a key feature of many stateful workloads. For example, a database administrator might want to replicate a database volume and create another instance of an existing database.

Https://github.com/kubernetes/community/tree/master/sig-storage

By providing a standard way to trigger clone operations in Kubernetes API, Kubernetes users can now handle such use cases without having to surround the Kubernetes API (and perform storage system-specific operations manually). Although cloning behaves like creating a volume snapshot and then creating a volume from the snapshot, the clone operation is more streamlined and more efficient for many back-end devices.

Kubernetes users can now incorporate cloning operations into their tools and policies in a cluster-independent manner, and can rest assured that cloning operations can work against any Kubernetes cluster, regardless of the underlying storage.

Kubernetes API and cloning

The clone feature in Kubernetes is enabled through the PersistentVolumeClaim.DataSource field. Prior to v1.15, the only valid object type allowed to be used as a data source (dataSource) was VolumeSnapshot. The clone feature extends the allowed PersistentVolumeclaim.DataSource.Kind field to allow not only VolumeSnapshot but also PersistentVolumeClaim. The existing behavior does not change.

No new objects were introduced to enable cloning. Instead, the existing data source fields in the PersistentVolumeClaim object are extended to accept the names of existing PersistentVolumeClaim in the same namespace. It is important to note that from the user's point of view, the clone is just another PersistentVolume and PersistentVolumeClaim, and the only difference is that this PersistentVolume is populated with the contents of another PersistentVolume at creation time. Once created, it behaves exactly like any other Kubernetes PersistentVolume and follows the same behavior and rules.

Which volume plug-ins support Kubernetes cloning?

Kubernetes supports three types of volume plug-ins: in-tree, Flex, and container storage interfaces (Container Storage Interface, CSI). For more information, see Kubernetes Volume Plugin FAQ.

Https://github.com/container-storage-interface/spec/blob/master/spec.md

Https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md

Clones only support CSI drivers (not in-tree or Flex). To use the Kubernetes cloning feature, make sure that the CSI driver for cloning is deployed on the cluster. For a list of CSI drivers that currently support cloning, see the CSI driver documentation.

Https://kubernetes-csi.github.io/docs/drivers.html

Kubernetes cloning requirement

Before you can use Kubernetes volume cloning, you must:

Ensure that the CSI driver for cloning is deployed and running on the Kubernetes cluster.

Enable the Kubernetes volume clone feature through the new Kubernetes feature gate (alpha is disabled by default):

Set the following flag on the API server binaries:-- features-gates=VolumePVCDataSource=true

The source and destination declarations must be in the same namespace.

Create a clone in Kubernetes

"to prepopulate a new volume with data from an existing Kubernetes volume, use the dataSource field in PersistentVolumeClaim." There are three parameters:

Name-name of the PersistentVolumeClaim object to be used as the source

Kind-must be PersistentVolumeClaim

ApiGroup-must be ""

ApiVersion: v1kind: PersistentVolumeClaimmetadata: name: pvc-clone Namespace: demo-namespacespec: storageClassName: csi-storageclass dataSource: name: src-pvc kind: PersistentVolumeClaim apiGroup: "" accessModes:-ReadWriteOnce resources: requests: storage: 1Gi # NOTE this capacity must be specified and must be > = the capacity of the source volume

When the PersistentVolumeClaim object is created, it triggers the provisioning of a new volume that is prepopulated with data from the specified data source volume. It is the responsibility of the CSI plug-in to clone the volume.

As a storage vendor, how can I add support for cloning to my CSI driver?

For more information on how to implement cloning in the CSI plug-in, refer to the section in the CSI documentation for developing CSI drivers for Kubernetes.

Https://kubernetes-csi.github.io/docs/developing.html

What are the limitations of alpha?

The alpha implementation of cloning Kubernetes has the following limitations:

Cloning volumes across different namespaces is not supported

Cloning volumes across different storage classes (backend) is not supported

The future

Based on feedback and adoption, the Kubernetes team plans to advance the CSI cloning implementation to beta in version 1.16.

With regard to cloning, one of the questions that users often encounter is "how about cloning across namespaces?" . As mentioned earlier, the current version requires that the source and target are in the same namespace. However, efforts are under way to suggest that future versions of the namespace transfer API,Kubernetes may provide the ability to transfer volume resources from one namespace to another.

This is the answer to the question about how to analyze Kubernetes's volume clone Alpha. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

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.