Component Custom Storage
Why Do Components Need Custom Storage
The previous document Component Storage Settings talked about several storage types supported by Kato by default. Different enterprises and different businesses have different storage requirements. For example, big data services require high-performance storage. Kato fulfills the needs of custom storage types. Users can install custom storage types for Kato to use, which can well solve the high-performance storage requirements that Kato’s default storage types cannot meet.
Before understanding the implementation principle of Kato custom storage type, you need to understand the dynamic storage function implemented by kubernetes through storageClass.
Kato integrates with the existing storage of the Kato platform based on kubernetes' realization of dynamic storage functions, and supports user-defined storage types for components on the Kato platform.
Creation of Custom Storage Types
The creation of a custom storage type needs to consider the different storage types, and combine the characteristics and configurations of various storage types to achieve unified resource definition. Kubernetes abstracts the resource definition of storageClass for this requirement. Kato abstracts the definition of the storage type of Kato on the basis of kubernetes. Users can customize the storage type through the Kato platform. After enabling it, a corresponding storageClass will be generated for console users. Choose to use in the storage module of the component management.
Creation of Storage
The Kato platform will detect the storageClass resource existing in the kubernetes cluster, and consider the storageClass resource object as a user-defined storage type for Kato console components to choose and use.
After the user selects the corresponding custom storage type of the storageClass type in the component storage management of the Kato console, the component needs to be restarted or upgraded to make the storage changes take effect. At this time, the Kato cluster component rbd-worker will find the corresponding storageClass according to the selected storage type, and generate the corresponding PVC according to the user’s storage requirements, and mount it to the corresponding pod instance of the component.
After the driver creates PV based on PVC, PVC and PV will form a one-to-one binding relationship. At this time, the status of PVC is bound. At this time, the instance of PVC will continue to the next step of the life cycle. Otherwise, the unbound state of pvc will prevent the normal creation of pod instances, and it will be difficult to achieve the normal operation of Kato components.
Recycling of Storage
Storage recycling occurs when the component is deleted. The storage created by the specified storageClass will be selected according to the storage recycling strategy corresponding to the storageClass whether to recycle the storage, restore the storage and keep it or do nothing when the PVC is deleted.
When adding a storage type, users can specify the corresponding storage recycling strategy by themselves. But Kato will only delete the pvc corresponding to the component when the component is deleted. The deletion of pvc means that the storage bound to the pvc will be selected according to the recycling strategy of storageClass.
How to Add Storage
For connecting Alibaba Cloud disk storage to Kato platform, please refer to Kato Platform Docking Alibaba Cloud Disk
For docking ceph block storage to Kato platform, please refer to Kato platform docking ceph-rbd block storage
Custom Storage Defect
Different storage types have different storage service support. For example, block storage, file storage, and object storage have different read and write modes. The single read and single write read and write mode can only be linked once, and cannot be shared. At present, the Kato platform is only open to use custom storage for stateful components, and custom storage types cannot be shared with other components for common use.
Storage Backup and Migration
The implementation of custom storage is completely dependent on kubernetes. When the storage is mounted, it will only be mounted to the host corresponding to the instance, not cluster sharing. The Kato platform cannot obtain the data of custom storage well and perform data backup during component backup. Therefore, the Kato platform currently skips data backup when applying backups for components that use custom storage, and only backs up the storage type used by the component.
Custom Storage Options
The Kato platform will record the storage type used by the component during application sharing and backup. When an application using a custom storage type is migrated to other clusters or installed to other clusters through shared installation, the storage type cannot be found Case. In response to this abnormal situation, the Kato platform has designed a set of logic for selecting the optimal storage type. When the corresponding storage type is not found, the Kato platform will select the most suitable storage type for the component according to the component type and storage expectations, and Kato shared storage is selected by default.
- The selection of the optimal storage type will undergo more detailed optimization iterations in the later stage, and will comprehensively consider the storage read and write characteristics, sharing characteristics, backup and recovery strategies and other related characteristics to jointly determine the correct and fastest storage type