CSIDriver Object

Two CSI drivers serve one Pod, so why does one volume get a VolumeAttachment and an fsGroup change while the other gets Pod info in its mount call instead? Each driver here has a cluster scoped CSIDriver object named exactly after it, whose fields tell the attach-detach controller whether to attach and tell Kubelet whether to pass Pod info and apply fsGroup. A driver with no such object gets the defaults, and attach is required.

Play the animation 3 steps, animated, best on a wide screen

CSIDriver Object diagram: The CSIDriver object

CSIDriver Object, step by step

  1. Each volume names its driver, and each driver here has a cluster scoped CSIDriver object of that exact name. The attach and detach controller reads attachRequired from it. The disk driver says true, so the controller writes VolumeAttachment csi-5e8b. The NFS driver says false, so no attach is needed.

    Play from step 1
  2. Kubelet reads both objects and calls NodePublishVolume on each node plugin, and podInfoOnMount true adds Pod info such as the Pod name, namespace and UID to the NFS call only. Neither driver applies fsGroup itself, so File makes Kubelet change the group of data to 2000, and None leaves shared as exported.

    Play from step 2
  3. Suppose instead the NFS driver ships no CSIDriver object: no field is set. The controller and Kubelet treat it as attachRequired true. The controller writes csi-c41d, but this driver runs no external-attacher, so nothing marks csi-c41d attached, shared stays unmounted and the Pod waits in ContainerCreating.

    Play from step 3

Sources