2018-07-14 08:52:55 +00:00
# CSI for S3
2019-05-14 19:53:44 +00:00
2018-07-14 08:52:55 +00:00
This is a Container Storage Interface ([CSI](https://github.com/container-storage-interface/spec/blob/master/spec.md)) for S3 (or S3 compatible) storage. This can dynamically allocate buckets and mount them via a fuse mount into any container.
2018-07-14 08:48:22 +00:00
2019-05-14 19:53:44 +00:00
## Kubernetes installation
### Requirements
2022-06-22 13:29:28 +00:00
* Kubernetes 1.17+
2018-07-14 08:48:22 +00:00
* Kubernetes has to allow privileged containers
* Docker daemon must allow shared mounts (systemd flag `MountFlags=shared` )
2019-05-14 19:53:44 +00:00
### 1. Create a secret with your S3 credentials
2018-07-14 08:48:22 +00:00
```yaml
apiVersion: v1
kind: Secret
metadata:
name: csi-s3-secret
2020-06-03 04:08:27 +00:00
# Namespace depends on the configuration in the storageclass.yaml
namespace: kube-system
2018-07-14 08:48:22 +00:00
stringData:
accessKeyID: < YOUR_ACCESS_KEY_ID >
2021-07-27 11:54:17 +00:00
secretAccessKey: < YOUR_SECRET_ACCESS_KEY >
# For AWS set it to "https://s3.< region > .amazonaws.com", for example https://s3.eu-central-1.amazonaws.com
endpoint: https://storage.yandexcloud.net
# For AWS set it to AWS region
#region: ""
2023-03-10 15:40:17 +00:00
# For S3-compatible set it to bucket lookup style (choices: Auto [default], DNS, Path)
#bucketLookup: ""
2018-07-14 08:48:22 +00:00
```
2019-05-15 18:42:50 +00:00
The region can be empty if you are using some other S3 compatible storage.
2019-05-14 19:53:44 +00:00
### 2. Deploy the driver
2018-07-14 08:48:22 +00:00
```bash
cd deploy/kubernetes
2019-05-14 19:53:44 +00:00
kubectl create -f provisioner.yaml
kubectl create -f attacher.yaml
kubectl create -f csi-s3.yaml
2018-07-14 08:48:22 +00:00
```
2019-05-14 19:53:44 +00:00
### 3. Create the storage class
2018-07-14 08:48:22 +00:00
```bash
2021-04-05 13:07:16 +00:00
kubectl create -f examples/storageclass.yaml
2018-07-14 08:48:22 +00:00
```
2019-05-14 19:53:44 +00:00
### 4. Test the S3 driver
2019-05-15 19:14:18 +00:00
1. Create a pvc using the new storage class:
2019-05-14 19:53:44 +00:00
2021-04-05 13:12:31 +00:00
```bash
kubectl create -f examples/pvc.yaml
```
2019-05-14 19:53:44 +00:00
2021-04-05 13:07:16 +00:00
1. Check if the PVC has been bound:
2019-05-14 19:53:44 +00:00
2021-04-05 13:12:31 +00:00
```bash
$ kubectl get pvc csi-s3-pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
csi-s3-pvc Bound pvc-c5d4634f-8507-11e8-9f33-0e243832354b 5Gi RWO csi-s3 9s
```
2019-05-14 19:53:44 +00:00
2021-04-05 13:07:16 +00:00
1. Create a test pod which mounts your volume:
2019-05-14 19:53:44 +00:00
2021-04-05 13:12:31 +00:00
```bash
kubectl create -f examples/pod.yaml
```
2019-05-14 19:53:44 +00:00
2021-04-05 13:12:31 +00:00
If the pod can start, everything should be working.
2018-07-14 08:48:22 +00:00
2021-04-05 13:07:16 +00:00
1. Test the mount
2019-05-14 19:53:44 +00:00
2021-04-05 13:12:31 +00:00
```bash
$ kubectl exec -ti csi-s3-test-nginx bash
$ mount | grep fuse
s3fs on /var/lib/www/html type fuse.s3fs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
$ touch /var/lib/www/html/hello_world
```
2019-05-14 19:53:44 +00:00
2018-07-14 08:48:22 +00:00
If something does not work as expected, check the troubleshooting section below.
2019-05-14 19:53:44 +00:00
## Additional configuration
2021-04-05 13:07:16 +00:00
### Bucket
By default, csi-s3 will create a new bucket per volume. The bucket name will match that of the volume ID. If you want your volumes to live in a precreated bucket, you can simply specify the bucket in the storage class parameters:
```yaml
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: csi-s3-existing-bucket
2021-07-27 10:05:32 +00:00
provisioner: ru.yandex.s3.csi
2021-04-05 13:07:16 +00:00
parameters:
2021-07-27 11:34:43 +00:00
mounter: geesefs
2023-03-02 13:12:41 +00:00
options: "--memory-limit 1000 --dir-mode 0777 --file-mode 0666"
2021-04-05 13:07:16 +00:00
bucket: some-existing-bucket-name
```
If the bucket is specified, it will still be created if it does not exist on the backend. Every volume will get its own prefix within the bucket which matches the volume ID. When deleting a volume, also just the prefix will be deleted.
2022-12-21 13:14:26 +00:00
### Static Provisioning
If you want to mount a pre-existing bucket or prefix within a pre-existing bucket and don't want csi-s3 to delete it when PV is deleted, you can use static provisioning.
To do that you should omit `storageClassName` in the `PersistentVolumeClaim` and manually create a `PersistentVolume` with a matching `claimRef` , like in the following example: [deploy/kubernetes/examples/pvc-manual.yaml ](deploy/kubernetes/examples/pvc-manual.yaml ).
2019-05-14 19:53:44 +00:00
### Mounter
2022-06-22 13:29:28 +00:00
We **strongly recommend** to use the default mounter which is [GeeseFS ](https://github.com/yandex-cloud/geesefs ).
2018-08-06 17:27:24 +00:00
2022-06-22 13:29:28 +00:00
However there is also support for two other backends: [s3fs ](https://github.com/s3fs-fuse/s3fs-fuse ) and [rclone ](https://rclone.org/commands/rclone_mount ).
2018-07-22 10:59:30 +00:00
2018-07-29 12:54:28 +00:00
The mounter can be set as a parameter in the storage class. You can also create multiple storage classes for each mounter if you like.
2022-06-22 13:29:28 +00:00
As S3 is not a real file system there are some limitations to consider here.
Depending on what mounter you are using, you will have different levels of POSIX compability.
Also depending on what S3 storage backend you are using there are not always [consistency guarantees ](https://github.com/gaul/are-we-consistent-yet#observed-consistency ).
You can check POSIX compatibility matrix here: https://github.com/yandex-cloud/geesefs#posix-compatibility-matrix.
2018-07-22 10:59:30 +00:00
2021-07-26 11:51:19 +00:00
#### GeeseFS
2019-05-14 19:53:44 +00:00
2021-07-26 11:51:19 +00:00
* Almost full POSIX compatibility
* Good performance for both small and big files
2022-06-22 13:29:28 +00:00
* Does not store file permissions and custom modification times
2023-03-02 13:12:41 +00:00
* By default runs **outside** of the csi-s3 container using systemd, to not crash
mountpoints with "Transport endpoint is not connected" when csi-s3 is upgraded
or restarted. Add `--no-systemd` to `parameters.options` of the `StorageClass`
to disable this behaviour.
2019-03-07 19:27:02 +00:00
2019-05-14 19:53:44 +00:00
#### s3fs
2021-07-26 11:51:19 +00:00
* Almost full POSIX compatibility
* Good performance for big files, poor performance for small files
2022-06-22 13:29:28 +00:00
* Very slow for directories with a large number of files
2018-07-22 10:59:30 +00:00
2021-07-26 11:51:19 +00:00
#### rclone
2019-05-14 19:53:44 +00:00
2022-06-22 13:29:28 +00:00
* Poor POSIX compatibility
2021-07-26 11:51:19 +00:00
* Bad performance for big files, okayish performance for small files
* Doesn't create directory objects like s3fs or GeeseFS
2022-06-22 13:29:28 +00:00
* May hang :-)
2018-07-22 10:59:30 +00:00
2019-05-14 19:53:44 +00:00
## Troubleshooting
### Issues while creating PVC
2019-05-15 19:14:18 +00:00
Check the logs of the provisioner:
2019-05-14 19:53:44 +00:00
```bash
kubectl logs -l app=csi-provisioner-s3 -c csi-s3
2018-07-14 08:48:22 +00:00
```
2019-05-14 19:53:44 +00:00
### Issues creating containers
2019-05-15 19:14:18 +00:00
1. Ensure feature gate `MountPropagation` is not set to `false`
2. Check the logs of the s3-driver:
2019-05-14 19:53:44 +00:00
```bash
kubectl logs -l app=csi-s3 -c csi-s3
2018-07-14 08:48:22 +00:00
```
2019-05-14 19:53:44 +00:00
## Development
2018-07-14 08:48:22 +00:00
This project can be built like any other go application.
2019-05-14 19:53:44 +00:00
2018-07-14 08:48:22 +00:00
```bash
2021-08-24 10:33:26 +00:00
go get -u github.com/yandex-cloud/k8s-csi-s3
2018-07-14 08:48:22 +00:00
```
2019-05-14 19:53:44 +00:00
### Build executable
2018-07-14 08:48:22 +00:00
```bash
2019-05-14 19:53:44 +00:00
make build
2018-07-14 08:48:22 +00:00
```
2019-05-14 19:53:44 +00:00
### Tests
2018-07-14 08:48:22 +00:00
Currently the driver is tested by the [CSI Sanity Tester ](https://github.com/kubernetes-csi/csi-test/tree/master/pkg/sanity ). As end-to-end tests require S3 storage and a mounter like s3fs, this is best done in a docker container. A Dockerfile and the test script are in the `test` directory. The easiest way to run the tests is to just use the make command:
2019-05-14 19:53:44 +00:00
2018-07-14 08:48:22 +00:00
```bash
2019-05-14 19:53:44 +00:00
make test
2018-07-14 08:48:22 +00:00
```