This is a Container Storage Interface (CSI) for S3 (or S3 compatible) storage. This can dynamically allocate buckets and mount them via a fuse mount into any container.
- Kubernetes 1.17+
- Kubernetes has to allow privileged containers
- Docker daemon must allow shared mounts (systemd flag
MountFlags=shared)
Helm chart is published at https://yandex-cloud.github.io/k8s-csi-s3:
helm repo add yandex-s3 https://yandex-cloud.github.io/k8s-csi-s3/charts
helm install csi-s3 yandex-s3/csi-s3
apiVersion: v1
kind: Secret
metadata:
name: csi-s3-secret
# Namespace depends on the configuration in the storageclass.yaml
namespace: kube-system
stringData:
accessKeyID: <YOUR_ACCESS_KEY_ID>
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: ""The region can be empty if you are using some other S3 compatible storage.
cd deploy/kubernetes
kubectl create -f provisioner.yaml
kubectl create -f driver.yaml
kubectl create -f csi-s3.yamlIf you're upgrading from <= 0.35.5 - delete all resources from attacher.yaml:
wget https://raw.githubusercontent.com/yandex-cloud/k8s-csi-s3/v0.35.5/deploy/kubernetes/attacher.yaml
kubectl delete -f attacher.yaml
If you're upgrading from <= 0.40.6 - delete all resources from old provisioner.yaml:
wget -O old-provisioner.yaml https://raw.githubusercontent.com/yandex-cloud/k8s-csi-s3/v0.40.6/deploy/kubernetes/provisioner.yaml
kubectl delete -f old-provisioner.yamlThen reapply csi-s3.yaml, driver.yaml and provisioner.yaml:
cd deploy/kubernetes
kubectl apply -f provisioner.yaml
kubectl apply -f driver.yaml
kubectl apply -f csi-s3.yamlkubectl create -f examples/storageclass.yaml-
Create a pvc using the new storage class:
kubectl create -f examples/pvc.yaml
-
Check if the PVC has been bound:
$ 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
-
Create a test pod which mounts your volume:
kubectl create -f examples/pod.yaml
If the pod can start, everything should be working.
-
Test the mount
$ kubectl exec -ti csi-s3-test-nginx bash $ mount | grep fuse pvc-035763df-0488-4941-9a34-f637292eb95c: on /usr/share/nginx/html/s3 type fuse.geesefs (rw,nosuid,nodev,relatime,user_id=65534,group_id=0,default_permissions,allow_other) $ touch /usr/share/nginx/html/s3/hello_world
If something does not work as expected, check the troubleshooting section below.
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:
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: csi-s3-existing-bucket
provisioner: ru.yandex.s3.csi
parameters:
mounter: geesefs
options: "--memory-limit 1000 --dir-mode 0777 --file-mode 0666"
bucket: some-existing-bucket-nameIf 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.
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.
We strongly recommend to use the default mounter which is GeeseFS.
However there is also support for two other backends: s3fs and rclone.
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.
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.
You can check POSIX compatibility matrix here: https://github.com/yandex-cloud/geesefs#posix-compatibility-matrix.
- Almost full POSIX compatibility
- Good performance for both small and big files
- Does not store file permissions and custom modification times
- 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-systemdtoparameters.optionsof theStorageClassto disable this behaviour.
- Almost full POSIX compatibility
- Good performance for big files, poor performance for small files
- Very slow for directories with a large number of files
- Poor POSIX compatibility
- Bad performance for big files, okayish performance for small files
- Doesn't create directory objects like s3fs or GeeseFS
- May hang :-)
Check the logs of the provisioner:
kubectl logs -l app=csi-provisioner-s3 -c csi-s3- Ensure feature gate
MountPropagationis not set tofalse - Check the logs of the s3-driver:
kubectl logs -l app=csi-s3 -c csi-s3This project can be built like any other go application.
go get -u github.com/yandex-cloud/k8s-csi-s3make buildCurrently the driver is tested by the CSI Sanity Tester. 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:
make test
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent