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.
@@ -121,16 +117,7 @@ All mounters have different strengths and weaknesses depending on your use case.
* Files can be viewed normally with any S3 client
* Does not support appends or random writes
#### s3ql (not recommended*)
* (Almost) full POSIX compatibility
* Uses its own object format
* Files are not readable with other S3 clients
* Support appends
* Supports compression before upload
* Supports encryption before upload
#### s3backer (not recommended*)
#### s3backer (experimental*)
* Represents a block device stored on S3
* Allows to use a real filesystem
@@ -139,7 +126,8 @@ All mounters have different strengths and weaknesses depending on your use case.
* Supports compression before upload (Not yet implemented in this driver)
* Supports encryption before upload (Not yet implemented in this driver)
*s3ql and s3backer are not recommended at this point because volume corruption can occur pretty quickly in case of an unexpected shutdown of a Kubernetes node or CSI pod.
*s3backer is experimental at this point because volume corruption can occur pretty quickly in case of an unexpected shutdown of a Kubernetes node or CSI pod.
The s3backer binary is not bundled with the normal docker image to keep that as small as possible. Use the `<version>-full` image tag for testing s3backer.
Fore more detailed limitations consult the documentation of the different projects.