Illumina Innovates with Rancher and Kubernetes
When deploying an application that needs to retain data, you’ll need to create persistent storage. Persistent storage allows you to store application data external from the pod running your application. This storage practice allows you to maintain application data, even if the application’s pod fails.
The documents in this section assume that you understand the Kubernetes concepts of persistent volumes, persistent volume claims, and storage classes. For more information, refer to the section on how storage works.
To set up persistent storage, the Manage Volumes role is required.
If you are provisioning storage for a cluster hosted in the cloud, the storage and cluster hosts must have the same cloud provider.
For provisioning new storage with Rancher, the cloud provider must be enabled. For details on enabling cloud providers, refer to this page.
For attaching existing persistent storage to a cluster, the cloud provider does not need to be enabled.
The overall workflow for setting up existing storage is as follows:
For details and prerequisites, refer to this page.
The overall workflow for provisioning new storage is as follows:
We provide examples of how to provision storage with NFS, vSphere, and Amazon’s EBS.
In clusters that store data on GlusterFS volumes, you may experience an issue where pods fail to mount volumes after restarting the kubelet. For details on preventing this from happening, refer to this page.
In Rancher Launched Kubernetes clusters that store data on iSCSI volumes, you may experience an issue where kubelets fail to automatically connect with iSCSI volumes. For details on resolving this issue, refer to this page.
Before you create a hostPath volume, you need to set up an extra_bind in your cluster configuration. This will mount the path as a volume in your kubelets, which can then be used for hostPath volumes in your workloads.