From b8a8f12b55d98a9219969313154aa2b4fbf47ea7 Mon Sep 17 00:00:00 2001 From: stoneshi-yunify Date: Sat, 14 Sep 2024 15:52:51 +0800 Subject: [PATCH] update readme Signed-off-by: stoneshi-yunify --- README.md | 26 ++++++++++++++++---------- 1 file changed, 16 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index 1df7dce..0624ee4 100644 --- a/README.md +++ b/README.md @@ -10,7 +10,7 @@ One typical usecase is using it to change the ownership/permissions of the volum # Installation ## Deploy CRD -``` +```sh kubectl apply -f config/crd/bases ``` @@ -19,24 +19,30 @@ Create a volume initializer yaml and apply it. Take [this](config/samples/storage.kubesphere.io_v1alpha1_initializer.yaml) for example. -## Deploy webhook -``` -kubectl apply -f deploy/webhook-deployment.yaml +## Deploy Webhook + +```sh +deploy/prepare.sh && kubectl apply -f deploy/webhook-deployment.yaml ``` ## Test Create pod with pvc volumes to test. -Take [this](config/samples/mongo-test.yaml) for example. +Take [this](config/samples/mongo-test.yaml) for example. This example requires you have storage class named `local-path` and `local-path2` on your cluster. You can install the [local-path-provisioner](https://github.com/rancher/local-path-provisioner) for quick testing. # Environment Variables The following environment variables will be present in the injected init container. -| Environment Variable | Explanation | Present When | Example Values | -|----------------------|------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------|-------------------| -| PVC_1_MOUNT_PATH | pvc volume's mount path in the init container | Always | `/data` | -| PVC_1_UID | value from pod's annotation `volume.storage.kubesphere.io/uid` or `${volume-name}.volume.storage.kubesphere.io/uid`, can be used to chown the volume | When annotation exists | `mongodb`, `1001` | -| PVC_1_GID | value from pod's annotation `volume.storage.kubesphere.io/gid` or `${volume-name}.volume.storage.kubesphere.io/gid`, can be used to chown the volume | When annotation exists | `0`, `mongodb` | +| Environment Variable | Explanation | Present When | Example Values | +|----------------------|-------------------------------------------------------------------------------------------------------------------------------------------------|-------------------|-------------------| +| PVC_1_MOUNT_PATH | pvc volume's mount path in the init container | Always | `/data` | +| PVC_1_UID | value from pod's label `volume.storage.kubesphere.io/uid` or `${volume-name}.volume.storage.kubesphere.io/uid`, can be used to chown the volume | When label exists | `mongodb`, `1001` | +| PVC_1_GID | value from pod's label `volume.storage.kubesphere.io/gid` or `${volume-name}.volume.storage.kubesphere.io/gid`, can be used to chown the volume | When label exists | `0`, `mongodb` | + + +# FAQ +1. Why not use pod's annotations instead of labels to pass the volume's UID/GID to init container? +- The webhook listens the pod CREATE events, such pods are likely generated from replicaset(from deployment/statefulset/daemonset), and normally don't have annotations present at the admission stage (i.e. when this webhook processes the requests). Therefore, we need to use the labels. # Limitations