Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Fastest and deepest Analysis of K8S 1.12 Features: Kubernetes CSI Snapshot (part I)

2025-01-17 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

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

Background

Many storage systems provide the ability to create storage volume "snapshots" (snapshot) to prevent data loss. Snapshots can replace traditional backup systems to back up and restore primary and critical data. Snapshots can back up data quickly (for example, it takes only a fraction of a second to create a GCE PD snapshot) and provide rapid recovery time objectives (RTO) and recovery point objectives (RPO). Snapshots can also be used for data replication, distribution, and migration.

Back in kubernetes 1.8, the volume snapshot system prototype was released and its implementation is located in the external-storage (https://github.com/kubernetes-incubator/external-storage) library). The prototype is based on CRD implementation, provides external controller and provisioner binary, and supports storage volumes such as GCE PD,AWS EBS,OpenStack Cinder,GlusterFS and Kubernetes hostPath.

The community storage trend of Kubernetes is to use CSI to implement storage plug-ins. This article adds snapshot support for CSI storage plug-ins. The trend for Kubernetes is to keep the core API as small as possible, so we adopted the CRD implementation and added an external snapshot controller to handle volume snapshots, and external provisioner will also be upgraded to support the creation of volume,CSI snapshot specification details from snapshots can be seen at https://github.com/container-storage-interface/spec/pull/224.

target

For the first snapshot support version in Kubernetes, we only support the CSI volumes plug-in to create snapshots on demand.

Goal 1: achieve standardized snapshot operations, support the creation, listing and deletion of snapshots and other REST API. Currently, API will be implemented using CRD (CustomResourceDefinitions).

Goal 2: implement CSI volume snapshot support. External-snapshotter will be deployed along with other external components of the CSI volume plug-in (for example, external-attacher, external-provisioner).

Goal 3: provide a convenient way to create new storage volumes from snapshots and restore existing volumes.

The following goals will not be achieved at this stage, but will be considered at a later stage.

Goal 4: provide application-consistent snapshots by providing pre/post snapshot hooks to freeze / unfreeze applications and / or unmount / mount file systems.

Goal 5: provide higher levels of management, such as backing up and restoring pod and statefulSet, and creating consistent snapshot groups.

Detailed design

In this proposal, volume snapshots are considered another storage resource managed by Kubernetes. Therefore, the snapshot API and controller follow the existing design pattern of volume management.

VolumeSnapshot

VolumeSnapshotContent

VolumeSnapshotClass

Three API, which are similar in structure to PersistentVolumeClaim and PersistentVolume and storageClass. The function of the external snapshot controller is similar to that of in-tree 's PV controller. It is also recommended that a new data source structure be added to the PersistentVolumeClaim (PVC) API to support restoring data volumes from snapshots. The API and controller design are described in detail in the following sections.

Snapshot API design

VolumeSnapshot and VolumeSnapshotContent API are modeled and designed after PersistentVolumeClaim and PersistentVolume. In the first release, the VolumeSnapshot life cycle was completely independent of its source (PVC). When you delete PVC / PV, the corresponding VolumeSnapshot and VolumeSnapshotContent objects continue to exist. However, for some volume plug-ins, snapshots depend on their storage volumes. In future releases, we plan to do complete lifecycle management to better handle the relationship between snapshots and their volumes. "(for example, add a finalizer to prevent the storage volume from being deleted when there is a snapshot dependent on the storage volume."

VolumeSnapshot object

VolumeSnapshotContent object

VolumeSnapshotClass object

Instead of reusing existing StorageClass, we will add a new API object, VolumeSnapshotClass, to avoid mixing parameters between snapshot and volume. Each CSI volume plug-in can have its own default VolumeSnapshotClass. If no VolumeSnapshotClass is provided, the default value is used. VolumeSnapshotClass adds new parameters to the snapshot.

Key points of Snapshot Controller Design

As shown in the following figure, the CSI snapshot controller architecture consists of external-snapshotter (external snapshots), and external-snapshotter communicates with the out-of-tree CSI volume plug-in through sockets (/ run / csi / socket by default, which can be configured by-csi-address). External-snapshotter is part of Kubernetes's implementation of Container Storage Interface (CSI). It is an external controller that monitors VolumeSnapshot and VolumeSnapshotContent objects and creates / deletes snapshots.

Usually external-snapshotter uses ControllerGetCapabilities to verify that the CSI driver supports CREATE_DELETE_SNAPSHOT calls.

External-snapshotter is responsible for creating / deleting snapshots and binding VolumeSnapshot and VolumeSnapshotContent objects. It follows the kubernetes controller pattern and uses informer to monitor VolumeSnapshot and VolumeSnapshotContent create / update / delete events. Filter out non-conforming VolumeSnapshot instances by Snapshotter = = and handle these events using a work queue with exponential Backoff.

For a dynamically created snapshot, it should be associated with a VolumeSnapshotClass. You can explicitly specify VolumeSnapshotClass in the VolumeSnapshot API object. If the user does not specify a VolumeSnapshotClass, the default VolumeSnapshotClass created by admin is used. This is similar to using the default StorageClass to configure PersistentVolumeClaim.

For statically bound snapshots, user/admin must correctly specify two-way pointers for VolumeSnapshot and VolumeSnapshotContent so that the controller knows how to bind them. Otherwise, if the VolumeSnapshot points to a VolumeSnapshotContent that does not exist, or if the VolumeSnapshotContent does not point to the VolumeSnapshot, the VolumeSnapshot is set to the error state.

For each CSI volume plug-in, external-snapshotter, external-attacher, and external-provisioner run in the same sidecar.

In the current design, a retry will not be performed in the controller when the storage system cannot create a snapshot. This is because when the time when the snapshot is created is important, the user may not want to retry when taking a consistent snapshot or scheduling a snapshot. In future releases, the maxRetries flag or retry termination timestamp will be added to allow users to control whether retries are needed.

For related services, please visit: https://support.huaweicloud.com/cce/index.html?utm_content=cce_helpcenter_2019

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.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report