mirror of
https://github.com/ceph/ceph-csi.git
synced 2025-06-13 10:33:35 +00:00
Fix markdown style issue
Signed-off-by: Madhu Rajanna <mrajanna@redhat.com>
This commit is contained in:
Madhu Rajanna
committed by
mergify[bot]
mergify[bot]
parent
0fc294ae5b
commit
7043b3839a
@ -1,10 +1,15 @@
|
||||
# CSI CephFS plugin
|
||||
|
||||
The CSI CephFS plugin is able to both provision new CephFS volumes and attach and mount existing ones to workloads.
|
||||
The CSI CephFS plugin is able to both provision new CephFS volumes
|
||||
and attach and mount existing ones to workloads.
|
||||
|
||||
## Building
|
||||
|
||||
CSI CephFS plugin can be compiled in a form of a binary file or in a form of a Docker image. When compiled as a binary file, the result is stored in `_output/` directory with the name `cephfsplugin`. When compiled as an image, it's stored in the local Docker image store.
|
||||
CSI CephFS plugin can be compiled in a form of a binary file or in a form of a
|
||||
Docker image.
|
||||
When compiled as a binary file, the result is stored in `_output/`
|
||||
directory with the name `cephfsplugin`.
|
||||
When compiled as an image, it's stored in the local Docker image store.
|
||||
|
||||
Building binary:
|
||||
|
||||
@ -30,10 +35,13 @@ Option | Default value | Description
|
||||
`--volumemounter` | _empty_ | default volume mounter. Available options are `kernel` and `fuse`. This is the mount method used if volume parameters don't specify otherwise. If left unspecified, the driver will first probe for `ceph-fuse` in system's path and will choose Ceph kernel client if probing failed.
|
||||
`--metadatastorage` | _empty_ | Whether should metadata be kept on node as file or in a k8s configmap (`node` or `k8s_configmap`)
|
||||
|
||||
**Available environmental variables:**
|
||||
`KUBERNETES_CONFIG_PATH`: if you use `k8s_configmap` as metadata store, specify the path of your k8s config file (if not specified, the plugin will assume you're running it inside a k8s cluster and find the config itself).
|
||||
**Available environmental variables:** `KUBERNETES_CONFIG_PATH`: if you use
|
||||
`k8s_configmap` as metadata store, specify the path of your k8s config file (if
|
||||
not specified, the plugin will assume you're running it inside a k8s cluster and
|
||||
find the config itself).
|
||||
|
||||
`POD_NAMESPACE`: if you use `k8s_configmap` as metadata store, `POD_NAMESPACE` is used to define in which namespace you want the configmaps to be stored
|
||||
`POD_NAMESPACE`: if you use `k8s_configmap` as metadata store, `POD_NAMESPACE`
|
||||
is used to define in which namespace you want the configmaps to be stored
|
||||
|
||||
**Available volume parameters:**
|
||||
|
||||
@ -48,25 +56,32 @@ Parameter
|
||||
`csi.storage.k8s.io/provisioner-secret-name`, `csi.storage.k8s.io/node-stage-secret-name` | for Kubernetes | name of the Kubernetes Secret object containing Ceph client credentials. Both parameters should have the same value
|
||||
`csi.storage.k8s.io/provisioner-secret-namespace`, `csi.storage.k8s.io/node-stage-secret-namespace` | for Kubernetes | namespaces of the above Secret objects
|
||||
|
||||
**Required secrets for `provisionVolume=true`:**
|
||||
**Required secrets for `provisionVolume=true`:**
|
||||
Admin credentials are required for provisioning new volumes
|
||||
|
||||
* `adminID`: ID of an admin client
|
||||
* `adminKey`: key of the admin client
|
||||
|
||||
**Required secrets for `provisionVolume=false`:**
|
||||
**Required secrets for `provisionVolume=false`:**
|
||||
User credentials with access to an existing volume
|
||||
|
||||
* `userID`: ID of a user client
|
||||
* `userKey`: key of a user client
|
||||
|
||||
Notes on volume size: when provisioning a new volume, `max_bytes` quota attribute for this volume will be set to the requested volume size (see [Ceph quota documentation](http://docs.ceph.com/docs/mimic/cephfs/quota/)). A request for a zero-sized volume means no quota attribute will be set.
|
||||
Notes on volume size: when provisioning a new volume, `max_bytes` quota
|
||||
attribute for this volume will be set to the requested volume size (see [Ceph
|
||||
quota documentation](http://docs.ceph.com/docs/mimic/cephfs/quota/)). A request
|
||||
for a zero-sized volume means no quota attribute will be set.
|
||||
|
||||
## Deployment with Kubernetes
|
||||
|
||||
Requires Kubernetes 1.13
|
||||
|
||||
Your Kubernetes cluster must allow privileged pods (i.e. `--allow-privileged` flag must be set to true for both the API server and the kubelet). Moreover, as stated in the [mount propagation docs](https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation), the Docker daemon of the cluster nodes must allow shared mounts.
|
||||
Your Kubernetes cluster must allow privileged pods (i.e. `--allow-privileged`
|
||||
flag must be set to true for both the API server and the kubelet). Moreover, as
|
||||
stated in the [mount propagation
|
||||
docs](https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation),
|
||||
the Docker daemon of the cluster nodes must allow shared mounts.
|
||||
|
||||
YAML manifests are located in `deploy/cephfs/kubernetes`.
|
||||
|
||||
@ -78,7 +93,9 @@ kubectl create -f csi-provisioner-rbac.yaml
|
||||
kubectl create -f csi-nodeplugin-rbac.yaml
|
||||
```
|
||||
|
||||
Those manifests deploy service accounts, cluster roles and cluster role bindings. These are shared for both RBD and CephFS CSI plugins, as they require the same permissions.
|
||||
Those manifests deploy service accounts, cluster roles and cluster role
|
||||
bindings. These are shared for both RBD and CephFS CSI plugins, as they require
|
||||
the same permissions.
|
||||
|
||||
**Deploy CSI sidecar containers:**
|
||||
|
||||
@ -87,7 +104,8 @@ kubectl create -f csi-cephfsplugin-attacher.yaml
|
||||
kubectl create -f csi-cephfsplugin-provisioner.yaml
|
||||
```
|
||||
|
||||
Deploys stateful sets for external-attacher and external-provisioner sidecar containers for CSI CephFS.
|
||||
Deploys stateful sets for external-attacher and external-provisioner
|
||||
sidecar containers for CSI CephFS.
|
||||
|
||||
**Deploy CSI CephFS driver:**
|
||||
|
||||
@ -95,7 +113,8 @@ Deploys stateful sets for external-attacher and external-provisioner sidecar con
|
||||
kubectl create -f csi-cephfsplugin.yaml
|
||||
```
|
||||
|
||||
Deploys a daemon set with two containers: CSI driver-registrar and the CSI CephFS driver.
|
||||
Deploys a daemon set with two containers: CSI driver-registrar and
|
||||
the CSI CephFS driver.
|
||||
|
||||
## Verifying the deployment in Kubernetes
|
||||
|
||||
@ -119,4 +138,7 @@ You can try deploying a demo pod from `examples/cephfs` to test the deployment f
|
||||
|
||||
### Notes on volume deletion
|
||||
|
||||
Volumes that were provisioned dynamically (i.e. `provisionVolume=true`) are allowed to be deleted by the driver as well, if the user chooses to do so. Otherwise, the driver is forbidden to delete such volumes - attempting to delete them is a no-op.
|
||||
Volumes that were provisioned dynamically (i.e. `provisionVolume=true`) are
|
||||
allowed to be deleted by the driver as well, if the user chooses to do
|
||||
so.Otherwise, the driver is forbidden to delete such volumes - attempting to
|
||||
delete them is a no-op.
|
||||
|
||||
@ -1,19 +1,25 @@
|
||||
# CSI RBD Plugin
|
||||
|
||||
The RBD CSI plugin is able to provision new RBD images and attach and mount those to worlkoads.
|
||||
The RBD CSI plugin is able to provision new RBD images and
|
||||
attach and mount those to worlkoads.
|
||||
|
||||
## Building
|
||||
|
||||
CSI RBD plugin can be compiled in a form of a binary file or in a form of a Docker image. When compiled as a binary file, the result is stored in `_output/` directory with the name `rbdplugin`. When compiled as an image, it's stored in the local Docker image store.
|
||||
CSI RBD plugin can be compiled in a form of a binary file or in a form of a
|
||||
Docker image. When compiled as a binary file, the result is stored in
|
||||
`_output/` directory with the name `rbdplugin`. When compiled as an image, it's
|
||||
stored in the local Docker image store.
|
||||
|
||||
Building binary:
|
||||
|
||||
```bash
|
||||
$ make rbdplugin
|
||||
make rbdplugin
|
||||
```
|
||||
|
||||
Building Docker image:
|
||||
|
||||
```bash
|
||||
$ make image-rbdplugin
|
||||
make image-rbdplugin
|
||||
```
|
||||
|
||||
## Configuration
|
||||
@ -31,9 +37,13 @@ Option | Default value | Description
|
||||
**Available environmental variables:**
|
||||
`HOST_ROOTFS`: rbdplugin searches `/proc` directory under the directory set by `HOST_ROOTFS`.
|
||||
|
||||
`KUBERNETES_CONFIG_PATH`: if you use `k8s_configmap` as metadata store, specify the path of your k8s config file (if not specified, the plugin will assume you're running it inside a k8s cluster and find the config itself).
|
||||
`KUBERNETES_CONFIG_PATH`: if you use `k8s_configmap` as metadata store, specify
|
||||
the path of your k8s config file (if not specified, the plugin will assume
|
||||
you're running it inside a k8s cluster and find the config itself).
|
||||
|
||||
`POD_NAMESPACE`: if you use `k8s_configmap` as metadata store, `POD_NAMESPACE` is used to define in which namespace you want the configmaps to be stored
|
||||
`POD_NAMESPACE`: if you use `k8s_configmap` as metadata store,
|
||||
`POD_NAMESPACE` is used to define in which namespace you want
|
||||
the configmaps to be stored
|
||||
|
||||
**Available volume parameters:**
|
||||
|
||||
@ -48,9 +58,11 @@ Parameter | Required | Description
|
||||
`csi.storage.k8s.io/provisioner-secret-namespace`, `csi.storage.k8s.io/node-publish-secret-namespace` | for Kubernetes | namespaces of the above Secret objects
|
||||
`mounter`| no | if set to `rbd-nbd`, use `rbd-nbd` on nodes that have `rbd-nbd` and `nbd` kernel modules to map rbd images
|
||||
|
||||
**Required secrets:**
|
||||
Admin credentials are required for provisioning new RBD images
|
||||
`ADMIN_NAME`: `ADMIN_PASSWORD` - note that the key of the key-value pair is the name of the client with admin privileges, and the value is its password
|
||||
**Required secrets:**
|
||||
|
||||
Admin credentials are required for provisioning new RBD images `ADMIN_NAME`:
|
||||
`ADMIN_PASSWORD` - note that the key of the key-value pair is the name of the
|
||||
client with admin privileges, and the value is its password
|
||||
|
||||
Also note that CSI RBD expects admin keyring and Ceph config file in `/etc/ceph`.
|
||||
|
||||
@ -58,33 +70,40 @@ Also note that CSI RBD expects admin keyring and Ceph config file in `/etc/ceph`
|
||||
|
||||
Requires Kubernetes 1.11
|
||||
|
||||
Your Kubernetes cluster must allow privileged pods (i.e. `--allow-privileged` flag must be set to true for both the API server and the kubelet). Moreover, as stated in the [mount propagation docs](https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation), the Docker daemon of the cluster nodes must allow shared mounts.
|
||||
Your Kubernetes cluster must allow privileged pods (i.e. `--allow-privileged`
|
||||
flag must be set to true for both the API server and the kubelet). Moreover, as
|
||||
stated in the [mount propagation
|
||||
docs](https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation),
|
||||
the Docker daemon of the cluster nodes must allow shared mounts.
|
||||
|
||||
YAML manifests are located in `deploy/rbd/kubernetes`.
|
||||
|
||||
**Deploy RBACs for sidecar containers and node plugins:**
|
||||
|
||||
```bash
|
||||
$ kubectl create -f csi-attacher-rbac.yaml
|
||||
$ kubectl create -f csi-provisioner-rbac.yaml
|
||||
$ kubectl create -f csi-nodeplugin-rbac.yaml
|
||||
kubectl create -f csi-attacher-rbac.yaml
|
||||
kubectl create -f csi-provisioner-rbac.yaml
|
||||
kubectl create -f csi-nodeplugin-rbac.yaml
|
||||
```
|
||||
|
||||
Those manifests deploy service accounts, cluster roles and cluster role bindings. These are shared for both RBD and CephFS CSI plugins, as they require the same permissions.
|
||||
Those manifests deploy service accounts, cluster roles and cluster role
|
||||
bindings. These are shared for both RBD and CephFS CSI plugins, as they require
|
||||
the same permissions.
|
||||
|
||||
**Deploy CSI sidecar containers:**
|
||||
|
||||
```bash
|
||||
$ kubectl create -f csi-rbdplugin-attacher.yaml
|
||||
$ kubectl create -f csi-rbdplugin-provisioner.yaml
|
||||
kubectl create -f csi-rbdplugin-attacher.yaml
|
||||
kubectl create -f csi-rbdplugin-provisioner.yaml
|
||||
```
|
||||
|
||||
Deploys stateful sets for external-attacher and external-provisioner sidecar containers for CSI RBD.
|
||||
Deploys stateful sets for external-attacher and external-provisioner
|
||||
sidecar containers for CSI RBD.
|
||||
|
||||
**Deploy RBD CSI driver:**
|
||||
|
||||
```bash
|
||||
$ kubectl create -f csi-rbdplugin.yaml
|
||||
kubectl create -f csi-rbdplugin.yaml
|
||||
```
|
||||
|
||||
Deploys a daemon set with two containers: CSI driver-registrar and the CSI RBD driver.
|
||||
@ -119,7 +138,7 @@ The Helm chart is located in `deploy/rbd/helm`.
|
||||
**Deploy Helm Chart:**
|
||||
|
||||
```bash
|
||||
$ helm install ./deploy/rbd/helm
|
||||
helm install ./deploy/rbd/helm
|
||||
```
|
||||
|
||||
The Helm chart deploys all of the required resources to use the CSI RBD driver.
|
||||
|
||||
Reference in New Issue
Block a user