Skip to content

Commit 3ade6a4

Browse files
gnufiedgnufied
committed
Add a condition field for capturing status of resize on PVC
1 parent 9bb2192 commit 3ade6a4

File tree

1 file changed

+77
-8
lines changed

1 file changed

+77
-8
lines changed

‎contributors/design-proposals/grow-volume-size.md‎

Lines changed: 77 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -25,12 +25,12 @@ Enable users to increase size of PVs that their pods are using. The user will up
2525
| ----------------| :---------------: | :--------------------------:| :----------------------: |
2626
| EBS | Yes | Yes | Yes |
2727
| GCE PD | Yes | Yes | Yes |
28-
| Azure Disk | Yes | Yes | No |
28+
| GlusterFS | Yes | No | Yes |
2929
| Cinder | Yes | Yes | Yes |
3030
| Vsphere | Yes | Yes | No |
3131
| Ceph RBD | Yes | Yes | No |
3232
| Host Path | No | No | No |
33-
| GlusterFS | Yes | No | Yes |
33+
| Azure Disk | Yes | Yes | No |
3434
| Azure File | No | No | No |
3535
| Cephfs | No | No | No |
3636
| NFS | No | No | No |
@@ -63,13 +63,15 @@ For volume types that only require volume plugin based api call, this will be on
6363
A new controller called `volume_expand_controller` will listen for pvc size expansion requests and take action as needed. The steps performed in this
6464
new controller will be:
6565

66-
* Watch for pvc update requests and add pvc to controller's desired state of world if a increase in volume size was requested.
66+
* Watch for pvc update requests and add pvc to controller's desired state of world if a increase in volume size was requested. Once PVC is added to
67+
controller's desired state of world - `pvc.Status.Conditions` will be updated with `ResizeStarted: True`.
68+
* For unbound or pending PVCs - resize will trigger no action in `volume_expand_controller`.
6769
* A reconciler will read desired state of world and perform corresponding volume resize operation. If there is a resize operation in progress
6870
for same volume then resize request will be pending and retried once previous resize request has completed.
6971
* Controller resize in effect will be level based rather than edge based. If there are more than one pending resize request for same PVC then
7072
new resize requests for same PVC will replace older pending request.
7173
* Resize will be performed via volume plugin interface, executed inside a goroutine spawned by `operation_exectutor`.
72-
* A new plugin interface called `volume.Exander` will be added to volume plugin interface. The controller call to expand the PVC will look like:
74+
* A new plugin interface called `volume.Expander` will be added to volume plugin interface. The controller call to expand the PVC will look like:
7375

7476
```go
7577
func (og *operationGenerator) GenerateExpandVolumeFunc(
@@ -103,11 +105,11 @@ func (og *operationGenerator) GenerateExpandVolumeFunc(
103105
}
104106
```
105107

106-
* Once volume expand is successful, the volume will be marked as expanded and new size will be updated in `pv.spec.capacity`. Any errors will be
107-
reported as *events* on PVC object.
108+
* Once volume expand is successful, the volume will be marked as expanded and new size will be updated in `pv.spec.capacity`. Any errors will be reported as *events* on PVC object.
109+
* If resize failed in above step, in addition to events - `pvc.Status.Conditions` will be updated with `ResizeFailed: True`. Corresponding error will be added to condition field as well.
108110
* Depending on volume type next steps would be:
109111

110-
* If volume is of type that does not require file system resize, then `pvc.status.capacity` will be immediately updated to reflect new size. This would conclude the volume expand operation.
112+
* If volume is of type that does not require file system resize, then `pvc.status.capacity` will be immediately updated to reflect new size. This would conclude the volume expand operation. Also `pvc.Status.Conditions` will be updated with `Ready: True`.
111113
* If volume if of type that requires file system resize then a file system resize will be performed on kubelet. Read below for steps that will be performed for file system resize.
112114

113115
* If volume plugin is of type that can not do resizing of attached volumes (such as `Cinder`) then `ExpandVolumeDevice` can return error by checking for
@@ -122,13 +124,43 @@ reported as *events* on PVC object.
122124

123125
### File system resize on kublet
124126

127+
A File system resize will be pending on PVC until a new pod that uses this volume is scheduled somewhere. While theoretically we *can* perform
128+
online file system resize if volume type and file system supports it - we are leaving it for next iteration of this feature.
129+
125130
* When calling `MountDevice` or `Setup` call of volume plugin, volume manager will in addition compare `pv.spec.capacity` and `pvc.status.capacity` and if `pv.spec.capacity` is greater
126131
than `pvc.status.spec.capacity` then volume manager will additionally resize the file system of volume.
127132
* The call to resize file system will be performed inside `operation_generator.GenerateMountVolumeFunc`. `VolumeToMount` struct will be enhanced to store PVC as well.
128133
* Any errors during file system resize will be added as *events* to Pod object and mount operation will be failed.
134+
* If there are any errors during file system resize `pvc.Status.Conditions` will be updated with `ResizeFailed: True`. Any errors will be added to
135+
`Conditions` field.
129136
* File System resize will not be performed on kubelet where volume being attached is ReadOnly. This is similar to pattern being used for performing formatting.
130-
* After file system resize is successful, `pvc.status.capacity` will be updated to match `pv.spec.capacity` and volume expand operation will be considered complete.
137+
* After file system resize is successful, `pvc.status.capacity` will be updated to match `pv.spec.capacity` and volume expand operation will be considered complete. Also `pvc.Status.Conditions` will be updated with `Ready: True`.
138+
139+
#### Reduce coupling between resize operation and file system type
131140

141+
A file system resize in general requires presence of tools such as `resize2fs` or `xfs_growfs` on the host where kubelet is running. There is a concern
142+
that open coding call to different resize tools direclty in Kubernetes will result in coupling between file system and resize operation. To solve this problem
143+
we have considered following options:
144+
145+
1. Write a library that abstracts away various file system operations, such as - resizing, formatting etc.
146+
147+
Pros:
148+
* Relatively well known pattern
149+
Cons:
150+
* Depending on version with which Kubernetes is compiled with, we are still tied to which file systems are supported in which version
151+
of kubernetes.
152+
2. Ship a wrapper shell script that encapsulates various file system operations and as long as the shell script supports particular file system
153+
the resize operation is supported.
154+
Pros:
155+
* Kubernetes Admin can easily replace default shell script with her own version and thereby adding support for more file system types.
156+
Cons:
157+
* I don't know if there is a pattern that exists in kube today for shipping shell scripts that are called out from code in Kubernetes. Flex is
158+
different because, none of the flex scripts are shipped with Kuberntes.
159+
3. Ship resizing tools in a container.
160+
161+
162+
Of all options - #3 is our best bet but we are not quite there yet. Hence, I would like to propose that we ship with support for
163+
most common file systems in curent release and we revisit this coupling and solve it in next release.
132164

133165
## API and UI Design
134166

@@ -173,6 +205,43 @@ spec:
173205
174206
`pvc.spec.resources.requests.storage` field of pvc object will become mutable after this change.
175207

208+
In addition to that PVC's status will have a `Conditions []PvcCondition` - which will be used
209+
to communicate the status of PVC to the user.
210+
211+
So the `PersistentVolumeClaimStatus` will become:
212+
213+
```go
214+
type PersistentVolumeClaimStatus struct {
215+
Phase PersistentVolumeClaimPhase
216+
AccessModes []PersistentVolumeAccessMode
217+
Capacity ResourceList
218+
// New Field added as part of this Change
219+
Conditions []PVCCondition
220+
}
221+
222+
// new API type added
223+
type PVCCondition struct {
224+
Type PVCConditionType
225+
Status ConditionStatus
226+
LastProbeTime metav1.Time
227+
LastTransitionTime metav1.Time
228+
Reason string
229+
Message string
230+
}
231+
232+
// new API type
233+
type PVCConditionType string
234+
235+
// new Constants
236+
const (
237+
PVCReady PVCConditionType = "Ready"
238+
PVCResizeStarted PVCConditionType = "ResizeStarted"
239+
PVCResizeFailed PVCResizeFailed = "ResizeFailed"
240+
)
241+
```
242+
243+
244+
176245
### Other API changes
177246

178247
This proposal relies on ability to update PVC status from kubelet. While updating PVC's status

0 commit comments

Comments
 (0)