Virtual pools
Virtual pools provide a layer of abstraction between Trident storage backends and Kubernetes StorageClasses
. They allow an administrator to define aspects, such as location, performance, and protection for each backend in a common, backend-agnostic way without making a StorageClass
specify which physical backend, backend pool, or backend type to use to meet desired criteria.
Learn about virtual pools
The storage administrator can define virtual pools on any of the Trident backends in a JSON or YAML definition file.
Any aspect specified outside the virtual pools list is global to the backend and will apply to all the virtual pools, while each virtual pool might specify one or more aspects individually (overriding any backend-global aspects).
|
Most aspects are specified in backend-specific terms. Crucially, the aspect values are not exposed outside the backend's driver and are not available for matching in StorageClasses
. Instead, the administrator defines one or more labels for each virtual pool. Each label is a key:value pair, and labels might be common across unique backends. Like aspects, labels can be specified per-pool or global to the backend. Unlike aspects, which have predefined names and values, the administrator has full discretion to define label keys and values as needed. For convenience, storage administrators can define labels per virtual pool and group volumes by label.
A StorageClass
identifies which virtual pool to use by referencing the labels within a selector parameter. Virtual pool selectors support the following operators:
Operator | Example | A pool's label value must: |
---|---|---|
|
performance=premium |
Match |
|
performance!=extreme |
Not match |
|
location in (east, west) |
Be in the set of values |
|
performance notin (silver, bronze) |
Not be in the set of values |
|
protection |
Exist with any value |
|
!protection |
Not exist |