-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Start adding a KEP for csi volume resizing #780
Conversation
/approve |
@saad-ali addressed all the open comments. PTAL. thanks. |
The design of CSI volume resizing is made of two parts. | ||
|
||
|
||
#### External resize controller |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
indent should be one level up
|
||
#### External resize controller | ||
|
||
To support resizing of CSI volumes an external resize controller will monitor all PVCs. If a PVC meets following critirea for resizing, it will be added to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
criteria
|
||
#### External resize controller | ||
|
||
To support resizing of CSI volumes an external resize controller will monitor all PVCs. If a PVC meets following critirea for resizing, it will be added to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the internal resize controller need any changes to ignore CSI volumes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no - this was resolved couple of releases back when another sig-storage member wanted to externally resize volumes.
To support resizing of CSI volumes an external resize controller will monitor all PVCs. If a PVC meets following critirea for resizing, it will be added to | ||
controller's workqueue: | ||
|
||
- The driver name disovered from PVC should match name of driver currently known(by querying driver info via CSI RPC call) to external resize controller. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does it get the driver name? From StorageClass?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From PV.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's clarify that.
lgtm please squash |
Clarify dependency on online resizing.
fb99f34
to
c4f4b1b
Compare
@msau42 done! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: childsb, gnufied, msau42 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm looks like I forgot to hit submit on this.
You can address these in a follow up PR
|
||
[umbrella issues]: https://github.com/kubernetes/kubernetes/issues/62096 | ||
|
||
## Implementation History |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please update the Implementation History to clarify what has been implemented.
|
||
### External resize controller | ||
|
||
To support resizing of CSI volumes an external resize controller will monitor all PVCs. If a PVC meets following criteria for resizing, it will be added to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: monitor all changes to PVCs
To support resizing of CSI volumes an external resize controller will monitor all PVCs. If a PVC meets following critirea for resizing, it will be added to | ||
controller's workqueue: | ||
|
||
- The driver name disovered from PVC should match name of driver currently known(by querying driver info via CSI RPC call) to external resize controller. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's clarify that.
- The driver name disovered from PVC should match name of driver currently known(by querying driver info via CSI RPC call) to external resize controller. | ||
- Once it notices a PVC has been updated and by comparing old and new PVC object, it determines more space has been requested by the user. | ||
|
||
Once PVC gets picked from workqueue, the controller will also compare requested PVC size with actual size of volume in `PersistentVolume` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does this check do?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We also need to check PV size before actually doing controller resize because it is possible that, volume already has been resized and controller is just resyncing PVCs.
object. Once PVC passes all these checks, a CSI `ControllerExpandVolume` call will be made by the controller if CSI plugin implements `ControllerExpandVolume` | ||
RPC call. | ||
|
||
If `ControllerExpandVolume` call is successful and plugin implements `NodeExpandVolume`: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(i.e. the CSI driver has a EXPAND_VOLUME
node capability)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, I did not use use capabilities in this document on purpose because I thought "plugins implements NodeExpandVolume
"is synonymous with "plugin has EXPAND_VOLUME
node capability".
- if `ControllerExpandVolumeResponse` returns `true` in `node_expansion_required` then `FileSystemResizePending` condition will be added to PVC and `NodeExpandVolume` operation will be queued on kubelet. Also volume size reported by PV will be updated to new value. | ||
- if `ControllerExpandVolumeResponse` returns `false` in `node_expansion_required` then volume resize operation will be marked finished and both `pvc.Status.Capacity` and `pv.Spec.Capacity` will report updated value. | ||
|
||
If plugin does not implement `NodeExpandVolume` then volume resize operation will be marked as finished and both `pvc.Status.Capacity` and `pv.Spec.Capacity` will report updated value after successful completion of `ControllerExpandVolume` RPC call. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If ControllerExpandVolume
call is successful and the plugin does not implement...
|
||
#### Offline volume resizing on kubelet: | ||
|
||
This is the default mode and in this mode `NodeExpandVolume` will only be called when volume is being mounted on the node. In other words, pod that was using the volume must be re-created for expansion on node to happen. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What causes kubelet to start this process of calling NodeExpandVolume
? Based on above it seems like some component (mount operation?) watches the PVC and triggers this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah - offline resizing is done as part of MountVolume
operation (in operation_executor.go
). The actual checks we perform are outlined below. I am going to update this document to be more explicit.
RPC call. | ||
|
||
If `ControllerExpandVolume` call is successful and plugin implements `NodeExpandVolume`: | ||
- if `ControllerExpandVolumeResponse` returns `true` in `node_expansion_required` then `FileSystemResizePending` condition will be added to PVC and `NodeExpandVolume` operation will be queued on kubelet. Also volume size reported by PV will be updated to new value. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So kubelet will wait until the FileSystemResizePending
condition is applied to PVC? If so, this smells fishy. My understanding was that conditions were informative for end user and not to be used to trigger behavior in other components?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No kubelet does not check for FileSystemResiznePending
condition saad. From proposal:
When a pod that is using the PVC is started, kubelet will compare pvc.spec.resources.requests.storage and pvc.Status.Capacity. It also compares PVC's size with pv.Spec.Capacity and if it detects PV is reporting same size as pvc's spec but PVC's status is still reporting smaller value then it determines - a volume expansion is pending on the node. At this point if plugin implements NodeExpandVolume RPC call then, kubelet will call it
xref #556