mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-30 23:14:26 +00:00
Remove unneeded intermediate folders
This commit is contained in:
Billy Tat
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: Creating Persistent Storage in Amazon's EBS
|
||||
weight: 3053
|
||||
aliases:
|
||||
- /rancher/v2.x/en/cluster-admin/volumes-and-storage/examples/ebs/
|
||||
---
|
||||
|
||||
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.]({{<baseurl>}}/rancher/v2.5/en/cluster-admin/volumes-and-storage/attaching-existing-storage/)
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: Provisioning Storage Examples
|
||||
weight: 3053
|
||||
aliases:
|
||||
- /rancher/v2.5/en/tasks/clusters/adding-storage/provisioning-storage/
|
||||
- /rancher/v2.5/en/k8s-in-rancher/volumes-and-storage/examples/
|
||||
- /rancher/v2.x/en/cluster-admin/volumes-and-storage/examples/
|
||||
---
|
||||
|
||||
Rancher supports persistent storage with a variety of volume plugins. However, before you use any of these plugins to bind persistent storage to your workloads, you have to configure the storage itself, whether its a cloud-based solution from a service-provider or an on-prem solution that you manage yourself.
|
||||
|
||||
For your convenience, Rancher offers documentation on how to configure some of the popular storage methods:
|
||||
|
||||
- [NFS](./nfs)
|
||||
- [vSphere](./vsphere)
|
||||
- [EBS](./ebs)
|
||||
@@ -0,0 +1,69 @@
|
||||
---
|
||||
title: NFS Storage
|
||||
weight: 3054
|
||||
aliases:
|
||||
- /rancher/v2.5/en/tasks/clusters/adding-storage/provisioning-storage/nfs/
|
||||
- /rancher/v2.x/en/cluster-admin/volumes-and-storage/examples/nfs/
|
||||
---
|
||||
|
||||
Before you can use the NFS storage volume plug-in with Rancher deployments, you need to provision an NFS server.
|
||||
|
||||
>**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.5/en/cluster-admin/volumes-and-storage/).
|
||||
>
|
||||
>- 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.
|
||||
|
||||
1. Using a remote Terminal connection, log into the Ubuntu server that you intend to use for NFS storage.
|
||||
|
||||
1. Enter the following command:
|
||||
|
||||
```
|
||||
sudo apt-get install nfs-kernel-server
|
||||
```
|
||||
|
||||
1. Enter the command below, which sets the directory used for storage, along with user access rights. Modify the command if you'd like to keep storage at a different directory.
|
||||
|
||||
```
|
||||
mkdir -p /nfs && chown nobody:nogroup /nfs
|
||||
```
|
||||
- The `-p /nfs` parameter creates a directory named `nfs` at root.
|
||||
- The `chown nobody:nogroup /nfs` parameter allows all access to the storage directory.
|
||||
|
||||
1. Create an NFS exports table. This table sets the directory paths on your NFS server that are exposed to the nodes that will use the server for storage.
|
||||
|
||||
1. Open `/etc/exports` using your text editor of choice.
|
||||
1. Add the path of the `/nfs` folder that you created in step 3, along with the IP addresses of your cluster nodes. Add an entry for each IP address in your cluster. Follow each address and its accompanying parameters with a single space that is a delimiter.
|
||||
|
||||
```
|
||||
/nfs <IP_ADDRESS1>(rw,sync,no_subtree_check) <IP_ADDRESS2>(rw,sync,no_subtree_check) <IP_ADDRESS3>(rw,sync,no_subtree_check)
|
||||
```
|
||||
|
||||
**Tip:** You can replace the IP addresses with a subnet. For example: `10.212.50.12/24`
|
||||
|
||||
1. Update the NFS table by entering the following command:
|
||||
|
||||
```
|
||||
exportfs -ra
|
||||
```
|
||||
|
||||
1. Open the ports used by NFS.
|
||||
|
||||
1. To find out what ports NFS is using, enter the following command:
|
||||
|
||||
```
|
||||
rpcinfo -p | grep nfs
|
||||
```
|
||||
2. [Open the ports](https://help.ubuntu.com/lts/serverguide/firewall.html.en) that the previous command outputs. For example, the following command opens port 2049:
|
||||
|
||||
```
|
||||
sudo ufw allow 2049
|
||||
```
|
||||
|
||||
**Result:** Your NFS server is configured to be used for storage with your Rancher nodes.
|
||||
|
||||
## What's Next?
|
||||
|
||||
Within Rancher, add the NFS server as a storage volume and/or storage class. After adding the server, you can use it for storage for your deployments.
|
||||
+79
@@ -0,0 +1,79 @@
|
||||
---
|
||||
title: vSphere Storage
|
||||
weight: 3055
|
||||
aliases:
|
||||
- /rancher/v2.5/en/tasks/clusters/adding-storage/provisioning-storage/vsphere/
|
||||
- /rancher/v2.x/en/cluster-admin/volumes-and-storage/examples/vsphere/
|
||||
---
|
||||
|
||||
To provide stateful workloads with vSphere storage, we recommend creating a vSphereVolume StorageClass. This practice dynamically provisions vSphere storage when workloads request volumes through a persistent volume claim.
|
||||
|
||||
In order to dynamically provision storage in vSphere, the vSphere provider must be [enabled.]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/cloud-providers/vsphere)
|
||||
|
||||
- [Prerequisites](#prerequisites)
|
||||
- [Creating a StorageClass](#creating-a-storageclass)
|
||||
- [Creating a Workload with a vSphere Volume](#creating-a-workload-with-a-vsphere-volume)
|
||||
- [Verifying Persistence of the Volume](#verifying-persistence-of-the-volume)
|
||||
- [Why to Use StatefulSets Instead of Deployments](#why-to-use-statefulsets-instead-of-deployments)
|
||||
|
||||
### Prerequisites
|
||||
|
||||
In order to provision vSphere volumes in a cluster created with the [Rancher Kubernetes Engine (RKE)]({{< baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/), the [vSphere cloud provider]({{<baseurl>}}/rke/latest/en/config-options/cloud-providers/vsphere) must be explicitly enabled in the [cluster options]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/options/).
|
||||
|
||||
### Creating a StorageClass
|
||||
|
||||
> **Note:**
|
||||
>
|
||||
> The following steps can also be performed using the `kubectl` command line tool. See [Kubernetes documentation on persistent volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) for details.
|
||||
|
||||
1. From the Global view, open the cluster where you want to provide vSphere storage.
|
||||
2. From the main menu, select **Storage > Storage Classes**. Then click **Add Class**.
|
||||
3. Enter a **Name** for the class.
|
||||
4. Under **Provisioner**, select **VMWare vSphere Volume**.
|
||||
|
||||
{{< img "/img/rancher/vsphere-storage-class.png" "vsphere-storage-class">}}
|
||||
|
||||
5. Optionally, specify additional properties for this storage class under **Parameters**. Refer to the [vSphere storage documentation](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/storageclass.html) for details.
|
||||
5. Click **Save**.
|
||||
|
||||
### Creating a Workload with a vSphere Volume
|
||||
|
||||
1. From the cluster where you configured vSphere storage, begin creating a workload as you would in [Deploying Workloads]({{<baseurl>}}/rancher/v2.5/en/k8s-in-rancher/workloads/deploy-workloads/).
|
||||
2. For **Workload Type**, select **Stateful set of 1 pod**.
|
||||
3. Expand the **Volumes** section and click **Add Volume**.
|
||||
4. Choose **Add a new persistent volume (claim)**. This option will implicitly create the claim once you deploy the workload.
|
||||
5. Assign a **Name** for the claim, ie. `test-volume` and select the vSphere storage class created in the previous step.
|
||||
6. Enter the required **Capacity** for the volume. Then click **Define**.
|
||||
|
||||
{{< img "/img/rancher/workload-add-volume.png" "workload-add-volume">}}
|
||||
|
||||
7. Assign a path in the **Mount Point** field. This is the full path where the volume will be mounted in the container file system, e.g. `/persistent`.
|
||||
8. Click **Launch** to create the workload.
|
||||
|
||||
### Verifying Persistence of the Volume
|
||||
|
||||
1. From the context menu of the workload you just created, click **Execute Shell**.
|
||||
2. Note the directory at root where the volume has been mounted to (in this case `/persistent`).
|
||||
3. Create a file in the volume by executing the command `touch /<volumeMountPoint>/data.txt`.
|
||||
4. **Close** the shell window.
|
||||
5. Click on the name of the workload to reveal detail information.
|
||||
6. Open the context menu next to the Pod in the *Running* state.
|
||||
7. Delete the Pod by selecting **Delete**.
|
||||
8. Observe that the pod is deleted. Then a new pod is scheduled to replace it so that the workload maintains its configured scale of a single stateful pod.
|
||||
9. Once the replacement pod is running, click **Execute Shell**.
|
||||
10. Inspect the contents of the directory where the volume is mounted by entering `ls -l /<volumeMountPoint>`. Note that the file you created earlier is still present.
|
||||
|
||||
|
||||
|
||||
### Why to Use StatefulSets Instead of Deployments
|
||||
|
||||
You should always use [StatefulSets](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) for workloads consuming vSphere storage, as this resource type is designed to address a VMDK block storage caveat.
|
||||
|
||||
Since vSphere volumes are backed by VMDK block storage, they only support an [access mode](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) of `ReadWriteOnce`. This setting restricts the volume so that it can only be mounted to a single pod at a time, unless all pods consuming that volume are co-located on the same node. This behavior makes a deployment resource unusable for scaling beyond a single replica if it consumes vSphere volumes.
|
||||
|
||||
Even using a deployment resource with just a single replica may result in a deadlock situation while updating the deployment. If the updated pod is scheduled to a node different from where the existing pod lives, it will fail to start because the VMDK is still attached to the other node.
|
||||
|
||||
### Related Links
|
||||
|
||||
- [vSphere Storage for Kubernetes](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/)
|
||||
- [Kubernetes Persistent Volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)
|
||||
Reference in New Issue
Block a user