ReadWriteMany - Dynamically Provisioned Persistent Volumes Using Amazon EFS
The efs-provisioner allows you to mount EFS storage as PersistentVolumes in kubernetes. It consists of a container that has access to an AWS EFS resource. The container reads a configmap containing the EFS filesystem ID, the AWS region and the name identifying the efs-provisioner. This name will be used later when you create a storage class.
- When you have application running on multiple nodes which require shared access to a file system
- When you have an application that requires multiple virtual machines to access the same file system at the same time, AWS EFS is a tool that you can use.
- EFS supports encryption.
- EFS is SSD based storage and its storage capacity and pricing will scale in or out as needed, so there is no need for the system administrator to do additional operations. It can grow to a petabyte scale.
- EFS now supports NFSv4 lock upgrading and downgrading, so yes, you can use sqlite with EFS… even if it was possible before.
- Easy to setup
Why Not EFS
- Sometimes when you think about using a service like EFS, you may also think about vendor lock-in and its negative sides
- Making an EFS backup may decrease your production FS performance; the throughput used by backup counts towards your total file system throughput.
- EFS is expensive compared to EBS (roughly twice the price of EBS storage)
- EFS is not the magical solution for all your distributed FS problems, it can be slow in many cases. Test, benchmark and measure to ensure your if EFS is a good solution for your use case.
- EFS distributed architecture results in a latency overhead for each file read/write operation.
- If you have the possibility to use a CDN, don’t use EFS, use it for the files which can’t be stored in a CDN.
- Don’t use EFS as a caching system, sometimes you could be doing this unintentionally.
- Last but not least, even if EFS is a fully managed NFS, you will face performance problems in many cases, resolving them takes time and needs effort.