mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-12 04:05:50 +00:00
Merge pull request #2189 from catherineluse/storage
Rewrite storage section
This commit is contained in:
Catherine Luse
@@ -6,227 +6,47 @@ aliases:
|
||||
- /rancher/v2.x/en/concepts/volumes-and-storage/
|
||||
- /rancher/v2.x/en/tasks/clusters/adding-storage/
|
||||
- /rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/
|
||||
- /rancher/v2.x/en/cluster-admin/volumes-and-storage/persistent-volume-claims/
|
||||
---
|
||||
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.
|
||||
|
||||
There are two ways to create persistent storage in Kubernetes: Persistent Volumes (PVs) and Storage Classes.
|
||||
Rancher can only manage storage in clusters [created with RKE.]({{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/)
|
||||
|
||||
## Persistent Volumes
|
||||
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.](./how-storage-works)
|
||||
|
||||
_Persistent Volumes_ are pre-provisioned storage volumes that you can bind to pods later. Each pre-provisioned volume corresponds to a Kubernetes persistent volume. When you start your application, it creates Persistent Volume Claims (PVCs) that bind to persistent volumes. A PVC corresponds to a Docker volume. Each PVC binds to one PV that includes the minimum resources that the PVC requires. The following figure illustrates the relationship between pods, PVCs, PVs, and the underlying cloud storage.
|
||||
### Setting up Existing Storage
|
||||
|
||||
|
||||
The overall workflow for setting up existing storage is as follows:
|
||||
|
||||
Rancher allows you to create PVs at the cluster level and bind them to PVCs later. Volumes are managed on a per-project basis.
|
||||
1. Set up persistent storage in an infrastructure provider.
|
||||
2. Add a persistent volume (PV) that refers to the persistent storage.
|
||||
3. Add a persistent volume claim (PVC) that refers to the PV.
|
||||
4. Mount the PVC as a volume in your workload.
|
||||
|
||||
## Storage Classes
|
||||
For details and prerequisites, refer to [this page.](./attaching-existing-storage)
|
||||
|
||||
Storage Classes allow you to create PVCs dynamically without having to create PVs first. For example, an Amazon EBS Storage Class will dynamically create EBS volumes and bind them to PVCs. A Storage Class is similar to the notion of a _storage driver_. The following figure illustrates how a PVC creation triggers the dynamic provisioning of an underlying EBS volume.
|
||||
### Dynamically Provisioning New Storage in Rancher
|
||||
|
||||
|
||||
The overall workflow for provisioning new storage is as follows:
|
||||
|
||||
1. Add a storage class and configure it to use your storage provider.
|
||||
2. Add a persistent volume claim (PVC) that refers to the storage class.
|
||||
3. Mount the PVC as a volume for your workload.
|
||||
|
||||
### Storage and Cloud Providers
|
||||
For details and prerequisites, refer to [this page.](./provisioning-new-storage)
|
||||
|
||||
When you provision persistent storage for a cluster [launched by RKE]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters), you must host your storage with the same provider that hosts the cluster. For example, if you're hosting your cluster on Amazon EC2, you must host your storage on Amazon EBS. To setup storage for your RKE-launched cluster, you must complete two tasks: enabling the **Cloud Provider** option for your cluster, and adding storage using the same provider.
|
||||
### Provisioning Storage Examples
|
||||
|
||||
<sup>Enabling Cloud Provider Option/Choosing Storage Provider</sup>
|
||||
|
||||
We provide examples of how to provision storage with [NFS,](./examples/nfs) [vSphere,](./examples/vsphere) and [Amazon's EBS.](./examples/nfs)
|
||||
|
||||
Before you set up storage for a cluster launched by RKE, make sure that the **Cloud Provider** option for the cluster is enabled. [Cloud providers]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/) are modules that allow you to use the provider's features in Rancher (like provisioning persistent storage).
|
||||
### GlusterFS Volumes
|
||||
|
||||
You can turn on the **Cloud Provider** option in one of two contexts:
|
||||
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.](./glusterfs-volumes)
|
||||
|
||||
- [When provisioning your cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning)
|
||||
- [When editing your cluster]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/editing-clusters)
|
||||
### iSCSI Volumes
|
||||
|
||||
When you begin setting up a [persistent volume](#adding-persistent-volumes) or [storage class](#adding-storage-classes), you can choose the storage plugin or provisioner for your cloud provider.
|
||||
In [Rancher Launched Kubernetes clusters]({{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-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.](./iscsi-volumes)
|
||||
|
||||
#### Storage Classes and Cloud Providers
|
||||
### Related Links
|
||||
|
||||
Additionally, storage classes feature a few extra settings for cloud providers.
|
||||
|
||||
Each storage class contains the fields `provisioner`, `parameters`, and `reclaimPolicy`, which are used when a persistent volume that belongs to the class needs to be dynamically provisioned.
|
||||
|
||||
The `provisioner` determines which volume plugin is used to provision the persistent volumes.
|
||||
|
||||
{{% accordion id="provisioners" label="Enabled Storage Class Provisioners" %}}
|
||||
- Amazon EBS Disk
|
||||
- AzureFile
|
||||
- AzureDisk
|
||||
- Google Persistent Disk
|
||||
- Longhorn
|
||||
- Vmware vSphere Volume
|
||||
- Local
|
||||
|
||||
{{% /accordion %}}
|
||||
<br/>
|
||||
|
||||
In addition to customizing each provisioner's options for the storage class, you can also define the volume `reclaimPolicy`. There are two options available:
|
||||
|
||||
- Delete volumes and underlying device when released by workloads.
|
||||
- Retain the volume for manual cleanup.
|
||||
|
||||
Finally, you can define custom `MountOptions` for the persistent volume created.
|
||||
|
||||
`parameters` are specific to each cloud storage provisioner. For full information about the storage classes provisioner parameters, refer to the official [Kubernetes documentation](https://kubernetes.io/docs/concepts/storage/storage-classes/#parameters).
|
||||
|
||||
### Adding Persistent Volumes
|
||||
|
||||
Your containers can store data on themselves, but if a container fails, that data is lost. To solve this issue, Kubernetes offers _persistent volumes_, which are external storage disks or file systems that your containers can access. If a container crashes, its replacement container can access the data in a persistent volume without any data loss.
|
||||
|
||||
Persistent volumes can either be a disk or file system that you host on premise, or they can be hosted by a vendor, such as Amazon EBS or Azure Disk.
|
||||
|
||||
>**Prerequisites:**
|
||||
>
|
||||
>- Permissions: `Manage Volumes` [role]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-role-reference)
|
||||
>- You must have [storage provisioned]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/).
|
||||
>- If provisioning storage for a cluster hosted in the cloud:
|
||||
>
|
||||
> - The storage and cluster hosts must be the [same provider](#storage-and-cloud-providers).
|
||||
> - The [cloud providers]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/) option must be enabled.
|
||||
|
||||
|
||||
1. From the **Global** view, open the cluster running the containers that you want to add persistent volume storage to.
|
||||
|
||||
1. From the main menu, select **Storage > Persistent Volumes**.
|
||||
|
||||
1. Click **Add Volume**.
|
||||
|
||||
1. Enter a **Name** for the persistent volume.
|
||||
|
||||
1. Select the **Volume Plugin** for the disk type or service that you're using.
|
||||
|
||||
>**Note:** When adding storage to a cluster that's hosted by a cloud provider:
|
||||
>
|
||||
>- You must enable the [cloud provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/) option for the cluster.
|
||||
>- You must use the cloud provider's plug-in for cloud storage. For example, if you have a Amazon EC2 cluster and you want to use cloud storage for it:
|
||||
>
|
||||
> - You must enable the `cloud provider` option for the EC2 cluster.
|
||||
> - You must use the `Amazon EBS Disk` volume plugin.
|
||||
|
||||
1. Enter the **Capacity** of your volume in gigabytes.
|
||||
|
||||
1. Complete the **Plugin Configuration** form. Each plugin type requires information specific to the vendor of disk type. For help regarding each plugin's form and the information that's required, refer to the plug-in's vendor documentation.
|
||||
|
||||
1. **Optional:** Complete the **Customize** form. This form features:
|
||||
|
||||
- [Access Modes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes):
|
||||
|
||||
This options sets how many nodes can access the volume, along with the node read/write permissions. The [Kubernetes Documentation](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes) includes a table that lists which access modes are supported by the plugins available.
|
||||
|
||||
- [Mount Options](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#mount-options):
|
||||
|
||||
Each volume plugin allows you to specify additional command line options during the mounting process. You can enter these options in the **Mount Option** fields. Consult each plugin's vendor documentation for the mount options available.
|
||||
|
||||
- **Assign to Storage Class:**
|
||||
|
||||
If you later want to automatically provision persistent volumes identical to the volume that you've specified here, assign it a storage class. Later, when you create a workload, you can assign it a persistent volume claim that references the storage class, which will provision a persistent volume identical to the volume you've specified here.
|
||||
|
||||
>**Note:** You must [add a storage class](#adding-storage-classes) before you can assign it to a persistent volume.
|
||||
|
||||
1. Click **Save**.
|
||||
|
||||
**Result:** Your new persistent volume is created.
|
||||
|
||||
|
||||
### Adding Storage Classes
|
||||
|
||||
_Storage Classes_ allow you to dynamically provision persistent volumes on demand. Think of storage classes as storage profiles that are created automatically upon a request (which is known as a _persistent volume claim_).
|
||||
|
||||
>**Prerequisites:**
|
||||
>
|
||||
>- Permissions: `Manage Volumes` [role]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-role-reference)
|
||||
>- You must have [storage provisioned]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/).
|
||||
>- If provisioning storage for a cluster hosted in the cloud:
|
||||
>
|
||||
> - The storage and cluster hosts must be the [same provider](#storage-and-cloud-providers).
|
||||
> - The [cloud providers]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/) option must be enabled.
|
||||
|
||||
1. From the **Global** view, open the cluster for which you want to dynamically provision persistent storage volumes.
|
||||
|
||||
1. From the main menu, select `Storage > Storage Classes`. Click `Add Class`.
|
||||
|
||||
1. Enter a `Name` for your storage class.
|
||||
|
||||
1. From the `Provisioner` drop-down, select the service that you want to use to dynamically provision storage volumes.
|
||||
|
||||
>**Note:** If the cluster you are adding a storage class for is a cloud service that also offers cloud storage, you must enable the `cloud provider` option for the cluster, and you must use the service's plug-in to use cloud storage. For example, if you have a Amazon EC2 cluster and you want to use cloud storage for it:
|
||||
>
|
||||
> - You must enable the `cloud provider` option for the EC2 cluster.
|
||||
> - You must use the `Amazon EBS Disk` provisioner.
|
||||
|
||||
1. From the `Parameters` section, fill out the information required for the service to dynamically provision storage volumes. Each provisioner requires different information to dynamically provision storage volumes. Consult the service's documentation for help on how to obtain this information.
|
||||
|
||||
1. Click `Save`.
|
||||
|
||||
## iSCSI Volumes With Rancher Launched Kubernetes Clusters
|
||||
|
||||
In [Rancher Launched Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) that store data on iSCSI volumes, you may experience an issue where kubelets fail to automatically connect with iSCSI volumes. This failure is likely due to an incompatibility issue involving the iSCSI initiator tool. You can resolve this issue by installing the iSCSI initiator tool on each of your cluster nodes.
|
||||
|
||||
Rancher Launched Kubernetes clusters storing data on iSCSI volumes leverage the [iSCSI initiator tool](http://www.open-iscsi.com/), which is embedded in the kubelet's `rancher/hyperkube` Docker image. From each kubelet (i.e., the _initiator_), the tool discovers and launches sessions with an iSCSI volume (i.e., the _target_). However, in some instances, the versions of the iSCSI initiator tool installed on the initiator and the target may not match, resulting in a connection failure.
|
||||
|
||||
|
||||
If you encounter this issue, you can work around it by installing the initiator tool on each node in your cluster. You can install the iSCSI initiator tool by logging into your cluster nodes and entering one of the following commands:
|
||||
|
||||
| Platform | Package Name | Install Command |
|
||||
| ------------- | ----------------------- | -------------------------------------- |
|
||||
| Ubuntu/Debian | `open-iscsi` | `sudo apt install open-iscsi` |
|
||||
| RHEL | `iscsi-initiator-utils` | `yum install iscsi-initiator-utils -y` |
|
||||
|
||||
|
||||
<br/>
|
||||
After installing the initiator tool on your nodes, edit the YAML for your cluster, editing the kubelet configuration to mount the iSCSI binary and configuration, as shown in the sample below.
|
||||
|
||||
>**Note:**
|
||||
>
|
||||
>Before updating your Kubernetes YAML to mount the iSCSI binary and configuration, make sure either the `open-iscsi` (deb) or `iscsi-initiator-utils` (yum) package is installed on your cluster nodes. If this package isn't installed _before_ the bind mounts are created in your Kubernetes YAML, Docker will automatically create the directories and files on each node and will not allow the package install to succeed.
|
||||
|
||||
```
|
||||
services:
|
||||
kubelet:
|
||||
extra_binds:
|
||||
- "/etc/iscsi:/etc/iscsi"
|
||||
- "/sbin/iscsiadm:/sbin/iscsiadm"
|
||||
```
|
||||
|
||||
## GlusterFS Volumes With Rancher Launched Kubernetes Clusters
|
||||
|
||||
In [Rancher Launched Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) that store data on GlusterFS volumes, you may experience an issue where pods fail to mount volumes after restarting the `kubelet`. The logging of the `kubelet` will show: `transport endpoint is not connected`. To prevent this from happening, you can configure your cluster to mount the `systemd-run` binary in the `kubelet` container. There are two requirements before you can change the cluster configuration:
|
||||
|
||||
- The node needs to have the `systemd-run` binary installed (this can be checked by using the command `which systemd-run` on each cluster node)
|
||||
- The `systemd-run` binary needs to be compatible with Debian OS on which the hyperkube image is based (this can be checked using the following command on each cluster node, replacing the image tag with the Kubernetes version you want to use)
|
||||
|
||||
```
|
||||
docker run -v /usr/bin/systemd-run:/usr/bin/systemd-run --entrypoint /usr/bin/systemd-run rancher/hyperkube:v1.16.2-rancher1 --version
|
||||
```
|
||||
|
||||
>**Note:**
|
||||
>
|
||||
>Before updating your Kubernetes YAML to mount the `systemd-run` binary, make sure the `systemd` package is installed on your cluster nodes. If this package isn't installed _before_ the bind mounts are created in your Kubernetes YAML, Docker will automatically create the directories and files on each node and will not allow the package install to succeed.
|
||||
|
||||
```
|
||||
services:
|
||||
kubelet:
|
||||
extra_binds:
|
||||
- "/usr/bin/systemd-run:/usr/bin/systemd-run"
|
||||
```
|
||||
|
||||
After the cluster has finished provisioning, you can check the `kubelet` container logging to see if the functionality is activated by looking for the following logline:
|
||||
|
||||
```
|
||||
Detected OS with systemd
|
||||
```
|
||||
|
||||
## What's Next?
|
||||
|
||||
Mount Persistent Volumes to workloads so that your applications can store their data. You can mount a either a manually created Persistent Volumes or a dynamically created Persistent Volume, which is created from a a Storage Class.
|
||||
|
||||
You can mount Persistent Volumes in one of two contexts:
|
||||
|
||||
- During deployment of a workload (recommended if possible). For more information, see [Deploying Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/).
|
||||
- Following workload creation. For more information, see [Adding Persistent Volume Claims]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/persistent-volume-claims/).
|
||||
|
||||
## Related Links
|
||||
|
||||
- [Kubernetes Documentation: Storage](https://kubernetes.io/docs/concepts/storage/)
|
||||
- [Kubernetes Documentation: Storage](https://kubernetes.io/docs/concepts/storage/)
|
||||
+103
@@ -0,0 +1,103 @@
|
||||
---
|
||||
title: Setting up Existing Storage
|
||||
weight: 1
|
||||
---
|
||||
|
||||
This section describes how to set up existing persistent storage for workloads in Rancher.
|
||||
|
||||
> This section assumes that you understand the Kubernetes concepts of persistent volumes and persistent volume claims. For more information, refer to the section on [how storage works.](../how-storage-works)
|
||||
|
||||
To set up storage, follow these steps:
|
||||
|
||||
1. [Set up persistent storage in an infrastructure provider.](#1-set-up-persistent-storage-in-an-infrastructure-provider)
|
||||
2. [Add a persistent volume that refers to the persistent storage.](#2-add-a-persistent-volume-that-refers-to-the-persistent-storage)
|
||||
3. [Add a persistent volume claim that refers to the persistent volume.](#3-add-a-persistent-volume-claim-that-refers-to-the-persistent-volume)
|
||||
4. [Mount the persistent volume claim as a volume in your workload.](#4-mount-the-persistent-storage-claim-as-a-volume-in-your-workload)
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- Rancher can only dynamically provision new storage in clusters [created with RKE.]({{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/)
|
||||
- To create a persistent volume as a Kubernetes resource, you must have the `Manage Volumes` [role.]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-role-reference)
|
||||
- If you are provisioning storage for a cluster hosted in the cloud, the storage and cluster hosts must have the same cloud provider, and the cloud provider must be enabled. The cloud provider must be enabled when the cluster is provisioned. For details on enabling cloud providers, refer to [this page.]({{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/)
|
||||
|
||||
### 1. Set up persistent storage in an infrastructure provider
|
||||
|
||||
Creating a persistent volume in Rancher will not create a storage volume. It only creates a Kubernetes resource that maps to an existing volume. Therefore, before you can create a persistent volume as a Kubernetes resource, you must have storage provisioned.
|
||||
|
||||
The steps to set up a persistent storage device will differ based on your infrastructure. We provide examples of how to set up storage using [vSphere,](../examples/vsphere) [NFS,](../examples/nfs) or Amazon's [EBS.](../examples/ebs)
|
||||
|
||||
### 2. Add a persistent volume that refers to the persistent storage
|
||||
|
||||
These steps describe how to set up a persistent volume at the cluster level in Kubernetes.
|
||||
|
||||
1. From the cluster view, select **Storage > Persistent Volumes**.
|
||||
|
||||
1. Click **Add Volume**.
|
||||
|
||||
1. Enter a **Name** for the persistent volume.
|
||||
|
||||
1. Select the **Volume Plugin** for the disk type or service that you're using. When adding storage to a cluster that's hosted by a cloud provider, use the cloud provider's plug-in for cloud storage. For example, if you have a Amazon EC2 cluster and you want to use cloud storage for it, you must use the `Amazon EBS Disk` volume plugin.
|
||||
|
||||
1. Enter the **Capacity** of your volume in gigabytes.
|
||||
|
||||
1. Complete the **Plugin Configuration** form. Each plugin type requires information specific to the vendor of disk type. For help regarding each plugin's form and the information that's required, refer to the plug-in's vendor documentation.
|
||||
|
||||
1. Optional: In the **Customize** form, configure the [access modes.](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes) This options sets how many nodes can access the volume, along with the node read/write permissions. The [Kubernetes Documentation](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes) includes a table that lists which access modes are supported by the plugins available.
|
||||
|
||||
1. Optional: In the **Customize** form, configure the [mount options.](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#mount-options) Each volume plugin allows you to specify additional command line options during the mounting process. Consult each plugin's vendor documentation for the mount options available.
|
||||
|
||||
1. Click **Save**.
|
||||
|
||||
**Result:** Your new persistent volume is created.
|
||||
|
||||
### 3. Add a persistent volume claim that refers to the persistent volume
|
||||
|
||||
These steps describe how to set up a PVC in the namespace where your stateful workload will be deployed.
|
||||
|
||||
1. Go to the project containing a workload that you want to add a persistent volume claim to.
|
||||
|
||||
1. Then click the **Volumes** tab and click **Add Volume**. (In versions prior to v2.3.0, click **Workloads** on the main navigation bar, then **Volumes.**)
|
||||
|
||||
1. Enter a **Name** for the volume claim.
|
||||
|
||||
1. Select the [Namespace]({{<baseurl>}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#namespaces) of the workload that you want to add the persistent storage to.
|
||||
|
||||
1. In the section called **Use an existing persistent volume,** go to the **Persistent Volume** drop-down and choose the persistent volume that you created.
|
||||
|
||||
1. **Optional:** From **Customize**, select the [Access Modes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes) that you want to use.
|
||||
|
||||
1. Click **Create.**
|
||||
|
||||
**Result:** Your PVC is created. You can now attach it to any workload in the project.
|
||||
|
||||
### 4. Mount the persistent volume claim as a volume in your workload
|
||||
|
||||
Mount PVCs to stateful workloads so that your applications can store their data.
|
||||
|
||||
You can mount PVCs during the deployment of a workload, or following workload creation.
|
||||
|
||||
The following steps describe how to assign existing storage to a new workload that is a stateful set:
|
||||
|
||||
1. From the **Project** view, go to the **Workloads** tab.
|
||||
1. Click **Deploy.**
|
||||
1. Enter a name for the workload.
|
||||
1. Next to the **Workload Type** field, click **More Options.**
|
||||
1. Click **Stateful set of 1 pod.** Optionally, configure the number of pods.
|
||||
1. Choose the namespace where the workload will be deployed.
|
||||
1. Expand the **Volumes** section and click **Add Volume > Use an existing persistent volume (claim).**.
|
||||
1. In the **Persistent Volume Claim** field, select the PVC that you created.
|
||||
1. In the **Mount Point** field, enter the path that the workload will use to access the volume.
|
||||
1. Click **Launch.**
|
||||
|
||||
**Result:** When the workload is deployed, it will make a request for the specified amount of disk space to the Kubernetes master. If a PV with the specified resources is available when the workload is deployed, the Kubernetes master will bind the PV to the PVC.
|
||||
|
||||
The following steps describe how to assign persistent storage to an existing workload:
|
||||
|
||||
1. From the **Project** view, go to the **Workloads** tab.
|
||||
1. Go to the workload that you want to add the persistent storage to. The workload type should be a stateful set. Click **Ellipsis (...) > Edit.**
|
||||
1. Expand the **Volumes** section and click **Add Volume > Use an existing persistent volume (claim).**.
|
||||
1. In the **Persistent Volume Claim** field, select the PVC that you created.
|
||||
1. In the **Mount Point** field, enter the path that the workload will use to access the volume.
|
||||
1. Click **Save.**
|
||||
|
||||
**Result:** The workload will make a request for the specified amount of disk space to the Kubernetes master. If a PV with the specified resources is available when the workload is deployed, the Kubernetes master will bind the PV to the PVC.
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: Creating Persistent Storage in Amazon's EBS
|
||||
weight: 3053
|
||||
---
|
||||
|
||||
This section describes how to set up Amazon's Elastic Block Store in EC2.
|
||||
|
||||
1. From the EC2 console, go to the **ELASTIC BLOCK STORE** section in the left panel and click **Volumes.**
|
||||
1. Click **Create Volume.**
|
||||
1. Optional: Configure the size of the volume or other options. The volume should be created in the same availability zone as the instance it will be attached to.
|
||||
1. Click **Create Volume.**
|
||||
1. Click **Close.**
|
||||
|
||||
**Result:** Persistent storage has been created.
|
||||
|
||||
For details on how to set up the newly created storage in Rancher, refer to the section on [setting up existing storage.](../attaching-existing-storage)
|
||||
@@ -10,9 +10,9 @@ Before you can use the NFS storage volume plug-in with Rancher deployments, you
|
||||
|
||||
>**Note:**
|
||||
>
|
||||
>- If you already have an NFS share, you don't need to provision a new NFS server to use the NFS volume plugin within Rancher. Instead, skip the rest of this procedure and complete [adding storage]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/).
|
||||
>- If you already have an NFS share, you don't need to provision a new NFS server to use the NFS volume plugin within Rancher. Instead, skip the rest of this procedure and complete [adding storage]({{<baseurl>}}/rancher/v2.x/en/cluster-admin/volumes-and-storage/).
|
||||
>
|
||||
>- This procedure demonstrates how to setup an NFS server using Ubuntu, although you should be able to use these instructions for other Linux distros (e.g. Debian, RHEL, Arch Linux, etc.). For official instruction on how to create an NFS server using another Linux distro, consult the distro's documentation.
|
||||
>- This procedure demonstrates how to set up an NFS server using Ubuntu, although you should be able to use these instructions for other Linux distros (e.g. Debian, RHEL, Arch Linux, etc.). For official instruction on how to create an NFS server using another Linux distro, consult the distro's documentation.
|
||||
|
||||
>**Recommended:** To simplify the process of managing firewall rules, use NFSv4.
|
||||
|
||||
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: GlusterFS Volumes
|
||||
weight: 5000
|
||||
---
|
||||
|
||||
> This section only applies to [RKE clusters.]({{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/)
|
||||
|
||||
In clusters that store data on GlusterFS volumes, you may experience an issue where pods fail to mount volumes after restarting the `kubelet`. The logging of the `kubelet` will show: `transport endpoint is not connected`. To prevent this from happening, you can configure your cluster to mount the `systemd-run` binary in the `kubelet` container. There are two requirements before you can change the cluster configuration:
|
||||
|
||||
- The node needs to have the `systemd-run` binary installed (this can be checked by using the command `which systemd-run` on each cluster node)
|
||||
- The `systemd-run` binary needs to be compatible with Debian OS on which the hyperkube image is based (this can be checked using the following command on each cluster node, replacing the image tag with the Kubernetes version you want to use)
|
||||
|
||||
```
|
||||
docker run -v /usr/bin/systemd-run:/usr/bin/systemd-run --entrypoint /usr/bin/systemd-run rancher/hyperkube:v1.16.2-rancher1 --version
|
||||
```
|
||||
|
||||
>**Note:**
|
||||
>
|
||||
>Before updating your Kubernetes YAML to mount the `systemd-run` binary, make sure the `systemd` package is installed on your cluster nodes. If this package isn't installed _before_ the bind mounts are created in your Kubernetes YAML, Docker will automatically create the directories and files on each node and will not allow the package install to succeed.
|
||||
|
||||
```
|
||||
services:
|
||||
kubelet:
|
||||
extra_binds:
|
||||
- "/usr/bin/systemd-run:/usr/bin/systemd-run"
|
||||
```
|
||||
|
||||
After the cluster has finished provisioning, you can check the `kubelet` container logging to see if the functionality is activated by looking for the following logline:
|
||||
|
||||
```
|
||||
Detected OS with systemd
|
||||
```
|
||||
@@ -0,0 +1,79 @@
|
||||
---
|
||||
title: How Persistent Storage Works
|
||||
weight: 1
|
||||
aliases:
|
||||
- /rancher/v2.x/en/tasks/workloads/add-persistent-volume-claim
|
||||
- /rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/persistent-volume-claims/
|
||||
---
|
||||
|
||||
A persistent volume (PV) is a piece of storage in the Kubernetes cluster, while a persistent volume claim (PVC) is a request for storage.
|
||||
|
||||
There are two ways to use persistent storage in Kubernetes:
|
||||
|
||||
- Use an existing persistent volume
|
||||
- Dynamically provision new persistent volumes
|
||||
|
||||
To use an existing PV, your application will need to use a PVC that is bound to a PV, and the PV should include the minimum resources that the PVC requires.
|
||||
|
||||
For dynamic storage provisioning, your application will need to use a PVC that is bound to a storage class. The storage class contains the authorization to provision new persistent volumes.
|
||||
|
||||
|
||||
|
||||
For more information, refer to the [official Kubernetes documentation on storage](https://kubernetes.io/docs/concepts/storage/volumes/)
|
||||
|
||||
This section covers the following topics:
|
||||
|
||||
- [About persistent volume claims](#about-persistent-volume-claims)
|
||||
- [PVCs are required for both new and existing persistent storage](#pvcs-are-required-for-both-new-and-existing-persistent-storage)
|
||||
- [Setting up existing storage with a PVC and PV](#setting-up-existing-storage-with-a-pvc-and-pv)
|
||||
- [Binding PVs to PVCs](#binding-pvs-to-pvcs)
|
||||
- [Provisioning new storage with a PVC and storage class](#provisioning-new-storage-with-a-pvc-and-storage-class)
|
||||
|
||||
# About Persistent Volume Claims
|
||||
|
||||
Persistent volume claims (PVCs) are objects that request storage resources from your cluster. They're similar to a voucher that your deployment can redeem for storage access. A PVC is mounted into a workloads as a volume so that the workload can claim its specified share of the persistent storage.
|
||||
|
||||
To access persistent storage, a pod must have a PVC mounted as a volume. This PVC lets your deployment application store its data in an external location, so that if a pod fails, it can be replaced with a new pod and continue accessing its data stored externally, as though an outage never occurred.
|
||||
|
||||
Each Rancher project contains a list of PVCs that you've created, available from **Resources > Workloads > Volumes.** (In versions prior to v2.3.0, the PVCs are in the **Volumes** tab.) You can reuse these PVCs when creating deployments in the future.
|
||||
|
||||
### PVCs are Required for Both New and Existing Persistent Storage
|
||||
|
||||
A PVC is required for pods to use any persistent storage, regardless of whether the workload is intended to use storage that already exists, or the workload will need to dynamically provision new storage on demand.
|
||||
|
||||
If you are setting up existing storage for a workload, the workload mounts a PVC, which refers to a PV, which corresponds to existing storage infrastructure.
|
||||
|
||||
If a workload should request new storage, the workload mounts PVC, which refers to a storage class, which has the capability to create a new PV along with its underlying storage infrastructure.
|
||||
|
||||
Rancher lets you create as many PVCs within a project as you'd like.
|
||||
|
||||
You can mount PVCs to a deployment as you create it, or later, after the deployment is running.
|
||||
|
||||
# Setting up Existing Storage with a PVC and PV
|
||||
|
||||
Your pods can store data in [volumes,](https://kubernetes.io/docs/concepts/storage/volumes/) but if the pod fails, that data is lost. To solve this issue, Kubernetes offers persistent volumes (PVs), which are Kubernetes resources that correspond to external storage disks or file systems that your pods can access. If a pod crashes, its replacement pod can access the data in persistent storage without any data loss.
|
||||
|
||||
PVs can represent a physical disk or file system that you host on premise, or a vendor-hosted storage resource, such as Amazon EBS or Azure Disk.
|
||||
|
||||
Creating a persistent volume in Rancher will not create a storage volume. It only creates a Kubernetes resource that maps to an existing volume. Therefore, before you can create a persistent volume as a Kubernetes resource, you must have storage provisioned.
|
||||
|
||||
> **Important:** PVs are created at the cluster level, which means that in a multi-tenant cluster, teams with access to separate namespaces could have access to the same PV.
|
||||
|
||||
### Binding PVs to PVCs
|
||||
|
||||
When pods are set up to use persistent storage, they mount a persistent volume claim (PVC) that is mounted the same way as any other Kubernetes volume. When each PVC is created, the Kubernetes master considers it to be a request for storage and binds it to a PV that matches the minimum resource requirements of the PVC. Not every PVC is guaranteed to be bound to a PV. According to the Kubernetes [documentation,](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)
|
||||
|
||||
> Claims will remain unbound indefinitely if a matching volume does not exist. Claims will be bound as matching volumes become available. For example, a cluster provisioned with many 50Gi PVs would not match a PVC requesting 100Gi. The PVC can be bound when a 100Gi PV is added to the cluster.
|
||||
|
||||
In other words, you can create unlimited PVCs, but they will only be bound to PVs if the Kubernetes master can find a sufficient PVs that has at least the amount of disk space required by the PVC.
|
||||
|
||||
To dynamically provision new storage, the PVC mounted in the pod would have to correspond to a storage class instead of a persistent volume.
|
||||
|
||||
# Provisioning New Storage with a PVC and Storage Class
|
||||
|
||||
Storage Classes allow you to create PVs dynamically without having to create persistent storage in an infrastructure provider first.
|
||||
|
||||
For example, if a workload is bound to a PVC and the PVC refers to an Amazon EBS Storage Class, the storage class can dynamically create an EBS volume and a corresponding PV.
|
||||
|
||||
The Kubernetes master will then bind the newly created PV to your workload's PVC, allowing your workload to use the persistent storage.
|
||||
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: iSCSI Volumes
|
||||
weight: 6000
|
||||
---
|
||||
|
||||
In [Rancher Launched Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) that store data on iSCSI volumes, you may experience an issue where kubelets fail to automatically connect with iSCSI volumes. This failure is likely due to an incompatibility issue involving the iSCSI initiator tool. You can resolve this issue by installing the iSCSI initiator tool on each of your cluster nodes.
|
||||
|
||||
Rancher Launched Kubernetes clusters storing data on iSCSI volumes leverage the [iSCSI initiator tool](http://www.open-iscsi.com/), which is embedded in the kubelet's `rancher/hyperkube` Docker image. From each kubelet (i.e., the _initiator_), the tool discovers and launches sessions with an iSCSI volume (i.e., the _target_). However, in some instances, the versions of the iSCSI initiator tool installed on the initiator and the target may not match, resulting in a connection failure.
|
||||
|
||||
If you encounter this issue, you can work around it by installing the initiator tool on each node in your cluster. You can install the iSCSI initiator tool by logging into your cluster nodes and entering one of the following commands:
|
||||
|
||||
| Platform | Package Name | Install Command |
|
||||
| ------------- | ----------------------- | -------------------------------------- |
|
||||
| Ubuntu/Debian | `open-iscsi` | `sudo apt install open-iscsi` |
|
||||
| RHEL | `iscsi-initiator-utils` | `yum install iscsi-initiator-utils -y` |
|
||||
|
||||
|
||||
After installing the initiator tool on your nodes, edit the YAML for your cluster, editing the kubelet configuration to mount the iSCSI binary and configuration, as shown in the sample below.
|
||||
|
||||
>**Note:**
|
||||
>
|
||||
>Before updating your Kubernetes YAML to mount the iSCSI binary and configuration, make sure either the `open-iscsi` (deb) or `iscsi-initiator-utils` (yum) package is installed on your cluster nodes. If this package isn't installed _before_ the bind mounts are created in your Kubernetes YAML, Docker will automatically create the directories and files on each node and will not allow the package install to succeed.
|
||||
|
||||
```
|
||||
services:
|
||||
kubelet:
|
||||
extra_binds:
|
||||
- "/etc/iscsi:/etc/iscsi"
|
||||
- "/sbin/iscsiadm:/sbin/iscsiadm"
|
||||
```
|
||||
-44
@@ -1,44 +0,0 @@
|
||||
---
|
||||
title: Persistent Volume Claims
|
||||
weight: 3052
|
||||
aliases:
|
||||
- /rancher/v2.x/en/tasks/workloads/add-persistent-volume-claim
|
||||
- /rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/persistent-volume-claims/
|
||||
---
|
||||
|
||||
_Persistent Volume Claims_ (or PVCs) are objects that request storage resources from your cluster. They're similar to a voucher that your deployment can redeem for storage access. When you create a deployment, you should usually attach a PVC so that your application can lay claim to persistent storage. This claim lets your deployment application store its data in an external location, so that if one of the application's containers fails, it can be replaced with a new container and continue accessing its data stored externally, as though an outage never occurred.
|
||||
|
||||
- Rancher lets you create as many PVCs within a project as you'd like.
|
||||
- You can mount PVCs to a deployment as you create it, or later after its running.
|
||||
- Each Rancher project contains a list of PVCs that you've created, available from **Resources > Workloads > Volumes.** (In versions prior to v2.3.0, the PVCs are in the **Volumes** tab.) You can reuse these PVCs when creating deployments in the future.
|
||||
|
||||
>**Prerequisite:**
|
||||
> You must have a pre-provisioned [persistent volume]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/#adding-a-persistent-volume) available for use, or you must have a [storage class created]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/#adding-storage-classes) that dynamically creates a volume upon request from the workload.
|
||||
|
||||
1. From the **Global** view, open the project containing a workload that you want to add a PVC to.
|
||||
|
||||
1. From the main navigation bar, choose **Resources > Workloads.** (In versions prior to v2.3.0, choose **Workloads** on the main navigation bar.) Then select the **Volumes** tab. Click **Add Volume**.
|
||||
|
||||
1. Enter a **Name** for the volume claim.
|
||||
|
||||
1. Select the [Namespace]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#namespaces) of the volume claim.
|
||||
|
||||
1. Select a **Source** option:
|
||||
|
||||
- **To dynamically provision a storage volume for the deployment:**
|
||||
|
||||
1. Choose **Use a Storage Class to provision a new persistent volume**
|
||||
|
||||
1. From the **Storage Class** drop-down, choose a pre-created storage class.
|
||||
|
||||
1. Enter a volume **Capacity**.
|
||||
|
||||
- **To use an existing persistent volume:**
|
||||
|
||||
1. Choose **Use an existing persistent volume:**
|
||||
|
||||
1. From the **Persistent Volume** drop-down, choose a pre-created persistent volume.
|
||||
|
||||
7. **Optional:** From **Customize**, select the [Access Modes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes) that you want to use.
|
||||
|
||||
**Result:** Your PVC is created. You can now attach it to any workload in the project.
|
||||
+109
@@ -0,0 +1,109 @@
|
||||
---
|
||||
title: Dynamically Provisioning New Storage in Rancher
|
||||
weight: 2
|
||||
---
|
||||
|
||||
This section describes how to provision new persistent storage for workloads in Rancher.
|
||||
|
||||
> This section assumes that you understand the Kubernetes concepts of storage classes and persistent volume claims. For more information, refer to the section on [how storage works.](../how-storage-works)
|
||||
|
||||
To provision new storage for your workloads, follow these steps:
|
||||
|
||||
1. [Add a storage class and configure it to use your storage provider.](#1-add-a-storage-class-and-configure-it-to-use-your-storage-provider)
|
||||
2. [Add a persistent volume claim that refers to the storage class.](#2-add-a-persistent-volume-claim-that-refers-to-the-storage-class)
|
||||
3. [Mount the persistent volume claim as a volume for your workload.](#3-mount-the-persistent-volume-claim-as-a-volume-for-your-workload)
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- Rancher can only dynamically provision new storage in clusters [created with RKE.]({{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/)
|
||||
- To set up persistent storage, the `Manage Volumes` [role]({{<baseurl>}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-role-reference) 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, and the cloud provider must be enabled. The cloud provider must be enabled when the cluster is provisioned. For details on enabling cloud providers, refer to [this page.]({{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/)
|
||||
- Make sure your storage provisioner is available to be enabled.
|
||||
|
||||
The following storage provisioners are enabled by default:
|
||||
|
||||
Name | Plugin
|
||||
--------|----------
|
||||
Amazon EBS Disk | `aws-ebs`
|
||||
AzureFile | `azure-file`
|
||||
AzureDisk | `azure-disk`
|
||||
Google Persistent Disk | `gce-pd`
|
||||
Longhorn | `flex-volume-longhorn`
|
||||
VMware vSphere Volume | `vsphere-volume`
|
||||
Local | `local`
|
||||
Network File System | `nfs`
|
||||
hostPath | `host-path`
|
||||
|
||||
To use a storage provisioner that is not on the above list, you will need to use a [feature flag to enable unsupported storage drivers.]({{<baseurl>}}/rancher/v2.x/en/installation/options/feature-flags/enable-not-default-storage-drivers/)
|
||||
|
||||
### 1. Add a storage class and configure it to use your storage provider
|
||||
|
||||
These steps describe how to set up a storage class at the cluster level.
|
||||
|
||||
1. Go to the cluster for which you want to dynamically provision persistent storage volumes.
|
||||
|
||||
1. From the cluster view, select `Storage > Storage Classes`. Click `Add Class`.
|
||||
|
||||
1. Enter a `Name` for your storage class.
|
||||
|
||||
1. From the `Provisioner` drop-down, select the service that you want to use to dynamically provision storage volumes. For example, if you have a Amazon EC2 cluster and you want to use cloud storage for it, use the `Amazon EBS Disk` provisioner.
|
||||
|
||||
1. From the `Parameters` section, fill out the information required for the service to dynamically provision storage volumes. Each provisioner requires different information to dynamically provision storage volumes. Consult the service's documentation for help on how to obtain this information.
|
||||
|
||||
1. Click `Save`.
|
||||
|
||||
**Result:** The storage class is available to be consumed by a PVC.
|
||||
|
||||
For full information about the storage class parameters, refer to the official [Kubernetes documentation.](https://kubernetes.io/docs/concepts/storage/storage-classes/#parameters).
|
||||
|
||||
### 2. Add a persistent volume claim that refers to the storage class
|
||||
|
||||
These steps describe how to set up a PVC in the namespace where your stateful workload will be deployed.
|
||||
|
||||
1. Go to the project containing a workload that you want to add a PVC to.
|
||||
|
||||
1. From the main navigation bar, choose **Resources > Workloads.** (In versions prior to v2.3.0, choose **Workloads** on the main navigation bar.) Then select the **Volumes** tab. Click **Add Volume**.
|
||||
|
||||
1. Enter a **Name** for the volume claim.
|
||||
|
||||
1. Select the [Namespace]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#namespaces) of the volume claim.
|
||||
|
||||
1. In the **Source** field, click **Use a Storage Class to provision a new persistent volume.**
|
||||
|
||||
1. Go to the **Storage Class** drop-down and select the storage class that you created.
|
||||
|
||||
1. Enter a volume **Capacity**.
|
||||
|
||||
1. Optional: Expand the **Customize** section and select the [Access Modes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes) that you want to use.
|
||||
|
||||
1. Click **Create.**
|
||||
|
||||
**Result:** Your PVC is created. You can now attach it to any workload in the project.
|
||||
|
||||
### 3. Mount the persistent volume claim as a volume for your workload
|
||||
|
||||
Mount PVCs to workloads so that your applications can store their data.
|
||||
|
||||
You can mount PVCs during the deployment of a workload, or following workload creation.
|
||||
|
||||
To attach the PVC to a new workload,
|
||||
|
||||
1. Create a workload as you would in [Deploying Workloads]({{<baseurl>}}/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/).
|
||||
1. For **Workload Type**, select **Stateful set of 1 pod**.
|
||||
1. Expand the **Volumes** section and click **Add Volume > Add a New Persistent Volume (Claim).**
|
||||
1. In the **Persistent Volume Claim** section, select the newly created persistent volume claim that is attached to the storage class.
|
||||
1. In the **Mount Point** field, enter the path that the workload will use to access the volume.
|
||||
1. Click **Launch.**
|
||||
|
||||
**Result:** When the workload is deployed, it will make a request for the specified amount of disk space to the Kubernetes master. If a PV with the specified resources is available when the workload is deployed, the Kubernetes master will bind the PV to the PVC.
|
||||
|
||||
To attach the PVC to an existing workload,
|
||||
|
||||
1. Go to the project that has the workload that will have the PVC attached.
|
||||
1. Go to the workload that will have persistent storage and click **Ellipsis (...) > Edit.**
|
||||
1. Expand the **Volumes** section and click **Add Volume > Add a New Persistent Volume (Claim).**
|
||||
1. In the **Persistent Volume Claim** section, select the newly created persistent volume claim that is attached to the storage class.
|
||||
1. In the **Mount Point** field, enter the path that the workload will use to access the volume.
|
||||
1. Click **Save.**
|
||||
|
||||
**Result:** The workload will make a request for the specified amount of disk space to the Kubernetes master. If a PV with the specified resources is available when the workload is deployed, the Kubernetes master will bind the PV to the PVC.
|
||||
+20
-16
@@ -17,23 +17,27 @@ Environment Variable Key | Default Value | Description
|
||||
### Types for Persistent Volume Plugins that are Enabled by Default
|
||||
Below is a list of storage types for persistent volume plugins that are enabled by default. When enabling this feature flag, any persistent volume plugins that are not on this list are considered experimental and unsupported:
|
||||
|
||||
- `aws-ebs`
|
||||
- `azure-disk`
|
||||
- `azure-file`
|
||||
- `flex-volume-longhorn`
|
||||
- `gce-pd`
|
||||
- `host-path`
|
||||
- `local`
|
||||
- `nfs`
|
||||
- `vsphere-volume`
|
||||
Name | Plugin
|
||||
--------|----------
|
||||
Amazon EBS Disk | `aws-ebs`
|
||||
AzureFile | `azure-file`
|
||||
AzureDisk | `azure-disk`
|
||||
Google Persistent Disk | `gce-pd`
|
||||
Longhorn | `flex-volume-longhorn`
|
||||
VMware vSphere Volume | `vsphere-volume`
|
||||
Local | `local`
|
||||
Network File System | `nfs`
|
||||
hostPath | `host-path`
|
||||
|
||||
### Types for StorageClass that are Enabled by Default
|
||||
Below is a list of storage types for a StorageClass that are enabled by default. When enabling this feature flag, any persistent volume plugins that are not on this list are considered experimental and unsupported:
|
||||
|
||||
- `aws-ebs`
|
||||
- `azure-disk`
|
||||
- `azure-file`
|
||||
- `gce-pd`
|
||||
- `longhorn`
|
||||
- `local`
|
||||
- `vsphere-volume`
|
||||
Name | Plugin
|
||||
--------|--------
|
||||
Amazon EBS Disk | `aws-ebs`
|
||||
AzureFile | `azure-file`
|
||||
AzureDisk | `azure-disk`
|
||||
Google Persistent Disk | `gce-pd`
|
||||
Longhorn | `flex-volume-longhorn`
|
||||
VMware vSphere Volume | `vsphere-volume`
|
||||
Local | `local`
|
||||
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 50 KiB |
Reference in New Issue
Block a user