53 lines
2.7 KiB
Markdown
53 lines
2.7 KiB
Markdown
|
# CSINodeInfo and CSIDriverInfo Usage and Lifecycle
|
||
|
|
|
||
|
|
CSINodeInfo is an API object representing CSI Information at the Node level.
|
||
|
|
CSINodeInfo contains a Spec and a Status, each containing Drivers represent the
|
||
|
|
driver spec and status respectively. The CSIDriverInfoSpec represents the
|
||
|
|
specification of the driver and is generally not changed, whereas the
|
||
|
|
CSIDriverInfoStatus represents the current status of the driver and can be
|
||
|
|
updated and reacted to by various components.
|
||
|
|
|
||
|
|
## Who creates it and when
|
||
|
|
|
||
|
|
CSINodeInfo is created by Kubelet when the first CSI Driver is installed to the
|
||
|
|
cluster and it is registered through the Kubelet device registration mechanism.
|
||
|
|
|
||
|
|
## Who updates CSIDriverInfo Spec and when
|
||
|
|
|
||
|
|
The CSIDriverInfoSpec for a driver is created upon installation of the CSI
|
||
|
|
Driver to the cluster and it is registered through the Kubelet device
|
||
|
|
registration mechanism. The spec is populated with information about the driver
|
||
|
|
through the nodeinfomanager (inside Kubelet) and will remain unchanged from then
|
||
|
|
on.
|
||
|
|
|
||
|
|
## Who updates Status and when
|
||
|
|
|
||
|
|
The CSIDriverInfoStatus for the driver is created upon installation of the CSI
|
||
|
|
Driver to the cluster (the same time as the spec) and it is registered through
|
||
|
|
the Kubelet device registration mechanism. The Status contains information about
|
||
|
|
installation and the required Volume Plugin Mechanism of the driver. When the
|
||
|
|
driver is installed/uninstalled through the Kubelet device registration
|
||
|
|
mechanism the Available flag is flipped from true/false respectively. The
|
||
|
|
migration status will also be updated when the flags for migration are set to
|
||
|
|
true/false on the Kubelet for that Driver on that node.
|
||
|
|
|
||
|
|
## Consumers of Status and Spec
|
||
|
|
|
||
|
|
Currently the only consumer of CSINodeInfo/CSIDriverInfo is the
|
||
|
|
csi-external-provisioner. In the future, the Attach Detach Controller (ADC) will
|
||
|
|
need to read this object to determine migration status on a per driver per node
|
||
|
|
basis. The creation of the CSINodeInfo object could possibly race with the
|
||
|
|
Attach/Detach controller as for CSI Migration the controller depend on the
|
||
|
|
existence of the API object for the driver but it will not have been created
|
||
|
|
yet. The ADC is expected to fail (and retry with exponential backoff) the
|
||
|
|
operation if it is expecting the object and it has not yet been created.
|
||
|
|
|
||
|
|
## Creation of CSINodeInfo object on Kubelet startup
|
||
|
|
|
||
|
|
For CSI Migration Alpha we expect any user who turns on the feature has both
|
||
|
|
Kubelet and ADC at a version where the CSINodeInfo's are being created on
|
||
|
|
Kubelet startup. We will not promote the feature to Beta (on by default) until
|
||
|
|
the CSINodeInfo's are being created on Kubelet startup for a 2 version skew to
|
||
|
|
prevent the case where the CSINodeInfo does not exist when the ADC depends on
|
||
|
|
it. This prevents the race described above becoming a permanent bad state.
|