kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #3295 from davidz627/feature/reconstructionMigration 

Volume Reconstruction migration design
This commit is contained in:
Kubernetes Prow Robot 2019-03-26 18:54:48 -07:00 committed by GitHub
parent 92a50cbb51 96ba398a40
commit f41ba061c9
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 23 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
contributors/design-proposals/storage/csi-migration.md
View File

@ -302,7 +302,29 @@ for where is it used before the translation.
### Volume Reconstruction
TODO: Design
Volume Reconstruction is currently a routine in the reconciler that runs on the
nodes when a Kubelet restarts and loses its cached state (`desiredState` and
`actualState`). It is kicked off in `syncStates()` in
`pkg/kubeletvolumemanager/reconciler/reconciler.go` and attempts to reconstruct
a volume based on the mount path on the host machine.
When CSI Migration is turned on, when the reconstruction code is run and it
finds a CSI mounted volume we currently do not know whether it was mounted as a
native CSI volume or migrated from in-tree. To solve this issue we will save a
`migratedVolume` boolean in the `saveVolumeData` function when the `NewMounter`
is created during the `MountVolume` call for that particular volume in the
Operation generator.
When the Kubelet is restarted and we lose state the Kubelet will call
`reconstructVolume` we can `loadVolumeData` and determine whether that CSI
volume was migrated or not, as well as get the information about the original
plugin requested. With that information we should be able to call the
`ReconstructVolumeOperation` with the correct in-tree plugin to get the original
in-tree spec that we can then pass to the rest of volume reconstruction. The
rest of the volume reconstruction code will then use this in-tree spec passed to
the `desiredState`, `actualState`, and `operationGenerator` and the volume will
go through the standard volume pathways and go through the standard migrated
volume lifecycles described above in the "Pre-Provisioned Volumes" section.
### Volume Limit