[1.22] Volume populators redesign #1495
Add dataSourceRef documentation
This commit is contained in:
		
							parent
							
								
									2923e6ba56
								
							
						
					
					
						commit
						2fd8c1435a
					
				|  | @ -785,6 +785,82 @@ spec: | ||||||
|       storage: 10Gi |       storage: 10Gi | ||||||
| ``` | ``` | ||||||
| 
 | 
 | ||||||
|  | ## Volume populators and data sources | ||||||
|  | 
 | ||||||
|  | {{< feature-state for_k8s_version="v1.22" state="alpha" >}} | ||||||
|  | 
 | ||||||
|  | {{< note >}} | ||||||
|  | Kubernetes supports custom volume populators; this alpha feature was introduced | ||||||
|  | in Kubernetes 1.18. Kubernetes 1.22 reimplemented the mechanism with a redesigned API. | ||||||
|  | Check that you are reading the version of the Kubernetes documentation that matches your | ||||||
|  | cluster. {{% version-check %}} | ||||||
|  | To use custom volume populators, you must enable the `AnyVolumeDataSource` | ||||||
|  | [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for | ||||||
|  | the kube-apiserver and kube-controller-manager. | ||||||
|  | {{< /note >}} | ||||||
|  | 
 | ||||||
|  | Volume populators take advantage of a PVC spec field called `dataSourceRef`. Unlike the | ||||||
|  | `dataSource` field, which can only contain either a reference to another PersistentVolumeClaim | ||||||
|  | or to a VolumeSnapshot, the `dataSourceRef` field can contain a reference to any object in the | ||||||
|  | same namespace, except for core objects other than PVCs. For clusters that have the feature | ||||||
|  | gate enabled, use of the `dataSourceRef` is preferred over `dataSource`. | ||||||
|  | 
 | ||||||
|  | ## Data source references | ||||||
|  | 
 | ||||||
|  | The `dataSourceRef` field behaves almost the same as the `dataSource` field. If either one is | ||||||
|  | specified while the other is not, the API server will give both fields the same value. Neither | ||||||
|  | field can be changed after creation, and attempting to specify different values for the two | ||||||
|  | fields will result in a validation error. Therefore the two fields will always have the same | ||||||
|  | contents. | ||||||
|  | 
 | ||||||
|  | There are two differences between the `dataSourceRef` field and the `dataSource` field that | ||||||
|  | users should be aware of: | ||||||
|  | * The `dataSource` field ignores invalid values (as if the field was blank) while the | ||||||
|  |   `dataSourceRef` field never ignores values and will cause an error if an invalid value is | ||||||
|  |   used. Invalid values are any core object (objects with no apiGroup) except for PVCs. | ||||||
|  | * The `dataSourceRef` field may contain different types of objects, while the `dataSource` field | ||||||
|  |   only allows PVCs and VolumeSnapshots. | ||||||
|  | 
 | ||||||
|  | Users should always use `dataSourceRef` on clusters that have the feature gate enabled, and | ||||||
|  | fall back to `dataSource` on clusters that do not. It is not necessary to look at both fields | ||||||
|  | under any circumstance. The duplicated values with slightly different semantics exist only for | ||||||
|  | backwards compatibility. In particular, a mixture of older and newer controllers are able to | ||||||
|  | interoperate because the fields are the same. | ||||||
|  | 
 | ||||||
|  | ### Using volume populators | ||||||
|  | 
 | ||||||
|  | Volume populators are {{< glossary_tooltip text="controllers" term_id="controller" >}} that can | ||||||
|  | create non-empty volumes, where the contents of the volume are determined by a Custom Resource. | ||||||
|  | Users create a populated volume by referring to a Custom Resource using the `dataSourceRef` field: | ||||||
|  | 
 | ||||||
|  | ```yaml | ||||||
|  | apiVersion: v1 | ||||||
|  | kind: PersistentVolumeClaim | ||||||
|  | metadata: | ||||||
|  |   name: populated-pvc | ||||||
|  | spec: | ||||||
|  |   dataSourceRef: | ||||||
|  |     name: example-name | ||||||
|  |     kind: ExampleDataSource | ||||||
|  |     apiGroup: example.storage.k8s.io | ||||||
|  |   accessModes: | ||||||
|  |     - ReadWriteOnce | ||||||
|  |   resources: | ||||||
|  |     requests: | ||||||
|  |       storage: 10Gi | ||||||
|  | ``` | ||||||
|  | 
 | ||||||
|  | Because volume populators are external components, attempts to create a PVC that uses one | ||||||
|  | can fail if not all the correct components are installed. External controllers should generate | ||||||
|  | events on the PVC to provide feedback on the status of the creation, including warnings if | ||||||
|  | the PVC cannot be created due to some missing component. | ||||||
|  | 
 | ||||||
|  | You can install the alpha [volume data source validator](https://github.com/kubernetes-csi/volume-data-source-validator) | ||||||
|  | controller into your cluster. That controller generates warning Events on a PVC in the case that no populator | ||||||
|  | is registered to handle that kind of data source. When a suitable populator is installed for a PVC, it's the | ||||||
|  | responsibility of that populator controller to report Events that relate to volume creation and issues during | ||||||
|  | the process. | ||||||
|  | 
 | ||||||
| ## Writing Portable Configuration | ## Writing Portable Configuration | ||||||
| 
 | 
 | ||||||
| If you're writing configuration templates or examples that run on a wide range of clusters | If you're writing configuration templates or examples that run on a wide range of clusters | ||||||
|  |  | ||||||
		Loading…
	
		Reference in New Issue