This is a Container Storage Interface (CSI) for S3 (or S3 compatible) storage and using Goofys Mounter. This can dynamically allocate buckets and mount them via Goofys FUSE into any container.
This is still very experimental and should not be used in any production environment. Unexpected data loss could occur depending on what mounter and S3 storage backend is being used.
- AWS EKS 1.14+
- Kubernetes 1.13+ (CSI v1.0.0 compatibility)
- Kubernetes has to allow privileged containers
- Docker daemon must allow shared mounts (systemd flag
MountFlags=shared
)
These 3 command will create 3 IAM roles with AmazonS3FullAccess access policy and associate a new Kubernetes Service Account.
eksctl create iamserviceaccount \
--name csi-attacher-sa \
--namespace kube-system \
--cluster <your_cluster_name> \
--attach-policy-arn arn:aws-cn:iam::aws:policy/AmazonS3FullAccess \
--approve \
--override-existing-serviceaccounts
eksctl create iamserviceaccount \
--name csi-s3-sa \
--namespace kube-system \
--cluster <your_cluster_name> \
--attach-policy-arn arn:aws-cn:iam::aws:policy/AmazonS3FullAccess \
--approve \
--override-existing-serviceaccounts
eksctl create iamserviceaccount \
--name csi-provisioner-sa \
--namespace kube-system \
--cluster <your_cluster_name> \
--attach-policy-arn arn:aws-cn:iam::aws:policy/AmazonS3FullAccess \
--approve \
--override-existing-serviceaccounts
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 attacher.yaml
kubectl create -f csi-s3.yaml
kubectl create -f storageclass.yaml
- Create a pvc using the new storage class:
kubectl create -f 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 busybox_pod_1.yaml
kubectl create -f busybox_pod_2.yaml
If the pod can start, everything should be working.
- Test the mount
$ kubectl exec -ti busybox-1 sh
$ mount | grep fuse
pvc-1a959cb4-603f-11ea-af00-021e45d100ce:csi-fs on /data type fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)
$ touch /data/hello_world
If something does not work as expected, check the troubleshooting section below.
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.
The driver can be configured to use one of these mounters to mount buckets:
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.
All mounters have different strengths and weaknesses depending on your use case. Here are some characteristics which should help you choose a mounter:
- Weak POSIX compatibility
- Performance first
- Files can be viewed normally with any S3 client
- Does not support appends or random writes
Check the logs of the provisioner:
kubectl logs -l app=csi-provisioner-s3 -c csi-s3
- Ensure feature gate
MountPropagation
is not set tofalse
- Check the logs of the s3-driver:
kubectl logs -l app=csi-s3 -c csi-s3
This project can be built like any other go application.
go get -u github.com/zorrofox/csi-s3
make build
Currently 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