You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Make the helper Pod receive only environment variables instead of args (this changes the interface in a non-backward compatible way but is simpler to use and potentially provides more backward compatibility in the future).
* Adds the manager options `--pvc-annotation[-required]` to pass through annotations from the PVC to the PV and to the helper Pod.
* Merge the helper Pod's `data` VolumeMount with the one provided with the template to be able to specify `mountPropagation` within the template.
* Rename `helperPod.yaml` to `helper-pod.yaml` (more convenient and if we break sth we can break this as well).
* Expose `--helper-pod-timeout` option.
* Provide a basic usage example of the new features (`examples/cache`).
* Support forceful termination of the manager binary (2xCtrl+c - since this is annoying during development otherwise).
Closesrancher#164Closesrancher#165
Signed-off-by: Max Goltzsche <[email protected]>
Copy file name to clipboardexpand all lines: README.md
+21-41
Original file line number
Diff line number
Diff line change
@@ -119,7 +119,7 @@ Now you've verified that the provisioner works as expected.
119
119
120
120
### Customize the ConfigMap
121
121
122
-
The configuration of the provisioner is a json file `config.json`and two bash scripts `setup` and `teardown`, stored in the a config map, e.g.:
122
+
The configuration of the provisioner is a json file `config.json`, a Pod template `helper-pod.yaml`and two bash scripts `setup` and `teardown`, e.g.:
123
123
```
124
124
kind: ConfigMap
125
125
apiVersion: v1
@@ -146,41 +146,11 @@ data:
146
146
}
147
147
setup: |-
148
148
#!/bin/sh
149
-
while getopts "m:s:p:" opt
150
-
do
151
-
case $opt in
152
-
p)
153
-
absolutePath=$OPTARG
154
-
;;
155
-
s)
156
-
sizeInBytes=$OPTARG
157
-
;;
158
-
m)
159
-
volMode=$OPTARG
160
-
;;
161
-
esac
162
-
done
163
-
164
-
mkdir -m 0777 -p ${absolutePath}
149
+
mkdir -m 0777 -p "$VOL_DIR"
165
150
teardown: |-
166
151
#!/bin/sh
167
-
while getopts "m:s:p:" opt
168
-
do
169
-
case $opt in
170
-
p)
171
-
absolutePath=$OPTARG
172
-
;;
173
-
s)
174
-
sizeInBytes=$OPTARG
175
-
;;
176
-
m)
177
-
volMode=$OPTARG
178
-
;;
179
-
esac
180
-
done
181
-
182
-
rm -rf ${absolutePath}
183
-
helperPod.yaml: |-
152
+
rm -rf "$VOL_DIR"
153
+
helper-pod.yaml: |-
184
154
apiVersion: v1
185
155
kind: Pod
186
156
metadata:
@@ -209,16 +179,26 @@ The configuration must obey following rules:
209
179
3. No duplicate paths allowed for one node.
210
180
4. No duplicate node allowed.
211
181
212
-
#### Scripts `setup` and `teardown` and `helperPod.yaml`
182
+
#### Scripts `setup` and `teardown` and the `helper-pod.yaml` template
213
183
214
-
The script `setup` will be executed before the volume is created, to prepare the directory on the node for the volume.
184
+
* The `setup` script is run before the volume is created, to prepare the volume directory on the node.
185
+
* The `teardown` script is run after the volume is deleted, to cleanup the volume directory on the node.
186
+
* The `helper-pod.yaml` template is used to create a helper Pod that runs the `setup` or `teardown` script.
215
187
216
-
The script `teardown` will be executed after the volume is deleted, to cleanup the directory on the node for the volume.
188
+
The scripts receive their input as environment variables:
217
189
218
-
The yaml file `helperPod.yaml` will be created by local-path-storage to execute `setup` or `teardown` script with three paramemters `-p <path> -s <size> -m <mode>` :
219
-
* path: the absolute path provisioned on the node
220
-
- size: pvc.Spec.resources.requests.storage in bytes
221
-
* mode: pvc.Spec.VolumeMode
190
+
| Environment variable | Description |
191
+
| -------------------- | ----------- |
192
+
|`VOL_DIR`| Volume directory that should be created or removed. |
193
+
|`VOL_NAME`| Name of the PersistentVolume. |
194
+
|`VOL_TYPE`| Type of the PersistentVolume (`Block` or `Filesystem`). |
195
+
|`VOL_SIZE_BYTES`| Requested volume size in bytes. |
196
+
|`PVC_NAME`| Name of the PersistentVolumeClaim. |
197
+
|`PVC_NAMESPACE`| Namespace of the PersistentVolumeClaim. |
198
+
|`PVC_ANNOTATION`| Value of the PersistentVolumeClaim annotation specified by the manager's `--pvc-annotation` option. |
199
+
|`PVC_ANNOTATION_{SUFFIX}`| Value of the PersistentVolumeClaim annotation with the prefix specified by the manager's `--pvc-annotation` option. The `SUFFIX` is the normalized path within the annotation name after the `/`. E.g. if `local-path-provisioner` is run with `--pvc-annotation=storage.example.org` the PVC annotation `storage.example.org/cache-name` is passed through to the Pod as env var `PVC_ANNOTATION_CACHE_NAME`. If the helper Pod requires such an annotation `local-path-provisioner` can be run with e.g. `--pvc-annotation-required=storage.example.org/cache-name`. |
200
+
201
+
Additional environment variables and defaults for the optional `PVC_ANNOTATION*` can be specified within the helper Pod template.
This example shows how to use short-lived PersistentVolumes for caching.
4
+
A [buildah](https://github.com/containers/buildah)-based helper Pod is used to provision a container file system based on an image as PersistentVolume and commit it when deprovisioning.
5
+
Users can select the desired cache or rather the image using a PersistentVolumeClaim annotation that is passed through to the helper Pod as environment variable.
6
+
7
+
While it is not part of this example caches could also be synchronized across nodes using an image registry.
8
+
The [cache-provisioner](https://github.com/mgoltzsche/cache-provisioner) project aims to achieve this as well as other cache management features.
9
+
10
+
## Test
11
+
12
+
### Test the helper Pod separately
13
+
14
+
The helper Pod can be tested separately using docker locally:
15
+
```sh
16
+
./helper-test.sh
17
+
```
18
+
19
+
### Test the integration
20
+
21
+
_Please note that a non-overlayfs storage directory (`/data/example-cache-storage`) must be configured._
22
+
_The provided configuration is known to work with minikube (`minikube start`) and kind (`kind create cluster; kind export kubeconfig`)._
23
+
24
+
Install the example kustomization:
25
+
```sh
26
+
kustomize build .| kubectl apply -f -
27
+
```
28
+
29
+
If you want to test changes to the `local-path-provisioner` binary locally:
Within another terminal create an example Pod and PVC that pulls and runs a container image using [podman](https://github.com/containers/podman):
46
+
```sh
47
+
kubectl apply -f test-pod.yaml
48
+
kubectl logs -f cached-build
49
+
```
50
+
51
+
If the Pod and PVC are removed and recreated you can observe that, during the 2nd Pod execution on the same node, the image for the nested container doesn't need to be pulled again since it is cached:
Usage: "A PersistentVolumeClaim annotation or prefix passed through to the helper pod as env vars (PVC_ANNOTATION[_<ANNOTATION_PATH_SUFFIX>]=<ANNOTATION_VALUE>)",
128
+
EnvVar: EnvPVCAnnotation,
129
+
Value: "",
130
+
},
131
+
cli.StringFlag{
132
+
Name: FlagPVCAnnotationRequired,
133
+
Usage: "Annotation that must be specified on PersistentVolumeClaims (multiple comma-separated)",
0 commit comments