We then integrated this ThirdPartyResource into our Skipper API, allowing our developers to automatically have EFS backed deployments.

At the time of writing this post we are managing 100 AWS EFS volumes with this implementation.

While this has worked great for us, we acknowledged that this approach would not be ideal for the Kubernetes community as developers would be required to have knowledge of the infrastructure the cluster is running on, such as:

Not only has this approach allowed us to decouple our applications from the storage layer, but it also allowed us to move away from our ThirdPartyResource definition and command-line client, meaning less code to maintain!

So, how do you use our AWS EFS Storage Class?

First, we declare our Storage Classes. I think of these as aliases for our storage, allowing us to decouple the hosting provider from the deployment.

For example, a Storage Class named “general” could be provisioned by “EFS: General Purpose” on AWS or “Azure File Storage” on Microsoft Azure.