update readme

Signed-off-by: stoneshi-yunify <stoneshi@kubesphere.io>

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