SourceVolumeMode is the mode of the volume whose snapshot is taken. -Can be either “Filesystem” or “Block”. +Can be either "Filesystem" or “Block”. If not specified, it indicates the source volume’s mode is unknown. This field is immutable. This field is an alpha field.
@@ -617,7 +617,7 @@ Kubernetes core/v1.PersistentVolumeModeSourceVolumeMode is the mode of the volume whose snapshot is taken. -Can be either “Filesystem” or “Block”. +Can be either "Filesystem" or “Block”. If not specified, it indicates the source volume’s mode is unknown. This field is immutable. This field is an alpha field.
diff --git a/book/src/group-snapshot-restore-feature.md b/book/src/group-snapshot-restore-feature.md index 437a5d1b..699f79bb 100644 --- a/book/src/group-snapshot-restore-feature.md +++ b/book/src/group-snapshot-restore-feature.md @@ -12,7 +12,7 @@ Beta | 1.32 | - | 8.2+ | 8.2+ | 8.2+ | 5.1+ ## Overview Some storage systems provide the ability to create a crash consistent snapshot of -multiple volumes. A group snapshot represents “copies” from multiple volumes that +multiple volumes. A group snapshot represents "copies" from multiple volumes that are taken at the same point-in-time. A group snapshot can be used either to rehydrate new volumes (pre-populated with the snapshot data) or to restore existing volumes to a previous state (represented by the snapshots). diff --git a/book/src/sidecar-containers.md b/book/src/sidecar-containers.md index 1ce8e793..c15a43d8 100644 --- a/book/src/sidecar-containers.md +++ b/book/src/sidecar-containers.md @@ -4,7 +4,7 @@ Kubernetes CSI Sidecar Containers are a set of standard containers that aim to simplify the development and deployment of CSI Drivers on Kubernetes. These containers contain common logic to watch the Kubernetes API, trigger -appropriate operations against the “CSI volume driver” container, and update the +appropriate operations against the "CSI volume driver" container, and update the Kubernetes API as appropriate. The containers are intended to be bundled with third-party CSI driver containers and deployed together as pods. diff --git a/book/src/topology.md b/book/src/topology.md index e1e70f33..2880d9ee 100644 --- a/book/src/topology.md +++ b/book/src/topology.md @@ -10,7 +10,7 @@ Beta | 1.14 | 1.16 | 1.1-1.4 GA | 1.17 | - | 1.5+ ## Overview -Some storage systems expose volumes that are not equally accessible by all nodes in a Kubernetes cluster. Instead volumes may be constrained to some subset of node(s) in the cluster. The cluster may be segmented into, for example, “racks” or “regions” and “zones” or some other grouping, and a given volume may be accessible only from one of those groups. +Some storage systems expose volumes that are not equally accessible by all nodes in a Kubernetes cluster. Instead volumes may be constrained to some subset of node(s) in the cluster. The cluster may be segmented into, for example, "racks" or "regions" and "zones" or some other grouping, and a given volume may be accessible only from one of those groups. To enable orchestration systems, like Kubernetes, to work well with storage systems which expose volumes that are not equally accessible by all nodes, the [CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md) enables: @@ -18,7 +18,24 @@ To enable orchestration systems, like Kubernetes, to work well with storage syst 2. Ability for Kubernetes (users or components) to influence where a volume is provisioned (e.g. provision new volume in either "zone 1" or "zone 2"). 3. Ability for a CSI Driver to opaquely specify where a particular volume exists (e.g. "volume X" is accessible by all nodes in "zone 1" and "zone 2"). -Kubernetes and the [external-provisioner](external-provisioner.md) use these abilities to make intelligent scheduling and provisioning decisions (that Kubernetes can both influence and act on topology information for each volume), +Kubernetes and the [external-provisioner](external-provisioner.md) use these abilities to make intelligent scheduling and provisioning decisions (that Kubernetes can both influence and act on topology information for each volume). This works like so: + +1. The CSI node plugin reports accessible topologies for the node. +2. The external-provisioner generates accessibility requirements, derived from (where applicable): the StorageClass' `volumeBindingMode` value, the StorageClass' `allowedTopologies` value, the accessible topologies reported for the node, and the values for external-provisioner's `--strict-topology` and `--immediate-topology` arguments. The result is a set of *requisite* and *preferred* topologies. This is described below. +3. The CSI controller plugin uses these accessibility requirements when requesting a volume from the storage system and when creating the resulting CSI Volume. + +The accessibility requirements used during CSI volume creation can therefore be visualized like so: + +[Delayed binding](https://kubernetes.io/docs/concepts/storage/storage-classes/#volume-binding-mode)? | Strict topology? | [Allowed topologies](https://kubernetes.io/docs/concepts/storage/storage-classes/#allowed-topologies)? | Immediate Topology? | [Resulting accessibility requirements](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume) +:---: |:---:|:---:|:---:|:---| +Yes | Yes | n/a | n/a | `Requisite` = `Preferred` = Selected node topology +Yes | No | No | n/a | `Requisite` = Aggregated cluster topology